BGP Local Preference
In the above topology R3 will generate these 2 prefixes 3.3.0.0/24 and 3.3.1.0/24 and R4 will generate these 2 prefixes 4.4.0.0/24 and 4.4.1.0/24 into BGP
Our goal is to use local preference to force R1 to route to 3.3.0.0/24 through R4
Now let’s check the BGP routing table of R1 and R2 before doing any changes
As we can see both R1 and R2 are using R3 to route to 3.3.0.0/24
now to apply local preference we need to match the prefix with a prefix list and then use a route-map to apply the route-map inbound to R4 on R1 (we want to influence outbound traffic so route-map should be applied inbound)
R1(config)#ip prefix-list R3_NET permit 3.3.0.0/24
R1(config)#route-map LOCAL_PREF permit 10
R1(config-route-map)#match ip address prefix-list R3_NET
R1(config-route-map)#set local-preference 200
R1(config-route-map)#route-map LOCAL_PREF permit 100
R1(config)#router bgp 100
R1(config-router)#neighbor 10.1.14.4 route-map LOCAL_PREF in
Remember to clear the BGP neighbor inbound
Now let’s check the BGP on R1
As expected we find that R1 is now using R4 to route to 3.3.0.0/24 because the local preference is now 200
R1#sh ip bgp 3.3.0.0
BGP routing table entry for 3.3.0.0/24, version 6
Paths: (3 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1 2
200
10.1.14.4 from 10.1.14.4 (10.1.34.4)
Origin IGP, localpref 200, valid, external, best
200
10.1.23.3 (inaccessible) from 10.1.12.2 (10.1.12.2)
Origin IGP, metric 0, localpref 100, valid, internal
200
10.1.13.3 from 10.1.13.3 (10.1.34.3)
Origin IGP, metric 0, localpref 100, valid, external
what about R2, when we were doing the same setup with weight attribute we saw how the weight attribute is only local to the router it is configured on
let’s see BGP on R2
As we can see that now R2 is using R1 to reach 3.3.0.0/24 because the local preference of 200 was advertised from R1
Remember that local preference is confined through the same AS i.e it doesn’t get advertised to eBGP neighbors
Comments
Post a Comment