DMZ Link BW Lab1
Topology: russo-spv4
Load bgp-dmz-bw.init.cfg
#R1-R10
config replace flash:bgp-dmz-bw.init.cfg
#XR11-14
configure
load bootflash:bgp-dmz-bw.init.cfg
commit replace
yThe 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.
Answer
#R6
int gi2.546
bandwidth 5000
!
router bgp 137
address-family ipv4
neighbor 10.4.6.4 dmzlink-bw
neighbor 137.0.0.1 send-community both
address-family ipv6
neighbor 137.0.0.1 send-community both
neighbor FD00:10:4:6::4 dmzlink-bw
#R7
interface GigabitEthernet2.547
bandwidth 3000
!
interface GigabitEthernet2.571
bandwidth 16000
!
router bgp 137
address-family ipv4
neighbor 10.4.7.4 dmzlink-bw
neighbor 10.7.11.11 dmzlink-bw
neighbor 137.0.0.1 send-community both
address-family ipv6
neighbor 137.0.0.1 send-community both
neighbor FD00:10:4:7::4 dmzlink-bw
neighbor FD00:10:7:11::11 dmzlink-bw
#XR12
int GigabitEthernet0/0/0/0.512
bandwidth 192
!
route-policy SET_DMZ_BW
if destination in (2.128.0.0/16 le 24) then
set extcommunity bandwidth (137:1000)
elseif destination in (2.129.0.0/16 le 24) then
set extcommunity bandwidth (137:2000)
endif
pass
end-policy
!
router bgp 137
neighbor 10.11.12.11
remote-as 173
address-family ipv4 unicast
route-policy SET_DMZ_BW in
!
neighbor fd00:10:11:12::11
dmz-link-bandwidth
#R1
router bgp 137
address-family ipv4
bgp dmzlink-bw
maximum-paths ibgp 4
address-family ipv6
bgp dmzlink-bw
maximum-paths ibgp 4Explanation/Verification
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.
#R1
router bgp 137
address-family ipv4
bgp dmzlink-bw
maximum-paths ibgp 4
address-family ipv6
bgp dmzlink-bw
maximum-paths ibgp 4We 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.
#R6
int gi2.546
bandwidth 5000
!
router bgp 137
address-family ipv4
neighbor 10.4.6.4 dmzlink-bw
address-family ipv6
neighbor FD00:10:4:6::4 dmzlink-bw
#R7
interface GigabitEthernet2.547
bandwidth 3000
!
interface GigabitEthernet2.571
bandwidth 16000
!
router bgp 137
address-family ipv4
neighbor 10.4.7.4 dmzlink-bw
neighbor 10.7.11.11 dmzlink-bw
address-family ipv6
neighbor FD00:10:4:7::4 dmzlink-bw
neighbor FD00:10:7:11::11 dmzlink-bwNote 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.
#R6
router bgp 137
address-family ipv4
neighbor 137.0.0.1 send-community both
address-family ipv6
neighbor 137.0.0.1 send-community both
#R7
router bgp 137
address-family ipv4
neighbor 10.4.7.4 dmzlink-bw
neighbor 10.7.11.11 dmzlink-bw
address-family ipv6
neighbor FD00:10:4:7::4 dmzlink-bw
neighbor FD00:10:7:11::11 dmzlink-bwOn 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.
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.
#XR12
int GigabitEthernet0/0/0/0.512
bandwidth 192
!
router bgp 137
neighbor fd00:10:11:12::11
dmz-link-bandwidthIOS-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)).
#XR12
route-policy SET_DMZ_BW
if destination in (2.128.0.0/16 le 24) then
set extcommunity bandwidth (137:1000)
elseif destination in (2.129.0.0/16 le 24) then
set extcommunity bandwidth (137:2000)
endif
pass
end-policy
!
router bgp 137
neighbor 10.11.12.11
remote-as 173
address-family ipv4 unicast
route-policy SET_DMZ_BW in
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.
A note on IOS-XE and VPNv4/VPNv6
On IOS-XE, you cannot do DMZ link-BW load sharing for iBGP-learned paths for a VPN AF.
R1(config-router-af)#maximum-paths ?
<1-32> Number of pathsSince you can do UCMP for eBGP learned paths, we can test this on R7.
#R7
router bgp 137
add vpnv4
bgp dmzlink-bw
maximum-paths 2
neighbor 10.4.7.4 dmzlink-bw
neighbor 10.7.11.11 dmzlink-bwR7 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.
Last updated