DMZ Link BW Lab2
Last updated
Last updated
Topology: russo-spv4
Load bgp-dmz-bw.init.cfg
The core, BGP, etc, is all pre-configured.
Configure DMZ-link bandwidth for AS 173 so that traffic from XR4 towards AS 137 is load shared in a 2:1 ratio between CSR4 (2) and XR1 (1). Do this for all address-families (ipv4/ipv6/vpnv4/vpnv6).
Enabling UCMP on IOS-XR is a little easier than on IOS-XE. First, IOS-XR fully supports DMZ link-BW UCMP for all address-families. But in this lab, on XR4 there is an additional configuration we must do. By default, XR4 has a lower IGP cost to XR1 (2) versus CSR4 (3). We must either make these equal, or better yet, tell the router to ignore the IGP cost and allow multipath for unequal-cost nexthops.
We must deal with the IOS-XE & IOS-XR interoperability issue for the DMZ BW extcommunity value. R4 will present the value in the BGP table as kilobytes (250,000 KB):
However, R4 will send this value (250,000) to XR4. XR4 will consider this as bytes per second, and display it in kbps in the CLI. 250,000 bytes = 2,000,000 bits = 2,000 kbps.
Above, we can see that XR1’s LB extcommunity value is easier to understand. 1,000 kbps was converted to a value of 125,000 bytes in the extcommunity value. XR4 converts this back to 1,000 kbps (1Mbps).
As you can see, this causes any link BW reported from an IOS-XE router to an XR router to be translated into a much lower value than it should be. And likewise, an XR value sent to an XE router is translated to a much higher value than it should be.
On XR4 we can verify that UCMP is working for all address-families. First we’ll check global IPv4 and IPv6.
We can also see the hash buckets in the FIB. I’m not exactly sure why there are so many, but it appears to be 42:21 which reduces to 2:1.
Lastly we can check routes for the DMZ VRF.
The verbose CEF output looks the same as above, so it is not displayed here.
