Rob Riker/ Simplified Networking: EFP

Showing posts with label EFP. Show all posts

Sunday, January 1, 2017

CCIE SPv4 - MPLS L2VPN - EVPN and PBB-EVPN

Software versions:
IOS XE 15.5
IOS XR 5.3

The topology for this demo:

In this post we will be taking a look at both EVPN and PBB-EVPN. Everything we have previously reviewed has been on the written and lab blueprints, EVPN and PBB-EVPN are only on the written blueprint and per the SPv4 PM, EVPN and PBB EVPN will not be tested on it the lab. I will cover the topics, features, terms and a brief demo to show what it looks like to get PBB-EVPN up and running. The bulk of this post will be covering the terms and an overview of how it all works.

One thing that I noticed as I was going through the documentation, Cisco Live videos, other publicly available white papers, RFCs, etc. It appears that EVPN for IOS XR doesn't exist. It appears that Cisco decided to go forward with PBB which is actually an enhancement to EVPN.

Cisco Live presentations

BRKMPL-2101 - Deploying MPLS-based Layer 2 Virtual Private Networks (2014 San Francisco) - 90 Mins

BRKMPL-2333 - E-VPN & PBB-EVPN: the Next Generation of MPLS-based L2VPN (2015 San Diego) - 90 Mins

RFCs

EVPN for MPLS

https://tools.ietf.org/html/rfc7432

PBB EVPN

https://tools.ietf.org/html/rfc7623

Let's take a look at why EVPN and PBB-EVPN were developed. First of all, DCI or Data Center Interconnect with current L2VPN services like VPLS and H-VPLS don't address the scale, redundancy, load balancing, fast convergence or simplified provisioning that EVPN/PBB offer.

Current VPLS design doesn't allow for All Active per flow redundancy. It uses a PW to exchange label information between PEs/UPEs. If a CE device is connected to 2 different VPLS PEs, only one of the PEs can be used to forward the data, both PEs can learn the MAC info of the CE. The problem that exists, just like in LAN switching, if 2 different MAC addresses are mapped to 1 IP address, how does the switch know which way to forward the data? It will flip-flop back and forth or drop the traffic as a result.

Remember that VPLS is simply providing a "bridge" over the MPLS core and advertising MAC addresses so that the CE knows how to reach other CEs over the VPLS network. If you dual or multi home a CE-PE connection, each PE will learn that MAC address. Multiple ACs can be used on different physical interfaces, they must be physical as subinterfaces borrow the main interface MAC. The issue with this solution is its costly, 2+ ACs back to multiple PEs, $$$$$. That doesn't solve the load balancing issue though, it would require the customer to know how to run ECMP, assuming they know that. The purpose here is to take the burden off the customer and for the SP to solve that issue.

I'm not bashing VPLS by any means, just pointing out some things to keep in mind in case you need all active load balancing, which seems to be the most common request I get when it comes to L2 services.

Ethernet VPN - Next generation solution for E-LAN multipoint services. PEs will run MP-BGP to advertise and learn Customer MAC (C-MAC) over the core, same operationally to L3 VPN. Learning on the PE access circuits or AC via data plane transparently. There is no pseudowire involvement at all. Uses unicast for MP2P or MP2MP depending on the need. Uses Multicast, specifically ingress replication over MP2P tunnel or can use LSM, this is used by the PEs to signal interest in joining the service.

Provider Backbone Bridge EVPN - Takes EVPN to the next level by adding a PBB header as the frame passes through the I and B Components. The EVPN forwarder add the EVPN MPLS Label (VPN Label) and a Control word, which is used to give the VPN Label a "0" value. As the Frame is forwarded out to the MPLS core, a PSN label or the Transport Label with the E-Type of 8847 or MPLS, a source address and destination address, the NH.

So let's hit the components you will see when deploying PBB-EVPN, we'll focus on this aspect, the 802.1ah or Provider backbone bridge MAC-in-MAC forwarding capability. We'll only focus design wise on the E-LAN solution as we only need to know this topic for the written exam.

The components!

Backbone Edge Bridges or BEBs - This is the edge of the MPLS Network.

PBB - 2^24 service instances per B-VLAN, leverages MAC in MAC routing, MAC in MAC means that the B-MAC is used to reach the PE that is advertises that B-MAC. This gives us 16 million I-SIDs per EVI, lots of scalability at the edge. Multiple I-SIDs can be mapped to a single EVI.

I-Component - The I-Component maps service VLAN identifiers to service instance identifiers. It adds a PBB header without a backbone VLAN tag. Learns and forwards C-MACs and maintains a mapping table of the C-MAC to B-MAC. Performs the PBB encapsulation and deencapsulation on the PIP or provider instance port. Similar to the "service instance" in VPLS

B-Component - The B-Component maps I-SIDs to backbond VID B-VIDs and adds a PBB header with a B-Tag. Learns and forwards traffic based on B-MACs learned from other PEs. Pushes and pops the B-VLAN on the CBP or Customer backbone port.

The 802.1ah standard specifies three types of BEBs, B-BEBs, I-BEBs and IB-BEBs. Only IB-BEBs are supported on ASR 9K. IOS XR supports IB-BEB bridge type at the Edge Node. IB-BEBs contain both the I-Component and the B-Component. The bridge selects the B-MAC and inserts the I-SID based on the provider (S) tag and customer (C) tag.

EVPN Instance or EVI - Think of this like the "bridge-domain" in VPLS, it is what binds all of the PEs together to flood data between themselves, EVIs do pretty much the same stuff. The EVI instance number must match among all participating PEs and is configured under the "PBB Core" configuration, ironically enough, pointing into the core of the network. There are several methods to identify traffic as well; Port, VLAN, VLAN Bundling and VLAN Aware Bundling. There can only be one EVI per core bridge.

Ethernet Segment Identifier or ESI - This is a "site" or CE, I also like to think of it like an Attachment Circuit, not 1 for 1 but the fact it is used to connect the PE to the CE. There are several connection styles, Single and Multi Homed Device and Network. This is a uniquely identified 10 byte identifier created under the EVPN configuration.

BGP Routes - 5 new Route Types

[1] Ethernet Auto-Discovery (AD) Route

[2] MAC Advertisement Route

[3] Inclusive Multicast Route

[4] EthernetSegment Route

(5) IP Prefix Advertisement Route

EVPN/PBB-EVPN define a single new BGP NLRI used to carry all EVPN routes

NLRI has a new SAFI (70)

Routes serve control plane purposes, including:

MAC / IP address reachability

MAC mass withdrawal

Split-Horizon label adv.

Aliasing

Multicast endpoint discovery

Redundancy group discovery

Designated forwarder election

BGP Route Attributes

Extended Communities

ESI MPLS Label

ES-Import

MAC Mobility

Default Gateway

Router’s MAC

New BGP extended communities defined

Expand information carried in BGP routes, including:

MAC address moves

C-MAC flush notification

Redundancy mode

MAC / IP bindings of a GW

Split-horizon label encoding

Designated Forwarder Election - Used to determine a designated forwarder in dual-homed or multi-homed devices or networks. The election is performed on a per service basis. The DF filtering function for MHN differs from that for MHD. Directionality is implemented differently depending on the connectivity type. DF filtering for MHN is applied for traffic both ingress and egress on the access-facing Ethernet interfaces. DF filtering for MHD is applied only to traffic that egress the access-facing interfaces. Traffic Types are also very similar to Directionality. DF filtering for MHN impacts both unicast as well as flooded multi-destination traffic. DF filtering for MHD only applies to flooded multi-destination traffic.

The DF idea is basically a way of determining which PE will forward frames received in from the core to the CE if multiple paths to the CE are available. The designated forwarder, depending on the deployment model, mentioned above, is leveraged will determine how the incoming traffic will be forwarded. If traffic is received in on a PE that is not the DF, it is simple discarded.

There is no data plane support for this feature, only a minimal amount of control plane functionality is available. We'll take a look the base PBB-EVPN configuration. Once the configuration is in place, we'll verify the configuration is working and then how the logic is laid out.

From the topology above, XR1, XR2 and XR2 will form a full mesh of iBGP L2VPN EVPN peerings with each other. Both XR and IOS can be used as BGP Route Reflectors, however I chose not to implement that. I will copy in the configuration from all three routers, but only verify on XR3 that it is working correctly.

XR1

l2vpn

bridge group CORE

bridge-domain CORE

pbb core

evpn evi 100

bridge group EVPN

bridge-domain EVPN

interface GigabitEthernet0/0/0/2.100

pbb edge i-sid 256 core-bridge CORE

router bgp 1

address-family l2vpn evpn

neighbor 192.168.1.12

remote-as 1

update-source Loopback0

address-family l2vpn evpn

neighbor 192.168.1.13

remote-as 1

update-source Loopback0

address-family l2vpn evpn

XR2

l2vpn

bridge group CORE

bridge-domain CORE

pbb core

evpn evi 100

bridge group EVPN

bridge-domain EVPN

interface GigabitEthernet0/0/0/1

pbb edge i-sid 256 core-bridge CORE

router bgp 1

address-family l2vpn evpn

neighbor 192.168.1.11

remote-as 1

update-source Loopback0

address-family l2vpn evpn

neighbor 192.168.1.13

remote-as 1

update-source Loopback0

address-family l2vpn evpn

XR3

l2vpn

bridge group CORE

bridge-domain CORE

pbb core

evpn evi 100

bridge group EVPN

bridge-domain EVPN

interface GigabitEthernet0/0/0/1

pbb edge i-sid 256 core-bridge CORE

router bgp 1

address-family l2vpn evpn

neighbor 192.168.1.11

remote-as 1

update-source Loopback0

address-family l2vpn evpn

neighbor 192.168.1.12

remote-as 1

update-source Loopback0

address-family l2vpn evpn

As you can see, the configuration isn't very intensive. However, it is pretty finicky if you don't put things in the right spots.

So let's verify this now:

RP/0/0/CPU0:XR3#sh l2vpn bridge-domain

Sun Jan 1 19:48:03.837 UTC

Legend: pp = Partially Programmed.

Bridge group: CORE, bridge-domain: CORE, id: 0, state: up, ShgId: 0, MSTi: 0

Type: pbb-core

Number of associated pbb-edge BDs: 1

Aging: 300 s, MAC limit: 4000, Action: none, Notification: syslog

Filter MAC addresses: 0

ACs: 0 (0 up), VFIs: 0, PWs: 0 (0 up), PBBs: 1 (1 up)

List of PBBs:

PBB Core, state: up

List of ACs:

List of Access PWs:

List of VFIs:

Bridge group: EVPN, bridge-domain: EVPN, id: 1, state: up, ShgId: 0, MSTi: 0

Type: pbb-edge, I-SID: 256

Aging: 300 s, MAC limit: 4000, Action: none, Notification: syslog

Filter MAC addresses: 0

ACs: 1 (1 up), VFIs: 0, PWs: 0 (0 up), PBBs: 1 (1 up)

List of PBBs:

PBB Edge, state: up, Static MAC addresses: 0

List of ACs:

Gi0/0/0/1, state: up, Static MAC addresses: 0

List of Access PWs:

List of VFIs:

The above output indicates that the 2 bridge domains, the EVPN and the CORE are both up and operational. Both have a MAC limit of 4000 and MAC aging time of 5 minutes.

RP/0/0/CPU0:XR3#sh l2vpn pbb backbone-source-mac

Sun Jan 1 19:49:08.713 UTC

Backbone Source MAC: 0b16.212c.3742

Chassis MAC : 0b16.212c.3742

The source MAC of XR3 is above, that will be the B-MAC that XR1 and XR1 will use as the destination address in the PBB Header.

RP/0/0/CPU0:XR3#show evpn evi detail

Sun Jan 1 19:50:26.267 UTC

EVI Bridge Domain Type

---------- ---------------------------- -------

100 CORE PBB

Unicast Label : 24311

Multicast Label: 24312

Flow Label: N

RD Config: none

RD Auto : (auto) 192.168.1.13:100

RT Auto : 1:100

Route Targets in Use Type

------------------------------ -------

1:100 Import

1:100 Export

You should take note that we didn't configure any VRF like attributes, RD/RT when we configured PBB, the bridge domains or BGP. That is because those values are auto generated based on the EVI value and the lo0 IP address and then EVI value. As you can see, the EVI is using 1:100 as the import and export value.

RP/0/0/CPU0:XR3#show evpn evi inclusive-multicast detail

Sun Jan 1 19:50:04.499 UTC

ISID: 256, Originating IP: 192.168.1.11 100

Nexthop: 192.168.1.11

Label : 24113

Source : Remote

ISID: 256, Originating IP: 192.168.1.12 100

Nexthop: 192.168.1.12

Label : 24211

Source : Remote

ISID: 256, Originating IP: 192.168.1.13 100

Nexthop: ::

Label : 24312

Source : Local

This is really important, in case you missed it eariler, inclusive multicast is critically important in the PBB environment. IM is used by the PEs to signal to the network they would like to join the PBB service. You can also see the label values that were generated by the respective PEs; XR1 - 24113; XR2 - 24211; XR3 - 24312.

RP/0/0/CPU0:XR3#show bgp l2vpn evpn summary

BGP is operating in STANDALONE mode.

Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer

Speaker 27 27 27 27 27 0

Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd

192.168.1.11 0 1 401 403 27 0 0 01:39:04 2

192.168.1.12 0 1 399 404 27 0 0 01:39:11 2

We can see that we have 2 BGP L2 VPN EVPN peerings, to XR1 and XR2 respectively. Each advertising 2 prefixes.

RP/0/0/CPU0:XR3#show bgp l2vpn evpn

Sun Jan 1 19:51:26.043 UTC

BGP router identifier 192.168.1.13, local AS number 1

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0x0 RD version: 0

BGP main routing table version 27

BGP NSR Initial initsync version 7 (Reached)

BGP NSR/ISSU Sync-Group versions 0/0

BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 192.168.1.11:100

*>i[2][0][48][0b16.212c.3742][0]/104

192.168.1.11 100 0 i

*>i[3][256][32][192.168.1.11]/80

192.168.1.11 100 0 i

Route Distinguisher: 192.168.1.12:100

*>i[2][0][48][0b16.212c.3742][0]/104

192.168.1.12 100 0 i

*>i[3][256][32][192.168.1.12]/80

192.168.1.12 100 0 i

Route Distinguisher: 192.168.1.13:100 (default for vrf CORE)

*> [2][0][48][0b16.212c.3742][0]/104

0.0.0.0 0 i

* i 192.168.1.11 100 0 i

* i 192.168.1.12 100 0 i

*>i[3][256][32][192.168.1.11]/80

192.168.1.11 100 0 i

*>i[3][256][32][192.168.1.12]/80

192.168.1.12 100 0 i

*> [3][256][32][192.168.1.13]/80

0.0.0.0 0 i

Processed 8 prefixes, 10 paths

A couple of things to note here. You'll notice that there is some uniqueness to the outputs above, namely the bracketed [2][0][48][MAC] outputs. This is essentially the power behind PBB.

There are 2 very important outputs, the [2] and the [3]. The [2] indicate a MAC advertisement Route and [3] indicates Inclusive Multicast Routes. We see 3 [3] followed by [256] which is the I-SID value. I have not found any documentation explaining the [32] or the reason there are /80 or /104 length prefixes. Those lengths are similar to BGP AD with BGP signaling but not exact.

RP/0/0/CPU0:XR3#show bgp l2vpn evpn bdomain CORE [2][0][48][0b16.212c.3742][0]$

Sun Jan 1 19:53:39.924 UTC

BGP routing table entry for [2][0][48][0b16.212c.3742][0]/104, Route Distinguisher: 192.168.1.13:100

Versions:

Process bRIB/RIB SendTblVer

Speaker 26 26

Local Label: 24311

Last Modified: Jan 1 18:12:01.298 for 01:41:38

Paths: (3 available, best #1)

Advertised to update-groups (with more than one peer):

0.2

Path #1: Received by speaker 0

Advertised to update-groups (with more than one peer):

0.2

Local

0.0.0.0 from 0.0.0.0 (192.168.1.13)

Origin IGP, localpref 100, valid, redistributed, best, group-best, import-candidate, rib-install

Received Path ID 0, Local Path ID 1, version 26

Extended community: RT:1:100

EVPN ESI: 0000.0000.0000.0000.0000

Path #2: Received by speaker 0

Not advertised to any peer

Local

192.168.1.11 (metric 4) from 192.168.1.11 (192.168.1.11)

Received Label 24112

Origin IGP, localpref 100, valid, internal, import-candidate, imported, rib-install

Received Path ID 0, Local Path ID 0, version 0

Extended community: RT:1:100

EVPN ESI: 0000.0000.0000.0000.0000

Source VRF: default, Source Route Distinguisher: 192.168.1.11:100

Path #3: Received by speaker 0

Not advertised to any peer

Local

192.168.1.12 (metric 2) from 192.168.1.12 (192.168.1.12)

Received Label 24210

Origin IGP, localpref 100, valid, internal, import-candidate, imported, rib-install

Received Path ID 0, Local Path ID 0, version 0

Extended community: RT:1:100

EVPN ESI: 0000.0000.0000.0000.0000

Source VRF: default, Source Route Distinguisher: 192.168.1.12:100

This output indicates how XR3 will use the RIB to figure out the path to XR1 and XR2. Both will use LDP to get to their respective locations. Since we are looking at a detailed output of a MAC advertisement route, this is data plane specific, No data plane support currently.

RP/0/0/CPU0:XR3#sh mpls forwarding labels 24311

Sun Jan 1 20:47:09.794 UTC

Local Outgoing Prefix Outgoing Next Hop Bytes

Label Label or ID Interface Switched

------ ----------- ------------------ ------------ --------------- ------------

24311 Pop No ID BD=0 PE point2point 0

RP/0/0/CPU0:XR3#sh mpls forwarding labels 24312

Sun Jan 1 20:47:12.864 UTC

Local Outgoing Prefix Outgoing Next Hop Bytes

Label Label or ID Interface Switched

------ ----------- ------------------ ------------ --------------- ------------

24312 Pop No ID BD=0 PEIM point2point 0

RP/0/0/CPU0:XR3#show bgp l2vpn evpn bdomain CORE [3][256][32][192.168.1.11]/80

Sun Jan 1 19:54:21.691 UTC

BGP routing table entry for [3][256][32][192.168.1.11]/80, Route Distinguisher: 192.168.1.13:100

Versions:

Process bRIB/RIB SendTblVer

Speaker 27 27

Last Modified: Jan 1 18:12:01.298 for 01:42:20

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

Local

192.168.1.11 (metric 4) from 192.168.1.11 (192.168.1.11)

Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 27

Extended community: RT:1:100

PMSI: flags 0x00, type 6, label 24113, ID 0xc0a8010b

Source VRF: default, Source Route Distinguisher: 192.168.1.11:100

This is Inclusive Multicast Route specific,

Thanks for stopping by!

Rob Riker, CCIE #50693

Saturday, December 24, 2016

CCIE SPv4 - MPLS L2VPN - H-VPLS BGP AD with LDP - MPLS Access - E-TREE

Software versions:
IOS XE 15.5
IOS XR 5.3

The topology for this demo:

In this post we will be taking a look at the "E-TREE" design for H-VPLS. We've taken a look at E-LAN, where all the spokes can talk to each other. E-TREE like in previous posts, is designed to limit or "root" connectivity at a 1 or more PE devices to control what the CEs will learn. I've also mentioned in previous E-TREE posts, that normally the customer would be prompted to use something like Phase 1 DMVPN, at least that is one customer based solution.

Our design will take the NPE design in the previous H-VPLS deployments and continue on with it, all I am doing is adding more service instances to to the interfaces connecting the customers. Not shown is 10+ service instances, I am doing this to see what kind of scale can be achieved and have multiple solutions configured at one time.

R2, R4 and R5 are our NPEs, R3, R6 and R1 are our UPEs. R1 is the root of the E-TREE and R3 and R6 are the leaves. R13 will form an EIGRP peering with both R10 and R7. R10 and R7 will not form any adjacency in this design.

Since we already have the "l2vpn vpls" address family activated in the NPE core, we're simply going to add another "vfi context", but modifying the route target import/export policies to facilitate the BGP propagation in the core. My order of configuration is from the Access layer inward toward the Core, this allows me to know exactly what configuration is needed at each stage in order to ensure I am meeting the design correctly, UPEs then the NPEs get configured.

NPEs

interface pseudowire12900

encapsulation mpls

neighbor 192.168.1.1 12900

signaling protocol ldp

l2vpn vfi context E_TREE

vpn id 900

autodiscovery bgp signaling ldp

route-target export 900:50693

route-target export 901:50693

route-target import 901:50693

no auto-route-target

bridge-domain 900

member vfi E_TREE

member pseudowire12900

interface pseudowire56900

encapsulation mpls

neighbor 192.168.1.6 56900

l2vpn vfi context E_TREE

vpn id 900

autodiscovery bgp signaling ldp

route-target import 900:50693

route-target export 901:50693

no auto-route-target

bridge-domain 900

member vfi E_TREE

member pseudowire56900

interface pseudowire34900

encapsulation mpls

neighbor 192.168.1.3 34900

l2vpn vfi context E_TREE

vpn id 900

autodiscovery bgp signaling ldp

route-target import 900:50693

route-target export 901:50693

no auto-route-target

bridge-domain 900

member vfi E_TREE

member pseudowire34900

UPE Configuration

interface pseudowire34900

encapsulation mpls

neighbor 192.168.1.4 34900

l2vpn xconnect context E_TREE

member GigabitEthernet2 service-instance 900

member pseudowire34900

interface pseudowire56900

encapsulation mpls

neighbor 192.168.1.5 56900

l2vpn xconnect context E_TREE

member pseudowire56900

member GigabitEthernet2 service-instance 900

interface pseudowire12900

encapsulation mpls

neighbor 192.168.1.2 12900

l2vpn xconnect context E_TREE

member pseudowire12900

member GigabitEthernet2 service-instance 900

Verification here is pretty straightforward, we'll take a look at R1 for the UPE and R2 for the NPE and then R7 and R13.

R1#sh l2vpn atom vc | b 12900

pw12900 192.168.1.2 12900 p2p E_TREE UP

We see that we have an active peering to R2 via the P2P pseudowire 12900.

R1#sh l2vpn service xconnect all | b E_TREE

VPWS name: E_TREE, State: UP

pw12900 192.168.1.2:12900(MPLS) 0 UP UP

Gi2 Gi2:900(Eth VLAN) 0 UP UP

We can verify the service is working, we see the pseudowire and the SI attached to G2 are both up and that the SI is an Ethernet VLAN for VLAN 900.

R1#sh l2vpn atom vc pseudowire 12900 detail | in lab

Last label FSM state change time: 02:44:55

Output interface: Gi1.112, imposed label stack {24209 37}

SSO Descriptor: 192.168.1.2/12900, local label: 43

We can see the labels imposed for both the PW label and the LDP label that is used to reach R2. The pseudowire is label 43 indicated below by the "point2point" and the LDP labels, local is 40 and 24209 is used to reach R2. Label 37 indicated above is what R2 has allocated to reach R1 over the pseudowire.

R1#show mpls forwarding-table labels 43

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

43 No Label l2ckt(52) 449112 Gi2 point2point

R1#show mpls forwarding-table labels 40

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

40 24209 192.168.1.2/32 0 Gi1.112 10.1.12.12

24510 192.168.1.2/32 0 Gi1.115 10.1.15.15

R2#sh mpls forwarding-table labels 37

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

37 No Label l2ckt(11) 0 none point2point

R2#sh l2vpn atom vc | in E_TREE

pw12900 192.168.1.1 12900 vfi E_TREE UP

pw100010 192.168.1.4 900 vfi E_TREE UP

pw100011 192.168.1.5 900 vfi E_TREE UP

We can see that we have the manually configure pseudowire, 12900, to R1 and the dynamically built ones, pseudowire 100010 and 100011 to R4 and R5 respectively.

R2#sh l2vpn service vfi name E_TREE

Legend: St=State XC St=State in the L2VPN Service Prio=Priority

UP=Up DN=Down AD=Admin Down IA=Inactive

SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware

m=manually selected

Interface Group Encapsulation Prio St XC St

--------- ----- ------------- ---- -- -----

VPLS name: E_TREE, State: UP

pw100006 E_TREE(VFI) 0 UP UP

pw100011 core_pw 192.168.1.5:900(MPLS) 0 UP UP

pw100010 core_pw 192.168.1.4:900(MPLS) 0 UP UP

pw12900 core_pw 192.168.1.1:12900(MPLS) 0 UP UP

This output shows us from a high level all the components for the "E_TREE" vfi are up and operational.

R2#sh l2vpn vfi name E_TREE

Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No

VFI name: E_TREE, state: up, type: multipoint, signaling: LDP

VPN ID: 900, VPLS-ID: 50693:900

RD: 50693:900, RT: export 900:50693, 901:50693,

Bridge-Domain 900 attachment circuits:

Pseudo-port interface: pseudowire100006

Interface Peer Address VC ID Discovered Router ID S

pseudowire100011 192.168.1.5 900 192.168.1.5 Y

pseudowire100010 192.168.1.4 900 192.168.1.4 Y

pseudowire12900 192.168.1.1 12900 n/a N

This output, although very close to the one above it, is more specific to the BGP aspects, showing BGP AD information, discover RIDs and which pseudowires have split horizon enabled/disabled. You'll also notice that the RT portion shows 2 variations, 900 and 901, this is due to the configuration of the RT policies on the NPEs to determine the extended community propagation in the NPE core.

R2#show bgp l2vpn vpls rd 50693:900

BGP table version is 21, local router ID is 192.168.1.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 50693:900

*> 50693:900:192.168.1.2/96

0.0.0.0 32768 ?

*>i 50693:900:192.168.1.4/96

192.168.1.4 0 100 0 ?

*>i 50693:900:192.168.1.5/96

192.168.1.5 0 100 0 ?

Here we see the specifics towards the E_TREE instance.

R2#show bgp l2vpn vpls rd 50693:900 192.168.1.4

BGP routing table entry for 50693:900:192.168.1.4/96, version 21

Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)

Not advertised to any peer

Refresh Epoch 4

Local

192.168.1.4 (metric 4) from 192.168.1.4 (192.168.1.4)

Origin incomplete, metric 0, localpref 100, valid, internal, best, AGI version(3556769798)

Extended Community: RT:901:50693 L2VPN AGI:50693:900

mpls labels in/out 16777215/16777215

rx pathid: 0, tx pathid: 0x0

We've expanded the output for R4 and can see that the RT and AGI are matching, necessary for the VPN to form and be operational.

R2#show bridge-domain 900

Bridge-domain 900 (3 ports in all)

State: UP Mac learning: Enabled

Aging-Timer: 300 second(s)

vfi E_TREE neighbor 192.168.1.4 900

vfi E_TREE neighbor 192.168.1.5 900

vfi E_TREE neighbor 192.168.1.1 12900

AED MAC address Policy Tag Age Pseudoport

0 000C.2994.B818 forward dynamic 298 E_TREE.100401d

1 FFFF.FFFF.FFFF flood static 0 OLIST_PTR:0xe7f9fce0

0 000C.2990.89E9 forward dynamic 298 E_TREE.100401e

0 000C.29BA.0E21 forward dynamic 297 E_TREE.100401c

We can see that we are indeed learning information from R1, R3 and R6 respectively, it's not obvious which MAC comes from which UPE, but rather that we have that info here.

Let's verify the labels and see how that info is derived.

R2#show l2vpn atom vc pseudowire 100010 detail | in label

Last label FSM state change time: 03:04:36

Output interface: Gi1.162, imposed label stack {24602 49}

SSO Descriptor: 192.168.1.4/900, local label: 34

R2#show mpls forwarding-table labels 24

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

24 23 192.168.1.4/32 0 Gi1.26 10.2.6.6

24602 192.168.1.4/32 0 Gi1.162 10.16.2.16

R2#show mpls forwarding-table labels 34

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

34 No Label l2ckt(9) 0 none point2point

So here we have the dynamically learned pseudowire labels allocated via LDP to reach R4. Labels 23 and 24602 are used to reach R4, label 34 is used to reach R4 over the pseudowire connection.

This process repeats itself for reachability to R5 and R1.

R2#show l2vpn atom vc pseudowire 100011 detail | in label

Last label FSM state change time: 03:05:00

Output interface: Gi1.26, imposed label stack {22 564}

SSO Descriptor: 192.168.1.5/900, local label: 36

R2#show mpls forwarding-table labels 23

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

23 22 192.168.1.5/32 3422 Gi1.26 10.2.6.6

24603 192.168.1.5/32 2122375 Gi1.162 10.16.2.16

R2#show mpls forwarding-table labels 36

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

36 No Label l2ckt(10) 0 none point2point

R2#show l2vpn atom vc pseudowire 12900 detail | in label

Last label FSM state change time: 03:02:26

Output interface: Gi1.162, imposed label stack {24609 43}

SSO Descriptor: 192.168.1.1/12900, local label: 37

R2#show mpls forwarding-table labels 26

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

26 24309 192.168.1.1/32 51698599 Gi1.132 10.13.2.13

24609 192.168.1.1/32 19646298 Gi1.162 10.16.2.16

R2#show mpls forwarding-table labels 37

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

37 No Label l2ckt(11) 0 none point2point

Let's trace how traffic coming from R1 and going to R3 will be forwarded in the access and the core.

R1#sh l2vpn atom vc pseudowire 12900 detail | in label

Last label FSM state change time: 03:10:37

Output interface: Gi1.112, imposed label stack {24209 37}

SSO Descriptor: 192.168.1.2/12900, local label: 43

R1#sh mpls forwarding-table labels 43

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

43 No Label l2ckt(52) 514652 Gi2 point2point

R1#sh mpls forwarding-table labels 40

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

40 24209 192.168.1.2/32 0 Gi1.112 10.1.12.12

24510 192.168.1.2/32 0 Gi1.115 10.1.15.15

R1 will use labels 24209 and 24510 to reach R2 via the LSP to R2's loopback. Label 43 is used to forward data over the pseudowire from the access into the core.

R1#traceroute 192.168.1.2 source 192.168.1.1 num

Type escape sequence to abort.

Tracing the route to 192.168.1.2

VRF info: (vrf in name/id, vrf out name/id)

1 10.1.12.12 [MPLS: Label 24209 Exp 0] 6 msec

10.1.15.15 [MPLS: Label 24510 Exp 0] 3 msec

10.1.12.12 [MPLS: Label 24209 Exp 0] 9 msec

2 10.15.16.16 [MPLS: Label 24610 Exp 0] 4 msec

10.12.16.16 [MPLS: Label 24610 Exp 0] 3 msec

10.15.16.16 [MPLS: Label 24610 Exp 0] 6 msec

3 10.16.2.2 5 msec * 4 msec

R2#sh l2vpn atom vc pseudowire 100010 detail | in label

Last label FSM state change time: 03:17:12

Output interface: Gi1.162, imposed label stack {24602 49}

SSO Descriptor: 192.168.1.4/900, local label: 34

R2 receives the traffic inbound and now needs to figure out where to send it. R1 sent traffic to R2 over the pseudowire, R2 allocated label 37 to reach R1, when R2 receives the traffic in with label 37, R2 knows to label swap that to label 34 to reach R4.

R2#show mpls forwarding-table labels 24

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

24 23 192.168.1.4/32 0 Gi1.26 10.2.6.6

24602 192.168.1.4/32 0 Gi1.162 10.16.2.16

R2#show mpls forwarding-table labels 34

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

34 No Label l2ckt(9) 0 none point2point

R2 will use labels 23 and 24602 to reach R4s loopack and label 34 to send traffic over pseudowire 100010 in the NPE core.

R2#traceroute 192.168.1.4 so lo0 num

Type escape sequence to abort.

Tracing the route to 192.168.1.4

VRF info: (vrf in name/id, vrf out name/id)

1 10.2.6.6 [MPLS: Label 23 Exp 0] 27 msec

10.16.2.16 [MPLS: Label 24602 Exp 0] 2 msec

10.2.6.6 [MPLS: Label 23 Exp 0] 4 msec

2 10.15.16.15 [MPLS: Label 24500 Exp 0] 4 msec

10.5.6.5 [MPLS: Label 517 Exp 0] 18 msec

10.15.16.15 [MPLS: Label 24500 Exp 0] 4 msec

3 10.4.5.4 63 msec

10.15.4.4 4 msec

R4 receives this traffic, since R4 allocated label 49 to the pseudowire to reach R2, it knows that when that label comes in, to label swap it to label 47 towards R3. It also locally allocated label 31 for LDP LSP switching,

R4#sh l2vpn atom vc pseudowire 34900 detail | in label

Last label FSM state change time: 04:26:02

Output interface: Gi1.34, imposed label stack {31}

SSO Descriptor: 192.168.1.3/34900, local label: 47

R4#sh mpls forwarding-table labels 31

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

31 Pop Label 192.168.1.3/32 123979228 Gi1.34 10.3.4.3

R4#sh mpls forwarding-table labels 47

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

47 No Label l2ckt(10) 0 none point2point

Since R3 and R4 are directly connected to each other, the LDP transport label is popped, label 31 and the label 47 is used to forward traffic towards R3.

R3#sh l2vpn atom vc pseudowire 34900 detail | in label

Last label FSM state change time: 04:35:24

Output interface: Gi1.34, imposed label stack {47}

SSO Descriptor: 192.168.1.4/34900, local label: 31

R3#sh mpls forwarding-table labels 31

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

31 No Label l2ckt(11) 367610 Gi2 point2point

Since R3 is the end of the LSP to reach R7, we leave the SP network and data is sent out the AC on G2.900 towards R7.

As you can see by the outputs below, all is well, R7 and R13 have formed EIGRP adjacency.

R7#sh ip eigrp nei

EIGRP-IPv4 Neighbors for AS(1)

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

10 192.168.90.13 Gi1.900 12 03:28:01 270 1620 0 563

R7#sh ip eigrp interfaces gigabitEthernet 1.900

EIGRP-IPv4 Interfaces for AS(1)

Xmit Queue PeerQ Mean Pacing Time Multicast Pending

Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes

Gi1.900 1 0/0 0/0 270 0/0 50 0

R13#sh ip eigrp nei

EIGRP-IPv4 Neighbors for AS(1)

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

19 192.168.90.7 Gi2.900 13 03:30:01 135 810 0 244

18 192.168.90.10 Gi2.900 12 03:30:01 1996 5000 0 531

R13#sh ip eigrp interfaces g2.900

EIGRP-IPv4 Interfaces for AS(1)

Xmit Queue PeerQ Mean Pacing Time Multicast Pending

Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes

Gi2.900 2 0/0 0/0 1065 0/0 4260 0

Thanks for stopping by!

Rob Riker, CCIE #50693