Bgp Multipath Load Sharing For Mpls Vpns Over Ip Tunnels; Inter-As Over Ip Tunnels; Multiple Tunnel Source Address - Cisco CRS Configuration Manual

BGP Multipath Load Sharing for MPLS VPNs over IP Tunnels

Note You must attach a QoS policy to the physical interface—not to the tunnel interface.
If Modified Deficit Round Robin (MDRR)/Weighted Random Early Detection (WRED) is configured for the
encapsulation interface in the input direction, the final value of the precedence or DSCP field in the IP carrier
header is used to determine the precedence class for which the MDRR/WRED policy is applied. On the
decapsulation interface in the input direction, you can configure a QoS policy based on the precedence or
DSCP value in the IP carrier header of the received packet. In this case, an MQC policy with a class to match
on precedence or DSCP value will match the precedence or DSCP value in the received IP carrier header.
Similarly, the precedence class for which the MDRR/WRED policy is applied on the decapsulation input
direction is also determined by precedence or DSCP value in the IP carrier header.
BGP Multipath Load Sharing for MPLS VPNs over IP Tunnels
BGP Multipath Load Sharing for EBGP and IBGP lets you configure multipath load balancing with both
external BGP and internal BGP paths in BGP networks that are configured to use MPLS VPNs. (When faced
with multiple routes to the same destination, BGP chooses the best route for routing traffic toward the destination
so that no individual router is overburdened.)
BGP Multipath Load Sharing is useful for multihomed autonomous systems and PE routers that import both
EBGP and IBGP paths from multihomed and stub networks.

Inter-AS over IP Tunnels

The L3VPN Inter-AS feature provides a method of interconnecting VPNs between different VPN service
providers. Inter-AS supports connecting different VPN service providers to provide native IP L3VPN services.
For more information about Inter-AS, see
Note The Cisco CRS-1 router supports only the Inter-AS option A.

Multiple Tunnel Source Address

Currently, L2TPv3 tunnel encapsulation transports the VPN traffic across the IP core network between PEs
with a /32 loopback addresses of PEs, and ingress PE uses a single /32 loopback address as the source IP
address of tunnel encapsulation. This results in an imbalance on the load. In order to achieve load balance in
the core, the ingress PE sends the VPN traffic with the source IP address of a L2TPv3 tunnel header taken
from the pool for a /28 IP address instead of a single /32 address. This is called the Multiple Tunnel Source
Address.
To support the /28 IP address, a keyword source-pool is used as an optional configuration command for the
tunnel template. This keyword is located in the source address configuration. The source address is published
to remote PEs through the BGP's tunnel SAFI messages.
Once the optional source-pool address is configured, it is sent to the forwarding information base (FIB). FIB
uses a load balancing algorithm to get one address from the pool, and uses that address to call the tunnel infra
DLL API to construct the tunnel encapsulation string.
The Multiple Tunnel Source Address infrastructure uses two primary models:
Cisco IOS XR Virtual Private Network Configuration Guide for the Cisco CRS Router, Release 6.1.x
38
Implementing MPLS VPNs over IP
Implementing MPLS VPNs over IP Tunnels
Tunnels.