It has been a while since my last post but I am willing to make it up :), and todays post will the beginning and more to come soon.
In SP environments; customers asks for main and backup scenarios for their sites and they set some requirements for these scnarios.
Lets Assume that a customer says that he has a backup HQ site that is at a separate geographical location from the main HQ and that the backup HQ should remain idle all the time unless the main HQ goes down, also he want to run EIGRP as PE-Ce routing protocol at his two HQ sites.
Note that both CE’s are advertising the same prefixes (192.168.1.0/24 and 192.168.2.0)
One way to achieve this is to change the EIGRP AD (90) to be higher that the iBGP AD (200)
| PE2#sho ip route vrf ABC 172.27.0.0/16 is variably subnetted, 3 subnets, 2 masks B 172.27.1.0/30 [200/0] via 1.1.1.1, 00:03:39 C 172.27.2.0/30 is directly connected, GigabitEthernet2/0 L 172.27.2.1/32 is directly connected, GigabitEthernet2/0 D 192.168.1.0/24 [210/130816] via 172.27.2.2, 00:02:16, GigabitEthernet2/0 D 192.168.2.0/24 [210/130816] via 172.27.2.2, 00:02:16, GigabitEthernet2/0 |
PE2 will still prefer the backupHQ routes as they will have higher weight in the BGP table, which means that others sites that are connected to PE2 will use the backupHQ connection.
| PE2#sho ip bgp vpnv4 vrf ABC Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:123 (default for vrf ABC) *>i172.27.1.0/30 1.1.1.1 0 100 0 ? *> 172.27.2.0/30 0.0.0.0 0 32768 ? *> 192.168.1.0 172.27.2.2 130816 32768 ? * i 1.1.1.1 130816 100 0 ? *> 192.168.2.0 172.27.2.2 130816 32768 ? * i 1.1.1.1 130816 100 0 ?PE2#sho ip bgp vpnv4 vrf ABC 192.168.1.0 BGP routing table entry for 100:123:192.168.1.0/24, version 25 Paths: (2 available, best #1, table ABC) Advertised to update-groups: 1 Local 172.27.2.2 from 0.0.0.0 (2.2.2.2) Origin incomplete, metric 130816, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:100:123 Cost:pre-bestpath:128:130816 0x8800:32768:0 0x8801:500:128256 0x8802:65281:2560 0x8803:65281:1500 0x8806:0:3232236033 mpls labels in/out 16/nolabel Local 1.1.1.1 (metric 10) from 1.1.1.1 (1.1.1.1) Origin incomplete, metric 130816, localpref 100, valid, internal Extended Community: RT:100:123 Cost:pre-bestpath:128:130816 0x8800:32768:0 0x8801:500:128256 0x8802:65281:2560 0x8803:65281:1500 0x8806:0:3232236033 mpls labels in/out 16/19 |
To solve this you will have to set the weight to zero and to lower the local preference so that PE2 prefers the routes coming from the main HQ.
But why make 3 different steps to achieve a goal that can be made in one step only, this is where the BGP Cost Community feature comes into play. BGP Cost Community is a BGP non-transitive extended community that influences the BGP best path selection by making the BGP to compare the Cost Community value to before getting into the regular BGP best path selection, where lower cost is better.
BGP Cost Community is enabled by default when using EIGRP as a PE-CE routing protocol, what is does is that it copy the EIGRP metric to be propagated along with the route, and when an PE receives the route with a Cost Community value it compares it and selects the one with the lower value.
In case a PE receives two routes and one of them doesn’t have a Cost Community value it assigns a default value of (2147483647). If a PE receives a route with a Cost Community but it doesn’t support this feature, the BGP Cost Community will be ignored and normal BGP best path selection will take place. Also if two routes have the same Cost Community values normal BGP best path selection will select the best route according to the BGP attributes.
So to achieve our goal in one step, we only have to manipulate the EIGRP metric under the customer interface by lowering the bandwidth value or raising the delay value.
| interface GigabitEthernet2/0 bandwidth 100 ip vrf forwarding ABC ip address 172.27.2.1 255.255.255.252 delay 1000 negotiation auto end |
Now lets check our routing/bgp tables on PE2
| PE2#sho ip route vrf ABC 172.27.0.0/16 is variably subnetted, 3 subnets, 2 masks B 172.27.1.0/30 [200/0] via 1.1.1.1, 00:23:10 C 172.27.2.0/30 is directly connected, GigabitEthernet2/0 L 172.27.2.1/32 is directly connected, GigabitEthernet2/0 B 192.168.1.0/24 [200/130816] via 1.1.1.1, 00:00:42 B 192.168.2.0/24 [200/130816] via 1.1.1.1, 00:00:42 PE2#sho ip bgp vpnv4 vrf ABC Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:123 (default for vrf ABC) *>i172.27.1.0/30 1.1.1.1 0 100 0 ? *> 172.27.2.0/30 0.0.0.0 0 32768 ? *>i192.168.1.0 1.1.1.1 130816 100 0 ? *>i192.168.2.0 1.1.1.1 130816 100 0 ?PE2#sho ip bgp vpnv4 vrf ABC 192.168.1.0 BGP routing table entry for 100:123:192.168.1.0/24, version 28 Paths: (1 available, best #1, table ABC) Not advertised to any peer Local 1.1.1.1 (metric 10) from 1.1.1.1 (1.1.1.1) Origin incomplete, metric 130816, localpref 100, valid, internal, best Extended Community: RT:100:123 Cost:pre-bestpath:128:130816 0x8800:32768:0 0x8801:500:128256 0x8802:65281:2560 0x8803:65281:1500 0x8806:0:3232236033 mpls labels in/out nolabel/19 |
What happened is:
Before manipulating the EIGRP metric, PE2 preferred its local routes not only for having higher weight but as both routes had same Cost Community metric, so the BGP attributes selected the best path and so the higher weight did win.
But now after PE2 local EIGRP had higher metric, PE2 preferred the iBGP learned routes as they have lower metric value, and the local EIGRP routes were withdrawn from both BGP and routing table.
If we check the below EIGRP topology table :
| PE2#sho ip eigrp vrf ABC topology 192.168.1.0 EIGRP-IPv4 Topology Entry for AS(500)/ID(172.27.2.1) VRF(ABC) EIGRP-IPv4(500): Topology base(0) entry for 192.168.1.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 130816 Descriptor Blocks: 1.1.1.1, from VPNv4 Sourced, Send flag is 0x0 Composite metric is (130816/0), route is Internal (VPNv4 Sourced) Vector metric: Minimum bandwidth is 1000000 Kbit Total delay is 5010 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1 Originating router is 192.168.2.1 172.27.2.2 (GigabitEthernet2/0), from 172.27.2.2, Send flag is 0x0 Composite metric is (25984000/128256), route is Internal Vector metric: Minimum bandwidth is 100 Kbit Total delay is 15000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1 Originating router is 192.168.2.1 |
we will find that the local EIGRP routes are no longer preferred due to their higher metric value and the iBGP route is preferred due to its lower metric.
And by that; we did acheive the customer’s requirements in an easier way.
That would be all for now 🙂
HTH
Abdullah Medhat
