Unified MPLS Functionality, Features, andConfiguration Example

Document ID: 118846

Contributed by Atahar Khan and Sudhir Kumar, Cisco TAC Engineers.Mar 20, 2015

Contents

IntroductionPrerequisites Requirements Components UsedConfigure Network Evolution Cisco Unified MPLS Features and Components Carry Label Information in BGP−4 (RFC 3107) BGP Prefix−Independent Convergence (BGP PIC) BGP Add−Path Loop−Free Alternates and rLFA for IGP Fast−Convergence Cisco Unified MPLS Architecture Example Unified MPLS Configuration Example Core Area Border Router − Cisco IOS® XR Core Area Border Router Configuration Pre−Aggregation Configuration Cell Site Gateway (CSG) Configuration MTG ConfigurationVerify CSG Node Output Pre−Agg Node Outputs Core ABR Node OutputsTroubleshootRelated Information

Introduction

This document describes Unified Multiprotocol Label Switching (MPLS), which is all about scaling. Itprovides a framework of technology solutions to bring simple end−to−end traffic and/or services across atraditionally segmented infrastructure. It makes use of both the benefits of a hierarchical infrastructure as itimproves scalability and the simplicity of network design.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of thedevices used in this document started with a cleared (default) configuration. If your network is live, make surethat you understand the potential impact of any command.

Configure

Network Evolution

When you look at the history of the network packet−based services, then a change in network business valuescan be observed. This goes from discrete connectivity enhancements in order to make applications as fluent aspossible, to collaboration technologies in order to support mobile collaboration. Finally, the on−demand cloudservices are introduced with the application services in order to optimize the tools used with an organizationand improve stability and cost−of−ownership.

Figure 1

This continuous value and functionality enhancement of the network results in a much more pervasive needfor network simplicity, manageability, integration, and stability where networks have been segmented as aresult of disjointed operational islands and no real end−to−end path control. Now there is a need to bring it alltogether with a single architecture which is easy to manage, provides scalability to 100,000's of nodes, anduses the current High Availability and Fast Convergence technologies. This is what Unified MPLS brings tothe table, which is the segmented network into a single control plane and end−to−end path visibility.

Modern Network Requirements

Increase bandwidth demand (Video)• Increase application complexity (Cloud and virtualization)• Increase need for convergence (Mobility)•

How can you simplify MPLS operations in increasingly larger networks with more complex applicationrequirements?

Traditional MPLS Challenges with Different Access Technologies

Complexity in order to achieve 50 millisecond convergence with Traffic Engineering Fast Reroute(TE FRR)

•

Need for sophisticated routing protocols and interaction with Layer 2 Protocols• Split large networks into domains while services are delivered end−to−end• Common end−to−end convergence and resiliency mechanisms• Troubleshoot and provision end−to−end across multiple domains•

The Unified MPLS attraction is summarized in this list:

Reduced number of operational points.In general transport platforms, a service has to be configured on every network element viaOperational Points. The management system has to know the topology.

♦

In Unified MPLS, with the integration of all MPLS islands, the minimum number ofOperational Points is achieved.

♦

•

Possibility to easily provision services: Layer 3 (L3) VPN, Virtual Private Wire Service (VPWS),Virtual Private LAN Service (VPLS), without pseudowire−stitching (PW−stitching) or InterASmechanisms. With the introduction of MPLS within the aggregation, some static configuration isavoided which creates MPLS Islands.

•

Provide end−to−end MPLS transport.• Keep Interior Gateway Protocol (IGP) areas separated and small routing tables.• Fast convergence.• Easy to configure and troubleshoot.• Ability to integrate with any access technology.• IPv6 readiness.•

Cisco Unified MPLS

Unified MPLS is defined by the addition of extra features with classical/traditional MPLS and it gives morescalability, security, simplicity and manageability. In order to deliver the MPLS services end−to−end,end−to−end Labeled Switches Path (LSP) is needed. The goal is to keep the MPLS services (MPLS VPN,MPLS L2VPN) as they are, but introduce greater scalability. In order to do this, move some of the IGPprefixes into Border Gateway Protocol (BGP) (the loopback prefixes of the Provider Edge (PE) routers),which then distributes the prefixes end−to−end.

Figure 2

Before the Cisco Unified MPLS architecture is discussed, it is important to understand the key features usedin order to make this a reality.

Features and Components

Carry Label Information in BGP−4 (RFC 3107)

It is a prerequisite to have a scalable method in order to exchange prefixes between network segments. Youcould simply merge the IGPs (Open Shortest Path First (OSPF), Intermediate System−to−Intermediate System(IS−IS), or Enhanced Interior Gateway Routing Protocol (EIGRP)) into a single domain. However an IGP isnot designed to carry 100,000s of prefixes. The protocol of choice for that purpose is BGP. It is a well−provenprotocol which supports the Internet with 100,000's of routes and MPLS−VPN environments with millions ofentries. Cisco Unified MPLS uses BGP−4 with label information exchange (RFC3107). When BGPdistributes a route, it can also distribute an MPLS label that is mapped to that route. The MPLS label mappinginformation for the route is carried in the BGP update message that contains the information about the route.If the next hop is not changed, the label is preserved and the label changes if the next hop changes. In UnifiedMPLS, the next hop changes at Area Border Routers (ABRs).

When you enable RFC 3107 on both BGP routers, the routers advertise to each other that they can then sendMPLS labels with the routes. If the routers successfully negotiate their ability to send MPLS labels, therouters add MPLS labels to all outgoing BGP updates.

The label exchange is needed in order to keep the end−to−end path information between segments. As aresult, each segment becomes small enough to be managed by operators and at the same time there is circuitinformation distributed for path awareness between two different IP speakers.

How does it work?

Figure 3

In Figure 3 you can see that there are three segments with Label Discovery Protocol Labeled Switches Path(LDP LSP) and the access network does not have LDP enabled. The objective is to join them together so thatthere is a single MPLS path (Internal BGP (iBGP) hierarchal LSP) between Pre−Aggregation (Pre−Agg)Nodes. As the network is a single BGP Autonomous System (AS), all sessions are iBGP sessions. Eachsegment runs its own IGP (OSPF, IS−IS,or EIGRP) and LDP LSP paths within the IGP domain. Within CiscoUnified MPLS, the routers (ABRs) that join the segments must be BGP inline route−reflectors with theNext−Hop−Self and RFC 3107 in order to carry a IPv4 + Label configured on the sessions. These BGPspeakers are within the Cisco Unified MPLS Architecture referenced to as ABRs.

Why are the ABRs inline route−reflectors?

One of the goals of Unified MPLS is to have a highly scalable end−to−end infrastructure. Thus, each segmentshould be kept simple in order to operate. All peerings are iBGP peerings, therefore there is a need for afull−mesh of peerings between all iBGP speakers within the complete network. That results in a very

impractical network environment if there are thousands of BGP speakers. If the ABRs are maderoute−reflectors, the number of iBGP peering is reduced to the number of BGP speakers 'per−segment' insteadof between 'all' BGP speakers of the complete AS.

Why Next−Hop−Self?

BGP operates on the base of recursive routing lookups. This is done in order to accommodate scalabilitywithin the underlying IGP that is utilized. For the recursive lookup, BGP uses Next−Hop attached to eachBGP route entry. Thus, for example, if a Source−Node desires to send a packet to a Destination−Node and ifthe packet hits the BGP router, then the BGP router does a routing lookup in its BGP routing table. It finds aroute toward Destination−Node and finds the Next−Hop as a next step. This Next−Hop must be known by theunderlying IGP. As the final step, the BGP router forwards the packet onwards based upon the IP and MPLSlabel information attached to that Next−Hop.

In order to make sure that within each segment only the Next−Hops are needed to be known by the IGP, it isneeded that the Next−Hop attached to the BGP entry is within the network segment and not within a neighboror further away segment. If you rewrite the BGP Next−Hop with the Next−Hop−Self feature, ensure that theNext−Hop is within the local segment.

Put It All Together

Figure 4

Figure 4 provides an example of how the L3 VPN prefix 'A' and label exchange operates and how the MPLSlabel stack is created to have the end−to−end path information for the traffic flow between both PEs.

The network is partitioned as three independent IGP/LDP domains. The reduced size of routing andforwarding tables on the routers is to enable better stability and faster convergence. LDP is used to buildintradomain LSPs within domains. RFC 3107 BGP IPv4+ labels are used as interdomain label distributionprotocol in order to build hierarchical BGP LSPs across domains. BGP3107 inserts one extra label in theforwarding label stack in the Unified MPLS architecture.

Intradomain − LDP LSP

Interdomain − BGP Hierarchical LSP

Figure 5

VPN Prefix 'A' is advertised by PE31 to PE11 with L3VPN service label 30 and next hop as PE31's loopbackvia end−to−end interdomain hierarchical BGP LSP. Now, look at the forwarding path for VPN prefix 'A' fromPE11 to PE31.

On PE11, Prefix A is known via BGP session with PE31 as next−hop PE31 and PE31 is recursivelyreachable via P1 with BGP label 100. PE11 received IPv4 + Label information from P1 as BGPupdates because it is enabled with the RFC 3107 feature in order to send the IPv4 + Labelinformation.

•

P1 is reachable from PE11 via intradomain LDP LSP and it adds another LDP label on top of theBGP label. Finally, the packet goes out of the PE11 node with three labels. For example, the 30L3VPN service label, the 100 BGP label, and the 200 LDP IGP label.

•

The LDP top label continues to swap in intradomain LDP LSP and the packet reaches P1 with twolabels after Penultimate Hop Popping (PHP).

•

P1 is configured as inline Route Reflector (RR) with next−hop self and it joins two IGP domains orLDP LSP.

•

On P1, the next hop for PE31 is changed to P2 and the update is received via BGP with IPv4 + Label(RFC3107). The BGP label is swapped with new label because next−hop is changed and the IGP labelis pushed on top.

•

The packet goes out of the P1 node with three labels and service label 30 is untouched. That is, the 30L3VPN service label, 101 BGP label, and 201 LDP label.

•

The LDP top label swaps in intradomain LDP LSP and the packet reaches P2 with two labels afterPHP.

•

On P2, the next hop for PE31 is changed again and it is reachable via IGP. The BGP label is removedas an implicit−null BGP label is received from PE31 for PHP.

•

The packet leaves with two labels. For example, the 30 L3VPN service label and the 110 LDP label.• On PE31, the packet arrives with one label after PHP of the LDP label and based on the service label30. The unlabeled packet is forwarded to the CE31 destination under Virtual Routing and Forwarding(VRF).

•

When you look at the MPLS label stack, the switching of the packet between a source and destination devicebased upon the previous prefix and label exchange is observed within the MPLS switching environment.

Figure 6

BGP Prefix−Independent Convergence (BGP PIC)

This is a Cisco technology which is used in BGP failure scenarios. The network converges without a loss ofthe traditional seconds in the BGP reconvergence. When BGP PIC is used, most failure scenarios can bereduced to a reconvergence time below 100 msec.

How is this done?

Traditionally when BGP detects a failure, it recalculates for each BGP entry for the best path. When there is arouting table with thousands of route entries, this can take a considerable amount of time. In addition, thisBGP router needs to distribute all those new best paths to each of its neighbors in order to inform them of thechanged network topology and the changed best−paths. As the final step, each of the recipient BGP speakersneeds to make a best path calculation in order to find the new best paths.

Every time the first BGP speaker detects something wrong, it starts the best path calculation until all of itsneighbor BGP speakers have done their recalculation, the traffic flow might be dropped.

Figure 7

The BGP PIC for IP and MPLS VPN feature improves BGP convergence after a network failure. Thisconvergence is applicable to both core and edge failures and can be used in both IP and MPLS networks. TheBGP PIC for IP and the MPLS VPN feature creates and stores a backup/alternate path in the routinginformation base (RIB), forwarding information base (FIB), and Cisco Express Forwarding (CEF) so thatwhen a failure is detected, the backup/alternate path can immediately take over, thus it enables fast failover.

With a single rewrite of the next−hop information the traffic flow is restored. Additionally the network BGPconvergence happens in the background, but the traffic flows are not impacted anymore. This rewrite happenswithin 50 msec. If you use this technology, network convergence is reduced to from seconds to 50 msec plusthe IGP convergence.

BGP Add−Path

BGP Add−Path is an improvement on how BGP entries are communicated between BGP speakers. If on acertain BGP speaker there is more than a single entry towards a certain destination, then that BGP speakeronly sends the entry which is its best path for that destination to its neighbors. The result is that no provisionsare made in order to allow the advertisement of multiple paths for the same destination.

BGP Add−Path is a BGP feature to allow more as only the best path, and allows multiple paths for the samedestination without the new paths implicitly replacing any previous ones. This extension to BGP isparticularly important in order to aid with BGP PIC, when BGP route−reflectors are used, so that the differentBGP speakers within an AS have access to more BGP paths as just the 'Best BGP path' in accordance with theroute−reflector.

Loop−Free Alternates and rLFA for IGP Fast−Convergence

Operations to achieve 50−millisecond restoration after a link or node failure can be simplified dramaticallywith the introduction of a new technology called loop−free alternates (LFAs). LFA enhance the link−staterouting protocols (IS−IS and OSPF) in order to find alternative routing paths in a loop−free manner. LFAallows each router to define and use a predetermined backup path if an adjacency (network node or link) fails.In order to deliver a 50 msec restoration time in case of link or node failures, MPLS TE FRR can be deployed.However, this requires the addition of another protocol (Resource Reservation Protocol, or RSVP) for setupand management of TE tunnels. While this might be necessary for bandwidth management, the protection andrestoration operation does not require bandwidth management. Hence, the overhead associated with theaddition of RSVP TE is considered high for simple protection of links and nodes.

LFA can provide a simple and easy technique without the deployment of RSVP TE in such scenarios. As aresult of these techniques, today's interconnected routers in large−scale networks can deliver 50 msecrestoration for link and node failures without a configuration requirement for the operator.

Figure 8

The LFA−FRR is a mechanism that provides local protection for unicast traffic in IP, MPLS, Ethernet OverMPLS (EoMPLS), Inverse Multiplexing over ATM (IMA) over MPLS, Circuit Emulation Service overPacket Switched Network (CESoPSN) over MPLS, and Structure−Agnostic Time Division Multiplexing over

Packet (SAToP) over MPLS networks. However, some topologies (such as the ring topology) requireprotection that is not afforded by LFA−FRR alone. The Remote LFA−FRR feature is useful in such situations.

The Remote LFA−FRR extends the basic behavior of LFA−FRR to any topology. It forwards the trafficaround a failed node to a remote LFA that is more than one hop away. In Figure 9, if the link between C1 andC2 fails to reach A1 then C2 sends the packet over a directed LDP session to C5 which has reachability to A1.

Figure 9

In Remote LFA−FRR, a node dynamically computes its LFA node. After the alternate node is determined(which is not directly connected), the node automatically establishes a directed Label Distribution Protocol(LDP) session to the alternate node. The directed LDP session exchanges labels for the particular forwarderror correction (FEC).

When the link fails, the node uses label stacking in order to tunnel the traffic to the remote LFA node, in orderto forward the traffic to the destination. All the label exchanges and tunneling to the remote LFA node aredynamic in nature and preprovisioning is not required. The whole label exchange and tunneling mechanism isdynamic and does not involve any manual provisioning.

For intradomain LSPs, remote LFA FRR is utilized for unicast MPLS traffic in ring topologies. Remote LFAFRR precalculates a backup path for every prefix in the IGP routing table, which allows the node to rapidlyswitch to the backup path when a failure is encountered. This provides recovery times on the order of 50msec.

Cisco Unified MPLS Architecture Example

When all of the previous tools and features are put together within a network environment, it creates the CiscoUnified MPLS network environment. This is the architecture example for large service providers.

Figure 10

The Core and Aggregation are organized as distinct IGP/LDP domains.• Interdomain hierarchical LSPs based on RFC 3107, BGP IPv4+ Labels which are extended out to thePre−agg.

•

Intradomain LSPs based on LDP.• The interdomain Core/Aggregation LSPs are extended in the Access Networks by the distribution ofthe Radio Access Networks Interior Gateway Protocol (RAN IGP) into the interdomain iBGP anddistribute the necessary labelled iBGP prefixes (MPC (Mobile Packet Core) gateway) into RAN IGP(via BGP communities).

•

Unified MPLS Configuration Example

Here ia a simplified example of Unified MPLS.

Core Area Border Router − Cisco IOS ® XR

Pre−Aggregation and Cell Site Gateway Routers − Cisco IOS

Figure 11

200:200MPC Community

300:300Aggregation Community

Core IGP Domain ISIS Level 2

Aggregation IGP DomainISIS Level 1

Access IGP Domain OSPF 0 Areas

Core Area Border Router Configuration

Figure 12

! IGP Configurationrouter isis core−aggnet 49.0100.1010.0001.0001.00address−family ipv4 unicastmetric−style widepropagate level 1 into level 2 route−policy drop−all ! Disable L1 to L2 redistribution!interface Loopback0ipv4 address 10.10.10.1 255.255.255.255passive!interface TenGigE0/0/0/0 !interface TenGigE0/0/0/1 circuit−type level−2−only ! Core facing ISIS L2 Link

!interface TenGigE0/0/0/2 circuit−type level−1 ! Aggregation facingis ISIS L1 Link

!route−policy drop−alldropend−policy

! BGP Configuration

router bgp 100bgp router−id 10.10.10.1address−family ipv4 unicastallocate−label all ! Send labels with BGP routes!session−group infraremote−as 100cluster−id 1001update−source Loopback0!neighbor−group agg use session−group infraaddress−family ipv4 labeled−unicast

route−reflector−client

route−policy BGP_Egress_Filter out ! BGP Community based Egress filtering

next−hop−self!neighbor−group mpcuse session−group infraaddress−family ipv4 labeled−unicast

route−reflector−client next−hop−self!neighbor−group coreuse session−group infra address−family ipv4 labeled−unicast

next−hop−self

community−set Allowed−Comm200:200, 300:300, !route−policy BGP_Egress_Filterif community matches−any Allowed−Comm then pass

Pre−Aggregation Configuration

Figure 13

interface Loopback0ipv4 address 10.10.9.9 255.255.255.255!interface Loopback1ipv4 address 10.10.99.9 255.255.255.255

! Pre−Agg IGP Configuration

router isis core−aggnet 49.0100.1010.0001.9007.00is−type level−1 ! ISIS L1 routermetric−style widepassive−interface Loopback0 ! Core−agg IGP loopback0

!RAN Access IGP Configuration

router ospf 1router−id 10.10.99.9redistribute bgp 100 subnets route−map BGP_to_RAN ! iBGP to RAN IGP redistributionnetwork 10.9.9.2 0.0.0.1 area 0network 10.9.9.4 0.0.0.1 area 0network 10.10.99.9 0.0.0.0 area 0 distribute−list route−map Redist_from_BGP in ! Inbound filtering to prefer labeled BGP learnt prefixes

ip community−list standard MPC_Comm permit 200:200!route−map BGP_to_RAN permit 10 ! Only redistribute prefixes marked with MPC community match community MPC_Comm set tag 1000route−map Redist_from_BGP deny 10match tag 1000!route−map Redist_from_BGP permit 20

! BGP Configurationrouter bgp 100bgp router−id 10.10.9.10bgp cluster−id 909neighbor csr peer−groupneighbor csr remote−as 100neighbor csr update−source Loopback100 ! Cell Site − Routers RAN IGP loopback100 as sourceneighbor abr peer−group

neighbor abr remote−as 100neighbor abr update−source Loopback0 ! Core POP ABRs − core−agg IGP loopback0 as sourceneighbor 10.10.10.1 peer−group abrneighbor 10.10.10.2 peer−group abrneighbor 10.10.13.1 peer−group csr!address−family ipv4bgp redistribute−internalnetwork 10.10.9.10 mask 255.255.255.255 route−map AGG_Comm ! Advertise with Aggregation Community (100:100)redistribute ospf 1 ! Redistribute RAN IGP prefixesneighbor abr send−communityneighbor abr next−hop−self

neighbor abr send−label ! Send labels with BGP routesneighbor 10.10.10.1 activateneighbor 10.10.10.2 activateexit−address−family!route−map AGG_Comm permit 10set community 300:300

Cell Site Gateway (CSG) Configuration

Figure 14

interface Loopback0ip address 10.10.13.2 255.255.255.255

! IGP Configurationrouter ospf 1router−id 10.10.13.2network 10.9.10.0 0.0.0.1 area 0network 10.13.0.0 0.0.255.255 area 0network 10.10.13.3 0.0.0.0 area 0

MTG Configuration

Figure 15

Interface lookback0ip address 10.10.11.1 255.255.255.255

! IGP Configurationrouter isis core−aggis−type level−2−only ! ISIS L2 routernet 49.0100.1010.0001.1001.00address−family ipv4 unicastmetric−style wide

! BGP Configurationrouter bgp 100

bgp router−id 10.10.11.1address−family ipv4 unicastnetwork 10.10.11.1/32 route−policy MPC_Comm ! Advertise Loopback−0 with MPC Communityallocate−label all ! Send labels with BGP routes!session−group infra

remote−as 100update−source Loopback0!neighbor−group abruse session−group infraaddress−family ipv4 labeled−unicast next−hop−self!neighbor 10.10.6.1use neighbor−group abr!neighbor 10.10.12.1use neighbor−group abr

community−set MPC_Comm200:200end−set!route−policy MPC_Commset community MPC_Commend−policy

Verify

The loopback prefix of the Mobile Packet Gateway (MPG) is 10.10.11.1/32, so that prefix is of interest. Now,look at how packets are forwarded from CSG to MPG.

The MPC prefix 10.10.11.1 is known to the CSG router from Pre−agg with route tag 1000 and it can beforwarded as a labeled packet with outgoing LDP label 31 (intra domain LDP LSP). The MPC community200:200 was mapped with route tag 1000 in Pre−agg node while redistribution is in OSPF.

CSG Node Output

CSG#sh mpls forwarding−table 10.10.11.1 detailLocal Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 34 31 10.10.11.1/32 0 Vl40 10.13.1.0 MAC/Encaps=14/18, MRU=1500, Label Stack{31}

Pre−Agg Node Outputs

In Pre−agg node, the MPC prefix is redistributed from BGP to RAN access OSPF process withcommunity−based filtering and the OSPF process is redistributed into BGP. This controlled redistribution isnecessary in order to make end−to−end IP reachabilty, at the same time each segment has minimum requiredroutes.

The 10.10.11.1/32 prefix is known via hierarichal BGP 100 with the MPC 200:200 community attached. The16020 BGP 3107 label received from the core Area Border Router (ABR) and the LDP label 22 is added ontop for intradomain forwarding after the next hop recursive lookup.

Pre−AGG1#sh ip route 10.10.11.1Routing entry for 10.10.11.1/32Known via "bgp 100", distance 200, metric 0, type internal

Redistributing via ospf 1Advertised by ospf 1 subnets tag 1000 route−map BGP_TO_RANRouting Descriptor Blocks:* 10.10.10.2, from 10.10.10.2, 1d17h ago Route metric is 0, traffic share count is 1 AS Hops 0 MPLS label: 16020

Pre−AGG1#sh bgp ipv4 unicast 10.10.11.1BGP routing table entry for 10.10.11.1/32, version 116586Paths: (2 available, best #2, table default)Not advertised to any peerLocal <SNIP>Local 10.10.10.2 (metric 30) from 10.10.10.2 (10.10.10.2) Origin IGP, metric 0, localpref 100, valid, internal, best

Community: 200:200 Originator: 10.10.11.1, Cluster list: 0.0.3.233, 0.0.2.89 mpls labels in/out nolabel/16020

Pre−AGG1#sh bgp ipv4 unicast labels Network Next Hop In label/Out label

10.10.11.1/32 10.10.10.1 nolabel/1602110.10.10.2 nolabel/16020

Pre−AGG1#sh mpls forwarding−table 10.10.10.2 detailLocal Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 79 22 10.10.10.2/32 76109369 Vl10 10.9.9.1 MAC/Encaps=14/18, MRU=1500, Label Stack{22}

Pre−AGG#sh mpls forwarding−table 10.10.11.1 detailLocal Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 530 16020 10.10.11.1/32 20924900800 Vl10 10.9.9.1 MAC/Encaps=14/22, MRU=1496, Label Stack{22 16020}

Core ABR Node Outputs

The prefix 10.10.11.1 is known via intradomain IGP (ISIS−L2) and as per the MPLS forwarding table. It isreachable through LDP LSP.

ABR−Core2#sh ip route 10.10.11.1Routing entry for 10.10.11.1/32Known via "isis core−agg", distance 115, metric 20, type level−2Installed Sep 12 21:13:03.673 for 2w3dRouting Descriptor Blocks 10.10.1.0, from 10.10.11.1, via TenGigE0/0/0/0, Backup Route metric is 0 10.10.2.3, from 10.10.11.1, via TenGigE0/0/0/3, Protected Route metric is 20No advertising protos.

For the distribution of the prefixes between the segmented areas, BGP with the label (RFC 3107) is utilized.What needs to reside still within the segmented areas of IGP are the loopbacks of the PEs and addressesrelated to the central infrastructure.

The BGP routers that connect different areas together are the ABRs that act as a BGP Route−Reflector. Thesedevices use the Next−Hop−Self feature, in order to avoid the need to have all Next−Hops of the completeAutonomous System within the IGP, instead of only the IP addresses of the PEs and the central infrastructure.Loop detection is completed based upon the BGP Cluster−IDs.

For Network resilience, BGP PIC with the BGP Add Path feature should be used with BGP and LFA withIGP. These features are not used in previous example.

Troubleshoot

There is currently no specific troubleshooting information available for this configuration.

Related Information

Seamless MPLS Architecture• Cisco Unified MPLS White Paper• Cisco Carrier Packet Transport (CPT) System• Technical Support & Documentation − Cisco Systems•

Updated: Mar 20, 2015 Document ID: 118846