BGP4 Case Studies/Tutorial Section 2
--------------------------------------------------------------------------------
As_path Attribute
Whenever a route update passes through an AS, the AS number is prepended to that update. The AS_path attribute is actually the list of AS numbers that a route has traversed in order to reach a destination. An AS-SET is an ordered mathematical set {} of all the ASs that have been traversed. An example of AS-SET is given later.
In the above example, network 190.10.0.0 is advertised by RTB in AS200, when that route traverses AS300 and RTC will append its own AS number to it. So when 190.10.0.0 reaches RTA it will have two AS numbers attached to it: first 200 then 300. So as far as RTA is concerned the path to reach 190.10.0.0 is (300,200).
The same applies for 170.10.0.0 and 180.10.0.0. RTB will have to take path (300,100) i.e. traverse AS300 and then AS100 in order to reach 170.10.0.0. RTC will have to traverse path (200) in order to reach 190.10.0.0 and path (100) in order to reach 170.10.0.0.
Index
--------------------------------------------------------------------------------
Origin Attribute
The origin is a mandatory attribute that defines the origin of the path information. The origin attribute can assume three values:
IGP: Network Layer Reachability Information (NLRI) is interior to the originating AS. This normally happens when we use the bgp network command or when IGP is redistributed into BGP, then the origin of the path info will be IGP. This is indicated with an "i" in the BGP table.
EGP: NLRI is learned via EGP (Exterior Gateway Protocol). This is
indicated with an "e" in the BGP table.
INCOMPLETE: NLRI is unknown or learned via some other means. This usually occurs when we redistribute a static route into BGP and the origin of the route will be incomplete. This is indicated with an "?" in the BGP table.
Example:
RTA#
router bgp 100
neighbor 190.10.50.1 remote-as 100
neighbor 170.10.20.2 remote-as 300
network 150.10.0.0
redistribute static
ip route 190.10.0.0 255.255.0.0 null0
RTB#
router bgp 100
neighbor 150.10.30.1 remote-as 100
network 190.10.50.0
RTE#
router bgp 300
neighbor 170.10.20.1 remote-as 100
network 170.10.0.0
RTA will reach 170.10.0.0 via: 300 i (which means the next AS path is 300 and the origin of the route is IGP).
RTA will also reach 190.10.50.0 via: i (which means, the entry is in the same AS and the origin is IGP).
RTE will reach 150.10.0.0 via: 100 i (the next AS is 100 and the origin is IGP).
RTE will also reach 190.10.0.0 via: 100 ? (the next AS is 100 and the
origin is incomplete "?", coming from a static route).
Index
--------------------------------------------------------------------------------
BGP Nexthop Attribute
The BGP nexthop attribute is the next hop IP address that is going to be used to reach a certain destination.
For EBGP, the next hop is always the IP address of the neighbor specified in the neighbor command. In the above example, RTC will advertise 170.10.0.0 to RTA with a next hop of 170.10.20.2 and RTA will advertise 150.10.0.0 to RTC with a next hop of 170.10.20.1. For IBGP, the protocol states that the next hop advertised by EBGP should be carried into IBGP. Because of that rule, RTA will advertise 170.10.0.0 to its IBGP peer RTB with a next hop of 170.10.20.2. So according to RTB, the next hop to reach 170.10.0.0 is 170.10.20.2 and NOT 150.10.30.1.
You should make sure that RTB can reach 170.10.20.2 via IGP, otherwise RTB will drop packets destined to 170.10.0.0 because the next hop address would be inaccessible. For example, if RTB is running IGRP you could also run igrp on RTA network 170.10.0.0. You would want to make IGRP passive on the link to RTC so BGP is only exchanged.
Example:
RTA#
router bgp 100
neighbor 170.10.20.2 remote-as 300
neighbor 150.10.50.1 remote-as 100
network 150.10.0.0
RTB#
router bgp 100
neighbor 150.10.30.1 remote-as 100
RTC#
router bgp 300
neighbor 170.10.20.1 remote-as 100
network 170.10.0.0
*RTC will advertise 170.10.0.0 to RTA with a NextHop 170.10.20.2
*RTA will advertise 170.10.0.0 to RTB with a NextHop= 170.10.20.2
(The external NextHop via EBGP is sent via IBGP)
Special care should be taken when dealing with multiaccess and NBMA networks as described in the following sections.
Index
--------------------------------------------------------------------------------
BGP Nexthop (Multiaccess Networks)
The following example shows how the nexthop will behave on a multiaccess network such as ethernet.
Assume that RTC and RTD in AS300 are running OSPF. RTC is running BGP with RTA. RTC can reach network 180.20.0.0 via 170.10.20.3. When RTC sends a BGP update to RTA regarding 180.20.0.0 it will use as next hop 170.10.20.3 and not its own IP address (170.10.20.2). This is because the network between RTA, RTC and RTD is a multiaccess network and it makes more sense for RTA to use RTD as a next hop to reach 180.20.0.0 rather than making an extra hop via RTC.
*RTC will advertise 180.20.0.0 to RTA with a NextHop 170.10.20.3.
If the common media to RTA, RTC and RTD was not multiaccess, but NBMA (Non Broadcast Media Access) then further complications will occur.
Index
--------------------------------------------------------------------------------
BGP Nexthop (NBMA)
If the common media as you see in the shaded area above is a frame relay or any NBMA cloud then the exact behavior will occur as if we were connected via ethernet. RTC will advertise 180.20.0.0 to RTA with a next hop of 170.10.20.3.
The problem is that RTA does not have a direct PVC to RTD, and cannot reach the next hop. In this case routing will fail.
In order to remedy this situation a command called NextHopself is created.
Index
--------------------------------------------------------------------------------
Nexthopself
Because of certain situations with the nexthop as we saw in the previous example, a command called next-hop-self is created. The syntax is:
neighbor {ip-addresspeer-group-name} next-hop-self
The next-hop-self command will allow us to force BGP to use a specified IP address as the next hop rather than letting the protocol choose the nexthop.
In the previous example the following will solve our problem:
RTC#
router bgp 300
neighbor 170.10.20.1 remote-as 100
neighbor 170.10.20.1 next-hop-self
RTC will advertise 180.20.0.0 with a NextHop = 170.10.20.2
Index
--------------------------------------------------------------------------------
BGP Backdoor
Consider the above diagram, RTA and RTC are running EBGP and RTB and RTC are running EBGP. RTA and RTB are running some kind of IGP (RIP, IGRP, etc.). By definition, EBGP updates have a distance of 20 which is lower than the IGP distances. Default distance is 120 for RIP, 100 for IGRP, 90 for EIGRP and 110 for OSPF.
RTA will receive updates about 160.10.0.0 via two routing protocols:
EBGP with a distance of 20 and IGP with a distance higher than 20.
By default, BGP has the following distances, but that could be changed by the distance command:
distance bgp external-distance internal-distance local-distance
external-distance:20
internal-distance:200
local-distance:200
RTA will pick EBGP via RTC because of the lower distance.
If we want RTA to learn about 160.10.0.0 via RTB (IGP), then we have two options:
1- Change EBGP's external distance or IGP's distance which is NOT recommended.
2- Use BGP backdoor
BGP backdoor will make the IGP route, the preferred route.
Use the following command: network address backdoor.
The configured network is the network that we would like to reach via IGP. For BGP this network will be treated as a locally assigned network except it will not be advertised in BGP updates.
Example:
RTA#
router eigrp 10
network 160.10.0.0
router bgp 100
neighbor 2.2.2.1 remote-as 300
network 160.10.0.0 backdoor
Network 160.10.0.0 will be treated as a local entry but will not be advertised as a normal network entry would.
RTA will learn 160.10.0.0 from RTB via EIGRP with distance 90, and will also learn it from RTC via EBGP with distance 20. Normally EBGP will be preferred, but because of the backdoor command EIGRP will be preferred.
Index
--------------------------------------------------------------------------------
Synchronization
Before we discuss synchronization let us look at the following scenario. RTC in AS300 is sending updates about 170.10.0.0. RTA and RTB are running IBGP, so RTB will get the update and will be able to reach 170.10.0.0 via next hop 2.2.2.1 (remember that the next hop is carried via IBGP). In order to reach the next hop, RTB will have to send the traffic to RTE.
Assume that RTA has not redistributed network 170.10.0.0 into IGP, so at this point RTE has no idea that 170.10.0.0 even exists.
If RTB starts advertising to AS400 that he can reach 170.10.0.0 then traffic coming from RTD to RTB with destination 170.10.0.0 will flow in and get dropped at RTE.
Synchronization states: If your autonomous system is passing traffic from another AS to a third AS, BGP should not advertise a route before all routers in your AS have learned about the route via IGP.
BGP will wait until IGP has propagated the route within the AS and then will advertise it to external peers. This is called synchronization.
In the above example, RTB will wait to hear about 170.10.0.0 via IGP before it starts sending the update to RTD. We can fool RTB into thinking that IGP has propagated the information by adding a static route in RTB pointing to 170.10.0.0. Care should be taken to make sure that other routers can reach 170.10.0.0 otherwise we will have a problem reaching that network.
Disabling synchronization
In some cases you do not need synchronization. If you will not be passing traffic from a different autonomous system through your AS, or if all routers in your AS will be running BGP, you can disable synchronization. Disabling this feature can allow you to carry fewer routes in your IGP and allow BGP to converge more quickly.
Disabling synchronization is not automatic, if you have all your routers in the AS running BGP and you are not running any IGP, the router has no way of knowing that, and your router will be waiting forever for an IGP update about a certain route before sending it to external peers. You have to disable synchronization manually in this case for routing to work correctly:
router bgp 100
no synchronization.
(Make sure you do a clear ip bgp address to reset the session)
Example:
RTB#
router bgp 100
network 150.10.0.0
neighbor 1.1.1.2 remote-as 400
neighbor 3.3.3.3 remote-as 100
no synchronization (RTB will put 170.10.0.0 in its ip routing table and will advertise it to RTD even if it does not have an IGP path to 170.10.0.0)
RTD#
router bgp 400
neighbor 1.1.1.1 remote-as 100
network 175.10.0.0
RTA#
router bgp 100
network 150.10.0.0
neighbor 3.3.3.4 remote-as 100
Index
--------------------------------------------------------------------------------
Weight Attribute
The weight attribute is a Cisco defined attribute. The weight is used for a best path selection process. The weight is assigned locally to the router. It is a value that only makes sense to the specific router and which is not propagated or carried through any of the route updates. A weight can be a number from 0 to 65535. Paths that the router originates have a weight of 32768 by default and other paths have a weight of zero.
Routes with a higher weight are preferred when multiple routes exist to the same destination. Let us study the above example. RTA has learned about network 175.10.0.0 from AS4 and will propagate the update to RTC. RTB has also learned about network 175.10.0.0 from AS4 and will propagate it to RTC. RTC has now two ways for reaching 175.10.0.0 and has to decide which way to go. If on RTC we can set the weight of the updates coming from RTA to be higher than the weight of updates coming from RTB, then we will force RTC to use RTA as a next hop to reach 175.10.0.0. This is achieved by using multiple methods:
1- Using the neighbor command
neighbor {ip-addresspeer-group} weight weight
2- Using AS path access-lists
ip as-path access-list access-list-number {permitdeny} as-regular-expression
neighbor ip-address filter-list access-list-number weight weight
3-Using route-maps
example:
RTC#
router bgp 300
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 weight 200 (route to 175.10.0.0 from RTA will have 200 weight)
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 weight 100 (route to 175.10.0.0 from RTB will have 100 weight)
*Routes with higher weight are preferred when multiple routes exist to the same destination. RTA will be preferred as the next hop.
The same outcome can be achieved via ip as-path and filter lists.
RTC#
router bgp 300
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 filter-list 5 weight 200
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 filter-list 6 weight 100
...
ip as-path access-list 5 permit ^100$ (this will only permit path 100)
ip as-path access-list 6 permit ^200$
...
The same outcome as above can be achieved by using routmaps.
RTC#
router bgp 300
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 route-map setweightin in
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 route-map setweightin in
...
ip as-path access-list 5 permit ^100$
...
route-map setweightin permit 10
match as-path 5
set weight 200
(anything that applies to access-list 5, i.e. packets from AS100, would have weight 200)
route-map setweightin permit 20
set weight 100
(anything else would have weight 100)
Index
--------------------------------------------------------------------------------
Local Preference Attribute
Local preference is an indication to the AS about which path is preferred to exit the AS in order to reach a certain network. A path with a higher local preference is more preferred. The default value for local preference is 100.
Unlike the weight attribute which is only relevant to the local router, local preference is an attribute that is exchanged among routers in the same AS.
Local preference is set via the "bgp default local-preference <>" command or with route-maps as will be demonstrated in the following example:
The bgp default local-preference command will set the local preference on the updates out of the router going to peers in the same AS. In the above diagram, AS256 is receiving updates about 170.10.0.0 from two different sides of the organization. Local preference will help us determine which way to exit AS256 in order to reach that network. Let us assume that RTD is the preferred exit point. The following configuration will set the local preference for updates coming from AS300 to 200 and those coming from AS100 to 150.
RTC#
router bgp 256
neighbor 1.1.1.1 remote-as 100
neighbor 128.213.11.2 remote-as 256
bgp default local-preference 150
RTD#
router bgp 256
neighbor 3.3.3.4 remote-as 300
neighbor 128.213.11.1 remote-as 256
bgp default local-preference 200
In the above configuration RTC will set the local preference of all updates to 150. The same RTD will set the local preference of all updates to 200. Since local preference is exchanged within AS256, both RTC and RTD will realize that network 170.10.0.0 has a higher local preference when coming from AS300 rather than when coming from AS100. All traffic in AS256 addressed to that network will be sent to RTD as an exit point.
More flexibility is provided by using route maps. In the above example, all updates received by RTD will be tagged with local preference 200 when they reach RTD. This means that updates coming from AS34 will also be tagged with the local preference of 200. This might not be needed. This is why we can use route maps to specify what specific updates need to be tagged with a specific local preference as shown below:
RTD#
router bgp 256
neighbor 3.3.3.4 remote-as 300
neighbor 3.3.3.4 setlocalin in
neighbor 128.213.11.1 remote-as 256
....
ip as-path 7 permit ^300$
...
route-map setlocalin permit 10
match as-path 7
set local-preference 400
route-map setlocalin permit 20
set local-preference 150
With this configuration, any update coming from AS300 will be set with a local preference of 200. Any other updates such as those coming from AS34 will be set with a value of 150.
Index
--------------------------------------------------------------------------------
Metric Attribute
The metric attribute which is also called Multi_exit_discriminator, MED (BGP4) or Inter-As (BGP3) is a hint to external neighbors about the preferred path into an AS. This is a dynamic way to influence another AS on which way to choose in order to reach a certain route given that we have multiple entry points into that AS. A lower value of a metric is more preferred.
Unlike local preference, metric is exchanged between ASs. A metric is carried into an AS but does not leave the AS. When an update enters the AS with a certain metric, that metric is used for decision making inside the AS. When the same update is passed on to a third AS, that metric will be set back to 0 as shown in the above diagram. The Metric default value is 0.
Unless otherwise specified, a router will compare metrics for paths from neighbors in the same AS. In order for the router to compare metrics from neighbors coming from different ASs the special configuration command "bgp always-compare-med" should be configured on the router.
In the above diagram, AS100 is getting information about network 180.10.0.0 via three different routers: RTC, RTD and RTB. RTC and RTD are in AS300 and RTB is in AS400.
Assume that we have set the metric coming from RTC to 120, the metric coming from RTD to 200 and the metric coming from RTB to 50. Given that by default a router compares metrics coming from neighbors in the same AS, RTA can only compare the metric coming from RTC to the metric coming from RTD and will pick RTC as the best next hop because 120 is less than 200. When RTA gets an update from RTB with metric 50, he can not compare it to 120 because RTC and RTB are in different ASs (RTA has to choose based on some other attributes).
In order to force RTA to compare the metrics we have to add
bgp always-compare-med to RTA. This is illustrated in the configs below:
RTA#
router bgp 100
neighbor 2.2.2.1 remote-as 300
neighbor 3.3.3.3 remote-as 300
neighbor 4.4.4.3 remote-as 400
....
RTC#
router bgp 300
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-map setmetricout out
neighbor 1.1.1.2 remote-as 300
route-map setmetricout permit 10
set metric 120
RTD#
router bgp 300
neighbor 3.3.3.2 remote-as 100
neighbor 3.3.3.2 route-map setmetricout out
neighbor 1.1.1.1 remote-as 300
route-map setmetricout permit 10
set metric 200
RTB#
router bgp 400
neighbor 4.4.4.4 remote-as 100
neighbor 4.4.4.4 route-map setmetricout out
route-map setmetricout permit 10
set metric 50
With the above configs, RTA will pick RTC as next hop, considering all other attributes are the same. In order to have RTB included in the metric comparison, we have to configure RTA as follows:
RTA#
router bgp 100
neighbor 2.2.21 remote-as 300
neighbor 3.3.3.3 remote-as 300
neighbor 4.4.4.3 remote-as 400
bgp always-compare-med
In this case RTA will pick RTB as the best next hop in order to reach network 180.10.0.0.
Metric can also be set while redistributing routes into BGP, the command is:
default-metric number
Assume in the above example that RTB is injecting a network via static into AS100 then the following configs:
RTB#
router bgp 400
redistribute static
default-metric 50
ip route 180.10.0.0 255.255.0.0 null 0
will cause RTB to send out 180.10.0.0 with a metric of 50.
Index
--------------------------------------------------------------------------------
Community Attribute
The community attribute is a transitive, optional attribute in the range 0 to 4,294,967,200. The community attribute is a way to group destinations in a certain community and apply routing decisions (accept, prefer, redistribute, etc.) according to those communities.
We can use route maps to set the community attributes. The route map set command has the following syntax:
set community community-number [additive]
A few predefined well known communities (community-number) are:
-no-export (Do not advertise to EBGP peers)
-no-advertise (Do not advertise this route to any peer)
-internet (Advertise this route to the internet community, any router belongs to it)
An example of route maps where community is set is:
route-map communitymap
match ip address 1
set community no-advertise
or
route-map setcommunity
match as-path 1
set community 200 additive
If the additive keyword is not set, 200 will replace any old community that already exits; if we use the keyword additive then the 200 will be added to the community.
Even if we set the community attribute, this attribute will not be sent to neighbors by default.
In order to send the attribute to our neighbor we have to use the following:
neighbor {ip-addresspeer-group-name} send-community
Example:
RTA#
router bgp 100
neighbor 3.3.3.3 remote-as 300
neighbor 3.3.3.3 send-community
neighbor 3.3.3.3 route-map setcommunity out
(End of section 2)
Index
--------------------------------------------------------------------------------
No comments:
Post a Comment