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
R2
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
R5
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
R4
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
R3
interface pseudowire34900
encapsulation mpls
neighbor 192.168.1.4 34900
!
l2vpn xconnect context E_TREE
member GigabitEthernet2 service-instance 900
member pseudowire34900
R6
interface pseudowire56900
encapsulation mpls
neighbor 192.168.1.5 56900
!
l2vpn xconnect context E_TREE
member pseudowire56900
member GigabitEthernet2 service-instance 900
R1
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
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
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
