IOS XE 15.5
IOS XR 5.3
The topology for this demo:
In this post we will be taking the previous "Port" based configuration and leveraging the service instance for both "encapsulation dot1q VLAN" "VLAN" and "encapsulation dot1q VLAN second-dot1q VLAN" "QinQ" variations. Just like in the "Port" based configuration, the service instance is used to multiplex the port to support several configuration options that the EFP or Ethernet Flow Point capability is design to do. As discussed in previous posts, the EFP allows the SP to connect several customers to a single interface and, depending on the services needed, to selectively map the "service instance" to a "context", decoupling the interface from the service it is providing access to. This greatly increases the scale, and is supported for both P2P (EPL/EVPL), MP2MP (VPLS/H-VPLS) and P2MP (E-TREE or Rooted VPLS).
R1 and R6 are the PEs providing access into the SP core, R10 connecting to R6 and R13 to R1. Ihave OSPFv2 running on R13 and R10 to proove that there is dataplane connectivity between the CEs. We'll start out with the VLAN configuration variant to highlight the fact that if there are customers that require at least 1 VLAN, we'll be able to meet that need. The QinQ option will be visited a little later, very similar configuration, but with 2 VLAN tags.
To level set between the 2 variations, the only configuration difference is the service instance at the interface level, the VLAN variation has only a single VLAN encapsulated, where the QinQ variation has 2. Beyond that, the rest of the configuration is identical, I'll include all the necessary configuration to make sure you see the difference.
The VLAN Variant
R1
interface GigabitEthernet2
service instance 16 ethernet
encapsulation dot1q 1013
!
interface pseudowire16
encapsulation mpls
neighbor 192.168.1.6 16
!
l2vpn xconnect context VLAN
member pseudowire16
member GigabitEthernet2 service-instance 16
The interface level configuration is the same as Inter-VLAN routing without an IP address configured at the interface level.
The pseudowire configuration set the encapsulation to MPLS and the neighbor to R6, mapping to the VC-ID of 16.
The xconnect context has 2 members, pseudowire 16 and G2 service instance 16, providing the mapping from interface to bridge. As traffic from R13 comes into R1 on G2 SI 16, it will be immediately encap'd into MPLS and tLDP to R6 which will place the traffic onto G2 SI 16 out to R10, thus completely the circuit.
R6
interface GigabitEthernet2
service instance 16 ethernet
encapsulation dot1q 1013
!
interface pseudowire16
encapsulation mpls
neighbor 192.168.1.1 16
!
l2vpn xconnect context VLAN
member pseudowire16
member GigabitEthernet2 service-instance 16
I won't bore you with another breakdown, R1's config breakdown works on R6 😉.
So now we have completed the configuration between R1 and R6. Since we are dealing with P2P connections ro "xconnects", there are several debugs that show output of the AC or attachment circuit, PW or pseudowire and other details.
debug l2vpn xconnect event
debug l2vpn xconnect initialization
A couple things to point out, [192.168.1.1:16] indicates the PW; [Gi2:1013] indicates the SI.
If you leave the debugs running while you are enabling/disabling capabilities, be patient, there is a lot of update/sync type output.
XC VPWS[BF000001:192.168.1.1:16]: Update, i/f 4002
XC VPWS[BF000001:192.168.1.1:16]: Circuit attributes from client:
XC VPWS[BF000001:192.168.1.1:16]: Payload encap: Ethernet
XC VPWS[BF000001:192.168.1.1:16]: VLAN ID: 0
XC VPWS[BF000001:192.168.1.1:16]: Loadbalance mode: None
XC VPWS[BF000001:192.168.1.1:16]: Loadbalance Flow class: none
XC VPWS[BF000001:Gi2:1013]: Send active circuit attributes
XC VPWS[BF000001:Gi2:1013]: Circuit attributes to client:
XC VPWS[BF000001:Gi2:1013]: Payload encap: Ethernet
XC VPWS[BF000001:Gi2:1013]: VLAN ID: 0
XC VPWS[BF000001:Gi2:1013]: Loadbalance mode: None
XC VPWS[BF000001:Gi2:1013]: Loadbalance Flow class: none
XC VPWS[BF000001:192.168.1.1:16]: Update, i/f 4002
XC VPWS[BF000001:192.168.1.1:16]: Circuit attributes from client:
XC VPWS[BF000001:192.168.1.1:16]: Interface handle: 0x4002
XC VPWS[BF000001:192.168.1.1:16]: Status: UP (0x1)
XC VPWS[BF000001:192.168.1.1:16]: Payload encap: Ethernet
XC VPWS[BF000001:192.168.1.1:16]: Circuit Encap: Ethernet
XC VPWS[BF000001:192.168.1.1:16]: VCCV CC: 0x7
XC VPWS[BF000001:192.168.1.1:16]: Segment type: AToM
XC VPWS[BF000001:192.168.1.1:16]: Control Word: yes
XC VPWS[BF000001:192.168.1.1:16]: Fast Switchover: no
XC VPWS[BF000001:192.168.1.1:16]: MTU: 1500
XC VPWS[BF000001:192.168.1.1:16]: I/F Str: pw16
XC VPWS[BF000001:192.168.1.1:16]: Circuit string: 192.168.1.1:16
XC VPWS[BF000001:192.168.1.1:16]: Received status change, status is UP
XC VPWS[BF000001:Gi2:1013]: Circuit attributes to client:
XC VPWS[BF000001:Gi2:1013]: Interface handle: 0x4002
XC VPWS[BF000001:Gi2:1013]: Status: UP (0x1)
XC VPWS[BF000001:Gi2:1013]: Payload encap: Ethernet
XC VPWS[BF000001:Gi2:1013]: Circuit Encap: Ethernet
XC VPWS[BF000001:Gi2:1013]: VCCV CC: 0x7
XC VPWS[BF000001:Gi2:1013]: Segment type: AToM
XC VPWS[BF000001:Gi2:1013]: Control Word: yes
XC VPWS[BF000001:Gi2:1013]: Fast Switchover: no
XC VPWS[BF000001:Gi2:1013]: MTU: 1500
XC VPWS[BF000001:Gi2:1013]: I/F Str: pw16
XC VPWS[BF000001:Gi2:1013]: Circuit string: 192.168.1.1:16
XC: MPLS peer 192.168.1.1 vcid 16, VC state UP
So as you can see, the VC is up. Now it's time to look at some of the specific outputs, like the VC details, MPLS forwarding table, knowing which labels equal to forwarding and others to local mappings, how to correlate the outgoing label to the PW. Let's take a look at the basics first and then take a walk into the weeds.
R1#sh l2vpn atom vc
Service
Interface Peer ID VC ID Type Name Status
--------- --------------- ---------- ------ ------------------------ ----------
pw16 192.168.1.6 16 p2p VLAN UP
So we see that PW16 is up and operational.
R1#show mpls l2transport vc
Local intf Local circuit Dest address VC ID Status
------------- -------------------------- --------------- ---------- ----------
Gi2 Eth VLAN 1013 192.168.1.6 16 UP
Pretty much the same output, slightly different though.
R1#show 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.6:16 UP ac Gi2:1013(Eth VLAN) UP
This output gives us a bit more info, like the PW and the AC info.
Let's take a deeper look at the detailed output of the atom vc output.
R1#show l2vpn atom vc pseudowire 16 detail
pseudowire16 is up, VC status is up PW type: Ethernet
Create time: 1d01h, last status change time: 00:09:09
Last label FSM state change time: 00:09:09
Destination address: 192.168.1.6 VC ID: 16
Output interface: Gi1.112, imposed label stack {24207 30}
Preferred path: not configured
Default path: active
Next hop: 10.1.12.12
Member of xconnect service VLAN
Associated member Gi2 is up, status is up
Interworking type is Ethernet
Service id: 0x31000001
Signaling protocol: LDP, peer 192.168.1.6:0 up
Targeted Hello: 192.168.1.1(LDP Id) -> 192.168.1.6, LDP is UP
Graceful restart: not configured and not enabled
Non stop routing: not configured and not enabled
PWid FEC (128), VC ID: 16
Status TLV support (local/remote) : enabled/supported
LDP route watch : enabled
Label/status state machine : established, LruRru
Local dataplane status received : No fault
BFD dataplane status received : Not sent
BFD peer monitor status received : No fault
Status received from access circuit : No fault
Status sent to access circuit : No fault
Status received from pseudowire i/f : No fault
Status sent to network peer : No fault
Status received from network peer : No fault
Adjacency status of remote peer : No fault
Sequencing: receive disabled, send disabled
Bindings
Parameter Local Remote
------------ ------------------------------ ------------------------------
Label 32 30
Group ID 0 0
Interface
MTU 1500 1500
Control word on (configured: autosense) on
PW type Ethernet Ethernet
VCCV CV type 0x02 0x02
LSPV [2] LSPV [2]
VCCV CC type 0x07 0x07
CW [1], RA [2], TTL [3] CW [1], RA [2], TTL [3]
Status TLV enabled supported
SSO Descriptor: 192.168.1.6/16, local label: 32
Dataplane:
SSM segment/switch IDs: 4121/4096 (used), PWID: 1
Rx Counters
9773 input transit packets, 960362 bytes
0 drops, 0 seq err
Tx Counters
9778 output transit packets, 1255320 bytes
0 drops
There are 2 different sets of labels to pay attention to here, the "{24207 30}" and the "32 30".
The first set, 24207 is the outgoing label on R1 to XR2 to get to R6; 30 is the label that R6 will use to get to R1 via the P2P connection.
R1#show mpls forwarding-table 192.168.1.6
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
22 24207 192.168.1.6/32 0 Gi1.112 10.1.12.12
R6#show mpls forwarding-table labels 30
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
30 No Label l2ckt(1) 9598 Gi2 point2point
The second set is specific to the PW labels. Where R1 will use label 32 to reach R6 and will use label 30 to reach R1.
R1#show mpls forwarding-table labels 32
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
32 No Label l2ckt(1) 12134 Gi2 point2point
R6#show mpls forwarding-table labels 30
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
30 No Label l2ckt(1) 9598 Gi2 point2point
R6#show mpls forwarding-table 192.168.1.1
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
40 26 192.168.1.1/32 0 Gi1.26 10.2.6.2
526 192.168.1.1/32 0 Gi1.56 10.5.6.5
Being able to map the label to the service is important, the service being the P2P PW between the PEs, in this case, R1 to R6 is label 32 and R6 to R1 is label 30. The other label values, used to label switch to the other PE, 24207 on R1 and 26 on R6.
Taking a look at the "targeted LDP" outputs.
R6#show mpls ldp discovery
Targeted Hellos:
192.168.1.6 -> 192.168.1.1 (ldp): active/passive, xmit/recv
LDP Id: 192.168.1.1:0
We an see we have a P2P non-directly connected session up, transmitting and receiving. The label space is platform wide the "0" behind the LDP Id: 192.168.1.1:0.
More specifically...
R6#show mpls ldp discovery detail
Targeted Hellos:
192.168.1.6 -> 192.168.1.1 (ldp): active/passive, xmit/recv
Enabled by: MPLS AToM Circuit,
Hello interval: 10000 ms; Transport IP addr: 192.168.1.6
LDP Id: 192.168.1.1:0
Src IP addr: 192.168.1.1; Transport IP addr: 192.168.1.1
Hold time: 90 sec; Proposed local/peer: 90/90 sec
Reachable via 192.168.1.1/32
Password: not required, none, in use
It tells us this is an MPLS AToM circuit and the specifics of the peering.
We can see that R1 has advertised a number of label values.
R6#show mpls ldp bindings neighbor 192.168.1.1 detail
Local label filtering spec: host routes
lib entry: 10.1.11.0/24, rev 57
lib entry: 10.1.12.0/24, rev 58
lib entry: 10.1.15.0/24, rev 59
Not really applicable here, but it's important to know that under the hood, LDP is still the active label distribution protocol here and needs to be verified.
Let's take a look at the CEs, just to make sure that the connectivity is up and operational.
R10#sh ip ospf int br | in Gi1.1013
Gi1.1013 1 0 172.10.13.10/24 1 BDR 1/1
R10#show ip ospf neighbor | in GigabitEthernet1.1013
13.13.13.13 1 FULL/DR 00:00:33 172.10.13.13 GigabitEthernet1.1013
Awesome, good sign!. We can see that R10 has a peering with R13 and all is well.
The QinQ Variant
Now we'll look at the QinQ variant. This is where we will have 2 Dot1Q tags, one for the Service provider, the other for the customer. We've covered QinQ in detail in earlier posts, so I won't go into those details now.
R1
interface GigabitEthernet2
service instance 61 ethernet
encapsulation dot1q 100 second-dot1q 200
!
interface pseudowire61
encapsulation mpls
neighbor 192.168.1.6 61
!
l2vpn xconnect context QinQ
member GigabitEthernet2 service-instance 61
member pseudowire61
R6
interface GigabitEthernet2
service instance 61 ethernet
encapsulation dot1q 100 second-dot1q 200
!
interface pseudowire61
encapsulation mpls
neighbor 192.168.1.1 61
!
l2vpn xconnect context QinQ
member GigabitEthernet2 service-instance 61
member pseudowire61
So basically all we are doing is adding an additional VLAN tag to the forwarding process. The outer tag, the service provider tag, is stripped off as it enters the SP core and is label switched through the core. The inner tag, the customer tag, is not stripped off by default and is added encapsulation through the core. There are ways to "rewrite" that information which we will be taking a look at later on.
Let's take a look at the verification for this now, very similar to the VLAN variant, the main difference is simply a new set of labels used to switch the PW data between PEs.
R1#show l2vpn atom vc pseudowire 61 detail
pseudowire61 is up, VC status is up PW type: Ethernet
Create time: 4d00h, last status change time: 3d23h
Last label FSM state change time: 3d23h
Destination address: 192.168.1.6 VC ID: 61
Output interface: Gi1.115, imposed label stack {24508 28}
Preferred path: not configured
Default path: active
Next hop: 10.1.15.15
Member of xconnect service QinQ
Associated member Gi2 is up, status is up
Interworking type is Ethernet
Service id: 0x22000002
Signaling protocol: LDP, peer 192.168.1.6:0 up
Targeted Hello: 192.168.1.1(LDP Id) -> 192.168.1.6, LDP is UP
Graceful restart: not configured and not enabled
Non stop routing: not configured and not enabled
PWid FEC (128), VC ID: 61
Status TLV support (local/remote) : enabled/supported
LDP route watch : enabled
Label/status state machine : established, LruRru
Local dataplane status received : No fault
BFD dataplane status received : Not sent
BFD peer monitor status received : No fault
Status received from access circuit : No fault
Status sent to access circuit : No fault
Status received from pseudowire i/f : No fault
Status sent to network peer : No fault
Status received from network peer : No fault
Adjacency status of remote peer : No fault
Sequencing: receive disabled, send disabled
Bindings
Parameter Local Remote
------------ ------------------------------ ------------------------------
Label 39 28
Group ID 0 0
Interface
MTU 1500 1500
Control word on (configured: autosense) on
PW type Ethernet Ethernet
VCCV CV type 0x02 0x02
LSPV [2] LSPV [2]
VCCV CC type 0x07 0x07
CW [1], RA [2], TTL [3] CW [1], RA [2], TTL [3]
Status TLV enabled supported
SSO Descriptor: 192.168.1.6/61, local label: 39
Dataplane:
SSM segment/switch IDs: 20496/8198 (used), PWID: 2
Rx Counters
36973 input transit packets, 3781234 bytes
0 drops, 0 seq err
Tx Counters
36987 output transit packets, 4897012 bytes
0 drops
The 24508 label is used to reach R6's loopback. Label 28 is the label that R6 allocated to forward data over the PW.
R1#sh mpls forwarding-table labels 22
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
22 24207 192.168.1.6/32 0 Gi1.112 10.1.12.12
24508 192.168.1.6/32 0 Gi1.115 10.1.15.15
R6#show mpls forwarding-table labels 28
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
28 No Label l2ckt(2) 3783524 Gi2 point2point
Let's verify that R10 has an active OSPFv2 adjacency.
interface GigabitEthernet1.1310
encapsulation dot1Q 100 second-dot1q 200
ip address 192.168.10.10 255.255.255.0
end
R10#sh ip ospf int br | in Gi1.1310
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Gi1.1310 1 0 192.168.10.10/24 1 DR 1/1
R10#sh ip route 13.14.0.0
Routing entry for 13.14.0.0/24
Known via "ospf 1", distance 110, metric 2, type intra area
Last update from 192.168.10.13 on GigabitEthernet1.1310, 3d08h ago
Routing Descriptor Blocks:
* 192.168.10.13, from 13.13.13.13, 4d00h ago, via GigabitEthernet1.1310
Route metric is 2, traffic share count is 1
All is well. So we know that the configuration up to this point is operational.
No comments:
Post a Comment