Lab2 UCMP
Last updated
Last updated
Load lab2.init.cfg
The bandwidth of the R4-R6 and R5-R6 link has been changed, matching the diagram above. Configure UCMP so that R3 will send twice as much traffic to R4. Additionally, configure R6 to send twice as much traffic to R4.
Only do this for both IPv4 and IPv6 traffic in the core, and only IPv4 on R6. (Note that IPv6 UCMP does actually work on XRv, while it didn’t work on IOL in the previous IOL labs).
https://www.youtube.com/watch?v=YISpo321U7Q&list=PL3Y9eZjZCcsejbVWD3wJIePqe3NiImqxB&index=3
The DMZ link bandwidth feature allows you to do unequal multipath. BGP routes are tagged with the bandwidth of the external link from which the path was learned. This is signaled as a BGP extcommunity.
Enabling DMZ link bandwidth on IOS-XR is easier than on IOS-XE. You simply use the dmz-link-bandwidth command under the eBGP neighbor. The bandwidth from the interface is automatically copied into an ext RT.
On R4 and R5, we are not doing UCMP, so the maximum-paths command is not used. R3 will automatically receive the extcommunity by default (iBGP neighbors have “send-community both” functionality by default on IOS-XR).
On R3, we just need to enable multipathing for iBGP routes.
On R6, it will make a local UCMP decision. It does not send the DMZ link bw to any peers, so we don’t have to worry about sending communities. We need to enable the feature, enable it per eBGP peer, and enable eBGP multipathing.
On R4 and R5, we cannot locally see the extended community added to the route.
If we look at a remote neighbor, such as R3, we will see the extended community, which is called “LB” (I’m assuming meaning load balance). The value is in the format <ASN>:<bandwidth in kilobits>.
Also note that dmz link BW works for IPv6 on IOS-XR. This is not the case with IOS-XE.
R3 will automatically do proportional load sharing based on the bandwidth values.
Likewise R6 will place the BW in the BGP table for the paths, and do unequal load sharing.
