Layer 3 MPLS VPN Enterprise Consumer Guide Version 2 - Cisco
Layer 3 MPLS VPN Enterprise Consumer Guide Version 2
Available Languages
Download Options
View with Adobe Reader on a variety of devices
Layer 3 MPLS VPN Enterprise Consumer Guide Version 2
This document is written for networking engineers and administrators responsible for implementing a Layer 3 (L3) MPLS VPN service from a service provider (SP) network. It describes important considerations when choosing an SP and making the necessary connections. This document outlines these considerations, but it is not meant to be a comprehensive design guide.
Note Throughout this document, references to MPLS VPN mean Layer 3 MPLS VPN. The terms &self-managed& and &unmanaged& service are synonymous and refer to a service in which the enterprise customer is responsible for managing the CE devices as well as the devices within each of their sites. Also, the terms &customer& and &enterprise& are also synonymous and refer to the subscriber of the MPLS VPN service.
VPN service offers a cost effective way to expand geographically or to replace expensive dedicated circuits such as leased lines, Frame Relay, or ATM networks. An L3 MPLS VPN service is an attractive option because it provides full mesh capabilities and more bandwidth in the WAN in a more cost-effective manner than legacy TDM or packet switching technologies such as Frame Relay.
This section provides an MPLS VPN primer for enterprise customers looking for a quick introduction to this service. This section includes the following topics:
L3 MPLS VPN services allow businesses to outsource their current network core using a private IP-based service offering from a service provider. Unlike current overlay networks (such as ATM or Frame Relay service offerings), MPLS VPNs require that the enterprise peer with the SP at the IP L3 level. In this scenario, the SP network is involved in the L3 routing of the IP packets delivered by the enterprise.
This capability is implemented through Virtual Routing/Forwarding (VRF) tables for each customer, and MPLS labels to de-multiplex and to tunnel customer traffic through the SP core. Because the SP network participates in the routing of customer traffic, each enterprise must inject its prefixes into the appropriate VRF table in the SP network. The SP is responsible for ensuring that these routes are distributed to the appropriate customer VRF tables.
Routing scenarios can sometimes be complex, such as in a customer hub-and-spoke topology where traffic to and from each spoke is routed through the hub. However, the most common deployment is an any-to-any topology where any customer device can connect directly to the L3 MPLS VPN. Enterprise traffic entering the SP domain is then routed based on the information in the VRF table and encapsulated with MPLS labels to ensure proper tunneling and de-multiplexing through the core.
illustrates many of the acronyms and terms used when discussing L3 MPLS VPNs.
Figure&1 MPLS Layer 3 VPN Component Terminology
defines the acronyms and terms you should understand when designing and implementing an L3 MPLS VPN.
Table&1 L3 MPLS VPN Terminology&
Backdoor connectivity
Either a dynamic or permanent link, outside of the MPLS VPN cloud, over which a routing adjacency is formed to pass routing information that ties two customer domains together. This link is typically used to connect two geographically distinct sites and usually runs the same IGP protocol as the customer site. An example of a backdoor link is illustrated in .
Customer router that is connected only to other customer devices.
Customer edge router that peers at Layer 3 to the provider edge. The PE-CE interface runs either a dynamic routing protocol (eBGP, RIPv2, EIGRP, or OSPF) or a static routing protocol (Static, Connected).
Global routing/forwarding table
The non-VRF routing and forwarding table used in the SP core for infrastructure addressing reachability.
In this document, this refers to an MPLS frame-based label.
Multi-Protocol Border Gateway Protocol. In an MPLS VPN context, this protocol is run between PE routers to exchange customer prefixes in a VPNv4 format.
Managed CE service
Some service providers may offer an added service along with the Layer 3 MPLS VPN offering known as a managed CE service. The SP handles the operations, management, and administration of the CE router at one or more sites. There are typically added charges for what is essentially outsourced management of the CE devices.
Provider router, which resides in the core of the provider network. In an MPLS VPN context, the P router participates in the control plane for customer prefixes. The P router is sometimes referred to as a label switch router (LSR), in reference to its primary role in the core of the network, performing label switching/swapping of MPLS traffic.
Provider edge router. The PE router sits at the edge of the MPLS SP cloud. In an MPLS VPN context, separate VRF routing tables are allocated for each user group. Also, the PE still contains a global routing table for routes in the core SP infrastructure. The PE is sometimes referred to as a label edge router (LER) or edge label switch router (ELSR) in reference to its role at the edge of the MPLS cloud, performing label imposition and disposition.
Route distinguisher, which is a 64-bit value defined uniquely for each user group. The RD is combined with the customer IPv4 prefix to guarantee that the resulting VPNv4 prefix is unique.
Route target, which is a 64-bit value used as a BGP extended community attribute. The RT is used to determine the VPNv4 routes that should be installed in the respective VRF tables.
The combination of the RD and customer IPv4 prefix. These VPNv4 prefixes are passed in MP-BGP.
The virtual routing and forwarding table, which is separate from the global routing table that exists on PE routers. Routes are injected into the VRF from the CE-PE routing protocols for that VRF and any MP-BGP announcements that match the defined VRF route targets (RTs).
Figure&2 Backdoor Link Example
MPLS Layer 3 VPN services offer several advantages, including flexibility, scalability, and cost reduction.
lists some of the high-level advantages and disadvantages of the service. For more detailed information, see the following URL:
Table&2 Advantages and Disadvantages of MPLS Layer 3 VPN Services&
Scalable routing model—The Layer 3 peer-to-peer model reduces the demands on the CE device (low CPU trend, less IDB, and so forth). This is an improvement over the overlay model of a traditional Layer 2 SP offering (ATM and Frame Relay).
IP only—L3 MPLS VPNs transport only IPv4 traffic. Non-IP protocols need to be tunneled through some mechanism (such as GRE) on the CE or C device before reaching the PE.
Scalable bandwidth model—A Layer 3 MPLS VPN model is not limited by the PE-CE media type, but is limited only by the SP infrastructure for PE-CE (for example, Frame Relay, POS, or GE).
SP dependency—The customer is dependent on the SP in regards to Layer 3 features and capabilities. For example, although Cisco offers IP Multicast as a feature for MPLS VPNs (mVPN), not every SP offers it as a service.
Layer 3-based convergence and QoS capabilities are also dependent on the SP offering, and SLAs must be negotiated to manage these requirements.
Reduced total cost of ownership—MPLS cost is lower compared to other solutions because of outsourced networking responsibility and lower service costs (typically 10-40 percent lower).
Possible difficulties in integration—The difficulty of integration from Layer 2 to Layer 3 peering varies greatly depending on the SP offering. For example, EIGRP as a PE-CE protocol is ideal for customers already running EIGRP as their IGP. However, if the SP does not offer this service, integration with a different routing protocol, such as eBGP, might require design changes and training of network staff.
Intelligent QoS—The SP can now provide L3 QoS, which allows more intelligence in the SP core compared to L2 QoS.
Any-to-any connectivity—By peering with the SP at Layer 3, each site (after it is terminated into the SP cloud) can be configured with IP route reachability to all other customer sites. This allows any-to-any connectivity and offers more efficient routing compared to ensuring connectivity between spokes in a traditional hub-and-spoke topology. This is an important advantage where there is a growing trend toward distributed applications and VoIP.
This section briefly examines the L3 MPLS VPN control and data planes, and includes the following topics:
illustrates an example of BGP VPN route distribution using MP-BGP between a VPN that terminates on PE3 and PE7. The customer devices (C1 and CE2 on the left, and CE8 and C9 on the right) participate in the same VPN.
Figure&3 Figure 3BGP VPN Route Distribution
The distribution steps are as follows:
1. Customer routes are injected into the VRF table at PE3 using static, RIPv2, OSPF, or BGP routing protocol between the PE and the CE. The customer routes are passed as IPv4 prefixes (shown in the red shaded box under Step 1).
2. At PE3, the routes in the customer VRF are exported into MP-BGP as VPNv4 prefixes. To ensure VPNv4 route uniqueness, the customer IPv4 routes are prepended with a uniquely defined RD to create a distinct VPNv4 prefix. Every VRF configuration requires an RD to be defined. Its uniqueness guarantees customer VPNv4 uniqueness.
3. The exported routes are sent across the MPLS backbone between the BGP peers in PE3 and PE7. This process repeats for any other BGP peers that have members in the same VPN. Note that this step shows a logical connection between the two BGP peers. There can be a series of BGP route reflectors in between performing the VPN distribution as shown in Steps 3a and 3b.
The VPNv4 prefix (shown in red shaded boxes under Step 3) is composed of the RD and the customer IPv4 prefix. Because this VPNv4 prefix is a BGP route, multiple mandatory and optional BGP attributes are carried along with the prefix. One of these attributes is the route target (RT), which is an extended community BGP attribute.
4. The routes are imported into the correct VRF at PE7. Every VRF configuration contains VRF import and export definitions. The export definitions define which RTs are attached to the BGP VPNv4 prefix, as described in Step 3. The export definitions define the RTs that are carried along with the VPNv4 prefix on export. The import definitions define the RT tagged prefixes that are imported into the VRF. Only VPNv4 prefixes with a matching RT tag to the VRF import RT definitions are imported into that VRF.
5. The routes are accessible from a VPN at each site.
illustrates the process of packet forwarding for a packet originating from the customer cloud containing C1 and CE2 to the far-end customer cloud containing CE8 and C9.
Figure&4 MPLS Data Forwarding Example
1. The customer cloud composed of C1 and CE2 originates an IPv4 packet destined to an address at the far end (CE8 and C9). The routing entry on CE2 for the destination prefix forwards the packet to the PE3 device.
2. PE3 receives the customer packet and does a routing lookup according to the VRF table that is bound to that interface. In this case, the route resolves to a BGP prefix originated from PE7. PE3 imposes two labels on the IPv4 packet. The first label, referred to in this document as the VPN label, (shown in the purple &LB& shaded box) is the label that is used to uniquely identify a customer VPN prefix. The second label, referred to in this document as the forwarding label (shown by the yellow &LB& shaded box) is the label used to tunnel the packet through the P core to the far-end PE7 device.
3. The labeled packet is now forwarded at each hop through the SP core. Each P router makes a forwarding decision based on the top level label, and this top level label is swapped with a new label. This is shown by the yellow &LB& shaded box, and the outgoing packet is shown with a green &LB& shaded box. The underlying packet and inner label are left undisturbed during this process.
4. Eventually, PE7 receives the labeled packet and recognizes the inner VPN label (purple &LB&) as a VPN label for that specific customer prefix. The VPN label is stripped and a forwarding decision for the IPv4 packet is made based on the VPN label.
P5 may remove the top level label, leaving only the inner label when forwarding to PE7. This concept is known as penultimate hop popping (PHP), where the penultimate hop removes the top level label. The relevance to the enterprise is that in a PHP scenario, the SP-marked EXP value may not be copied down to the inner label. This depends on the MPLS QoS mode chosen. This is relevant only if the traffic from the PE to the CE (for example, PE7 to CE8 in ) must be queued based on the SP EXP marking
5. The original IPv4 packet is forwarded by the switch to the appropriate customer VRF interface.
The MPLS label is a 32-bit shim that is inserted between the L2 data link header and the underlying payload (in this case an IPv4 packet).
illustrates the format of the 32-bit label.
Figure&5 MPLS Label Detail
describes each field in this label:
Table&3 MPLS Label Field Descriptions
Allocated for the actual label value.
MPLS experimental bits. A Cisco convention is to use these experimental bits as a means of representing the class of service (CoS) of the MPLS frame.
End-of-stack (EOS) bit. Some MPLS applications such as L3 MPLS VPNs require the use of multiple labels. The EOS is set on the last label in the stack of labels.
Time to live for the MPLS frame. This performs a similar function to an IPv4 TTL.
MPLS VPNs, unlike other VPN types such as IPsec, perform no encryption. Despite this, however, a Layer 3 MPLS VPN service offers equivalent security to that of an ATM/Frame Relay service offering through the use of distinct routing tables and label spoofing mechanisms.
Third-party verification of the security of MPLS can be found at a Miercom study at the following URL:
For further information regarding MPLS security, see the following URL:
When choosing an SP for MPLS VPN services, you must consider your business needs. There is no single best choice for every organization. The best choice is the provider or providers that best meet your organizational needs and that offer the most transparent service. For enterprise customers who have a Cisco Advanced Services (AS) contract a more exhaustive questionnaire is available through the local Cisco AS Network Consulting Engineer (NCE). Enterprise customers without an AS contract should contact their Services Account Manager (SAM).
Note A critical prerequisite before choosing an SP is assessing your business requirements, environment, and objectives. Invest the time to understand your network, its underlying infrastructure, and application needs. You should also know the network and application requirements of branch networks and other remote locations.
This section describes some criteria to consider when selecting a provider, and includes the following topics:
This section describes the general architecture and services you should consider when selecting an SP. It includes the following topics:
A great starting point is to consider providers that are designated as Cisco Powered Networks. Service providers that display the Cisco Powered logo are uniquely positioned to help customers migrate to MPLS-based VPN services. These providers have earned the Cisco Powered designation by maintaining high levels of network quality and by basing their VPN services end-to-end on Cisco equipment.
In addition, an increasing number of Cisco Powered providers have earned the QoS Certification for VPN services. This means that they have been assessed by a third party for the ability of their SLAs to support real-time voice and video traffic, and for their use of Cisco best practices for QoS. Look for the QoS Certification as an extra indication that you can have confidence in the Cisco Powered provider.
Nearly 400 of the most successful service providers throughout the world offer services that have earned the Cisco Powered designation. Situated in 62 countries, these providers offer a wide range of services for both small and large businesses. From the basics, such as Internet access and web hosting, to managed services such as IP telephony and multiservice VPNs, these providers should be your first choice when you need to outsource a critical business function. For a list of recommended service providers, see the following URL:
Many companies need to expand their data networking to remote sites, data centers, or branch offices. Connectivity requirements may also span many regions in various countries. However, the services that specific providers offer may be limited geographically. Providers tend to offer more services in their home regions, and services are harder to obtain for remote regions. When evaluating L3 MPLS VPN services, you should understand the PE coverage and consider which cities around the world the PE routers used for customer connections are located. In many cases, providers have partners that provide local access. It is important to consider the locations where these partners provide PE routers, and to make sure this meets your organizational needs.
To establish a larger global footprint, providers may establish partnerships with other service providers to interconnect MPLS VPN networks. This is known as an interprovider MPLS VPN.
However, inter-AS MPLS VPNs can affect the availability or behavior of services such as QoS and Multicast. One provider may support these services in a different manner than the other, or a provider might not support a service at all. Therefore, it is important to consider SP inter-AS agreements and whether the implementation supports your network requirements.
Whether the MPLS VPN service is a managed CE service or not, the customer and the provider must agree about IP addressing on the CE-PE links. The service provider typically assumes the responsibility for determining the addresses to use. The SP may approach the address assignment in various ways, including the following:
oPrivate address space (RFC 1918)—In this scenario, addresses must be carefully assigned to prevent conflicts with RFC 1918 addresses used by the customer.
oUnnumbered addressing on the link—Although this may seem to be a good approach to save on address space, this approach causes a problem for network management devices, which are not able to capture a view of the PE-CE link. The use of unnumbered addressing requires the use of other addresses assigned to interfaces in the same routing table. This requires additional loopback interfaces for each VRF on the PE routers.
oSP address space—This allows each PE-CE link to have unique addresses but may require a large amount of address space.
oCustomer address space—This also allows for each PE-CE link to be addressed uniquely. However, this may get complex if the address space used by the customer is RFC 1918 address space that overlaps with RFC 1918 addresses used by the SP. The SP may be required to configure their management devices to deal with overlapping addresses.
Whatever approach is taken for assigning PE-CE addresses, careful coordination between the SP and the customer is essential. Otherwise, IP connectivity issues or network management problems may occur.
Layer 2 WANs were often designed in a hub-and-spoke topology because of historical costs and capability constraints. In this topology, spoke sites are not able to communicate with each other directly and can communicate with each other only through the hub site.
Customers may wish to maintain a hub-and-spoke model even after converting to an MPLS VPN. SP implementations of hub-and-spoke MPLS VPNs can force spoke site traffic to route through a centralized hub site to reach other spoke sites. Such routing behavior may be critical for centralized services such as firewalling spoke-to-spoke traffic. However, because MPLS VPNs typically offer any-to-any connectivity, creating a hub-and-spoke topology adds a level of complexity to the service.
Extranet support involves importing routes from one VRF into a different VRF that may service a different VPN site. Extranet VPNs support dynamic connectivity between your network and other networks subscribed to the same provider. This could be helpful for creating extranets with partners or vendors.
Remote access to the MPLS VPN lets service providers extend services to the last mile using a broad range of access options, including dial-up, DSL, and cable technologies. This lets remote users securely access the corporate intranet and extranet using an MPLS VPN.
Customers with remote workers should consider whether the SP offers remote access to the MPLS VPN. The customer may also be interested whether the solution allows IPsec termination for connecting to the customer network. SPs that offer dial access or IPsec termination into the customer network can be used for outsourcing support for existing dial-up and remote office telecommuters.
You should also consider how the SP protects against primary MPLS VPN connectivity failures. Some L3 MPLS offerings may include a backup service that terminates in the customer VRF. Other offerings may provide an external leased line, in which case it is not integrated into the VRF.
In the latter case, or in cases where no backup is provided, the customer must implement their own backup mechanism (leased line, DMVPN, second provider), and a backdoor connection may be required. When using a backdoor connection, it is critical to understand how your backup mechanism works to avoid potential routing loops or sub-optimal routing.
When choosing to move to an MPLS VPN environment, customers must consider any legacy applications, such as SNA or DECnet, that they are required to support. Because the MPLS VPN architecture supports only IP traffic, how the SP provides non-IP traffic support is critical when legacy applications must be supported.
The SP may require the customer to maintain the existing Frame Relay or ATM network for legacy applications. On the other hand, the provider can support legacy applications using GRE tunneling to facilitate transport over the MPLS VPN network. GRE tunneling adds a layer of complexity to the architecture that may be best handled by having the SP manage the CE routers. This places responsibility for configuration and maintenance with the SP.
Businesses that move to MPLS VPNs can often choose to purchase a &managed& CE service from an SP, which can handle part or all of the requirements for installation, provisioning, management, and security of network equipment. Managed services provide enterprise customers immediate access to the benefits of an MPLS network, with network availability and security being managed by the SP.
With a managed CE service, it is important to understand the limits of administrative control of the CE device. Customers may not be allowed to make any changes to the CE router, or there may be feature restrictions placed on the managed CE. If so, you should know the turnaround time for necessary changes or features to be deployed by the SP. You should also understand the visibility provided into the router because this affects your ability to troubleshoot network problems.
Everything described in , can potentially be included or negotiated in a service level agreement (SLA). The purpose of this subsection is to discuss SLAs in general.
An SLA sets the expectations between the provider and the customer. As an MPLS VPN customer, look for an SLA that answers the questions that are important to you, which may include the following:
oWhat is the provider is committed to deliver?
oHow will the provider deliver on commitments?
oWhat is meant by network availability? Is it CE to CE, PE to PE or CE to PE?
oHow are network performance agreements defined and measured? For example, is latency measured from CE to CE or PE to PE?
oAre any monitoring tools offered by the SP?
oWhat happens if a provider fails to deliver as promised?
oHow quickly does the SP respond to network problems?
oHow quickly do they respond to business growth needs by adding sites or equipment?
SLAs should not be limited to network performance and availability, but should encompass support and growth.
The details of an SLA may vary, but it should meet the specific requirements and network application needs of the customer. The following are some examples of network performance deliverables that might be negotiated:
oBandwidth
oLatencies
oPacket drop
oNetwork availability
oSLA reporting
SLAs should be based on realistic and measurable commitments. Having the ability to measure against the commitments ensures the success of the agreement. Defining what should be measured, how and when it should be measured, and how these measurements are reported eliminates any confusion or wasted effort regarding data collection. Clarity regarding the data facilitates the negotiation of penalties for non-performance.
When implementing an L3 MPLS VPN service, it is important to understand whether any changes are needed to the routing protocol used by an enterprise customer, how this protocol interacts with the SP, and other routing issues. This section describes some general issues and includes the following topics:
Specific details and considerations to keep in mind when implementing the L3 MPLS VPN are described later in this document.
SPs may impose limits on the number of routes that can be advertised by the customer. It is important to understand what these limits are and what notifications, warnings, or repercussions occur if the limits are exceeded.
If route limits are imposed, take careful note of any summarization that may be broken when the network is transitioned to the SP L3 MPLS VPN service. This is especially important in the case of hub-and-spoke enterprise designs where the hubs summarize the spoke address assignments. When the spoke sites transition to a Layer 3 MPLS VPN service, this summarization may break and the number of entries in the enterprise routing table may increase, depending on the original level of summarization.
Because a Layer 3 MPLS VPN service offering interacts with the SP at Layer 3, some routing environment considerations must usually be taken into account. This occurs when using a routing protocol on the PE-CE link that is different from the IGP used in the current enterprise environment. For example, an enterprise might use EIGRP as their IGP and eBGP as the PE-CE protocol. In this scenario, there must be careful consideration of administrative distance, redistribution between EIGRP to/from eBGP, and routing loops that might occur.
When backdoor connectivity (connectivity outside the MPLS VPN service) is used, there is potential for problems such as routing loops or sub-optimal routing. Depending on the protocol being used on the PE-CE link, various methods for implementing backdoors are available, but you need to understand what is supported by the SP. For example, are OSPF Sham Links supported? Does the PE support BGP cost community or Site of Origin (SoO)?
Because the SP in a Layer 3 MPLS VPN service is participating in routing with the enterprise, routing convergence depends on the SP network routing convergence. Some SPs do not provide a convergence SLA, but you should still understand the approximate convergence times for failures such as PE-CE link failure or CE route withdrawal. You should find out whether there is any flexibility in adjusting convergence times, and ensure that they are acceptable for your application needs.
When a site (CE) is connecting to multiple PEs, it makes sense to use all the links. CE-PE load balancing is controlled by the enterprise. PE-CE load balancing is controlled by the SP, so you should find out whether the SP supports this.
BGP multipath features employed in the SP environment let you load balance PE-CE traffic. Such load balancing lets the PE router forward against multiple BGP routes for the same customer prefixes, assuming they meet the BGP multipath requirements. This feature allows for load balancing across multiple BGP paths, but at the loss of determinism regarding the path traffic takes for a specific destination. For further information, see the following URL:
Without this load balancing feature, BGP normally selects a single best path, which may overload traffic on one link. One way to avoid this requires you to decide the prefixes that are preferred over each link in a multihomed environment. This solution requires the high administrative overhead of specifying prefixes, attribute setting, and so forth, but provides deterministic traffic flow.
Multihop eBGP can also be a useful load balancing tool. When multiple links exist between the CE and PE, eBGP can be configured between the loopbacks of the PE and CE routers. For more information, see the following URL: /en/US/tech/tk365/technologies_configuration_example45bf.shtml.
Access to the MPLS VPN network is provided over a link between the CE and PE routers. Service providers usually offer a wide range of connectivity options, such as Frame Relay, ATM, and Ethernet. This section describes some of the Layer 2 access options and includes the following topics:
You should consider the existing Layer 2 capabilities available at various sites, and whether the provider can offer connection options to match these capabilities. Otherwise, the cost of establishing Layer 2 connectivity to these &unmatched areas& should be considered.
You should also consider the range of access speeds supported in each access method, and whether the purchased access speed is less than the access method speed. For example, you might purchase a 30&Mbps rate on a 100 Mbps Fast Ethernet access method. In this case, some SPs perform traffic policing to enforce the purchase rate. This requires the CE to perform shaping to avoid overrunning the policer configured on the PE. In a managed CE environment, traffic shaping is configured by the SP.
It is important to understand the link failure detection mechanisms provided by the access methods used in a specific deployment. Access methods may have an inherent Layer 2 keepalive mechanism that supports link failure detection. Some access methods, such as Ethernet, may not appear down in the event of a failure on one end, which makes it difficult to detect failure. This depends on the physical configuration and the available features, such as Bidirectional Forwarding Detection (BFD).
The support for end-to-end QoS provided by MPLS helps ensure that critical networking traffic is given the appropriate priority through the network. You should discuss your requirements related to the types of traffic that need specific priorities.
It is important to understand the classes of service (CoS) that are available in the SP network. Can CoS values sent from the CE to the provider network be preserved until they reach the remote CE? If not, is it possible to map the CoS values used by the customer to the CoS values used by the SP so that they can be mapped back to the customer values at the opposite end of the VPN?
As mentioned earlier, providers may partner with other providers to interconnect MPLS VPN networks to provide global services, and these partnerships may affect QoS. Assignment of CoS values may differ from one provider to another, making it necessary to translate CoS values between providers. This is something that is typically made possible by the agreement between the MPLS VPN providers. This agreement must specify CoS equivalencies. You should understand these values and equivalent values to ensure that the SP QoS capabilities are sufficiently transparent to support your requirements.
Multicast allows information to be efficiently distributed between a single multicast source and many receivers. Multicast has many uses, including financial applications, software downloads, and audio and video streaming.
Initially, MPLS VPNs did not support IP multicast traffic. In early deployments, support for multicast traffic was provided through GRE tunnels. GRE tunnels were built between CE routers, and all multicast traffic between VPN sites was encapsulated using GRE. However, in this scenario, optimal multicast routing requires a full mesh of GRE tunnels, which is not scalable or manageable with a large number of VPN sites.
Multicast VPN (mVPN) provides a more scalable method of transporting multicast traffic between VPN sites. The details of mVPN can be found in the Multicast VPN Design Guide at the following URL:
You should know whether the provider supports mVPN as part of their MPLS VPN services. If not, what alternative solutions do they provide for multicast?
If mVPN is supported, are data multicast distribution trees (data MDTs) used? If so, what is the threshold and how many data MDTs are configured for customer data streams? A data MDT is a group that is dynamically created when the customer multicast traffic stream exceeds a configured threshold on the PE. The purpose of the MDT is to restrict transmission of a stream to the remote PEs that are interested. These numbers are important because when the throughput of the customer stream surpasses the data MDT threshold and the maximum number of data MDTs already exists, the group addresses are reused. This may mean that some PEs receive CE data to which they have not subscribed.
Are Auto-RP and bootstrap router (BSR) supported? BSR messages should not be exchanged between different domains, because routers in one domain may elect rendezvous points (RPs) in the other domain, resulting in protocol malfunction or loss of isolation between the domains.
MPLS VPN networks provide the same level of security as L2 VPN networks such as Frame Relay and ATM. MPLS VPN networks offer address space separation, routing separation, and are resistant to attacks and label spoofing. In an MPLS environment, a VPN customer may perform IP source address spoofing, but because there is a strict separation between VPNs and between the VPN and the core, this type of spoofing remains within the VPN where it originated. However, because MPLS VPN networks are part of a shared infrastructure, there are security considerations when evaluating an SP. This section describes some of these issues and includes the following topics:
Are Internet and VPN access provided over the same core infrastructure? It is helpful to understand the security measures in place to avoid having one network service affecting the other.
A VPN-only service is more secure because there is no chance of attacks from the Internet. However, the level of risk associated with a shared core infrastructure is acceptable for most customers. The SP may offer separate PE routers for Internet and VPN access. However, this usually comes at a higher cost to the customer.
It is important to MPLS VPN customers that the SP core is protected from outside attacks. This prevents attackers from using the SP core to attack the VPNs. You can ask the SP to disclose information about the security of their infrastructure when evaluating the SP.
What policies are in place to prevent deliberate or accidental misconfiguration within the SP that may expose the customer VPN to attacks from the Internet or other VPNs? MPLS VPNs are as secure as L2 VPNs, but people make mistakes. It is important that the proper policies are in place to mitigate the risks.
If choosing a managed CE service, the task of connecting to the service is placed on the service provider. However, you should understand the necessary considerations because many of them involve you. This section includes the following topics:
Migrating from a traditional Layer 2-based VPN such as Frame Relay or ATM, where the service provider does not participate in Layer 3 routing with the enterprise, to a Layer 3 MPLS VPN service, where the provider does participate in Layer 3 routing with the enterprise, offers several challenges. IT managers who want to take advantage of the benefits of Layer 3 MPLS VPNs are looking for guidance on how to plan for these challenges and how to manage the migration as transparently as possible. This section addresses some of the steps that should be taken to assist in a smooth migration. Because every enterprise migration case is different, the examples in this section emphasize some of the more important things to consider to help facilitate your own migration.
When you are considering migration, it is assumed that you have completed the task of actually choosing a service provider that meets the needs of your enterprise. As part of making this decision, you now have a good idea of what services the provider offers. You can now focus on assessing your network and identifying some of the important elements and requirements of the network that determine the overall complexity of the migration, such as the following:
oKnowing your internal site routing protocols and your options of PE-CE routing protocols offered by your provider. If your current internal routing protocol(s) are different from what the provider allows on the PE-CE links, some form of redistribution is required, unless you have the option to change your internal routing protocols.
oWhich enterprise sites will be multi-homed or need redundancy? Is load-balancing required for these sites? The enterprise may decide to multi-home some sites, while other sites might be single-homed only to the provider.
oDo any sites require backup services? Are these services provided by the service provider or by the enterprise?
oIf backup needs are provided by the enterprise, maintaining part of the existing network may provide the backup capability. Identify the parts of the existing network that will be maintained.
oIdentify temporary transit sites. The purpose of the transit site is to allow migrated sites to communicate with non-migrated sites. Typically, hub sites or sites that get the most traffic, such as data center sites, are selected as transit sites.
After the existing network elements and requirements have been assessed, you can compare your findings with what the service provider is currently offering to help plan the migration. For example, if you have determined that some sites require a high-speed backup solution but the service provider does not provide backup services, you must develop an in-house solution.
After the existing network elements have been assessed, you can start looking at the physical migration from the existing WAN core to the L3 MPLS VPN of the service providers, which is the first step of migration.
The physical migration starts with the site or one of the sites that have been designated as a transit site. In , Site 3 is a hub site that has been selected as a transit site for traffic between Sites 1 and 2.
Figure&6 Selecting the Transit Site
Start by provisioning a new circuit that attaches the CE at Site 3 to the PE in the MPLS network of the service provider. The original circuit into the original WAN stays intact at this time. Site 3 is the transit site, which means that it maintains connectivity between the sites that have migrated and those that have not. Because of this, the new PE-CE circuit that is provisioned must have enough bandwidth to accommodate the extra traffic.
After the new circuit has been provisioned for the new PE-CE link, Layer 3 connectivity over that link should be established. If a routing protocol is used over the PE-CE link, the RP peering can also be established at this time. The routing protocol to be run over this link is most likely determined by what the service provider supports. As previously mentioned, if this routing protocol is different from what is running internally to the site, some redistribution is required, and steps should be taken to avoid routing loops or sub-optimal routing that can occur with redistribution. PE-CE routing considerations are discussed subsequently in this document.
At this point, Layer 3 connectivity and RP peering have been established over the new circuit. Traffic between the sites continues to use the original WAN because no routing information is being exchanged over the MPLS network at this point.
shows the state of the topology with the new circuit established.
Figure&7 New Circuit Established
You can now migrate another site. In this case, Site 2 is chosen. Again, a new circuit is provisioned that attaches the CE at Site 2 to the PE in the MPLS network of the service provider. The existing connection stays intact, as shown in .
Figure&8 Migrating Site 2
After the physical circuit is in place, Layer 3 connectivity over the new link needs to be established. In most cases, the same routing protocol that is used over the Site 1 PE-CE link is also used on this link. Site 2 now has two connections to Site 3. One connection is via the new MPLS network, and a second is via the original WAN network. Routing information now gets exchanged over the MPLS network as well as over the original network. If at this point traffic is not flowing over the MPLS network, it may be necessary to influence the routing by manipulating some of the routing metrics so that the path over the MPLS network is the preferred path between Site 2 and Site 3. After the path through the MPLS network is established as the preferred path, the Site 2 connection to the original WAN can be disconnected.
At this point, you can see why Site 3 is called a transit site, as shown in .
Figure&9 Using Site 3 as the Transit Site
In , Site 1 is still communicating with Site 3 and Site 2 through the original WAN network, while Site 2 is now communicating with Site 3 and Site 1 through the new MPLS network.
Migrating Site 1 is your next step. Following the same procedure as before, first establish a new circuit to the MPLS network and then establish Layer 3 connectivity over the new circuit. After the new path over the MPLS network has been established as the preferred path, the original circuit can be disconnected, resulting in the network shown in .
Figure&10 Original Circuit Now Disconnected
This site-by-site approach can be followed until all sites have been migrated.
Because CE-PE routing protocols are a crucial piece to Layer 3 MPLS/VPNs, the next section describes their behavior in this environment.
This section includes the following topics:
BGP is one of the most common protocols used for routing between CE and PE devices. This section lists some important considerations to keep in mind when using BGP as the PE-CE protocol, and includes the following topics:
BGP requires that each BGP speaker be identified by an Autonomous System (AS) number. After choosing BGP as your PE-CE protocol, you must next determine the BGP AS allocation scheme. The selection of a BGP AS number for enterprise sites is an important consideration because it affects other aspects of network behavior, including load balancing, route-loop avoidance, and site characterization over the origin AS.
Most SPs offer two options for AS allocation:
oThe same BGP AS for every customer site
oA unique BGP AS for each customer site
These options are illustrated in . The left side shows an enterprise where every customer site uses AS 64520 to form an eBGP peering relationship with the SP, which uses AS 1379. The right panel illustrates an enterprise that allocates a unique AS for five sites, using the range 64512 through 64516.
Figure&11 BGP AS Allocation Schemes
One of the main advantages of allocating a unique AS per site is that you identify the originator of the route by noting the origin BGP AS in the AS PATH attribute. This quick identification simplifies troubleshooting. Furthermore, easy origin identification allows simple AS-path filters to perform BGP route manipulation for a particular site.
However, a unique AS for each site limits the number of BGP speaking sites to the number of available BGP AS numbers. The available BGP range depends on the enterprise and the willingness of the SP to support public BGP AS numbers (1-64511). You should normally use the private BGP AS range () and never use BGP AS numbers unless they are registered to you. However, with an L3 MPLS VPN service, using unregistered AS numbers may not be a problem if the BGP MPLS VPN announcements are not injected into the public Internet routing table.
One of the advantages of using the same AS for every site is that it reduces the chance of AS collisions. However, the use of the same AS for every customer site also creates some complexity.
A BGP speaker performs AS loop prevention by verifying that the AS PATH contains its own AS number. This is illustrated in , where Site 2 rejects a prefix originated from Site 1 because CE-2 recognizes its own AS (65001) in the AS PATH of the received route for 192.168.0.5/32.
Figure&12 BGP AS-PATH Loop Prevention
To use the same AS number for every customer site, AS loop prevention must be disabled. This is typically done by requesting that the SP adjust the AS PATH through the use of the as-override command. This is illustrated in , where PE-2 is configured with as-override. PE-2 replaces the neighboring peer AS CE2 (65001) with its own AS (100), when it is detected anywhere along the AS-PATH attribute of the advertised BGP route.
Figure&13 AS-Override Example
Mechanisms such as AS-override produce some additional complexity and configuration requirements on the SP. Another issue when using AS-override is that none of the BGP routes can be uniquely identified as originating from a specific site based on the AS-PATH. If the CE must identify the origin of the route based on some attribute, other mechanisms, such as BGP standard communities, should be considered. However, the latter option introduces additional configuration on the CE.
Rewriting the AS PATH essentially prevents the CE router from detecting a BGP loop, and can create problems in multihomed sites.
illustrates a case where a route loop occurs. Site 3 originates the N3 route. CE4 advertises the N3 route to PE3, passes it to PE4, PE1, and PE2, which then advertise it to their respective CE routers. Unfortunately, in the case of CE3, the N3 route is received and accepted because the AS-PATH has been adjusted. This creates a route loop because the N3 route is advertised back into Site-3, which originated the route.
Figure&14 BGP Route Loop with AS-override
Site of Origin (SoO) can be used to avoid an AS-override induced route loop. SoO is an extended community attribute attached to a BGP route used to identify the origin of the route. If the attached SoO is equal to the configured SoO for a BGP peering, the route is blocked f thereby avoiding a route loop. An example of SoO is shown in .
Figure&15 Site of Origin (SoO) Example
The PE4-CE3 and PE3-CE4 BGP peerings are configured with a SoO value of 100:65003. This configuration performs the following logic:
1. Any BGP advertisement received from these neighbors has an attached SoO equal to the configured value.
2. A check is performed on any BGP advertisement to these neighbors so that a loop is detected and the advertisement is blocked if the configured SoO value equals the attached SoO value.
The BGP route for N3 is received and the SoO value is attached to this route. PE3 propagates this route to PE1, PE2, and PE4. Note that the configured SoO for the PE1-CE1 and PE2-CE2 neighbor relationships are configured with SoO values of 100:65001 and 100:65002 respectively. Both PE1 and PE2 still advertise the N3 BGP route to their respective CEs because the configured SoO values do not match the attached SoO on the N3 route (100:65003). However, PE4 does not advertise the route to CE3 because the configured SoO for the PE4-CE3 neighbor relationship (100:65003) is equal to the attached value for the BGP N3 route.
The advantages and disadvantages of the various AS allocation methods are summarized in .
Table&4 Advantages and Disadvantages of AS Allocation Methods
Unique AS per site
Allows simple identification of route originator through the origin AS in AS-PATH attribute
Limits the number of customer sites to the number of available BGP AS
May require allocation of AS numbers outside of private AS range ()
Requires more careful tracking of BGP AS allocation to avoid AS collision
Same AS per site
Reduces likelihood of AS collision when multiple providers are used
No site unique characteristic can be inferred from the AS-PATH
Requires SP to rewrite AS-path via the use of AS-override (or customer configuration of allow-as)
The use of AS-override or other mechanism essentially disables BGP AS loop prevention check, so alternate loop prevention mechanisms must be employed, such as SoO
This section describes how a backdoor link between customer sites is used, and the implications when implementing an L3 MPLS VPN.
illustrates this topology.
Figure&16 Using a Backdoor Link with BGP
In this topology, two customer sites are connected to an MPLS VPN cloud. Each of the sites is running its own IGP. BGP is the PE-CE routing protocol. A network is being advertised from Site 1. PE1 receives this network from eBGP and in turn advertises it to PE2 through MP-iBGP. CE2 then receives it through eBGP from PE2. 10.1.0.0/16 is then redistributed into the Site 2 IGP as an external route.
At the same time, router C2 is receiving 10.1.0.0/16 from C1 through IGP. This routing update is an internal route. Now Site2 has two routes for 10.1.0.0/16: an external route from CE2, and an internal route from C2. Therefore, traffic in Site 2 destined for 10.1.0.0/16 uses the backdoor link because the internal route is preferred over an external route. This is not the desired behavior.
The backdoor link may exist from a legacy infrastructure and can be removed to solve the problem. But in many cases, backdoor links exist to provide redundancy and cannot be removed. One way to solve the problem is to summarize the routes on the backdoor link as shown in .
Figure&17 Summarizing Routes on a Backdoor Link
In this example, the external route for network 10.1.0.0/16 is still received from CE2. However, now on C1, the route is summarized to 10.0.0.0/8, and C1 receives the summarized route. Now traffic in Site 2 destined for 10.1.0.0/16 uses CE2 as the exit router because a more specific route is being received from CE2. The backdoor link is used only if the more specific route is lost.
Note Summarization requires special configuration when using OSPF. For OSPF, summarization is possible only on area border routers (ABRs). Therefore, to summarize you need to make C1 and C2 into ABRs. This means that the backdoor link is in area 0 while Site 1 and Site 2 are in a non-zero area or vice versa. Another possible solution for OSPF is running a different routing protocol between C1 and C2, and doing summarization while redistributing.
When a customer site is running an IGP and BGP is used as the PE-CE protocol, mutual redistribution must be done on the CE between the IGP and BGP. This can cause routes to get redistributed back into BGP, potentially creating routing loops. It is therefore recommended to use proper filters during mutual redistribution. Filters should be configured so that only site-specific routes are allowed to get redistributed into BGP, as shown in .
Figure&18 Using Filters to Prevent Loops
Similarly, if a backdoor link exists as shown in , there is a chance for routes originated in Site&1 to be learned back from C2. Therefore, you need to put filters on C1 and C2 to filter routes originated within the respective sites.
OSPF has been used as an IGP for a long time. This section discusses what you should consider when using OSPF as a PE-CE routing protocol.
In MPLS VPN networks, the OSPF process ID should match. Otherwise, external Type 5 routes are generated. In , two organizations have merged. In this scenario, Site 2 expects Type 3 inter-area routes from Site1 from PE2 but instead receives external Type 5 routes. This happens because the OSPF process ID is different on the two sites.
When implementing an L3 MPLS VPN, the SP cloud appears as a single router from the OSPF perspective. Instead of removing and reconfiguring the OSPF process, the SP may configure the same domain ID on both ingress and egress PEs to solve the problem.
Figure&19 Sites with Different OSPF Processes
When Net-1 is advertised from CE-1 to PE1 as an OSPF LSA Type 1, the PE1 router converts it into an MP-iBGP update and advertises this update to PE-2. PE-2 converts this to LSA Type 5 when it sees that the OSPF process ID of the destination is different. In this scenario, CE-2 receives an OSPF external route and this should not happen. If you configure the same domain ID on both PE-1 and PE-2 under the OSPF configuration, this problem can be solved without any further OSPF configuration changes. After making this change, CE-2 receives Net-1 as an inter-area OSPF route.
This section describes two types of OSPF summarization: ingress-side summarization and egress-side summarization.
Ingress PE-Based Summarization
If an MPLS VPN customer running OSPF as a PE-CE protocol wants to send a summary route to all other sites, it cannot be done because there is no ABR at the site. In this case, the PE router connected to this site can summarize in BGP and advertise the aggregate to all other sites. This is shown in .
Figure&20 Ingress PE-Based Summarization
CE-1 wants to send a summary route for 10.1.1.0 through 10.1.255.0 as 10.1/16 to all other sites from Site1/Area 1. PE-1 can summarize this address space in BGP and advertise an aggregate block to all other sites. CE routers at other customer sites see the aggregate as an external OSPF route.
Egress PE-Based Summarization
If an MPLS VPN customer running OSPF as a PE-CE protocol wants to send a summary route to only one or few sites, this cannot be done because there is no ABR at the site. In this case, the egress PE router connected to this destination site can summarize in BGP and advertise the aggregate to that site. This is shown in .
Figure&21 Egress PE-Based Summarization
The customer needs to send a summary route to Site3-Area3. The customer cannot summarize from each individual site because there is no ABR within the sites at Area 1 or Area 2. In this scenario, the customer can ask the SP to summarize routes on PE3 for routes destined to Site3.
Loop Scenario
In another case, shown in , the summary may originate in OSPF. The summary route 10/8 is propagated to all customer sites as a result of redistribution from OSPF into BGP. This can result in sub-optimal routing or routing loops.
Figure&22 OSPF Route Summarization May Create a Routing Loop
To prevent this situation, the summary route should be filtered while redistributing OSPF into BGP on PE3, unless it is desirable to send the summary to selected PEs. This can be done by using a route map called &block_summary&. This solution is shown in .
Figure&23 Using a Route Map to Prevent a Routing Loop
This section describes a few important concepts about the interaction of OSPF areas and the MPLS VPN backbone.
MPLS VPN Backbone Considered Area 0
Because the MPLS VPN backbone is considered Area 0, you do not necessarily need Area 0 at any site. Any Type 1 and Type 2 LSAs going across the MPLS VPN backbone are converted into Type 3 LSAs. Type 5 LSAs and external routes are received across the MPLS VPN backbone by the receiving OSPF routing process as Type 5 LSAs. This is shown in , where a Type 1 LSA is converted to a Type 3 LSA as it goes across the MPLS VPN backbone.
Figure&24 MPLS VPN Backbone Considered Area 0
Area 0 Adjacent to MPLS VPN
Area 0 must be adjacent to MPLS VPN or have a virtual link between Area 0 and the MPLS VPN backbone. The Area 0 site can be connected to the MPLS VPN backbone. However, if Area 0 exists, it must touch the MPLS VPN PE routers.
shows this.
Figure&25 Area 0 Must Connect to the MPLS VPN Backbone
If Area 0 is not adjacent to the MPLS VPN backbone, you should set up a virtual link between Area 0 and the MPLS VPN backbone.
Note OSPF rule—Summary LSAs from non-zero areas are not injected into backbone Area 0. Therefore, inter-area routes do not appear unless a virtual link is created.
The scenario with a virtual link between Area 0 and the MPLS VPN backbone is shown in .
Figure&26 Virtual Link Between Area 0 and the MPLS VPN Backbone
Sites in the Same Area Without a Backdoor Link
In the scenario illustrated in , the LSAs received at the sites are Type 3 LSAs (because any LSA transported across the MPLS VPN backbone are at least LSA Type 3), even though both sites are in the same area. If this is not desirable, you should consider using an OSPF Sham Link as shown in .
Figure&27 Using an OSPF Sham Link
Sites In the Same Area With a Backdoor Link
In , the OSPF route is advertised to the MPLS VPN backbone. The same prefix is learned as the intra-area route over the backdoor link. PE2 does not generate Type 3 LSAs after a Type 1 LSA is received from the site. In this scenario, traffic is sent over the backdoor link instead of the MPLS VPN cloud.
Figure&28 Sites in the Same Area with a Backdoor Link
Sites in the Same Area with Backdoor and Sham Links
A sham link is treat it is a point-to-point and demand-circuit type link. OSPF adjacency can be established over a sham link. A sham link is reported in the router Type 1 LSAs originated by the two routers connecting to the sham link. Any Type 1 and Type 2 LSA advertised over the sham link remains as Type 1 or Type 2. The MPLS VPN backbone or the backdoor link can be made the preferred path by adjusting the metrics.
illustrates this scenario.
Figure&29 Using a Sham Link with a Backdoor Link
EIGRP is another IGP used by many enterprise customers. This section specifically discusses what you might expect with EIGRP in an L3 MPLS environment, as well as backdoor connectivity for EIGRP. Backdoor connectivity between customer sites often causes problems for enterprises that run EIGRP as their PE-CE protocol. Typically, the intention is to use the L3 MPLS VPN service as the primary means of connectivity and the backdoor as a backup link. However, in backdoor scenarios with EIGRP as the PE-CE protocol and EIGRP over the backdoor link, the backdoor link may be preferred without some manipulation of the customer route. A feature known as BGP Cost Community can be implemented on the PE routers to add an additional comparison so that either choice is available based on configuration. EIGRP with and without BGP Cost Community support is discussed.
This section includes the following topics:
When using EIGRP as the CE-PE routing protocol as well as in the enterprise sites, it is important for the enterprise customer to understand how EIGRP behaves and is treated in the L3 MPLS VPN environment. The following points describe the general operation, followed by some example scenarios.
General operation is as follows:
oThe CE router and the enterprise site run EIGRP as before. There is very little change needed, if any.
oThe PE runs EIGRP in each VRF instance.
oThe PE redistributes EIGRP into MP-iBGP.
oMP-iBGP carry extended community EIGRP information across the backbone to other sites.
oThe PE routers at other sites redistribute the MP-iBGP routes back into EIGRP.
Example scenarios are as follows:
oScenario 1—Enterprise sites are running EIGRP with the same EIGRP AS number. (See .)
Figure&30 EIGRP—Same AS
In , the enterprise customer subscribed to the L3 MPLS VPN is running EIGRP at all their sites and using the same AS number at all their sites. The following sequence occurs:
1. The CE router advertises a network via EIGRP to the local PE router. This network can be internal or external.
2. The PE router redistributes the network from EIGRP into MP-iBGP with route information encoded in the extended community attributes within MP-iBGP.
3. The receiving PE receives the MP-iBGP updated that includes extended community information for EIGRP as well as a matching EIGRP AS number.
4. The PE recreates the EIGRP routes and sends them to the CE. These routes have the same route type as the original routes and they have the same metric as the sending PE had for these routes (the VPN backbone appears as zero cost).
oScenario 2— Enterprise sites are running EIGRP, but not all sites use the same EIGRP AS number. (See .)
Figure&31 EIGRP—Different AS
In , the enterprise customer subscribed to the L3 MPLS VPN service is running EIGRP at all their sites, but not all sites are using the same EIGRP AS number. The following sequence occurs:
1. The CE router advertises a network via EIGRP to the local PE router. In this case, it can be said that the route is an internal route.
2. The PE router redistributes the network from EIGRP into MP-iBGP with route information encoded in the extended community attributes within MP-iBGP.
3. The PE(s) attached to EIGRP sites, using the same EIGRP AS number as the originating site, receives the MP-iBGP update, which includes extended community information for EIGRP as well as a matching EIGRP AS number. The receiving PE recreates the route as an internal route with the same metric as the sending PE had for this network.
4. The PE(s) attached to EIGRP sites, using a different EIGRP AS number as the originating site, receives the MP-iBGP update, which includes extended community information for EIGRP and a non-matching EIGRP AS number. The PE recreates the EIGRP route as an external EIGRP route using the configured default metric and advertises to the CE.
oScenario 3—Some enterprise sites are running EIGRP while others are not. (See .)
Figure&32 EIGRP—No EIGRP
In , the enterprise customer subscribed to the L3 MPLS VPN service is running EIGRP at some sites but not at others. In this case, the customer is running OSPF at one site. The following sequence occurs:
1. The CE router advertises a network via OSPF to the local PE router.
2. The PE router redistributes the network from OSPF into MP-iBGP with route information encoded in the extended community attributes within MP-iBGP.
3. The PE attached to EIGRP site receives the MP-iBGP update, which does not include any extended community information for EIGRP.
4. The receiving PE, attached to the EIGRP site, recreates the route as an external EIGRP route using the configured default metric and advertises it to the CE. The originating protocol appears to be BGP.
As can be seen by the above scenarios, EIGRP behaves slightly differently based on the scenario.
Auto-Summarization
When configuring EIGRP, the default EIGRP behavior is to enable auto-summarization. Auto-summarization causes EIGRP to automatically summarize a network when a major network boundary is crossed. This might have undesirable effects on the network in an MPLS VPN environment. A site could receive the same summary from multiple other sites and would not be able to determine which site to use for a more specific route. If proper site addressing is planned, then auto-summarization should be disabled and any summarization can be manually performed.
illustrates a typical backdoor scenario with EIGRP as the PE-CE protocol and IGP over the backdoor link. Prefix 10.1.2.0/24 is owned by Site2 and advertised in EIGRP. The EIGRP route is advertised to CE1 in Site1 and PE2. PE2 installs this route in its VRF, redistributes this EIGRP route into BGP, and passes the route to PE1. Likewise, CE1 advertises this route to PE1. PE1 has two BGP paths available for 10.1.2.0/24:
oThe iBGP advertisement from PE2
oThe locally redistributed BGP route from the CE1 EIGRP advertisement.
In this case, a locally originated route is preferred based on the BGP best path decision process. However, such a decision leads to traffic being forwarded over the backdoor link as its primary path. For example, traffic originated in Site3 is destined to 10.1.2.0/24 routes to Site1 and over the backdoor link to Site2, as illustrated by the red arrow in .
Figure&33 EIGRP PE-CE Backdoor Scenario without BGP Cost Community
The topology shown in
does not achieve the goal of using the MPLS VPN service as a primary path. A means of affecting the PE1 choice must be available to have it prefer the iBGP learned announcement from PE2. This can be achieved through manipulation of BGP attributes or metrics before the local originated tiebreaker, such as weight or local preference. However, an additional attribute known as BGP Cost Community was developed to handle this case in a more graceful manner. More information regarding this feature can be found at the following URL:
The BGP Cost Community feature is configured on the PE and attaches an extended community attribute. This cost community value is compared, and it influences the path determination. By adjusting these community values as needed, traffic can be forwarded to the correct path.
illustrates how BGP Cost Community can cause the PE routers to prefer the L3 MPLS VPN service as the primary path. By default, when PE2 redistributes the EIGRP path into BGP, the BGP Cost Community attribute is populated with the EIGRP metric. As in , PE-1 has two options: the iBGP learned path from PE-2 or the locally originated BGP path learned through redistribution of the EIGRP route from CE-1. Because the EIGRP metric of the route advertised from CE-1 includes the added cost of traversing the backdoor link, the BGP Co}