IOS XE 15.5
IOS XR 5.3
The topology for this demo:
In this post we will take a look at manually manipulating the EIGRP to BGP redistribution that is automatically handled by default on IOS with the "populate bgp-ext-comm" command and manually configuring the EIGRP default mertic in XR. Although an additional configuration option, no real world use case comes to mind that would need manual configuration. Regardless, I will cover it as it is an option that maybe tested on. The idea is very simple, EIGRP metrics are automatically copied to BGP extended community values and propagated via VPNv4/VPNv6. There maybe a situation where this needs to be modified. Let's take a look at how the BGP VPNv4 tabel for VRF EIGRP looks now and we can begin the demo.
R1#sh bgp vpnv4 unicast vrf EIGRP 192.168.100.0
BGP routing table entry for 90:50693:192.168.100.0/24, version 363
Paths: (2 available, best #2, table EIGRP)
Not advertised to any peer
Refresh Epoch 1
Local
192.168.1.13 (metric 3) (via default) from 192.168.1.14 (192.168.1.14)
Origin incomplete, metric 10880, localpref 100, valid, internal
Extended Community: RT:90:50693 Cost:pre-bestpath:129:10880 0x8800:0:0
0x8801:90:288 0x8802:65281:2560 0x8803:1:1500 0x8804:0:1895825422
0x8805:11:0
Originator: 192.168.1.13, Cluster list: 192.168.1.14
mpls labels in/out nolabel/24020
rx pathid: 0, tx pathid: 0
Refresh Epoch 2
Local
192.168.1.13 (metric 3) (via default) from 192.168.1.2 (192.168.1.2)
Origin incomplete, metric 10880, localpref 100, valid, internal, best
Extended Community: RT:90:50693 Cost:pre-bestpath:129:10880 0x8800:0:0
0x8801:90:288 0x8802:65281:2560 0x8803:1:1500 0x8804:0:1895825422
0x8805:11:0
Originator: 192.168.1.13, Cluster list: 192.168.1.2
mpls labels in/out nolabel/24020
rx pathid: 0, tx pathid: 0x0
As you can see, R1 receives the info from R2 and XR4 with the BGP extended communities added in.
To be clear, disabling the auto propagation will cause the routes to be lost. I'll disable the population and level set.
R1
router eigrp CCIE
!
address-family ipv4 unicast vrf EIGRP autonomous-system 90
no populate bgp-ext-comm
R13#sh ip route vrf EIGRP | b Gateway
Gateway of last resort is not set
90.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 90.90.90.0/24 is directly connected, Loopback90
L 90.90.90.13/32 is directly connected, Loopback90
131.0.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 131.0.0.0/24 is directly connected, GigabitEthernet1.1090
L 131.0.0.13/32 is directly connected, GigabitEthernet1.1090
As you can see, R13 has lost all of it's routes. We have 2 choices to fix this, either the "default-metric" or we can manually define the metrics.
R1
router eigrp CCIE
!
address-family ipv4 unicast vrf EIGRP autonomous-system 90
!
topology base
redistribute bgp 50693 metric 1000000 1 255 1 1500
R13
R13#sh ip route vrf EIGRP eigrp | b Gateway
Gateway of last resort is not set
59.0.0.0/24 is subnetted, 1 subnets
D EX 59.0.0.0 [170/15360] via 131.0.0.1, 00:02:18, GigabitEthernet1.1090
83.0.0.0/24 is subnetted, 1 subnets
D EX 83.0.0.0 [170/15360] via 131.0.0.1, 00:02:18, GigabitEthernet1.1090
106.0.0.0/24 is subnetted, 1 subnets
D EX 106.0.0.0 [170/15360] via 131.0.0.1, 00:02:18, GigabitEthernet1.1090
113.0.0.0/24 is subnetted, 1 subnets
D EX 113.0.0.0 [170/15360] via 131.0.0.1, 00:02:18, GigabitEthernet1.1090
D EX 192.168.100.0/24
[170/15360] via 131.0.0.1, 00:02:18, GigabitEthernet1.1090
You'll notice that all of the EIGRP routes now show up as D EX, that is because the auto propagation that we've always used has been disabled and now the PE router acts as an injection point. We lose the visibility that we had prior to redistribution. Now I'll demo the default metric option.
R1
router eigrp CCIE
!
address-family ipv4 unicast vrf EIGRP autonomous-system 90
!
topology base
default-metric 100000 10 255 1 1400
redistribute bgp 50693
R13
R13#sh ip route vrf EIGRP eigrp | b Gateway
Gateway of last resort is not set
59.0.0.0/24 is subnetted, 1 subnets
D EX 59.0.0.0 [170/107520] via 131.0.0.1, 00:00:05, GigabitEthernet1.1090
83.0.0.0/24 is subnetted, 1 subnets
D EX 83.0.0.0 [170/107520] via 131.0.0.1, 00:00:05, GigabitEthernet1.1090
106.0.0.0/24 is subnetted, 1 subnets
D EX 106.0.0.0 [170/107520] via 131.0.0.1, 00:00:05, GigabitEthernet1.1090
113.0.0.0/24 is subnetted, 1 subnets
D EX 113.0.0.0 [170/107520] via 131.0.0.1, 00:00:05, GigabitEthernet1.1090
D EX 192.168.100.0/24
[170/107520] via 131.0.0.1, 00:00:05, GigabitEthernet1.1090
Both options work, default metric in my opinion is a bit more scalable since you dictate the values once and you can have several redistribution points into EIGRP and not have to manipulate each redistribution point. There is one other option available to us, that is redistribution with a route-map. This is just as scalable as the default metric feature but is globally configured and applied under the process.
R1
router eigrp CCIE
!
address-family ipv4 unicast vrf EIGRP autonomous-system 90
!
topology base
redistribute bgp 50693 route-map BGP_TO_EIGRP
route-map BGP_TO_EIGRP permit 10
set metric 1000000 1 255 1 1455
R13
R13#sh ip route vrf EIGRP eigrp | b Gateway
Gateway of last resort is not set
59.0.0.0/24 is subnetted, 1 subnets
D EX 59.0.0.0 [170/15360] via 131.0.0.1, 00:00:06, GigabitEthernet1.1090
83.0.0.0/24 is subnetted, 1 subnets
D EX 83.0.0.0 [170/15360] via 131.0.0.1, 00:00:06, GigabitEthernet1.1090
106.0.0.0/24 is subnetted, 1 subnets
D EX 106.0.0.0 [170/15360] via 131.0.0.1, 00:00:06, GigabitEthernet1.1090
113.0.0.0/24 is subnetted, 1 subnets
D EX 113.0.0.0 [170/15360] via 131.0.0.1, 00:00:06, GigabitEthernet1.1090
D EX 192.168.100.0/24
[170/15360] via 131.0.0.1, 00:00:06, GigabitEthernet1.1090
So either way you want to rollout it out, there are options. Let's take a look at the XR variants. The output below is a dump from BGP VPNv4 VRF EIGRP. As you can see, the information that XR3 learns has all the info from EIGRP as BGP extended communities.
RP/0/0/CPU0:XR3(config-eigrp-vrf-af)#do sh bgp vpnv4 unicast vrf EIGRP 131.0.0$
Sat Jan 14 14:15:16.206 UTC
Extended community: COST:128:128:10240 EIGRP route-info:0x8000:0 EIGRP AD:90:256 EIGRP RHB:255:0:2560 EIGRP LM:0xff:1:1500 EIGRP VRR:0x0:1.0.0.131 RT:90:50693
RP/0/0/CPU0:XR3(config)#do sh eigrp vrf EIGRP ipv4 topology 131.0.0.0/24
Sat Jan 14 14:20:14.025 UTC
IPv4-EIGRP VR(CCIE) AS(90) VRF EIGRP: Topology entry for 131.0.0.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1310720, RIB is 10240
Routing Descriptor Blocks:
192.168.1.1, from VPNv4 Sourced, Send flag is 0x0
Composite metric is (1310720/0), Route is Internal (VPNv4 Sourced)
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 10000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 0
Originating router is 131.0.0.1
Since we haven't really manipulated anything yet, there isn't much going on, but I wanted to show you the difference between a CE RIB (R14) with the autopropagation working and it not.
R14#sh ip route vrf EIGRP eigrp | b Gateway
Gateway of last resort is not set
59.0.0.0/24 is subnetted, 1 subnets
D 59.0.0.0 [90/15360] via 113.0.0.13, 08:14:44, GigabitEthernet1.1090
83.0.0.0/24 is subnetted, 1 subnets
D 83.0.0.0 [90/15360] via 113.0.0.13, 08:15:21, GigabitEthernet1.1090
90.0.0.0/24 is subnetted, 1 subnets
D 90.90.90.0 [90/16000] via 113.0.0.13, 08:15:21, GigabitEthernet1.1090
106.0.0.0/24 is subnetted, 1 subnets
D 106.0.0.0 [90/15360] via 113.0.0.13, 08:15:04, GigabitEthernet1.1090
131.0.0.0/24 is subnetted, 1 subnets
D 131.0.0.0 [90/15360] via 113.0.0.13, 08:15:06, GigabitEthernet1.1090
I will test out the route-policy variation as the default metric works identically in XR as it did in IOS.
R14#sh ip route vrf EIGRP eigrp | b Gateway
Gateway of last resort is not set
59.0.0.0/24 is subnetted, 1 subnets
D 59.0.0.0 [90/5637120] via 113.0.0.13, 00:00:06, GigabitEthernet1.1090
83.0.0.0/24 is subnetted, 1 subnets
D 83.0.0.0 [90/5637120] via 113.0.0.13, 00:00:06, GigabitEthernet1.1090
90.0.0.0/24 is subnetted, 1 subnets
D 90.90.90.0
[90/5637120] via 113.0.0.13, 00:00:06, GigabitEthernet1.1090
106.0.0.0/24 is subnetted, 1 subnets
D 106.0.0.0
[90/5637120] via 113.0.0.13, 00:00:06, GigabitEthernet1.1090
131.0.0.0/24 is subnetted, 1 subnets
D 131.0.0.0
[90/5637120] via 113.0.0.13, 00:00:06, GigabitEthernet1.1090
XR3
route-policy BGP_TO_EIGRP
set eigrp-metric 1000 100 255 1 1500
end-policy
!
router eigrp CCIE
vrf EIGRP
address-family ipv4
autonomous-system 90
redistribute bgp 50693 route-policy BGP_TO_EIGRP
It looks identical from the two RIB outputs on R14, however if you look at the total cost to reach the destinations, the new RPL configuration has caused the RIB outputs to show really high FD. Which tells me that the RPL is taking effect.
Keep in mind that this is only effecting routing update metrics from BGP to EIGRP, this doesn't effect what XR3 will see from the other PEs or effect the VRF EIGRP RIB on XR3.
RP/0/0/CPU0:XR3#sh bgp vpnv4 unicast vrf EIGRP 131.0.0.0/24 | b Extended commu$
Sat Jan 14 14:31:23.600 UTC
Extended community: COST:128:128:10240 EIGRP route-info:0x8000:0 EIGRP AD:90:256 EIGRP RHB:255:0:2560 EIGRP LM:0xff:1:1500 EIGRP VRR:0x0:1.0.0.131 RT:90:50693
RP/0/0/CPU0:XR3#sh route vrf EIGRP ipv4 | b Gateway
Sat Jan 14 14:33:25.891 UTC
Gateway of last resort is not set
B 59.0.0.0/24 [200/0] via 192.168.1.5 (nexthop in vrf default), 08:23:18
B 83.0.0.0/24 [200/0] via 192.168.1.3 (nexthop in vrf default), 08:23:46
B 90.90.90.0/24 [200/10880] via 192.168.1.3 (nexthop in vrf default), 01:05:21
B 106.0.0.0/24 [200/0] via 192.168.1.6 (nexthop in vrf default), 08:23:06
C 113.0.0.0/24 is directly connected, 6d23h, GigabitEthernet0/0/0/0.1090
L 113.0.0.13/32 is directly connected, 6d23h, GigabitEthernet0/0/0/0.1090
B 131.0.0.0/24 [200/0] via 192.168.1.1 (nexthop in vrf default), 08:23:46
D EX 192.168.100.0/24 [170/10880] via 113.0.0.14, 08:24:21, GigabitEthernet0/0/0/0.1090
The learned BGP metric of 10880 is learned in from R3. Which proves that the metric manipulation only happens when BGP is redistributed into EIGRP.
Thanks for stopping by!
Rob Riker, CCIE #50693
No comments:
Post a Comment