Example 7-26 Verifying the Number of Paths Known for 10.2.0.0 in VRF Blue
PE1#show ip bgp vpn vrf blue 10.2.0.0 BGP routing table entry for 2:2:10.2.0.0/16, version 9 Paths: (2 available, best #1, table blue) Advertised to non peer-group peers: 192.168.4.4 65005 10.9.1.2 from 10.9.1.2 (10.9.1.2) Origin IGP, metric 0, localpref 100, valid, external, best Extended Community: RT:2:2, mpls labels in/out 20/nolabel 65005, imported path from 1:1:10.2.0.0/16 192.168.4.4 (metric 21) from 192.168.4.4 (192.168.4.4) Origin IGP, metric 0, localpref 100, valid, internal Extended Community: RT:1:1, mpls labels in/out 20/19
By configuring the eiBGP multipath feature, as shown in Example 7-27, Router PE1 can use both paths in VRF blue.
Example 7-27 PE1's eiBGP Configuration
PE1(config)#router bgp 65100 PE1(config-router)#address-family ipv4 vrf blue PE1(config-router-af)#maximum-paths eibgp 2
When looking at the BGP output for 10.2.2.0 after configuration, which is shown in Example 7-28, the router marks both paths as multipath, although the eBGP path is best.
Example 7-28 Checking Multipath Configuration
PE1#show ip bgp vpn vrf blue 10.2.2.0 BGP routing table entry for 2:2:10.2.0.0/16, version 10 Paths: (2 available, best #1, table blue) Multipath: eiBGP Advertised to non peer-group peers: 192.168.4.4 65005 10.9.1.2 from 10.9.1.2 (10.9.1.2) Origin IGP, metric 0, localpref 100, valid, external, multipath, best Extended Community: RT:2:2, mpls labels in/out 20/nolabel 65005, imported path from 1:1:10.2.0.0/16 192.168.4.4 (metric 21) from 192.168.4.4 (192.168.4.4) Origin IGP, metric 0, localpref 100, valid, internal, multipath Extended Community: RT:1:1, mpls labels in/out 20/19 PE1#
Inbound IP packets will share the two known paths (iBGP/eBGP) per the show ip cef vrf blue command in Example 7-29.
Example 7-29 Verifying CEF
PE1#show ip cef vrf blue 10.2.2.0
10.2.0.0/16, version 11, epoch 0, per-destination sharing
0 packets, 0 bytes
tag information set
local tag: 20
via 10.9.1.2, 0 dependencies, recursive
traffic share 1
next hop 10.9.1.2, Serial3/0 via 10.9.1.0/30
valid adjacency
tag rewrite with Se3/0, point2point, tags imposed: {}
via 192.168.4.4, 0 dependencies, recursive
traffic share 1
next hop 172.16.2.2, Ethernet0/0 via 192.168.4.4/32
valid adjacency
tag rewrite with Et0/0, 172.16.2.2, tags imposed: {17 19}
0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
internal 0 packets, 0 bytes
However, inbound MPLS packets will share the one known eBGP path, as seen in the MPLS forwarding table. Note that only one entry is in the MPLS forwarding table for the VRF in Example 7-30. There will only be one entry if only one eBGP path exists.
Example 7-30 Verifying LFIB
PE1#show mpls forwarding vrf blue 10.2.2.0 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 20 Untagged 10.2.0.0/16[V] 0 Se3/0 point2point
One complication with BGP multipath is that load sharing over links occurs equally, regardless of the different link bandwidths. Unequal load sharing, which occurs with EIGRP, prevents overloading a smaller bandwidth link. Therefore, in Cisco IOS Release 12.2(2)T and later IOS versions, a BGP extended community attribute allows bandwidth differentiation across paths among iBGP peers. Check the Feature Navigator at Cisco.com for availability in your Cisco IOS version and Cisco platform. This feature supports iBGP, eBGP multipath load sharing, and eiBGP multipath load sharing in MPLS VPNs.
For the BGP router to do unequal load sharing between two or more valid BGP paths, the router uses the bandwidth community to set the variance of the links. The bgp dmzlink-bw command configures BGP to distribute traffic proportionally to the bandwidth of the link. Each router that contains an external interface that is available for multipath load sharing should have this command enabled. If you do not configure the bgp dmz-link command, the routers will send the link bandwidth extended community attribute in the updates to the iBGP peers, but the router will not use the DMZ-link bandwidth locally for unequal-cost load sharing if multiple BGP paths exist.
The neighbor <address> dmzlink-bw command propagates the link bandwidth attribute for routes learned from the specified external neighbor in the link bandwidth extended community. When the router receives the link bandwidth attribute and uses the BGP DMZ-link bandwidth, the router sets the traffic load-share value appropriately for multiple paths and passes the value to CEF as with EIGRP unequal-cost load sharing. The multipath router will advertise the aggregated bandwidth to its iBGP peers.
In Figure 7-7, site A has two routers, CE1 and CE2, advertising the prefix 10.8.8.0/24 to their connected provider edge routers, PE2 and PE3, respectively, through external BGP. PE2 and PE3 have a defined bandwidth on the interfaces connected to these CEs. The PE routers carry the BGP DMZ-link bandwidth from the BGP external neighbor through the BGP DMZ-link community. Example 7-31 shows the configuration to propagate the bandwidth attribute on PE2 and PE3.
BGP DMZ Link
Example 7-31 Modified Configuration on PE2 and PE3 to Carry BGP DMZ-Link Community
303-PE2#show run | b router bgp router bgp 65100 no synchronization bgp log-neighbor-changes neighbor 192.168.10.1 remote-as 65100 neighbor 192.168.10.1 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 192.168.10.1 activate neighbor 192.168.10.1 send-community extended exit-address-family ! address-family ipv4 vrf blue redistribute connected neighbor 10.1.1.5 remote-as 65500 neighbor 10.1.1.5 activate neighbor 10.1.1.5 dmzlink-bw no auto-summary no synchronization exit-address-family ! PE3-304#show run | b router bgp router bgp 65100 no synchronization bgp log-neighbor-changes neighbor 192.168.10.1 remote-as 65100 neighbor 192.168.10.1 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 192.168.10.1 activate neighbor 192.168.10.1 send-community extended exit-address-family ! address-family ipv4 vrf blue redistribute connected neighbor 10.2.2.6 remote-as 65500 neighbor 10.2.2.6 activate neighbor 10.2.2.6 dmzlink-bw no auto-summary no synchronization exit-address-family
The output in Example 7-32 shows that the PE routers carry the bandwidth. The router expresses the DMZ-link bandwidth in kilobytes (KBps), whereas the interface bandwidth is in kilobits (kbps).
Example 7-32 Verifying Bandwidth Carried Through BGP
303-PE2#show ip bgp vpn vrf blue 10.8.8.0 BGP routing table entry for 100:100:10.8.8.0/24, version 13 Paths: (1 available, best #1, table blue) Advertised to update-groups: 1 65500 10.1.1.5 (via blue) from 10.1.1.5 (10.8.8.5) Origin IGP, metric 0, localpref 100, valid, external, best Extended Community: RT:100:100 DMZ-Link Bw 1250 kbytes PE3-304#show ip bgp vpn vrf blue 10.8.8.0 BGP routing table entry for 100:100:10.8.8.0/24, version 6 Paths: (1 available, best #1, table blue) Advertised to update-groups: 1 65500 10.2.2.6 (via blue) from 10.2.2.6 (10.8.8.6) Origin IGP, metric 0, localpref 100, valid, external, best Extended Community: RT:100:100 DMZ-Link Bw 625 kbytes PE3-304#
Before the availability of the iBGP load-sharing feature, Cisco IOS would only select one iBGP best path. For iBGP load sharing to be successful, by default, the routes must have equal attributes, such as weight, local preference, AS path, origin code, and IGP metric. If the attributes are not the same, the router does not use the path as a multiple path and only picks the best path.
In this case, PE1's configuration allows utilization of both paths through iBGP load sharing, and the attributes are the equal. Therefore, PE1 receives the route and uses both paths through multipath configuration. PE1 uses the defined DMZ-link bandwidth locally because of the configured bgp dmzlink-bw command under the address family VPNv4.
Example 7-33 Configuring PE1 to Receive and Use the BGP-Carried Bandwidth
302-PE1#show run | b router bgp router bgp 65100 no synchronization bgp log-neighbor-changes neighbor 192.168.10.3 remote-as 65100 neighbor 192.168.10.3 update-source Loopback0 neighbor 192.168.10.4 remote-as 65100 neighbor 192.168.10.4 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 192.168.10.3 activate neighbor 192.168.10.3 send-community extended neighbor 192.168.10.4 activate neighbor 192.168.10.4 send-community extended bgp dmzlink-bw exit-address-family ! address-family ipv4 vrf blue neighbor 10.6.6.1 remote-as 65200 neighbor 10.6.6.1 activate maximum-paths ibgp 2 no auto-summary no synchronization exit-address-family
Router PE1 receives two paths, including the DMZ-link bandwidth, through the output shown in Example 7-34.
Example 7-34 BGP Verification That PE1 Receives Paths and Bandwidth
302-PE1#show ip bgp vpn vrf blue 10.8.8.0 BGP routing table entry for 100:100:10.8.8.0/24, version 11 Paths: (2 available, best #1, table blue) Multipath: iBGP Advertised to update-groups: 1 65500 192.168.10.3 (metric 65) from 192.168.10.3 (192.168.10.3) Origin IGP, metric 0, localpref 100, valid, internal, multipath, best Extended Community: RT:100:100 DMZ-Link Bw 1250 kbytes 65500 192.168.10.4 (metric 65) from 192.168.10.4 (192.168.10.4) Origin IGP, metric 0, localpref 100, valid, internal, multipath Extended Community: RT:100:100 DMZ-Link Bw 625 kbytes 302-PE1#
PE1 passes this DMZ-link bandwidth to the routing table and VRF table, as shown in Example 7-35. Notice that the traffic count is two for the path through 192.168.10.3 and one for the path through 192.168.10.4.
Example 7-35 Verifying BGP Unequal Load Sharing Through Routing and CEF Tables
302-PE1#show ip route vrf blue 10.8.8.0
Routing entry for 10.8.8.0/24
Known via "bgp 65100", distance 200, metric 0
Tag 65500, type internal
Last update from 192.168.10.4 04:09:31 ago
Routing Descriptor Blocks:
* 192.168.10.3 (Default-IP-Routing-Table), from 192.168.10.3, 04:09:31 ago
Route metric is 0, traffic share count is 2
AS Hops 1, BGP network version 0
Route tag 65500
192.168.10.4 (Default-IP-Routing-Table), from 192.168.10.4, 04:09:31 ago
Route metric is 0, traffic share count is 1
AS Hops 1, BGP network version 0
Route tag 65500
302-PE1#show ip cef vrf blue 10.8.8.0
10.8.8.0/24, version 82, epoch 0, per-destination sharing
0 packets, 0 bytes
tag information set, all rewrites owned
local tag: VPN route head
via 192.168.10.3, 0 dependencies, recursive
traffic share 2
next hop 10.10.10.3, Serial2/0 via 192.168.10.3/32 (Default)
valid adjacency
tag rewrite with
Recursive rewrite via 192.168.10.3/32, tags imposed {25}
via 192.168.10.4, 0 dependencies, recursive
traffic share 1
next hop 10.20.20.4, Serial3/0 via 192.168.10.4/32 (Default)
valid adjacency
tag rewrite with
Recursive rewrite via 192.168.10.4/32, tags imposed {18}
0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
internal 0 packets, 0 bytes
302-PE1#
Load Sharing Between P and P Devices
Sometimes network architects desire multiple links between the P and P devices to help distribute load. Different configurations are possible. Multiple links could exist between the same P devices, or multiple links could exist to different P devices. When going from one P device to another, the P device bases the forwarding decision on the MPLS label. With multiple paths, CEF is still the basis for populating the load-sharing table and deciding the ultimate path to a destination. When a P router with multiple outgoing equal-cost paths receives a packet with an MPLS label, it makes the load-sharing decision using the hash of the source and destination IP addresses as inputs in the CEF algorithm. The output of the hash determines which interface and label to use.
On a P router, using the show ip cef exact-route command is not applicable because it requires the presence of the destination IP addresses in the CEF table. As a quick, rough check of load sharing on a P router, an administrator can check the LFIB counters. However, this might not be accurate depending on the design. In later Cisco IOS code, such as IOS Release 12.0(28)S2, the show mpls forwarding-table labels <label> exact-path ipv4 <source ip> <destination ip> command is available to check the path.
Table 7-11 describes the commands used to determine the CEF path.
Table 7-11 Commands to Determine the CEF Path for a Flow
| Device Function | Most IOS Routers | SUP720 |
| IP-to-IP routing | show ip cef exact-route | show mls cef exact-route |
| IP-to-label switching | show ip cef vrf <vrf> exact-route | show mls cef exact-route <vrf> |
| Label-to-label switching | show mpls forwarding-table labels <label> exact-path ipv4 <src ip> <dst ip> | — |
CEF and MPLS VPN Load-Sharing Platform Dependencies
You must consider some platform dependencies when doing load sharing in an MPLS VPN scenario. On Cisco 12000 series routers, each line card makes independent forwarding decisions using hardware-based CEF tables. Therefore, the route calculated in software and viewed using the show ip cef exact-route <src> <dst> command executed on the RP might not be the actual path taken.
Another point is that the Engine 4 MPLS load-sharing mechanism is different from other line cards. The hash uses the destination next-hop address to load-share on the E4 line card instead of the source-destination pair. Therefore, load sharing can occur across the links in the core based on egress PE loopback addresses in an MPLS VPN environment. On E4+, load sharing occurs based on the IP source and destination addresses on a per-flow basis and can be more granular.