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.
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.