Chapter 7: Understanding CEF in an MPLS VPN Environment

Cisco Press

1 2 3 4 5 6 Page 5
Page 5 of 6

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.

Figure 7-7

Figure 7-7

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 FunctionMost IOS RoutersSUP720
IP-to-IP routingshow ip cef exact-routeshow mls cef exact-route
IP-to-label switchingshow ip cef vrf <vrf> exact-routeshow mls cef exact-route <vrf>
Label-to-label switchingshow 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.

Related:
1 2 3 4 5 6 Page 5
Page 5 of 6
SD-WAN buyers guide: Key questions to ask vendors (and yourself)