Lab2 UCMP
Last updated
Last updated
Load unix: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 IPv4 traffic. (It doesn’t work for IPv6).
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.
The command bgp dmzlink-bw enables the feature. The neighbor statement with the keyword dmzlink-bw causes the router to place the link’s bandwidth into the received BGP path as an extcommunity. You also need to use maximum-paths to enable load sharing. Load sharing will be based proportionally on the received dmz link BW extcommunity.
On R4 and R5, we are not doing UCMP, so the maximum-paths command is not used. All we need to do is enable the feature under BGP, and enable it for the R6 neighbor. We also need to send extcommunities to our iBGP peers, so R3 can receive this.
On R3, we just need to enable the feature, and 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 we should see that the eBGP route now contains an extcommunity which has the bandwidth of the link over which the eBGP peer is connected. The link BW is represented in bytes instead of bits. We also learn R5’s dmz link BW via iBGP.
R3 should learn these as well, and select both paths as multipath candidates.
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.