This article describes how to setup and use BGP 'AS_PATH' Attributes on Check Point Gaia OS. This article focuses on configuration of 'AS_PATH' Attributes related to BGP.
It is assumed that administrator has basic knowledge of routing in general and BGP in particular. For more details on BGP 'AS_PATH' Attributes, refer to RFC 4271 and other related BGP RFCs.
Before starting the configuration, administrator should be familiar with BGP and underlying features and their configurations such as static and dynamic routing, ClusterXL, VRRP cluster, SAM card configuration on 21000 appliances. For more details, refer to "Related documentation" section.
(II) Introduction to BGP Path Attributes
Path attributes are used by BGP to determine a path to the network. Each BGP update consists of one or more networks and set of attributes attached to them. BGP uses path attributes to provide more information about each route and to help prevent routing loops in an arbitrary topology.
Administrator can also use path attributes to determine administrative preferences. BGP collapses routes with similar path attributes into a single update for advertisement. Routes that are received in a single update are re-advertised in a single update.
BGP always propagates the best path to the peers.
There are two types of Path Attributes:
Well-known Path Attributes - must be recognized by all BGP implementations
Optional Path Attributes - may or may not be supported by the BGP implementations
Note: Well-known Attributes must be recognized by all BGP implementations.
Well-known Attributes fall into two sub-categories:
Mandatory
Discretionary
(II-1-A) Well-known Mandatory BGP Path Attributes
Mandatory attributes must be always included and carried in all BGP update messages to peers. The BGP implementation has to recognize the attribute, accept it and also advertise it to its peers.
There are three Well-known Mandatory Attributes that must be present on all updates:
ORIGIN Attribute
When a router originates a route in BGP, it sets its Origin Attribute.
The 'ORIGIN' Attribute can contain one of these three values:
IGP: Specifies the network layer reachability information (NLRI) is internal to this AS. It may have been learned via an internal routing protocol or it may be a static route or interface route.
EGP: This Origin Attribute specifies that the NLRI was learnt from EGP.
Incomplete: Set when the NLRI was learnt from some other means, such as redistributed routes into BGP. The information to determine the 'Origin' for such routes (redistributed routes) is not complete since the origin of these routes cannot be determined.
If BGP has multiple routes to a destination network, then Origin Attribute is one of the factors in determining the preferred route:
'IGP' is the highest preferred 'ORIGIN' value.
'EGP' is in the middle.
'Incomplete' is the lowest preferred 'ORIGIN' value.
AS_PATH Attribute
'AS_PATH' Attribute gives a list of AS Numbers traversed when reaching to a destination. Every BGP speaker, when advertising a route to a peer, will include its own AS number in the NLRI. The subsequent BGP speakers, who advertise this route, will add their own AS number to the 'AS_PATH', the subsequent AS numbers get prepended to the list. The end result is the 'AS_PATH' attribute is able to describe all the Autonomous Systems it has traversed, beginning with the most recent AS and ending with the originating AS.
BGP uses this mechanism to detect routing loops. Routers in an AS will reject the routes when its own AS number is detected in the route advertisement.
'AS_PATH' can be used as a decision factor in route selection. By using "AS_PATH prepending" feature, administrator can influence the routing decision of BGP speakers in other Autonomous Systems. "AS path prepending" adds the local AS number to the current location in the AS path as many times as the administrator specifies.
NEXT_HOP Attribute
'NEXT_HOP' Attribute specifies the next hop IP address to reach the destination - the following set of rules has to be followed for different BGP scenarios:
If the BGP Peers are in different Autonomous Systems, then the 'NEXT_HOP' IP address that will be sent in the update message will be the IP address of the advertising router.
If the BGP peers are in the same Autonomous Systems (iBGP Peers), and the destination network being advertised in the update message is also in the same AS, then the 'NEXT_HOP' IP address that will be sent in the update message will be the IP address of the advertising router.
If the BGP peers are in the same Autonomous Systems (iBGP Peers), and the destination network being advertised in the update message is in an external AS, then the 'NEXT_HOP' IP address that will be sent in the update message will be the IP address of the external peer router which sent the advertisement to this AS.
Discretionary Attributes are recognized by the BGP implementation, but may or may not be sent in a specific 'UPDATE' message. It is up to the discretion of BGP Implementation to send or not to send these attributes in the update messages to the BGP peers.
LOCAL_PREF
'LOCAL_PREF' (Local Preference) Attribute is only used in updates sent to the iBGP Peers. It is not passed on to the BGP peers in other Autonomous Systems.
This attribute specifies the BGP Speaker's degree of preference for an advertised route.
The higher the value of Local Preference attribute the more preferred the route is.
Note that the Local Preference will only affect the traffic leaving the AS.
ATOMIC_AGGREGATOR
'ATOMIC_AGGREGATOR' Attribute aggregates routes that are non-identical, but point to the same destination. In effect, it summarizes the routes when advertising them to the BGP peer.
When a router receives routes for the same destination, it makes the best path decision by selecting the more specific path. When aggregation is performed, the BGP Speaker starts advertising the less specific routes to its peers, but the path detail information is lost in this process. Anytime a BGP speaker does this aggregation by summarizing more specific routes into a less specific route, it has to inform its downstream BGP peers that aggregation has been done - this is done by attaching the 'ATOMIC_AGGREGATE' attribute to the update message.
When the downstream BGP speakers receive the route with 'ATOMIC_AGGREGATE' attribute set, then they cannot advertise the more specific routes for this aggregated route, and they will have to keep the 'ATOMIC_AGGREGATE' attribute attached when advertising this route to their BGP peers.
Note: Optional attributes may or may not be supported by the BGP implementations.
Optional BGP Path attributes fall into two sub-categories:
Transitive
Non-Transitive
(II-2-A) Optional Transitive BGP Path Attributes
BGP process has to accept the path, in which it is included, and should pass it on to other peers, even if these attributes are not supported. Meaning, if any optional attribute is not recognized by a BGP implementation, then BGP looks to check if the 'Transitive' flag is set. If this flag is set, then BGP implementation should accept the attribute and advertise it to its other BGP Peers.
Gaia OS supports the Optional Transitive Attribute called 'COMMUNITY':
BGP communities allow administrator to apply a common routing policy across multiple BGP peers that are in the same group.
This attribute simplifies the policy enforcement by grouping a set of BGP peers with common properties to share a common set of policy.
Routing decisions are based on the identity of the group or community. To implement this feature, administrator should map a set of communities to certain BGP local preference values. Then administrator can apply a uniform BGP configuration to the community as a whole as opposed to each router within the community. The routers in the community can accept/restrict routes that match their community values.
Range of values for the 'COMMUNITY' attribute:
from 0x0000000 to 0x0000FFFF [0 - 65535]
from 0xFFFF0000 to 0xFFFFFFFF [4294901760 - 4294967295] - are reserved
Some of the well-known communities are:
Community Attribute
Hex Value
Description
NO_EXPORT
0xFFFFFF01
Not advertised outside a BGP confederation boundary. A stand-alone Autonomous System that is not part of a confederation should be considered a confederation itself.
NO_ADVERTISE
0xFFFFFF02
Not advertised to other BGP peers.
NO_EXPORT_SUBCONFED
0xFFFFFF03
Not advertised to external BGP peers. This includes peers in other members' Autonomous Systems inside a BGP confederation.
A route can carry more than one community attribute and the BGP peer that receives such a route with multiple community attributes can act based on one, some or all of the community attributes. A router can also add or modify the community attributes before passing them to other BGP peers.
If the 'Transitive' flag is not set, then BGP implementation can quietly ignore the attribute, it does not have to accept and advertise this attribute to its other peers.
Gaia OS supports Non-transitive Attribute called 'MULTI_EXIT_DISC' ('MED'):
'Multi-exit Discriminator' (MED) values are used to help external neighbors decide which of the available entry points into an AS are preferred. A lower MED value is preferred over a higher MED value and breaks the tie between two or more preferred paths.
Note that MED is not passed beyond the receiving AS. It is only used to influence traffic between two directly connected Autonomous Systems. In addition, MED is never compared when the routes to the same destination are received from two or more different Autonomous Systems. MED only applies to the routes advertised by a single Autonomous System.
Note: A BGP session does not accept MEDs from an external peer, unless the 'Accept MED' field is set for an external peer.
The following table summarizes the configurable path attributes and their definitions:
BGP Attribute
Description
AS_PATH
Identifies the Autonomous Systems, through which routing information carried in an 'UPDATE' message passed. Components of this list can be AS_SETs or AS_SEQUENCES.
NEXT_HOP
Defines the IP address of the border router that should be used as the next hop to the destinations listed in the 'UPDATE' message.
MULTI_EXIT_DISC
Discriminates among multiple exit or entry points to the same neighboring Autonomous System. Used only on external links.
LOCAL_PREF
Determines which external route should be taken and is included in all iBGP 'UPDATE' messages. The assigned BGP speaker sends this message to BGP speakers within its own Autonomous System, but not to neighboring Autonomous Systems. Higher values of a 'LOCAL_PREF' are preferred.
ATOMIC_AGGREGATE
Specifies to a BGP speaker that a less specific route was chosen over a more specific route. The BGP speaker attaches the 'ATOMIC_AGGREGATE' attribute to the route when it reproduces it to other BGP speakers. The BGP speaker that receives this route cannot remove the 'ATOMIC_AGGREGATE' attribute or make any Network Layer Reachability Information (NLRI) of the route more specific. This attribute is used only for debugging purposes.
(III) BGP Best Path Algorithm
BGP Best Path Algorithm selects the first valid path in the list of valid paths as the current best path. It then compares the best path with the next path in the list, until BGP reaches the end of the list of valid paths.
BGP Best Path Algorithm uses the following rules to determine the best path:
Prefer the path with the highest Local Preference ('LOCAL_PREF' has a value of 100 by default).
Prefer the path with the shortest 'AS_PATH'.
Prefer the path with the lowest origin type (IGP (lowest) < EGP < INCOMPLETE (highest)).
Prefer the path with the lowest MED
Notes:
When ECMP is disabled, MED is compared only if the first (the neighboring) Autonomous System is the same in the two paths. When ECMP is enabled, this check is skipped.
Gaia OS supports MED values from 0 to 2147483646. The advertised MED should belong to this range.
Paths received with MED value of "-1" (which means "No MED") will not be compared.
Prefer eBGP over iBGP paths.
Prefer the path with the lowest IGP metric to the BGP next hop (only works for iBGP).
Prefer the route that comes from the BGP router with the lowest router ID.
(IV) Configuration
(IV-1) Configuration in VRRP cluster and ClusterXL
The following sections will cover configuration for BGP Path Attributes. The configuration of these attributes must be identical on all members of VRRP cluster or ClusterXL.
The example below explains how 'AS_PATH' can be used to selectively accept routes based on AS:
R1 is configured to redistribute network 172.20.0.0/16 to AS 100 (via R2)
R2 is configured to redistribute route 172.20.0.0/16 received from AS 50 (via R1) to AS 30 (via R3)
R3 is configured with BGP policy to accept only network 172.20.0.0/16 from AS 50 (received from R2)
Configuration
Configuration of R1:
We need to redistribute static route 172.20.0.0/16 into AS 100 via R2 using routemaps.
In Gaia Portal
Go to "Advanced Routing" - click on "Route Redistribution"
Click on "Add Redistribution From" button - select "BGP based on AS"
In "To Protocol" field, select "BGP AS 100"
In "From Protocol" field, select "Static"
In "Static Route" field, select "172.20.0.0/16"
(Optional) In "Metric" field, enter the desired value
In Clish
set routemap ToPeer-R2 id 10 on
set routemap ToPeer-R2 id 10 allow
set routemap ToPeer-R2 id 10 match network 172.20.0.0/16 all
set routemap ToPeer-R2 id 10 match protocol static
set bgp external remote-as 100 export-routemap ToPeer-R2 preference 1 family inet on
save config
Configuration of R2:
We need to redistribute route 172.20.0.0/16 received from AS 50 (via R1) to AS 30 (via R3) using routemaps.
In Gaia Portal
Step 1: Accept routes received from AS 50 (via R1):
Go to "Advanced Routing" - click on "Inbound Route Filters"
Click on "Add" button - select "Add BGP Policy (Based on AS)"
In "Add BGP Policy", enter the policy number between 512-1024
In "Action" field, select "Accept" (to accept the route from AS 50)
Administrator can also change other optional parameters:
LOCAL_PREF for this policy
LOCAL_PREF for all Inbound filter policies
Weight for all Inbound filter policies
Step 2: Redistribute static route 172.19.0.0/16 on R2 into AS 30
Go to "Advanced Routing" - click on "Route Redistribution"
Click on "Add Redistribution From" button - select "Static"
In "To Protocol" field, select "BGP AS 30"
In "Static Route" field, select "172.19.0.0/16"
(Optional) In "Metric" field, enter the desired value
Step 3: Redistribute network 172.20.0.0/16 into AS 30 via R2
Go to "Advanced Routing" - click on "Route Redistribution"
Click on "Add Redistribution From" button - select "BGP based on AS"
In "To Protocol" field, select "BGP AS 30"
In "Route", either enter a range in "Address Range" (and select "Match Type"), or select "All" for redistributing routes to AS 30
In "Action" field, select "Accept" to allow the network to redistribute (Note: Selecting "Restrict" will not redistribute the network (or network range))
(Optional) In "Metric" field, enter the desired value
In Clish
Step 1: Accept routes received from AS 50 (via R1)
set routemap FromPeer-R1 id 10 on
set routemap FromPeer-R1 id 10 allow
set bgp external remote-as 50 import-routemap FromPeer-R1 preference 1 family inet on
save config
Step 2: Redistribute static route 172.19.0.0/16 on R2 into AS 30
set routemap ToPeer-R3 id 10 on
set routemap ToPeer-R3 id 10 allow
set routemap ToPeer-R3 id 10 match network 172.19.0.0/16 all
set routemap ToPeer-R3 id 10 match protocol static
set bgp external remote-as 30 export-routemap ToPeer-R3 preference 1 family inet on
save config
Step 3: Redistribute network 172.20.0.0/16 into AS 30 via R2
set routemap ToPeer-R3 id 20 on
set routemap ToPeer-R3 id 20 allow
set routemap ToPeer-R3 id 20 match network 172.20.0.0/16 all
set routemap ToPeer-R3 id 20 match protocol bgp
set bgp external remote-as 30 export-routemap ToPeer-R3 preference 1 family inet on
save config
Configuration of R3:
We need to match AS 50 to accept routes originating from AS 50 and reject routes originating from AS 100.
In Gaia Portal
Inbound route filters policy: match AS 50 to accept routes originating from AS 50 only
Regular Expressions can be used for matching AS in the AS_PATH
Go to "Advanced Routing" - click on "Inbound Route Filters"
Click on "Add" button - select "Add BGP Policy (Based on AS-PATH)"
In "Add BGP Policy":
enter the policy number between 1-511
type the AS-Path Regular Expression (in our example, "_50")
select the Origin (in our example, "Any")
In "Action" field, select "Accept" (to accept the route with AS_PATH 50)
In Clish
set routemap FromPeer-R2 id 10 on
set routemap FromPeer-R2 id 10 allow
set routemap FromPeer-R2 id 10 match aspath-regex "_50" origin any
set routemap FromPeer-R2 id 20 on
set routemap FromPeer-R2 id 20 restrict
set routemap FromPeer-R2 id 20 match aspath-regex "100" origin any
set bgp external remote-as 100 import-routemap FromPeer-R2 preference 1 family inet on
save config
Verification
On R2 - Verify the route appears in routing table:
R2> show route bgp
Codes: C - Connected, S - Static, R - RIP, B - BGP,
O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA)
A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
U - Unreachable, i - Inactive
B 172.20.0.0/16 via 10.40.1.1, eth2, cost -1, age 10389
R2>
On R3 - Verify that route appears in routing table:
R3> show route bgp
Codes: C - Connected, S - Static, R - RIP, B - BGP,
O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA)
A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
U - Unreachable, i - Inactive
B 172.20.0.0/16 via 10.22.1.6, eth1, cost -1, age 5307
R3>
Autonomous System Path prepending helps administrator to use 'AS_PATH' as a decision factor in selection of routes in other Autonomous Systems. "AS path prepending" adds the local AS number to the current location in the AS path as many times as the administrator specifies.
In he example below:
R1 is configured to redistribute network 172.19.0.0/16 with 'AS_PATH' prepend count 2
R2 is configured to redistribute network 172.19.0.0/16 with 'AS_PATH' prepend count 10
R3 receives advertises from R1 and R2 for network 172.19.0.0/16, but because 'AS_PATH' in R2's advertisement is higher than 'AS_PATH' in R1's advertisement, R3 selects R1 as next hop gateway for 172.19.0.0/16 network
Configuration
Configuration of R3:
We need to accept routes from AS 100.
In Gaia Portal
Go to "Advanced Routing" - click on "Inbound Route Filters"
Click on "Add" button - select "Add BGP Policy (Based on AS)"
In "Add BGP Policy", enter policy number between 512-1024 and enter AS Number (in our example, AS 100)
In "Action" field, select "Accept" (to accept the route from AS 100)
Click on "Save" button
In Clish
set routemap FromPeer-R1R2 id 10 on
set routemap FromPeer-R1R2 id 10 allow
set bgp external remote-as 100 import-routemap FromPeer-R1R2 preference 1 family inet on
save config
Configuration of R2:
Configuration is performed only in Clish. We use route redistribution routemap called "ToPeer-R3".
set routemap ToPeer-R3 id 10 on
set routemap ToPeer-R3 id 10 allow
set routemap ToPeer-R3 id 10 match network 172.19.0.0/16 all
set routemap ToPeer-R3 id 10 match protocol static
set routemap ToPeer-R3 id 10 action aspath-prepend-count 10
set bgp external remote-as 30 export-routemap ToPeer-R3 preference 1 family inet on
save config
When R1 is Down, the following BGP peers are shown on R3:
R3> show bgp peers
Flags: R - Peer restarted, W - Waiting for End-Of-RIB from Peer
PeerID AS Routes ActRts State InUpds OutUpds Uptime
10.22.1.6 100 1 1 Established 1 0 00:00:21
10.30.1.6 100 0 0 Active 0 0 00:00:00
In addition, notice that R3 has received 'ASPATH' with 10 counts of AS 100:
Configuration is performed only in Clish. We use route redistribution routemap called "ToPeer-R3".
set routemap ToPeer-R3 id 10 on
set routemap ToPeer-R3 id 10 allow
set routemap ToPeer-R3 id 10 match network 172.19.0.0/16 all
set routemap ToPeer-R3 id 10 match protocol static
set routemap ToPeer-R3 id 10 action aspath-prepend-count 2
set bgp external remote-as 30 export-routemap ToPeer-R3 preference 1 family inet on
save config
When both R1 and R2 are UP and advertising network 172.19.0.0/16, the following BGP peers are shown on R3:
R3> show bgp peers
Flags: R - Peer restarted, W - Waiting for End-Of-RIB from Peer
PeerID AS Routes ActRts State InUpds OutUpds Uptime
10.22.1.6 100 1 0 Established 1 0 00:07:26
10.30.1.6 100 1 1 Established 2 0 00:06:26
R3>
In addition, notice that BGP on R3 selects R1 as next hop gateway for 172.19.0.0/16 network:
R3> show route bgp detailed
Route: 172.19/16
Nexthop: 10.30.1.6
Metric: -1
LocalPref: 100
Interface: eth2
Age: 10
Rank: 170
Weight: 0
ASPATH: (30),100,100,IGP.(Id-5)
LocalAS: 30
PeerAS: 100
Origin: IGP
OriginatorID: 10.30.1.6
R3>
R3> show route bgp
Codes: C - Connected, S - Static, R - RIP, B - BGP,
O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
U - Unreachable, i - Inactive
B 172.19.0.0/16 via 10.30.1.6, eth2, cost -1, age 28
R3>
(IV-4) Configuration of BGP Local Preference
Local Preference determines which is the preferred exit point for external route and is included in all iBGP 'UPDATE' messages. The higher the value of Local Preference attribute, the more preferred the route is. Note that Local Preference will only affect the traffic leaving the Autonomous System.
In the example below, R3 advertises two networks 172.16.22.0/24 and 172.16.40.0/24 into As 100 via R1 and R2. By applying higher value of Local Preference on R2, administrator can ensure that traffic from AS 100 to AS 30 networks will be forwarded by R2 over R2-R3 link.
Configuration
Configuration of R3:
In Gaia Portal
Step 1: Redistribute network 172.16.22.0/24 to AS 100
Go to "Advanced Routing" - click on "Route Redistribution"
Click on "Add Redistribution From" button - select "Static"
In "To Protocol" field, select "BGP AS 100"
In "Static Route" field, select "172.16.22.0.0/24"
(Optional) In "Metric" field, enter the desired value
Step 2: Redistribute static route 172.16.40.0/24 to AS 100
Go to "Advanced Routing" - click on "Route Redistribution"
Click on "Add Redistribution From" button - select "Static"
In "To Protocol" field, select "BGP AS 100"
In "Static Route" field, select "172.16.40.0/24"
(Optional) Enter the same "Metric" value as was entered for 172.16.22.0/24
In Clish
set routemap ToPeer-R1R2 id 10 on
set routemap ToPeer-R1R2 id 10 allow
set routemap ToPeer-R1R2 id 10 match network 172.16.22.0/24 all
set routemap ToPeer-R1R2 id 10 match network 172.16.40.0/24 all
set routemap ToPeer-R1R2 id 10 match protocol direct
set bgp external remote-as 100 export-routemap ToPeer-R1R2 preference 1 family inet on
save config
Configuration of R1:
We set the Local Preference value 10 to AS 30 routes.
In Gaia Portal
Go to "Advanced Routing" - click on "Inbound Route Filters"
Click on "Add" button - select "Add BGP Policy (Based on AS)"
In "Add BGP Policy", enter policy number between 512-1024, and enter AS Number (in our example, AS 30)
In "Action" field, select "Accept" (to accept the route from AS 30)
In "LOCAL_PREF" field, enter 10 (default value is 100)
In Clish
set routemap FromPeer-R3 id 10 on
set routemap FromPeer-R3 id 10 allow
set routemap FromPeer-R3 id 10 match network 172.16.22.0/24 all
set routemap FromPeer-R3 id 10 match network 172.16.40.0/24 all
set routemap FromPeer-R3 id 10 action localpref 10
set bgp external remote-as 30 import-routemap FromPeer-R3 preference 1 family inet on
save config
Configuration of R2:
We set the Local Preference value 20 to AS 30 routes.
In Gaia Portal
Go to "Advanced Routing" - click on "Inbound Route Filters"
Click on "Add" button - select "Add BGP Policy (Based on AS)"
In "Add BGP Policy", enter policy number between 512-1024, and enter the AS Number (in our example, AS 30)
In "Action" field, select "Accept" (to accept the route from AS 30)
In "LOCAL_PREF" field, enter 20 (default value is 100)
In Clish
set routemap FromPeer-R3 id 10 on
set routemap FromPeer-R3 id 10 allow
set routemap FromPeer-R3 id 10 match network 172.16.22.0/24 all
set routemap FromPeer-R3 id 10 match network 172.16.40.0/24 all
set routemap FromPeer-R3 id 10 action localpref 20
set bgp external remote-as 30 import-routemap FromPeer-R3 preference 1 family inet on
save config
Verification
On R1 - Verify that route appears in routing table:
R1> show route bgp
Codes: C - Connected, S - Static, R - RIP, B - BGP,
O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
U - Unreachable, i - Inactive
B 172.16.22.0/24 via 10.30.1.5, eth1, cost -1, age 4
B 172.16.40.0/24 via 10.30.1.5, eth1, cost -1, age 4
R1>
R1> show route bgp detailed
Route: 172.16.22/24
Nexthop: 10.30.1.5
Metric: -1
LocalPref: 10
Interface: eth1
Age: 21
Rank: 170
Weight: 0
ASPATH: (100),30,IGP.(Id-11)
LocalAS: 100
PeerAS: 30
Origin: IGP
OriginatorID: 10.22.1.5
Route: 172.16.40/24
Nexthop: 10.30.1.5
Metric: -1
LocalPref: 10
Interface: eth1
Age: 21
Rank: 170
Weight: 0
ASPATH: (100),30,IGP.(Id-11)
LocalAS: 100
PeerAS: 30
Origin: IGP
OriginatorID: 10.22.1.5
R1>
On R2 - Verify that route appears in routing table:
R2> show route bgp
Codes: C - Connected, S - Static, R - RIP, B - BGP,
O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
U - Unreachable, i - Inactive
B 172.16.22.0/24 via 10.22.1.5, eth1, cost -1, age 26
B 172.16.40.0/24 via 10.22.1.5, eth1, cost -1, age 26
R2>
R2> show route bgp detailed
Route: 172.16.22/24
Nexthop: 10.22.1.5
Metric: -1
LocalPref: 20
Interface: eth1
Age: 124
Rank: 170
Weight: 0
ASPATH: (100),30,IGP.(Id-14)
LocalAS: 100
PeerAS: 30
Origin: IGP
OriginatorID: 10.22.1.5
Route: 172.16.40/24
Nexthop: 10.22.1.5
Metric: -1
LocalPref: 20
Interface: eth1
Age: 124
Rank: 170
Weight: 0
ASPATH: (100),30,IGP.(Id-14)
LocalAS: 100
PeerAS: 30
Origin: IGP
OriginatorID: 10.22.1.5
R2>
(IV-5) Configuration of BGP Multi-Exit Discriminator
The Multi-Exit Discriminator (MED) is used to suggest to an external AS the preferred route into the Autonomous System.
In the example below:
R1 is advertising route 172.19.0.0/16 with MED 10
R2 is advertising route 172.19.0.0/16 with MED 20
Since lower value is preferred, R3 in AS 30 will select route from R1 for network 172.19.0.0/16.
Notes:
Gaia OS supports MED values from 0 to 2147483646. The advertised MED should belong to this range.
MEDs are advertised throughout the local Autonomous System.
Configuration
Configuration of R1:
We redistribute route 172.19.0.0/16 to AS 30.
In Gaia Portal
Go to "Advanced Routing" - click on "Route Redistribution"
Click on "Add Redistribution From" button - select "Static"
In "To Protocol" field, select "BGP AS 30"
In "Static Route" field, select "172.19.0.0.0/16"
In "Metric" field, enter 10
In Clish
set routemap ToPeer-R3 id 10 on
set routemap ToPeer-R3 id 10 allow
set routemap ToPeer-R3 id 10 match network 172.19.0.0/16 all
set routemap ToPeer-R3 id 10 match protocol direct
set routemap ToPeer-R3 id 10 action metric value 10
set bgp external remote-as 30 export-routemap ToPeer-R3 preference 1 family inet on
save config
Configuration of R2:
We redistribute route 172.19.0.0/16 to AS 30.
In Gaia Portal
Go to "Advanced Routing" - click on "Route Redistribution"
Click on "Add Redistribution From" button - select "Static"
In "To Protocol" field, select "BGP AS 30"
In "Static Route" field, select "172.19.0.0.0/16"
In "Metric" field, enter 20
In Clish
set routemap ToPeer-R1 id 10 on
set routemap ToPeer-R1 id 10 allow
set routemap ToPeer-R3 id 10 match network 172.19.0.0/16 all
set routemap ToPeer-R3 id 10 match protocol direct
set routemap ToPeer-R3 id 10 action metric value 20
set bgp external remote-as 30 export-routemap ToPeer-R3 preference 1 family inet on
save config
Configuration of R2:
Configuration is performed only in Clish. We import routes from AS 100. For MED to work on R3, 'accept-med' should be enabled on R3 for both BGP peers.
set routemap FromPeer-R1R2 id 10 on
set routemap FromPeer-R1R2 id 10 allow
set routemap FromPeer-R1R2 id 10 match network 172.19.0.0/16 all
set bgp external remote-as 100 peer 10.22.1.6 accept-med on
set bgp external remote-as 100 peer 10.30.1.6 accept-med on
set bgp external remote-as 100 import-routemap FromPeer-R1R2 preference 1 family inet on
save config
Verification
On R1 - Verify it is sending MED value of 10:
R1> show bgp peer 10.30.1.5 advertise
IPv4 Route MED LocalPref Nexthop Communities
172.19/16 10 0 10.30.1.6
R1>
On R2 - Verify it is sending MED value of 20:
R2> show bgp peer 10.22.1.5 advertise
IPv4 Route MED LocalPref Nexthop Communities
172.19/16 20 0 10.22.1.6
R2>
On R3 - Verify it is receiving correct MED values:
R3> show bgp peer 10.30.1.6 received
IPv4 Route MED LocalPref Nexthop Communities
172.19/16 10 N/A(EBGP) 10.30.1.6
R3>
R3> show bgp peer 10.22.1.6 received
IPv4 Route MED LocalPref Nexthop Communities
172.19/16 20 N/A(EBGP) 10.22.1.6
R3>
On R3 - Verify that route 172.19.0.0/16 is pointing to R1 (10.30.1.6):
R3> show route bgp
Codes: C - Connected, S - Static, R - RIP, B - BGP,
O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
U - Unreachable, i - Inactive
B 172.19.0.0/16 via 10.30.1.6, eth2, cost 10, age 295
R3>
(IV-6) Configuration of BGP Communities
In BGP Communities configuration, routing decisions are based on the identity of the group or community. To implement this feature, administrator should map a set of communities to certain BGP local preference values. Then administrator can apply a uniform BGP configuration to the community as a whole as opposed to each router within the community. The routers in the community can capture routes that match their community values.
BGP Communities can be configured in Clish and using the 'routemap' command.
The example below shows how BGP communities can be used to filter routes, which can later be used by peers to set specific policy for those routes.
Example of Named Communities:
Administrator needs inbound traffic from AS 100 destined to 172.16.22.0/24 to come over R2-R3 link. However, in case of failure of R2, the traffic should come on R1-R3 link. To achieve this policy, we can use 'Community Attribute'.
In this setup, two communities have been used:
Community ID (AS:Community) 30:300
Community ID (AS:Community) 30:250
Clarifications:
R3 announces network 172.16.22.0/24 with prefix community attribute 30:300 and 172.16.40.0/24 with prefix community attribute 30:250 to R1 and R2.
R1 and R2 filter network 172.16.22.0/24 with Community ID 30:300, while R1 applies 'LocalPref' of 10 and R2 applies 'LocalPref' of 20 to this network.
Since higher value of 'LocalPref' is preferred, traffic towards 172.16.22.0/24 is sent via R2, except when R2 fails, the traffic can pass via R1.
172.16.40.0/24 with prefix community attribute 30:250 is rejected as R1 and R2 do not belong to community 250.
Configuration:
Configuration of R3:
Configuration is performed only in Clish using routemaps.
set bgp communities on
set routemap ToPeers-R1R2 id 10 on
set routemap ToPeers-R1R2 id 10 allow
set routemap ToPeers-R1R2 id 10 match network 172.16.22.0/24 all
set routemap ToPeers-R1R2 id 10 match protocol direct
set routemap ToPeers-R1R2 id 10 action community 300 as 30 on
set routemap ToPeers-R1R2 id 20 on
set routemap ToPeers-R1R2 id 20 allow
set routemap ToPeers-R1R2 id 20 match network 172.16.40.0/24 all
set routemap ToPeers-R1R2 id 20 match protocol direct
set routemap ToPeers-R1R2 id 20 action community 250 as 30 on
set bgp external remote-as 100 export-routemap ToPeers-R1R2 preference 1 family inet on
save config
Configuration of R1:
We match community 300 on AS 30 and apply 'LOCAL_PREF' of 10.
In Gaia Portal
Go to "Advanced Routing" - click on "Inbound Route Filters"
Click on "Add" button - select "Add BGP Policy (Based on AS)"
In "Add BGP Policy", enter the policy number between 512-1024, and enter the AS Number (in our example, AS 30)
In "Action" field, select "Accept" (to accept the route from AS 30)
In "LOCAL_PREF" field, enter 10
In Clish
set bgp communities on
set routemap FromPeer-R3 id 10 on
set routemap FromPeer-R3 id 10 allow
set routemap FromPeer-R3 id 10 match community 300 as 30 on
set routemap FromPeer-R3 id 10 action localpref 10
set bgp external remote-as 30 import-routemap FromPeer-R3 preference 1 family inet on
save config
Configuration of R2:
We match community 300 on AS 30 and apply LOCAL_PREF of 20.
In Gaia Portal
Go to "Advanced Routing" - click on "Inbound Route Filters"
Click on "Add" button - select "Add BGP Policy (Based on AS)"
In "Add BGP Policy", enter the policy number between 512-1024, and enter the AS Number (in our example, AS 30)
In "Action" field, select "Accept" (to accept the route from AS 30)
In "LOCAL_PREF" field, enter 20
In Clish
set bgp communities on
set routemap FromPeer-R1 id 10 on
set routemap FromPeer-R1 id 10 allow
set routemap FromPeer-R1 id 10 match community 300 as 30 on
set routemap FromPeer-R1 id 10 action localpref 20
set bgp external remote-as 30 import-routemap FromPeer-R1 preference 1 family inet on
save config
Verification
Note: BGP Community Attribute is presented in format "AA:NN", where the first part ("AA") is the AS number, and the second part ("NN") is a 2-byte community number.
On R1, run these commands:
R1> show route bgp
Codes: C - Connected, S - Static, R - RIP, B - BGP,
O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
U - Unreachable, i - Inactive
B 172.16.22.0/24 via 10.30.1.5, eth1, cost -1, age 10
R1>
R1> show route bgp detailed
Route: 172.16.22/24
Nexthop: 10.30.1.5
Metric: -1
LocalPref: 10
Interface: eth1
Age: 28
Rank: 170
Weight: 0
ASPATH: (100),30,IGP.(Id-6),comm-30.300
LocalAS: 100
PeerAS: 30
Origin: IGP
OriginatorID: 10.22.1.5
Communities: 30:300
R1>
On R2, run these commands:
R2> show route all
Codes: C - Connected, S - Static, R - RIP, B - BGP,
O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
U - Unreachable, i - Inactive
B 172.16.22.0/24 via 10.22.1.5, eth1, cost -1, age 4347
R2>
R2> show route bgp detailed
Route: 172.16.22/24
Nexthop: 10.22.1.5
Metric: -1
LocalPref: 20
Interface: eth1
Age: 5901
Rank: 170
Weight: 0
ASPATH: (100),30,IGP.(Id-9),comm-30.300
LocalAS: 100
PeerAS: 30
Origin: IGP
OriginatorID: 10.22.1.5
Communities: 30:300
R2>
Traffic from AS 100 to AS 30 will go via R2 over R2-R3 link. However, if R2 fails, the traffic will flow via R1 over R1-R3 link.
