Policy Control

Policy Control Using BGP Attributes

Most commonly used BGP attributes:

  • LOCAL_PREF
  • AS_PATH
  • MED
  • ORIGIN
  • NEXT_HOP
  • WEIGHT

BGP picks a best path for a destination IP prefix from multiple paths and then installs it in the routing table. This best path forwards IP traffic. By default, BGP does a decent job of choosing the appropriate path; however, with the huge size of router-based networks, it is essential that BGP path selection be managed by network operators to have a BGP policy that optimally uses the network. BGP attributes are often manipulated to manage BGP networks.

LOCAL_PREF Attribute

  • Local_Pref in BGP updates defines a preference of one exit point within an AS over others to reach the originator of the route.
  • It has no significance outside an AS; therefore, it affects only the outgoing traffic from an AS.
  • Not advertised to EBGP neighbors, only propagated to IBGP peers.
  • Higher is better.

Because LOCAL_PREF is advertised to all IBGP neighbors, R3, R4, and R5 receive 131.108.1.0/24 with a LOCAL_PREF of 200 from R2.

  • R3 has an additional path for 131.108.1.0/24 from R1, and its LOCAL_PREF was unchanged and is defaulted to 100.
  • Now, R3 must decide between two paths for 131.108.1.0/24, one from R1 and the other from R2. The path with the higher LOCAL_PREF wins; therefore, the path from R2 will win and get installed in the routing table for R3.
  • Similarly, R4 and R5 will choose R2 to reach 131.108.1.0/24.
  • R4 and R5 are receiving only one path for 131.108.1.0/24, and that is from R2.

When R6 in AS 111 is sending traffic for 131.108.1.1, it exits AS 110 from R2 because AS 110 has preferred R2 as an exit point for 131.108.1.0/24.

				
					// R2
access-list 1 permit 131.108.1.0
access-list 2 permit any
!
route-map SET_LOCAL_PREF permit 10
 match ip address 1
 set local-preference 200
route-map SET_LOCAL_PREF permit 20
 match ip address 2
!
router bgp 110
 neighbor 1.1.1.1 remote-as 109
 neighbor 1.1.1.1 route-map SET_LOCAL_PREF in
				
			

MED Attribute

  • MED in BGP updates defines a method to choose among multiple exit points in the same neighboring AS.
  • MED is a nontransitive attribute of BGP; therefore, if it is received from an EBGP neighbor, it is sent to an IBGP neighbor, but it does not get propagated to other EBGP neighbors.
  • A lower MED value is preferred when comparing the two updates.
  • R1 has two links to AS 110.
  • The link between R1 and R2 has a higher bandwidth than the link between R1 and R3. Therefore, R1 might decide that all traffic destined to 131.108.1.0/24 must exit AS 110 through the R1–R2 link, not the R1–R3 link.

A lower MED value is preferred when comparing the two updates. In Cisco IOS, MED is compared only between updates from within the same AS. To compare MED values in updates from different autonomous systems, Cisco IOS must be configured with bgp always-compare-med in BGP subcommands.

The AS 109 policy dictates that all traffic destined for 131.108.1.0/24 should come through the R1–R2 link and that the R1–R3 link should be used as a backup in case the R1–R2 link goes down.

With this configuration, the prefix 131.108.1.0/24 MED field looks like the following in R2 and R3:

  • In R2, MED = 10 for the path from R1.
  • In R3, MED = 10 for the path from R2; MED = 20 for the path from R1.

R2 has only one path for 131.108.1.0/24, whereas R3 has two. This is because R2 is advertising its best route to all its IBGP neighbors (R3, R4, and R5). R3’s best path for 131.108.1.0/24 is from R2, so R3 will not advertise its best path back to R2 because that path originally came from R2.

MED is a nontransitive attribute and will not be advertised to AS 111 by AS 110. R5 and R6 might configure to advertise the same or different MED to R6 in AS 111, but the MED value originally set by R1 in AS 109 will not be kept.

				
					// R1
access-list 1 permit 131.108.1.0
access-list 2 permit any
!
route-map SEND_LOWER_MEDpermit 10
 match ip address 1
 set metric 10
route-map SEND_LOWER_MED permit 20
 match ip address 2
!
route-map SEND_HIGHER_MED permit 10
 match ip address 1
 set metric 20
route-map SEND_HIGHER_MED permit 20
 match ip address 2
!
router bgp 109
 neighbor 1.1.7.2 remote-as 110
 neighbor 1.1.7.2 route-map SEND_LOWER_MED out
 neighbor 1.1.2.3 remote-as 110
 neighbor 1.1.2.3 route-map SEND_HIGHER_MED out
				
			

The MED attribute plays a significant role in influencing incoming traffic in case multiple connections exist between the same AS. It is most commonly seen in enterprise BGP networks where routers in AS 109 are dual homed to an ISP in AS 110.

In Cisco IOS, MED is compared only between updates from within the same AS. R3 compared MEDs because 131.108.1.0/24 came from the same AS 109. To compare MED values in updates from different autonomous systems, Cisco IOS must be configured with bgp always-compare-med in BGP subcommands.

AS 109 has two regional connections, east and west, with AS 110. AS 109 needs to make sure that regional traffic destined to AS 109 regions must enter through their respective regional links. This can be accomplished by defining the following:

  1. AS 109 must advertise the proper MEDs
  2. AS 110 must honor AS 109 MED announcements.

The first task is achieved through the configuration shown above. The second task is more of a peering agreement between AS 109 and AS 110. Honoring MED means that AS 110 must accept the MED announcements from AS 109 and will not overwrite them with its own policies. Honoring MED is typically a two-way relationship: AS 110 honors AS 109 MED only if AS 109 does the same for AS 110 MED. By honoring the MED, AS 110 carries traffic destined to AS 109 through its backbone and exits at the closest point in AS 109. If AS 110 decides not to honor AS 109 MED, it will have its own policies to carry traffic for AS 109. Instead of an optimal exit point, AS 110 might choose the closest exit point.

Traffic sourcing behind R2 destined for 140.1.1.1 will traverse AS 110 backbone routers because they have all received the proper MED announcement from AS 109 as the MED is propagated within the IBGP cloud. This traffic exits AS 110 at R5, the exit point closest to the destination, 141.1.1.1. Similarly, traffic behind R4 destined for 131.108.1.1 exits at R3.

In some situations, ISPs do not honor each other’s MEDs. In this case, AS 110 might dump all traffic destined to AS 109 to its closest exit point and not carry its traffic through the backbone. Such an example can arise when traffic destined to 140.1.1.1 from sources behind R2 carries over to R3 and exits to R1; AS 109 must carry that traffic across its backbone to reach R6 in the east region. Proper usage of the MED attribute can also be called cold potato routing.

AS_PATH Attribute

  • The AS_PATH attribute defines the list of autonomous systems through which a BGP update has traversed.
  • It is a mandatory attribute that BGP updates must carry, and it is changed only when a BGP update is sent to an EBGP neighbor.
  • A smaller AS_PATH length is preferred when comparing the two BGP updates.
  • AS 109 is advertising 131.108.1.0/24 to its EBGP neighbor in AS 110.
  • R1 prepends its AS number 109 in that field.
  • R2 advertises this update to its IBGP speakers R3 and R4 but does not change the AS_PATH.
  • R3 and R4 prepend their AS 110 when advertising this prefix to AS 111.
  • When a router receives a BGP update that has an AS_PATH attribute that lists its own AS in it, that update is considered looped and is dropped. This mechanism is used in BGP to detect routing loops.
  • A smaller AS_PATH length is preferred when comparing the two BGP updates.

R3 has two paths for this prefix, one from R1 and the other from R2. The best-path calculation rule will tie because the AS_PATH length is identical, at 1. BGP Best-path calculation moves down to next tie-breaking criteria.

  1. One approach is to use MEDs so that R1 advertises a lower MED when advertising prefix 131.108.1.0/24 to R2 and advertises a higher MED to R3.
  2. Another approach is to make the AS_PATH length longer for the advertisement from R1 to R3 for this prefix. Because the BGP best-path calculation rule looks at AS_PATH length as the tie-breaker rule between multiple paths, the R1–R3 path will lose and the R1–R2 path will win and be installed in the routing table.

By observing the AS_PATH, a BGP speaker can find out which AS originated the prefix and how many autonomous systems this prefix has traversed. The right-most AS is the originator of the prefix and the left-most is the neighboring AS that has announced the prefix. The middle autonomous systems in the AS_PATH are the intermediate autonomous systems that the prefix has traversed. Such an order of AS_PATH is called an AS_SEQUENCE, in which AS_PATH sequence is in the order that it has maintained.

				
					// R1
access-list 1 permit 131.108.1.0
access-list 2 permit any
!
router bgp 109
 network 131.108.1.0 mask 255.255.255.0
 neighbor 1.1.2.3 remote-as 110
 neighbor 1.1.2.3 route-map AS_PREPEND out
 neighbor 1.1.7.2 remote-as 110
!
route-map AS_PREPEND permit 10
 match ip address 1
 set as-path prepend 109 109
route-map AS_PREPEND permit 20
 match ip address 2
				
			

NEXT_HOP Attribute

  • The IP address of the border router should be used as a next hop to reach prefixes propagated by that border router.
  • This could be an IP address that belongs in the same AS or it could be an external IP address that shares the same subnet as that on a border router.
  • NEXT_HOP is typically learned through an Interior Gateway Protocol (IGP), such as OSPF or IS-IS, and the cost to reach the NEXT_HOP often plays an important rule in calculating the best path.
  • The NEXT_HOP for 131.108.1.0/24 is the IP address of the R1 subnet that connects to R2.
  • The NEXT_HOP attribute is not changed throughout the AS.
  • Cisco IOS allows the user to change the NEXT_HOP to be the IP address of an internal border router instead of an external address, such as Loopback of R2. This is done by using the neighbor IBGP-Neighbor-IP-address next-hop-self command in BGP.
  • By changing NEXT_HOP from an external address to the loopback, routers carry one less subnet in the routing table. Because loopback IP addresses are carried in IGP, no additional work is needed to propagate the NEXT_HOP.

ORIGIN Attribute

  • The originator of the BGP update generates the ORIGIN attribute and defines how the original path was originated.
  • Each prefix has an ORIGIN attribute. Routers, which receive updates with the ORIGIN attribute, should forward the ORIGIN attribute to all BGP neighbors unchanged.

WEIGHT Attribute

  • WEIGHT is a 4-byte integer number and is not a BGP attribute because it is not defined in RFC 1771.
  • It is a Cisco proprietary attribute that has priority over all other BGP attributes when doing the best-path calculation in Cisco IOS Software.
  • WEIGHT is not shared with any BGP neighbor because it has local significance in the router and because the neighboring router might not understand Cisco’s proprietary attribute.
  • Because WEIGHT has local significance in the router, it does not affect neighboring routers’ BGP policy, as in the case of LOCAL_PREF and MED that gets shared among other routers in the AS, and all the AS is affected when using those attributes.
  • AS 109 has three exit points and connects to three different ISPs.
  • AS 109 has low-bandwidth links in its Core, so therefore AS 109 would like to have BGP policy that makes minimal use of the Core.
  • This can happen if each exit router chooses all the prefixes from its corresponding connected ISP as the best route.
  • In Cisco IOS, if R1, R2, and R3 assign WEIGHT to all the prefixes learned from ISP1, ISP2, and ISP3, respectively, R1, R2, and R3 choose ISP1, ISP2, and ISP3, respectively, for all Internet routes.
  • Traffic originated from the source connected to R1 always exits through ISP1. This way, the core of AS 109 never carries any Internet traffic unless a BGP session with an ISP fails anywhere.

Such BGP policy is also called hot Potato routing.

				
					// R3
access-list 1 permit 131.108.1.0
access-list 2 permit any
!
router bgp 110
 neighbor 1.1.2.1 remote-as 109
 neighbor 1.1.2.1 route-map SET_WEIGHT in
 neighbor 1.1.8.2 remote-as 110
!
route-map SET_WEIGHT permit 10
 match ip address 1
 set weight 2000
route-map SET_WEIGHT permit 20
 match ip address 2
				
			

The set command configures the WEIGHT to 2000 for prefixes that pass access-list 1. The second sequence of the route map is necessary to allow all other prefixes from this neighbor without changing the WEIGHT.

R3 has two paths for 131.108.1.0/24, one from R1 and the other from R2. Even though the path from R2 has a MED of 10, R3 prefers the path from R1 because of the WEIGHT assignment. In best-path calculation, WEIGHT has the highest priority over all other attributes.

Reading BGP Attributes

Attribute and Other Fields Attribute Value
AS_PATH 1740 701 80
LOCAL_PREF 100
MED
20
NEXT_HOP 192.41.177.69
Origin Code
IGP
"external" Neighbor 192.41.177.69 is an EBGP neighbor
BGP peer address from 192.41.177.69
BGP RID 134.24.127.131

Leave a Reply

Related Post

BGP CommunitiesBGP Communities

BGP Communities BGP communities are an optional transitive BGP attribute that can traverse from autonomous system to autonomous system. A BGP community is a 32-bit number that can be included