DMZ Link BW Lab1
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 137 as follows:
Traffic from CSR1 destined for prefixes in 2.128.0.0/16 is load-shared in a 5:3:8 ratio to CSR6, CSR7, XR12
Traffic from CSR1 destined for prefixes in 2.129.0.0/16 is load-shared in a 5:3:16 ratio to CSR6, CSR7, XR12
All IPv6 prefixes advertised by CSR2 should be load shared in a 5:3:24 ratio from CSR1 to CSR6, CSR7, XR12
All of these prefixes are advertised by CSR2.
On IOS-XE, we enable use of the dmzlink-bw feature for UCMP on a router using the command “bgp dmzlink-bw” under the address-family. In this lab, this command is only needed on R1.
We enable the function of copying the link’s bandwidth into a bandwidth load-balancing extcommunity using the command “dmzlink-bw” on a neighbor. R6 and R7 require this.
Note above that we set the bandwidth for the R7-XR11 link, but these paths are never considered a best path. R7 will always prefer the path via R4 due to “bgp bestpath compare-routerid.” This disables the oldest-eBGP-route bestpath selection step. This is why we will always see a traffic share of 3 for R7 instead of 16.
Additionally on IOS-XE, we must send-community to our iBGP peers. This is enabled by deafult on IOS-XR for iBGP peers.
On IOS-XE, the link bandwidth is copied into the extcommunity value in kilobytes instead of kilobits. Notice that the link bandwidth for R6-R4 is in bits but the extcommunity is in bytes.
IOS-XE appears to not adhere to the standard when this value is placed in the extcommunity. The value is advertised as a link bandwidth of 625, which wireshark interprets as bytes per second, or 0.006 Mbps. This presents interoperability issues between IOS-XE & IOS-XR.
On IOS-XR, we never have to enable “dmzlink-bw” at an address-family level. We simply associate the command with a neighbor to copy the link bandwidth into the extcommunity attribute.
IOS-XR appears to adhere to the standard, where the value placed in the extcommunity is bytes per second. The value above is 192 kilobits per second, which is 192000 bits, or 24000 bytes. The value 24000 is placed in the extcommunity field. IOS-XE interprets this as 24000 kilobits. So to allow R1 to “correctly” use 24kbps, we had to change the bandwidth on IOS-XR to 192kbps. This demonstrates the interoperability issues for DMZ link-BW between IOS-XE and IOS-XR.
IOS-XR also allows us to set the extcommunity explicitly using an RPL. This allowed us to signal a different value for certain prefixes in this lab. XR12 sets the value to <ASN>:1000 and <ASN>:2000 depending on the received prefix. XR12 believes this is bytes per second, which would be 8Kbps and 16Kbps. XR12 displays the Kbps number in the show output. Quite confusing! (However, this makes IOS-XR more intuitive, because in general the link bandwidth (kbps) will be shown in the BGP output (kbps)).
When XR12 sends these paths to R1, R1 will interpret it as 1000kbps and 2000kbps, instead of 1000 bytes/sec and 2000 bytes/sec.
This allows R1 to achieve the ratio of load balancing we are looking for.
On IOS-XE, you cannot do DMZ link-BW load sharing for iBGP-learned paths for a VPN AF.
Since you can do UCMP for eBGP learned paths, we can test this on R7.
R7 is doing Inter-AS option B, so there is no local VRF table. We can instead look at the LFIB for verification that traffic is load shared.
Apparently there is a 1:1 ratio of load sharing, so this is not really working correctly. This is what Nick Russo found as well.
