Chapter 7: Understanding CEF in an MPLS VPN Environment

Cisco Press

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

Consider a case where the PE and CE routers use external BGP to peer to each other's physical address. Note that the example shows a scenario that would require multipath BGP with or without the use of MPLS. CE1 and PE1 are running eBGP to share routes. Example 7-13 looks at the routing table on CE1 to reach the server 10.2.4.1. Although two paths exist to reach 10.2.4.1, only one path is in the routing table. As seen in Chapter 6, CEF will follow the routing table and only install one path in the FIB because that is all that is in the routing table.

Example 7-13 CE1's Routing and FIB Entries for 10.2.4.1

CE1#show ip route 10.2.4.1
Routing entry for 10.2.0.0/16
 Known via "bgp 65001", distance 20, metric 0
 Tag 65100, type external
 Last update from 10.3.1.1 00:04:40 ago
 Routing Descriptor Blocks:
 * 10.3.1.1, from 10.3.1.1, 00:04:40 ago
   Route metric is 0, traffic share count is 1
   AS Hops 2
CE1#show ip cef 10.2.4.1
10.2.0.0/16, version 14, epoch 0, cached adjacency to Serial3/0
0 packets, 0 bytes
 via 10.3.1.1, 0 dependencies, recursive
  next hop 10.3.1.1, Serial3/0 via 10.3.1.0/30
  valid cached adjacency

The issue is that BGP only passes the best path to the routing table. In Example 7-14, the path through 10.3.1.1 is the best one. PE1 passes down both paths through the two BGP neighbor connections. However, BGP on the CE picks only one path as the best path. CEF is only going to use what is specified in the routing table. Therefore, the question is how to get BGP to install both paths in the CE's routing table.

Example 7-14 CE1's BGP Table

CE1#show ip bgp 10.2.4.1
BGP routing table entry for 10.2.0.0/16, version 3
Paths: (2 available, best #2, table Default-IP-Routing-Table)
 Advertised to non peer-group peers:
 10.3.1.5 
 65100 65005
  10.3.1.5 from 10.3.1.5 (192.168.2.2)
   Origin IGP, localpref 100, valid, external
 65100 65005
  10.3.1.1 from 10.3.1.1 (192.168.2.2)
   Origin IGP, localpref 100, valid, external, best

The option is to configure BGP multipath to allow BGP to install both paths in the routing table, as shown in Example 7-15.

Example 7-15 CE1's BGP Multipath Configuration

CE1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
CE1(config)#router bgp 65001
CE1(config-router)#maximum-path 2
CE1(config-router)#end
CE1#
CE1#show run | b router bgp
router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 network 10.1.0.0 mask 255.255.0.0
 neighbor 10.3.1.1 remote-as 65100
 neighbor 10.3.1.5 remote-as 65100
 maximum-paths 2
 no auto-summary
!
!Output omitted for brevity

Note that after adding the maximum-path configuration, CE1 still marks one path as best, but it also marks both paths as multipath and installs them in the routing table. With eBGP multipath enabled on CE1, CE1 now uses both paths to reach 10.2.4.1.

Example 7-16 Verification of BGP Multipath

CE1#show ip bgp 10.2.4.1
BGP routing table entry for 10.2.0.0/16, version 5
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Multipath: eBGP
Flag: 0x800
 Advertised to non peer-group peers:
 10.3.1.5 
 65100 65005
  10.3.1.5 from 10.3.1.5 (192.168.2.2)
   Origin IGP, localpref 100, valid, external, multipath
 65100 65005
  10.3.1.1 from 10.3.1.1 (192.168.2.2)
   Origin IGP, localpref 100, valid, external, multipath, best
CE1#show ip route 10.2.4.1
Routing entry for 10.2.0.0/16
 Known via "bgp 65001", distance 20, metric 0
 Tag 65100, type external
 Last update from 10.3.1.5 00:01:58 ago
 Routing Descriptor Blocks:
 * 10.3.1.1, from 10.3.1.1, 00:10:41 ago
   Route metric is 0, traffic share count is 1
   AS Hops 2
  10.3.1.5, from 10.3.1.5, 00:01:58 ago
   Route metric is 0, traffic share count is 1
   AS Hops 2

CE1#show ip cef 10.2.4.1
10.2.0.0/16, version 15, epoch 0, per-destination sharing
0 packets, 0 bytes
 via 10.3.1.1, 0 dependencies, recursive
  traffic share 1
  next hop 10.3.1.1, Serial3/0 via 10.3.1.0/30
  valid adjacency
 via 10.3.1.5, 0 dependencies, recursive
  traffic share 1
  next hop 10.3.1.5, Serial2/0 via 10.3.1.4/30
  valid adjacency
 0 packets, 0 bytes switched through the prefix
 tmstats: external 0 packets, 0 bytes
      internal 0 packets, 0 bytes

This solves the problem of load sharing in the direction of CE to PE. However, an issue still exists in the direction of PE to CE. To allow PE1 to use both paths to reach 10.1.1.1, multipath would also be required on PE1. Remember that with MPLS VPN, all remote locations would point across the core to PE1 to reach CE1 or destinations behind CE1 if this is the only way known. Without multipath enabled, PE1's LFIB shows the information shown in Example 7-17.

Example 7-17 Verification of PE1's LFIB Without Multipath Configuration

PE1#show mpls forwarding vrf red 10.1.1.1
Local Outgoing  Prefix      Bytes tag Outgoing  Next Hop  
tag  tag or VC  or Tunnel Id   switched  interface       
19   Untagged  10.1.0.0/16[V]  0     Se2/0   point2point

Only one path is known in the LFIB. Look at the routing table and CEF table of PE1 in Example 7-18.

Example 7-18 Verification of PE1's VRF Red Routing and FIB Tables Without Multipath Configuration

PE1#show ip cef vrf red 10.1.1.1
10.1.0.0/16, version 11, epoch 0, cached adjacency to Serial2/0
0 packets, 0 bytes
 tag information set
  local tag: 19
 via 10.3.1.2, 0 dependencies, recursive
  next hop 10.3.1.2, Serial2/0 via 10.3.1.0/30
  valid cached adjacency
  tag rewrite with Se2/0, point2point, tags imposed: {}
PE1#show ip route vrf red 10.1.1.1
Routing entry for 10.1.0.0/16
 Known via "bgp 65100", distance 20, metric 0
 Tag 65001, type external
 Last update from 10.3.1.2 00:02:59 ago
 Routing Descriptor Blocks:
 * 10.3.1.2, from 10.3.1.2, 00:02:59 ago
   Route metric is 0, traffic share count is 1
   AS Hops 1

Only one path is known in the VRF red routing table and the corresponding CEF table. Now, Example 7-19 shows the BGP table for this VRF to verify whether multiple paths are available at that level.

Example 7-19 Verification of BGP Table for VRF Red

PE1#show ip bgp vpnv4 vrf red 10.1.1.1
BGP routing table entry for 1:1:10.1.0.0/16, version 25296
Paths: (2 available, best #2, table red)
 Advertised to non peer-group peers:
 10.3.1.6 192.168.4.4 
 65001
  10.3.1.6 from 10.3.1.6 (10.3.1.6)
   Origin IGP, metric 0, localpref 100, valid, external
   Extended Community: RT:1:1,
   mpls labels in/out 19/nolabel
 65001
  10.3.1.2 from 10.3.1.2 (10.3.1.6)
   Origin IGP, metric 0, localpref 100, valid, external, best
   Extended Community: RT:1:1,
   mpls labels in/out 19/nolabel

Therefore, both paths are in the BGP table, but only one path is available in the routing and CEF tables for VRF red. Example 7-20 shows the configuration for adding multipath for this VRF.

Example 7-20 Multipath Configuration on PE1

PE1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
PE1(config)#router bgp 65100
PE1(config-router)#address-family ipv4 vrf red
PE1(config-router-af)#maximum-path 2

Now, looking at the BGP table in Example 7-21, both paths are marked multipath.

Example 7-21 Verification of BGP Multipath Configuration on PE1

PE1#show ip bgp vpnv4 vrf red 10.1.1.1
BGP routing table entry for 1:1:10.1.0.0/16, version 25298
Paths: (2 available, best #2, table red)
Multipath: eBGP
Flag: 0x800
 Advertised to non peer-group peers:
 10.3.1.6 192.168.4.4 
 65001
  10.3.1.6 from 10.3.1.6 (10.3.1.6)
   Origin IGP, metric 0, localpref 100, valid, external, multipath
   Extended Community: RT:1:1,
   mpls labels in/out 19/nolabel
 65001
  10.3.1.2 from 10.3.1.2 (10.3.1.6)
   Origin IGP, metric 0, localpref 100, valid, external, multipath, best
   Extended Community: RT:1:1,
   mpls labels in/out 19/nolabel

Both paths are in the VRF routing table, VRF CEF table, and LFIB in Example 7-22.

Example 7-22 Verification of Multipath Load Sharing on PE1

PE1#show ip route vrf red 10.1.1.1
Routing entry for 10.1.0.0/16
 Known via "bgp 65100", distance 20, metric 0
 Tag 65001, type external
 Last update from 10.3.1.6 00:01:19 ago
 Routing Descriptor Blocks:
 * 10.3.1.2, from 10.3.1.2, 00:05:40 ago
   Route metric is 0, traffic share count is 1
   AS Hops 1
  10.3.1.6, from 10.3.1.6, 00:01:19 ago
   Route metric is 0, traffic share count is 1
   AS Hops 1
PE1#show ip cef vrf red 10.1.1.1
10.1.0.0/16, version 12, epoch 0, per-destination sharing
0 packets, 0 bytes
 tag information set
  local tag: 19
 via 10.3.1.2, 0 dependencies, recursive
  traffic share 1
  next hop 10.3.1.2, Serial2/0 via 10.3.1.0/30
  valid adjacency
  tag rewrite with Se2/0, point2point, tags imposed: {}
 via 10.3.1.6, 0 dependencies, recursive
  traffic share 1
  next hop 10.3.1.6, Serial3/0 via 10.3.1.4/30
  valid adjacency
  tag rewrite with Se3/0, point2point, tags imposed: {}
 0 packets, 0 bytes switched through the prefix
 tmstats: external 0 packets, 0 bytes
      internal 0 packets, 0 bytes
PE1#show mpls forwarding vrf red 10.1.1.1
Local Outgoing  Prefix      Bytes tag Outgoing  Next Hop  
tag  tag or VC  or Tunnel Id   switched  interface       
19   Untagged  10.1.0.0/16[V]  0     Se2/0   point2point 
    Untagged  10.1.0.0/16[V]  0     Se3/0   point2point

With MPLS VPN, you can use the show ip cef vrf <name> exact-route command to verify the path that traffic takes on the PE, as shown in Example 7-23.

Example 7-23 Path Verification on PE1 from 10.2.4.1

PE1#show ip cef vrf red exact-route 10.2.4.1 10.1.1.1
10.2.4.1    -> 10.1.1.1    : Serial2/0 (next hop 10.3.1.2)

A traceroute from the server 10.2.4.1 confirms that traffic from 10.2.4.1 to 10.1.1.1 is taking the path through Serial 2/0 on PE1. Traffic sourced from 10.2.9.3 to 10.1.1.1 takes a different path, as shown in Example 7-24.

Example 7-24 Path Verification on PE1 from 10.2.9.3

PE1#show ip cef vrf red exact-route 10.2.9.3 10.1.1.1
10.2.9.3    -> 10.1.1.1    : Serial3/0 (next hop 10.3.1.6)

Another way to load-share in this case between the PE and CE routers is to use eBGP multihop. Peering to the loopback addresses through BGP and using statics to reach the loopback address would allow CEF to perform recursion and use both paths.

Using statics or another routing protocol, such as Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), or Routing Information Protocol (RIP), would also be acceptable to enable load sharing in this case. The key is understanding that CEF is a basic building block and that it relies on the routing table. Going from the MPLS network to the CE network (label-to-IP), the PE router has to look into the incoming MPLS packet and perform a hash with the source and destination IP addresses to determine the outgoing interface. Therefore, traffic sharing is still flow based.

Some customers use multilink PPP (MLPPP) instead of CEF to load-share between the PE and CE routers. Check the Feature Navigator or Software Advisor on Cisco.com to verify that support is available for your hardware or software in an MPLS VPN case.

In all cases, adding multiple links between the PE and CE routers can consume memory and CPU resources. Use care when adding links and complexity to avoid network scalability issues.

PE-CE Load Sharing: Site Multihomed to Different PEs

In some cases, it might be necessary to share resources between VPNs with other CE routers connected to multiple PE routers. Importing routes between VRFs enables you to share resources between VPNs by creating an extranet. In such a multihomed environment, it is sometimes convenient to load-share across all known paths. The BGP Multipath Load Sharing feature for both eBGP and iBGP allows configuration for multipath load sharing with both eBGP and iBGP paths in MPLS VPNs. This is called eiBGP multipath.

The eiBGP multipath feature enables core routers to send traffic to destinations through multiple paths using iBGP paths or eBGP paths. In MPLS VPN networks, in a VRF that has paths imported from an eBGP and iBGP path, the PE router can use both eBGP and iBGP paths and install them in the routing table with this feature. Typically, the PEs use only the eBGP paths to reach these CE destinations. Packets sent from the PE router on an eBGP path leave as IP packets, and packets sent on an iBGP path leave as MPLS packets. When the other PE receives MPLS packets, the PE does a label lookup only, so eiBGP multipath does not cause loops. By default, eiBGP multipath performs unequal load sharing by installing multiple paths.

To configure the eiBGP multipath feature, use the maximum-paths eibgp <n> command. This command installs up to n paths if the first autonomous system (AS) is the same and if the appropriate steps in the path selection algorithm are all equal. The multi-exit discriminator (MED) is not part of the criteria to determine whether a path is suitable for multipath because this is a comparison of different sorts of routes.

In Figure 7-6, for traffic in VRF blue going to 10.2.0.0 through PE1, traffic will always use the eBGP path. In Example 7-25, notice that the eBGP path is the only path known through the LFIB and the VRF routing table.

Figure 7-6

Figure 7-6

MPLS VPN Extranet

Example 7-25 Verifying the LFIB and Routing Table for 10.2.0.0

PE1#show mpls forwarding vrf blue 10.2.0.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 
PE1#show ip route vrf blue 10.2.0.0
Routing entry for 10.2.0.0/16
 Known via "bgp 65100", distance 20, metric 0
 Tag 65005, type external
 Last update from 10.9.1.2 00:04:22 ago
 Routing Descriptor Blocks:
 * 10.9.1.2, from 10.9.1.2, 00:04:22 ago
   Route metric is 0, traffic share count is 1
   AS Hops 1

However, looking at the BGP table in Example 7-26, two paths are known: one path through external BGP and the other through the imported path from VRF red learned through internal BGP from PE2.

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