Rob Riker/ Simplified Networking

Friday, December 23, 2016

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

Software versions:
IOS XE 15.5
IOS XR 5.3

The topology for this demo:

In the previous post we took a look at H-VPLS in a very basic setup, conceptually basic, configuration wise it is rather intensive. In this post we'll take H-VPLS deeper with BGP AD with LDP signaling for E-LAN, where all the CEs can communicate with each other.

In the previous post, we configured manual NPE pseudowires, which works in our little lab to test out the configuration, but in a large SP network with 100s of NPEs, that is not going to happen. So we implement BGP AD with LDP signaling to provide the scalability required for large environments. Since our deployment is rather small, I don't bother with BGP configuration scaling techniques, just a couple of neighbor statements where needed to get functionality working.

We've taken a look at VPLS with BGP AD in prior posts, so the BGP configuration there is what we'll use here. We'll be activating the "l2vpn vpls" address family and this is what we'll enable the propagation of NLRI between the NPEs so that the SP Access where the UPEs sit will be able to advertise and learn information from the NPEs and provide end to end connectivity. We'll start with the NPE configuration and work our way out to the customer. I didn't configure it that way, I started on the Customer, then the UPE, then the NPEs, then the went back to make sure it was working. It was my way of proving each step and the order of operations were followed. It also allows me to see the minimum required level of configuration needed to get the function working.

NPEs

R4
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include

signaling protocol ldp
!
interface pseudowire34100
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.3 34100

signaling protocol ldp
!
l2vpn vfi context VPLS_100
vpn id 100
autodiscovery bgp signaling ldp
route-target export 100:50693
route-target import 100:50693

no auto-route-target
!
bridge-domain 100
member vfi VPLS_100

member pseudowire34100
!
router bgp 50693
bgp log-neighbor-changes
neighbor 192.168.1.2 remote-as 50693
neighbor 192.168.1.2 update-source Loopback0
neighbor 192.168.1.5 remote-as 50693
neighbor 192.168.1.5 update-source Loopback0
!
address-family l2vpn vpls
neighbor 192.168.1.2 activate
neighbor 192.168.1.2 prefix-length-size 2
neighbor 192.168.1.5 activate

neighbor 192.168.1.5 prefix-length-size 2

R5
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include

signaling protocol ldp
!
interface pseudowire56100
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.6 56100

signaling protocol ldp
!
l2vpn vfi context VPLS_100
vpn id 100
autodiscovery bgp signaling ldp
route-target export 100:50693

route-target import 100:50693
!
bridge-domain 100
member vfi VPLS_100

member pseudowire56100
!
router bgp 50693
bgp log-neighbor-changes
neighbor 192.168.1.2 remote-as 50693
neighbor 192.168.1.2 update-source Loopback0
neighbor 192.168.1.4 remote-as 50693
neighbor 192.168.1.4 update-source Loopback0
!
address-family l2vpn vpls
neighbor 192.168.1.2 activate
neighbor 192.168.1.2 prefix-length-size 2
neighbor 192.168.1.4 activate

neighbor 192.168.1.4 prefix-length-size 2

R2
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include

signaling protocol ldp
!
interface pseudowire12100
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.1 12100

signaling protocol ldp
!
l2vpn vfi context VPLS_100
vpn id 100
autodiscovery bgp signaling ldp
route-target export 100:50693
route-target import 100:50693

no auto-route-target
!
bridge-domain 100
member vfi VPLS_100

member pseudowire12100
!
router bgp 50693
bgp log-neighbor-changes
neighbor 192.168.1.4 remote-as 50693
neighbor 192.168.1.4 update-source Loopback0
neighbor 192.168.1.5 remote-as 50693
neighbor 192.168.1.5 update-source Loopback0
!
address-family l2vpn vpls
neighbor 192.168.1.4 activate
neighbor 192.168.1.4 prefix-length-size 2
neighbor 192.168.1.5 activate

neighbor 192.168.1.5 prefix-length-size 2

UPE Configuration

R3
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include

signaling protocol ldp
!
interface pseudowire34100
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.4 34100

signaling protocol ldp
!
l2vpn xconnect context VPLS_100
member GigabitEthernet2 service-instance 100

member pseudowire34100

R6
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include

signaling protocol ldp
!
interface pseudowire56100
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.5 56100

signaling protocol ldp
!
l2vpn xconnect context VPLS_100
member GigabitEthernet2 service-instance 100

member pseudowire56100

R1
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include

signaling protocol ldp
!
interface pseudowire12100
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.2 12100

signaling protocol ldp
!
l2vpn xconnect context VPLS_100
member GigabitEthernet2 service-instance 100

member pseudowire12100

Now that we have everything configured, in my testing, it took on average 2-4 minutes for BGP to run best path and propagate information.

We'll verify the VPLS part and make sure all is well with BGP.

R3#sh xc all | in 100

UP pri ac Gi2:100(Eth VLAN) UP mpls 192.168.1.4:34100 UP

R3#sh l2vpn service xconnect all | in 100

VPWS name: VPLS_100, State: UP

Gi2 Gi2:100(Eth VLAN) 0 UP UP

pw34100 192.168.1.4:34100(MPLS) 0 UP UP

We can see that the UPE configuration is good and that the peering to R4 is operational.

NPE Verification:

R4#sh l2vpn service vfi name VPLS_100 | b Interface

Interface Group Encapsulation Prio St XC St

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

VPLS name: VPLS_100, State: UP

pw100002 VPLS_100(VFI) 0 UP UP

pw100005 core_pw 192.168.1.5:100(MPLS) 0 UP UP

pw100003 core_pw 192.168.1.2:100(MPLS) 0 UP UP

pw34100 core_pw 192.168.1.3:34100(MPLS) 0 UP UP

We can see that the l2vpn service is up and operational, this output and the next are centric to the VPLS aspect, this one specifically highlights all parts of the service, pseudowires to the other NPEs and the UPE. pw100002 specifically points to the operational status of the VFI instance.

R4#show l2vpn vfi name VPLS_100

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

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

VPN ID: 100, VPLS-ID: 50693:100

RD: 50693:100, RT: 100:50693,

Bridge-Domain 100 attachment circuits:

Pseudo-port interface: pseudowire100002

Interface Peer Address VC ID Discovered Router ID S

pseudowire100005 192.168.1.5 100 192.168.1.5 Y

pseudowire100003 192.168.1.2 100 192.168.1.2 Y

pseudowire34100 192.168.1.3 34100 n/a N

Like the previous output, vfi centric, however this is more specific to the actual forwarding of traffic on the NPE, we see 3 different psuedowires, 2 to the other NPEs and 1 to the UPE, you'll see that split horizon is enabled on the NPE facing pseudowires. You'll also see the "Discovered Router ID", this is an indication that BGP AD is being used, you normally won't see that, you'll see the pseudowire info and the VC-ID used to reach that remote device, here we see that R5 and R2 show up. but R3 we see the "n/a", meaning that R3 is statically assigned and not running BGP AD.

R4#sh bgp l2vpn vpls all summary

BGP router identifier 192.168.1.4, local AS number 50693

BGP table version is 7, main routing table version 7

3 network entries using 792 bytes of memory

3 path entries using 408 bytes of memory

2/2 BGP path/bestpath attribute entries using 496 bytes of memory

1 BGP extended community entries using 40 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

BGP using 1736 total bytes of memory

BGP activity 4/1 prefixes, 4/1 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

192.168.1.2 4 50693 139 139 7 0 0 02:02:10 1

192.168.1.5 4 50693 125 128 7 0 0 01:50:17 1

We see that we have connectivity to R2 and R5, and we're learning 1 pfx from each, however this isn't a "prefix" so to speak, but rather a MAC from that router.

R4#sh bgp l2vpn vpls all

BGP table version is 7, local router ID is 192.168.1.4

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:100

*>i 50693:100:192.168.1.2/96

192.168.1.2 0 100 0 ?

*> 50693:100:192.168.1.4/96

0.0.0.0 32768 ?

*>i 50693:100:192.168.1.5/96

192.168.1.5 0 100 0 ?

We can see that we have /96 prefixes learned, the RD:RID of the remote device, this is a good sign of solid propagation of MAC learned from the remote peer.

R4#sh bgp l2vpn vpls all 192.168.1.2

BGP routing table entry for 50693:100:192.168.1.2/96, version 2

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

Not advertised to any peer

Refresh Epoch 1

Local

192.168.1.2 (metric 4) from 192.168.1.2 (192.168.1.2)

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

Extended Community: RT:100:50693 L2VPN AGI:50693:100

mpls labels in/out 16777215/16777215

rx pathid: 0, tx pathid: 0x0

We take a deeper look at what R2 has advertised to us, we see the AGI info is the same as the RT and RD, all of these values must match in order for R4 to learn the routes. Another thing to take note on is that the "mpls labels" are 16777215, which simply means max value or not used. BGP signaling for VPLS doesn't exchange labels, it exchanges details on how the label should be derived. The quickest way to find that out is to look at the atom DB.

R4#show l2vpn atom vc pseudowire 100003 detail | in label

Last label FSM state change time: 02:52:05

Output interface: Gi1.154, imposed label stack {24510 33}

SSO Descriptor: 192.168.1.2/100, local label: 51

This output shows that label 51 is allocated for the p2p pseudowire.

R4#show mpls forwarding-table labels 51

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

51 No Label l2ckt(8) 0 none point2point

This output shows that label 24510 is used to reach the next hop, which at the moment, hasn't incremented the "label switched" portion, which is no big deal.

R4#show mpls forwarding-table labels 40

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

40 527 192.168.1.2/32 7884 Gi1.45 10.4.5.5

24510 192.168.1.2/32 0 Gi1.154 10.15.4.15

R4#sh bridge-domain 100

Bridge-domain 100 (3 ports in all)

State: UP Mac learning: Enabled

Aging-Timer: 300 second(s)

vfi VPLS_100 neighbor 192.168.1.3 34100

vfi VPLS_100 neighbor 192.168.1.2 100

vfi VPLS_100 neighbor 192.168.1.5 100

AED MAC address Policy Tag Age Pseudoport

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

0 000C.29BA.0E21 forward dynamic 297 VPLS_100.1004016

0 000C.2994.B818 forward dynamic 298 VPLS_100.1004019

0 000C.2990.89E9 forward dynamic 296 VPLS_100.1004017

This output shows that we have dynamically learned about 3 UPEs who have forwarded data into the NPE core. WE see the three peers, 2 of them being NPE peers, the other is the UPE peer. Since R2 and R5 were learned dynamically, there "VC-ID" is 100 and not statically defined like R3 is.

Customer verification:

R7#sh ip eigrp nei

EIGRP-IPv4 Neighbors for AS(1)

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

8 192.168.100.10 Gi1.100 14 02:56:22 257 1542 0 462

9 192.168.100.13 Gi1.100 10 02:57:58 334 2004 0 495

All is well!

Thanks for stopping by!

Rob Riker, CCIE #50693

Wednesday, December 21, 2016

CCIE SPv4 - MPLS L2VPN - Hierarchical VPLS (H-VPLS) - MPLS Access and PW Redundancy

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 H-VPLS. We've taken a look at VPLS in previous posts, however, H-VPLS is scalability enhancement to VPLS as you may know it. With traditional VPLS, all PEs that wish to exchange customer data must join the bridge domain used to propagate the L2 traffic. Much in the same way that traditional iBGP works, if no route reflection is used, all iBGP speakers must connect to all other iBGP speakers. H-VPLS works in much the same manner. We have to introduce some new terms and their functions before we tackle the config.

U-PE - User Provider Edge: This is the PE that participates in forwarding with the customer equipment, this could be a switch or a router. The router forms PW peerings with the MPLS core of N-PEs and is the entry point of customer data into the SP network. The UPE can connect to 1 or multiple NPEs for redundancy. In this post we will focus on 1 UPE connecting to 1 NPE for easing into this topic, I'll do another post focusing on redundancy and failover options.

N-PE - Network Provider Edge: This is the PE that participates in MPLS SP core forwarding and forms PW peerings with the UPEs. Think of the NPE as loosely analogous to the BGP route reflector, it does more than host the control plane and sits in the data plane. It enables the "hierarchy" that makes H-VPLS possible. As previously stated, traditional VPLS PEs form a "full mesh" of peering with other PEs. In H-VPLS, UPEs only form PW peerings with NPEs. NPEs form a full mesh of PW peerings with other NPEs. That's where the "loosely" part comes into play, it reduces the UPE full mesh requirement, beyond that, no real savings.

Let's take the above topology, we'll focus on 2 different parts, R4, R5 and R2 will be the "NPEs", XR5 and XR6 are Provider core routers, and R1, R3, R6 and XR3 will be the "UPEs". The NPEs will form a full mesh of peerings and terminate the "SP Access". SP Access relates to the part of the SP network that customers connect to, the SP core is the part where no customers connect. So the NPEs are the SP core and the UPEs are the SP access. As stated in previous posts, XRv doesn't support the L2 VPN data plane, we'll just get the control plane up and running. *NOTE* XRv doesn't appear to support the NPE feature.

Since the UPEs are configured with the "xconnect" context and the NPEs are configured with the "vfi" contexts, the deployment is slightly different. The UPE pretty much acts like a intermediary device between the customer and the NPE router. Since we'll be dealing with 2 PWs, we'll configure the redundancy on the UPEs as we go.

UPE to NPE peerings

R3 to R2 and R4

R6 to R5 and R4

R1 to R2 and R5

XR3 to R2 and R5

NPE Configuration

template type pseudowire HVPLS

encapsulation mpls

sequencing both

control-word include

signaling protocol ldp

interface pseudowire34105

description UPE_TO_R3

source template type pseudowire HVPLS

encapsulation mpls

neighbor 192.168.1.3 34105

signaling protocol ldp

interface pseudowire42105

description NPE_TO_R2

source template type pseudowire HVPLS

encapsulation mpls

neighbor 192.168.1.2 42105

signaling protocol ldp

interface pseudowire45105

description NPE_TO_R5

source template type pseudowire HVPLS

encapsulation mpls

neighbor 192.168.1.5 45105

signaling protocol ldp

interface pseudowire46105

source template type pseudowire HVPLS

encapsulation mpls

neighbor 192.168.1.6 46105

signaling protocol ldp

!
l2vpn vfi context H_VPLS
vpn id 105
member pseudowire42105
member pseudowire45105
!
bridge-domain 150
member vfi H_VPLS
member pseudowire46105
member pseudowire34105

R5
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include
signaling protocol ldp
!
interface pseudowire15105
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.1 15105
signaling protocol ldp
interface pseudowire45105
description NPE_TO_R4
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.4 45105
signaling protocol ldp
interface pseudowire52105
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.2 52105
signaling protocol ldp
interface pseudowire53105
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.13 53105
signaling protocol ldp
interface pseudowire56105
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.6 56105
!
l2vpn vfi context H_VPLS
vpn id 105
member pseudowire52105
member pseudowire45105
!
bridge-domain 150
member vfi H_VPLS
member pseudowire53105
member pseudowire15105
member pseudowire56105

R2
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include
signaling protocol ldp
!
interface pseudowire12105
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.1 12105
signaling protocol ldp
interface pseudowire23105
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.13 23105
signaling protocol ldp
interface pseudowire32105
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.3 32105
signaling protocol ldp
interface pseudowire42105
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.4 42105
signaling protocol ldp
interface pseudowire52105
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.5 52105
!
l2vpn vfi context H_VPLS
vpn id 150
member pseudowire52105
member pseudowire42105
!
bridge-domain 150
member vfi H_VPLS
member pseudowire32105
member pseudowire23105
member pseudowire12105

UPE Configuration
R3
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include
signaling protocol ldp
!
interface pseudowire32105
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.2 32105
signaling protocol ldp
interface pseudowire34105
source template type pseudowire HVPLS
encapsulation mpls

neighbor 192.168.1.4 34105
!
l2vpn xconnect context H_VPLS
member pseudowire34105 group HVPLS_RED priority 5
member pseudowire32105 group HVPLS_RED priority 10
member GigabitEthernet2 service-instance 150

R6
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include
signaling protocol ldp
!
interface pseudowire46105
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.4 46105
signaling protocol ldp
interface pseudowire56105
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.5 56105
signaling protocol ldp
!
l2vpn xconnect context HVPLS
member GigabitEthernet2 service-instance 150
member pseudowire56105 group HVPLS_RED priority 5
member pseudowire46105 group HVPLS_RED priority 10

R1
template type pseudowire HVPLS
encapsulation mpls
sequencing both
control-word include
signaling protocol ldp
!
interface pseudowire12105
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.2 12105
signaling protocol ldp
interface pseudowire15105
source template type pseudowire HVPLS
encapsulation mpls
neighbor 192.168.1.5 15105
signaling protocol ldp
!
l2vpn xconnect context H_VPLS
member GigabitEthernet2 service-instance 150
member pseudowire12105 group HVPLS_RED priority 5
member pseudowire15105 group HVPLS_RED priority 10

XR3
l2vpn
xconnect group H_VPLS
p2p H_VPLS
interface GigabitEthernet0/0/0/1
neighbor ipv4 192.168.1.2 pw-id 23105
backup neighbor 192.168.1.5 pw-id 53105

Let's verify the NPE core from R4s perspective.

R4#sh l2vpn atom vc | in H
pw42105 192.168.1.2 42105 vfi H_VPLS UP
pw34105 192.168.1.3 34105 vfi H_VPLS UP
pw45105 192.168.1.5 45105 vfi H_VPLS UP
pw46105 192.168.1.6 46105 vfi H_VPLS STANDBY

We can see that the connections between the NPEs and UPEs are up and running.

R4#sh l2vpn service vfi name H_VPLS
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: H_VPLS, State: UP
pw100001 H_VPLS(VFI) 0 UP UP
pw46105 core_pw 192.168.1.6:46105(MPLS) 0 SB SB
pw42105 core_pw 192.168.1.2:42105(MPLS) 0 UP UP
pw34105 core_pw 192.168.1.3:34105(MPLS) 0 UP UP
pw45105 core_pw 192.168.1.5:45105(MPLS) 0 UP UP

This output is just a bit more detailed than the last, it give us more specific status to the "VFI" than just the up or down status of the xconnect.

R4#sh bridge-domain
Bridge-domain 150 (4 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
vfi H_VPLS neighbor 192.168.1.5 45105
vfi H_VPLS neighbor 192.168.1.2 42105
vfi H_VPLS neighbor 192.168.1.3 34105
vfi H_VPLS neighbor 192.168.1.6 46105
AED MAC address Policy Tag Age Pseudoport
0 000C.2994.B818 forward dynamic 299 H_VPLS.1004010
1 FFFF.FFFF.FFFF flood static 0 OLIST_PTR:0xe7fa6c00
0 000C.2990.89E9 forward dynamic 297 H_VPLS.1004014
0 000C.29BA.0E21 forward dynamic 296 H_VPLS.1004013

By consulting the bridge domain, we can see that we are learning 3 MACs from the different PWs we have configured, more importantly the learning is being done from both NPE and UPE devices.

R4#sh l2vpn vfi name H_VPLS
Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No

VFI name: H_VPLS, state: up, type: multipoint, signaling: LDP
VPN ID: 105
Bridge-Domain 150 attachment circuits:
Pseudo-port interface: pseudowire100001
Interface Peer Address VC ID S
pseudowire46105 192.168.1.6 46105 N
pseudowire42105 192.168.1.2 42105 Y
pseudowire34105 192.168.1.3 34105 N
pseudowire45105 192.168.1.5 45105 Y

We can see that the NPE pseudowires, R2 and R5 have split horizon enabled, where the connections down to the UPEs do not have split horizon enabled. This is intentional, we don't want to send info we learn from NPEs back out to those same NPEs. This is the core, so we use those connections to receive data and forward it out to the UPEs. As information is propagated from the SP access into the SP core, LDP is used to figure out where to send the data. If split horizon wasn't enabled between NPEs then data would flood uncontrolled in the core, just like a switch would just send the data everywhere.

Let's verify R3 and then XR3 since we have both IOS and XR in the access layer.

R3
R3#sh l2vpn atom vc | in H
pw32105 192.168.1.2 32105 p2p H_VPLS STANDBY
pw34105 192.168.1.4 34105 p2p H_VPLS UP

R3#sh xconnect all
Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware

XC ST Segment 1 S1 Segment 2 S2
------+---------------------------------+--+---------------------------------+--
UP pri mpls 192.168.1.4:34105 UP ac Gi2:150(Eth VLAN) UP
IA pri mpls 192.168.1.2:32105 SB ac Gi2:150(Eth VLAN) SB

Since both R3 and XR3 are configured with xconnect l2vpn, there isn't much to verify other than the PWs being up.

XR3
RP/0/0/CPU0:XR3#sh l2vpn xconnect
Thu Dec 22 02:48:03.848 UTC
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed

XConnect Segment 1 Segment 2
Group Name ST Description ST Description ST
------------------------ ----------------------------- -----------------------------
H_VPLS H_VPLS UP Gi0/0/0/1 UP 192.168.1.2 23105 UP
Backup
192.168.1.5 53105 SB

RP/0/0/CPU0:XR3#sh l2vpn atom-db
Thu Dec 22 02:48:24.976 UTC

Peer ID Source VC ID Encap SIG FEC AD
_______________________________________________________________________________

192.168.1.2 192.168.1.13 23105 MPLS LDP 128 none
192.168.1.5 192.168.1.13 53105 MPLS LDP 128 none

RP/0/0/CPU0:XR3#sh l2vpn database ac
Thu Dec 22 02:49:39.751 UTC
GigabitEthernet0/0/0/1:
Other-Segment MTU: 0
Other-Segment status flags: 0x3
Signaled capability valid: Yes
Signaled capability flags: 0x20
Configured capability flags: 0x0
XCID: 0x1
PSN Type: MPLS Dynamic
ETH data:
Xconnect tags: 0
Vlan rewrite tag: 0
AC defn:
ac-ifname: GigabitEthernet0_0_0_1
capabilities: 0x0000707f
extra-capabilities: 0x00000000
parent-ifh: 0x00000000
ac-type: 0x04
interworking: 0x00
AC info:
seg-status-flags: 0x00000003
segment mtu/l2-mtu: 1500/1514

Lets verify the CE side
R7

router eigrp 1
network 0.0.0.0
!
interface GigabitEthernet1.150
encapsulation dot1Q 150
ip address 192.168.150.7 255.255.255.0
!
R7#sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
7 192.168.150.13 Gi1.150 14 01:34:18 378 2268 0 422
6 192.168.150.10 Gi1.150 11 01:37:56 128 768 0 386

All is well.

Thanks for stopping by!

Rob Riker, CCIE #50693