Hello my friend,

I’m starting the next interesting part of my journey in land of Nokia (Alcatel-Lucent) and Cisco IOS XR. In this and a couple of next series we’ll talk about MPLS L2 VPN services. The easiest one is VPWS (Virtual Pseudo Wire Service) and we’ll review two its types: LDP-based and BGP-based.

Disclaimer

As usually I hope that you know basic of VPWS. If not, refer to some learning materials and/or courses. The good examples are “Nokia Service Architecture SRC course” and book “MPLS in the SDN Era”.

Brief overview

VPWS has a lot of other names. In Nokia (Alcatel-Lucent) SR OS it’s called “x”pipe, where “x” represent type of traffic being transported, like epipe – Ethernet VPWS, cpipe – CESoPSN VPWS and etc. Cisco world has another marvelous name AToM, what stands for Any Transport over MPLS. There are also a lot of other abbreviations like PW (PseudoWire), PWE3 (PseudoWire End-to-End Emulation), E-line (MEF description), VLL (virtual Leased Line) and so on.

Regardless of the term used, in nutshell VPWS is just encapsulation of L2 PDU (protocol data unit, i.E. frame for Ethernet) coming from one device into MPLS labeled frame, transfer this MPLS frame over MPLS cloud and decapsulation from MPLS back to original L2PDU at another side of MPLS cloud. Usually the original structure of L2 PDU including L2 header is preserved, so two hosts on different sides of the VPWS will have L2 adjacency with each other. “Usually” means that in certain cases there might be no L2 adjacency, if we implement interworking, what means connection of two different media types (Ethernet and TDM, for example) on two ends of the same pseudowire.

What are we going to test?

As I’ve mentioned in the very beginning there are two type of signaling for VPWS. The first one is LDP-based and described in RFC4447. This type is called “Martini” VPWS by the name of one of the authors, whose name is Luca Martini. The second type of VPWS is BGP-based and described in RFC6624. The type is called “Kompella” VPWS by the name of the author, whose name Kireeti Kompella. I provide these names, because quite often you can see in the different forums or articles referring to “Martini” or “Kompella” L2 VPN.

Topology

In the recent article (link) I was considering of changing the physical topology. The reason for that was my ongoing test of openvswitch (link), which I have installed instead of ordinary linux bridge. Unfortunately there are some problems with its operation, which lead to sporadic packet drop. This problem isn’t visible, when I test lab infrastructure with ping, but ISIS adjacency flaps each 2-5 minutes. That’s why I decided to use further topology that I’ve used before:

030_net_02_phy

You can point out that devices’ names are a little bit different at the picture above. Besides hostnames I’ve changed IP addressing scheme as well. In my opinion, these changes makes configuration and its tracking easier. The resulting logical topology is the following:

050_net_02_logical

Let’s briefly discussed devices role and what is configured. Routers SR1 and XR3 are PE (provider edge) routers, and SR2 is P (provider core) router. It means that all kind of services (i.e. L2/L3 MPLS VPNs) we’ll configure between SR1 and XR3. As routing protocol (IGP) we’ll use ISIS in this lab. MPLS forwarding plane will be formed by RSVP-TE, so all interfaces between our routers are enabled in MPLS (in Cisco IOS XR MPLS TRAFFIC-ENG) and RSVP contexts. In the same time MPLS LSPs aren’t configured, so it will be part of our configuration. Initial configuration for the lab is in the following files:

Brief overview of MPLS service framework

Configuration of different MPLS-related (and not only) services in Nokia (Alcatel-Lucent) SR OS looks unusual for everyone, who comes from Cisco IOS world. But for those, who have experience with Cisco IOS XR, the difference isn’t so huge, but it still exists.

The common thing for Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR is that configuration is done in specific configuration context. In classical Cisco IOS/ IOS XR the configuration of VPNs is done partially at interface level (sometimes the main part of the config is done at the interface). So Cisco IOS XR is different from Cisco IOS in this question. Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR is very similar in this question.

The main difference between Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR is mapping of the service to transport tunnel (we can also call this process as next-hop lookup).

In Nokia (Alcatel-Lucent) SR OS you have a concept of SDP (Service Distribution Point). SDP is configuration entity that has information about MPLS transport to be used (LDP, SPRING, BGP, RSVP) and signaling (targeted LDP or BGP). After SDP is configured you map different services (VPWSs or VPLSs) to SDP. Another configuration entity is “Customer”. Each service is mapped to a certain (and only one) customer in the time of creation. Each customer can have multiple services mapped to it. So “Customer” is used for administrative and monitoring purposes rather than for technical tasks.

In Cisco IOS XR you have concept of groups (xconnect or bridge), which might be considered as analog of Nokia’s “Customer”. All the configuration regarding service signaling is done into configuration context of each certain service. And mapping of the service to MPLS forwarding plane is done automatically via next-hop lookup process that is common not only for MPLS services but for usual routing as well.

This difference is really crucial to understand. For Cisco IOS XR approach seems to be more logical, as we have common rules for all traffic (or may be it seems to be more logical because I have more experience with Cisco). On the other hand in Nokia (Alcatel-Lucent) SR OS it’s easier to map certain traffic to certain path, what is important for differentiating customers according to SLA (gold, silver, bronze) or just different type of traffic to different paths.

Good explanation of Nokia (Alcatel-Lucent) MPLS service framework is provided in “Nokia Service Architecture SRC course”.

I guess it might be hard to understand words without images above, so let’s go to configuration phase and there you’ll understand it better, I hope.

LDP-based VPWS (Martini)

Historically Martini VPWS was developed earlier than Kompella VPWS, so I’ll review it first. Here is the sample service that we want to deploy:

050_net_03_vpws_ldp

In general we have to pass the following steps (both in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR) to get LDP-based VPWS running:

  • establish MPLS LSP (in case of RSVP-TE we need configure MPLS tunnel);
  • configure customer interfaces in appropriate way;
  • configure VPWS including creation of signaling session (t-LDP) and align its parameters.

Keep in mind that following parameters must match at both Pes in order VPWS to get up: VC-ID, VC-Type, MTU

Here is configuration to get our service working:

Nokia (Alcatel-Lucent) VSR (SR 7750) Cisco IOS XR (ASR 9000)
SR1 XR1

A:SR1>edit-cfg# candidate view
—————————
configure
port “1/1/2”
ethernet
mode access
encap-type dot1q
exit
no shutdown
exit
router
mpls
path “loose”
no shutdown
exit
lsp “SR1_to_XR3”
to 10.255.255.33
cspf
least-fill
primary “loose”
bandwidth 33
exit
no shutdown
exit
exit
ldp
no shutdown
exit
exit
service
customer 2 create
description “CUSTOMER_A”
exit
sdp 1 mpls create
far-end “10.255.255.33”
lsp “SR1_to_XR3”
path-mtu 1514
no shutdown
exit
epipe “1” customer 2 create
sap “1/1/2:222” create
exit
spoke-sdp “1:1133” vc-type vlan create
exit
no shutdown
exit
exit
exit
—————————

RP/0/0/CPU0:XR3(config)#show conf
interface tunnel-te53311
ipv4 unnumbered loopback 0
signalled-name XR3_to_SR1
signalled-bandwidth 330000
autoroute destination 10.255.255.11
destination 10.255.255.11
record-route
path-option 10 dynamic
!
interface GigabitEthernet0/0/0/0.222 l2transport
dot1q vlan 222
!
l2vpn
logging
pseudowire
!
pw-class VPWS_CW
encapsulation mpls
control-word
!
!
xconnect group CUSTOMER_A
p2p VPWS-LDP
interface GigabitEthernet0/0/0/0.222
neighbor ipv4 10.255.255.11 pw-id 1133
pw-class VPWS_CW
!
!
!
!
end

I suppose you have question “what we are doing here”, right? Well, the question is fully correct, so let’s discuss, what we are doing here.

In Nokia (Alcatel-Lucent) VSR (SR 7750) we have to configure customer-facing port as “access”. It’s necessary, otherwise you won’t be able to map it to any service. Also point it that we map it to service, we call it SAP “Service Attachment Point”, but technically it’s just the same port. Then we configure MPLS LSP to Cisco IOS XR router XR3 using RSVP-TE.

For more information about configuration of MPLS / RSVP-TE LSP refer to corresponding article.

Pay attention that we enable LDP, but we don’t make any configurations there. T-LDP sessions is established automatically to IPv4 address configured in SDP as “far-end”, when SDP is associated to at least one service and this service is activated. You don’t see any remarks that SDP uses targeted LDP, because it’s default configuration. Further in BGP-based VPWS we’ll change it. Also we map SDP to certain MPLS LSP. Each configuration entity (CUSTOMER, SDP, EPIPE) has a number, which is an arbitrary value. Using SDP number, you map epipe (what is actually VPWS service) to certain MPLS LSP to certain PE. Combination sdp “1:1133” is very important, because it means that you establish T-LDP session to far-end of SDP 1 with VC-ID (or PW-ID) 1133. You can reuse the same SDP for other services with other VC-IDs. Also it’s necessary to configure VC-TYPE as Vlan, otherwise you won’t interoperate with Cisco IOS XR, where Vlan is the only VC-TYPE for VPWS if attached interface is tagged. Though it isn’t necessary, we enable control-word for this VPWS, as it eliminates possibility of out-of-order packets in cases of load balancing (ECMP) in the network.

In Cisco IOS XR there is no specific type of port for different customer services. The only keyword is “l2stranport” upon sub interface creation, what means that switching engine is used. You configure “l2transport” at sub interface in Cisco IOS XR, when you configure VPWS, VPLS, EVPN or just local BVI (bridge virtual interface). Then we configure pseudowire-class (in BGP-based VPWS we’ll configure it in Nokia (Alcatel-Lucent) SR OS as well), where we define usage of control-word. “Xconnect” group is used for configuration of VPWS and certain “p2p” entry is a VPWS itself (epipe in Nokia (Alcatel-Lucent) SR OS). Again, the most important is VC-ID match between SR1 and XR3. Here we map VC-ID directly to neighbor IPv5 address of the neighbor, what creates targeted-LDP session to SR1. We don’t configure VC-TYPE, as it’s already Vlan and is only possible in this case. Pw-class is added to neighbor configuration to be used on VPWS.

Configuration of path-mtu is workaround. It’s configured automatically, but here I change manually just to bring VPWS working. Different MTUs and their interdependency is good explained in “Nokia Service Architecture SRC course”.

Now, after explanation above I assume that you feel yourself more confident with configuration of LDP-based (Martini) VPWS in mixed environment with Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR. Let’s review the output of the most important show commands. The next two are from Nokia (Alcatel-Lucent) VSR (SR7750):

A:SR1# show service service-using
============================================================================
Services
============================================================================
ServiceId Type Adm Opr CustomerId Service Name
—————————————————————————-
1 Epipe Up Up 2
2147483648 IES Up Down 1 _tmnx_InternalIesService
2147483649 intVpls Up Down 1 _tmnx_InternalVplsService
—————————————————————————-
Matching Services : 3
—————————————————————————-
============================================================================
!
!
A:SR1# show service id 1 base
============================================================================
Service Basic Information
============================================================================
Service Id : 1 Vpn Id : 0
Service Type : Epipe
Name : (Not Specified)
Description : (Not Specified)
Customer Id : 2 Creation Origin : manual
Last Status Change: 10/20/2016 07:59:37
Last Mgmt Change : 10/20/2016 07:56:01
Test Service : No
Admin State : Up Oper State : Up
MTU : 1514
Vc Switching : False
SAP Count : 1 SDP Bind Count : 1
Per Svc Hashing : Disabled
Force QTag Fwd : Disabled
—————————————————————————-
Service Access & Destination Points
—————————————————————————-
Identifier Type AdmMTU OprMTU Adm Opr
—————————————————————————-
sap:1/1/2:222 q-tag 1518 1518 Up Up
sdp:1:1133 S(10.255.255.33) Spok 1518 1518 Up Up
============================================================================

The first command show all configured services and their numbers, whereas the second one displays the basic information about service (including service-MTU) and operational status of the service and its components. Very often you will want to check the detail information about service components, especially if they are operational down to find error description. More often you have problems with LDP-related part of VPWS that is SDP, so here you can see details of SDP in context of this service:

A:SR1# show service id 1 sdp 1:1133 detail
============================================================================
Service Destination Point (Sdp Id : 1:1133) Details
============================================================================
—————————————————————————-
Sdp Id 1:1133 -(10.255.255.33)
—————————————————————————-
Description : (Not Specified)
SDP Id : 1:1133 Type : Spoke
Spoke Descr : (Not Specified)
VC Type : VLAN VC Tag : 0
Admin Path MTU : 1518 Oper Path MTU : 1518
Delivery : MPLS
Far End : 10.255.255.33
Tunnel Far End : n/a LSP Types : RSVP
—-
Admin State : Up Oper State : Up
MinReqd SdpOperMTU : 1518
Acct. Pol : None Collect Stats : Disabled
Ingress Label : 262141 Egress Label : 24002
Admin ControlWord : Preferred Oper ControlWord : True
Admin BW(Kbps) : 0 Oper BW(Kbps) : 0
BFD Template : None
BFD-Enabled : no BFD-Encap : ipv4
Last Status Change : 10/20/2016 07:59:37 Signaling : TLDP
Last Mgmt Change : 10/20/2016 07:56:01
Endpoint : N/A Precedence : 4
PW Status Sig : Enabled
Peer Fault Ip : None
Peer Vccv CV Bits : lspPing
Peer Vccv CC Bits : pwe3ControlWord mplsRouterAlertLabel
mplsPwDemultiplexorLabel
—————————————————————————-
RSVP/Static LSPs
—————————————————————————-
Associated LSP List :
Lsp Name : SR1_to_XR3
Admin State : Up Oper State : Up
Time Since Last Tr*: 00h05m03s
—————————————————————————-
============================================================================

The output above is significantly reduced, and I’ve left only relevant information to our case. As we use targeted LDP (T-LDP) for session signaling, we can check the parameters of this service in LDP:

A:SR1# show router ldp bindings services
============================================================================
LDP Bindings (IPv4 LSR ID 10.255.255.11)
(IPv6 LSR ID ::)
============================================================================
Legend: U – Label In Use, N – Label Not In Use, W – Label Withdrawn
S – Status Signaled Up, D – Status Signaled Down
E – Epipe Service, V – VPLS Service, M – Mirror Service
A – Apipe Service, F – Fpipe Service, I – IES Service, R – VPRN service
P – Ipipe Service, WP – Label Withdraw Pending, C – Cpipe Service
BU – Alternate For Fast Re-Route, TLV – (Type, Length: Value)
LF – Lower FEC, UF – Upper FEC, e – Label ELC
============================================================================
LDP Service FEC 128 Bindings
============================================================================
Type VCId SDPId IngLbl LMTU
Peer SvcId EgrLbl RMTU
—————————————————————————-
E-Vlan 1133 1 262141U 1500
10.255.255.33:0 1 24002S 1500
—————————————————————————-
!
!
A:SR1# show router ldp bindings services service-id 1 detail
============================================================================
LDP Bindings (IPv4 LSR ID 10.255.255.11)
(IPv6 LSR ID ::)
============================================================================
Legend: (see above)
============================================================================
LDP Service FEC 128 Bindings
============================================================================
Type : E-Vlan VcId : 1133
SvcId : 1 SdpId : 1
Peer Address : 10.255.255.33:0
Vc-switching : No
LMTU : 1500 RMTU : 1500
Egr. Lbl : 24002S Egr. Ctl Word : Yes
Egr. Flags : None Egr. Status Bits : Supported (0x0)
Egr. Flow Label Tx : No Egr. Flow Label Rx : No
Egr. PW Status Sig : Enabled
Egr. Vccv CV Bits : lsp-ping
Egr. Vccv CC Bits : pwe3-control-word router-alert-label mpls-demux-label-tl1
Ing. Lbl : 262141U Ing. Ctl Word : Yes
Ing. Flags : None Ing. Status Bits : Supported (0x0)
Ing. Flow Label Tx : No Ing. Flow Label Rx : No
Ing. Wdraw Reason : N/A
Ing. PW Status Sig : Enabled
Ing. Vccv CV Bits : lsp-ping bfd-fault-detect
Ing. Vccv CC Bits : pwe3-control-word router-alert-label
—————————————————————————-
============================================================================
No. of VC Labels: 1
============================================================================

You can see that Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR has different set of attributes activated by default. Nevertheless it doesn’t impact operation. The most important is to align VC-ID, VC-TYPE and Service-MTU. Also if you configure control world (as we do in this example), it also must be align, so it must be configured at both sides of VPWS.

What about Cisco IOS XR? It also has a number of useful commands that shows, what is going on with your L2 VPN:

RP/0/0/CPU0:XR3#show l2vpn xconnect
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
———————— —————————– —————————–
CUSTOMER_A VPWS-LDP UP Gi0/0/0/0.222 UP 10.255.255.11 1133 UP
—————————————————————————————-
!
!
RP/0/0/CPU0:XR3#show l2vpn xconnect group CUSTOMER_A detail
Group CUSTOMER_A, XC VPWS-LDP, state is up; Interworking none
AC: GigabitEthernet0/0/0/0.222, state is up
Type VLAN; Num Ranges: 1
VLAN ranges: [222, 222]
MTU 1500; XC ID 0x1; interworking none
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
drops: illegal VLAN 0, illegal length 0
PW: neighbor 10.255.255.11, PW ID 1133, state is up ( established )
PW class VPWS_CW, XC ID 0xff000001
Encapsulation MPLS, protocol LDP
Source address 10.255.255.33
PW type Ethernet VLAN, control word enabled, interworking none
PW backup disable delay 0 sec
Sequencing not set
PW Status TLV in use
MPLS Local Remote
———— —————————– —————————
Label 24002 262141
Group ID 0x100 unknown
Interface GigabitEthernet0/0/0/0.222 unknown
MTU 1500 1500
Control word enabled enabled
PW type Ethernet VLAN Ethernet VLAN
VCCV CV type 0x2 0x6
(LSP ping verification) (LSP ping verification)
(BFD PW FD only)
VCCV CC type 0x7 0x3
(control word) (control word)
(router alert label) (router alert label)
(TTL expiry)
———— —————————– —————————-
Incoming Status (PW Status TLV):
Status code: 0x0 (Up) in Notification message
Outgoing Status (PW Status TLV):
Status code: 0x0 (Up) in Notification message
MIB cpwVcIndex: 4278190081
Create time: 18/10/2016 00:42:33 (01:55:39 ago)
Last time status changed: 18/10/2016 02:05:38 (00:32:33 ago)
Last time PW went down: 18/10/2016 02:05:12 (00:32:59 ago)

The output above is similar to “show router ldp binding” in Nokia (Alcatel-Lucent) SR OS. There is no SDP in Cisco IOS XR, so as I’ve said the mapping of VPWS to the MPLS LSP is done via next-hop lookup. The next-hop for this service is IPv4 address 10.255.255.11 (SR1), so in the routing table we check that this addess is available through MPLS tunnel built with RSVP-TE:

RP/0/0/CPU0:XR3#show route ipv4 10.255.255.11/32
Routing entry for 10.255.255.11/32
Known via “application”, distance 2, metric 0 (connected)
Installed Oct 18 02:05:29.366 for 00:35:18
Routing Descriptor Blocks
directly connected, via tunnel-te53311
Route metric is 0
No advertising protos.
!
!
RP/0/0/CPU0:XR3#show mpls traffic-eng tunnels 53311 brief
TUNNEL NAME DESTINATION STATUS STATE
tunnel-te53311 10.255.255.11 up up

The latter command shows the LFIB of XR1, where you can see labels for VPWS service as well.

Cisco IOS XRv doesn’t support forwarding plane for L2VPN, so we can’t make any kind of ping. But positive output of show commands is OK to check service operation.

BGP-based VPWS (Kompella)

The second type of VPWS that you may configure is BGP-based VPWS. Personally I like this type of VPWS more, because you can fully avoid usage of LDP in your network. I don’t say that LDP is bad, LDP is good. But if you can reduce the number of signaling protocols used in the network, it’s worth it. Remember the networking mantra:

050_net_04_vpws_bgp

The good network design isn’t the one, to which you can’t add something. The good network design is the one, from which you can’t remove anything.

To get BGP-based VPWS working we need to perform the following activities (both in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR) to get LDP-based VPWS running:

  • establish MPLS LSP (in case of RSVP-TE we need configure MPLS tunnel);
  • configure customer interfaces in appropriate way;
  • configure BGP session for address-family l2vpn vpls-vpws (AFI/SAFI 25/65);
  • configure BGP auto discovery parameters at PEs (important: route-targets must match at both ends);
  • configure BGP signaling;

So you can see that we have a little bit more steps than in LDP-based VPWS. Also I want you to pay attention to the first step. In the beginning of the article I was talking that in Nokia (Alcatel-Lucent) SR OS we used SDPs for service mapping to MPLS LSP and for signaling. So we need to create new SDP that use BGP as signaling protocol:

In the same time Cisco IOS XR maps traffic to tunnel using next-hop lookup in routing table, so we don’t need to create any new tunnel, if SR1 announces prefixes with BGP NH attribute set to its system interface IPv4 address (10.255.255.11). So to build BGP-based VPWS (Kompella) we implement the following configuration to SR1 and XR3:

Nokia (Alcatel-Lucent) VSR (SR 7750) Cisco IOS XR (ASR 9000)
SR1 XR1

A:SR1>edit-cfg# candidate view
—————————
configure
router
autonomous-system 65000
bgp
group “iBGP”
family l2-vpn
local-address “10.255.255.11”
peer-as 65000
neighbor “10.255.255.33”
exit
exit
no shutdown
exit
exit
service
sdp-group
group-name “SDP_FOR_BGP_AD” value 0
exit
sdp 11 mpls create
far-end “10.255.255.33”
lsp “SR1_to_XR3”
signaling bgp
path-mtu 1518
sdp-group “SDP_FOR_BGP_AD”
no shutdown
exit
pw-template 1 prefer-provisioned-sdp create
controlword
vc-type vlan
sdp-include “SDP_FOR_BGP_AD”
exit
epipe “2” customer 2 create
service-mtu 1500
bgp
route-distinguisher “10.255.255.11:1”
route-target “target:65000:1”
pw-template-binding 1
exit
exit
bgp-vpws
ve-name “SR1”
ve-id 11
exit
remote-ve-name “XR3”
ve-id 33
exit
exit
sap “1/1/2:333” create
exit
no shutdown
exit
exit
exit
—————————

RP/0/0/CPU0:XR3(config)#show conf
interface GigabitEthernet0/0/0/0.333 l2transport
encapsulation dot1a 333
rewrite ingress tag pop 1 symmetric
!
router bgp 65000
bgp router-id 10.255.255.33
bgp log neighbor changes detail
address-family l2vpn vpls-vpws
!
neighbor 10.255.255.11
remote-as 65000
update-source Loopback0
address-family l2vpn vpls-vpws
!
!
!
l2vpn
xconnect group CUSTOMER_A
mp2mp VPWS-BGP
vpn-id 3311
l2-encapsulation vlan
autodiscovery bgp
rd 10.255.255.33:1
route-target 65000:1
signaling-protocol bgp
ce-id 33
interface GigabitEthernet0/0/0/0.333 remote-ce-id 11
!
!
!
!
!
!
end

In Nokia (Alcatel-Lucent) SR OS we configure BGP in corresponding address-family first of all. Then we create new SDP, but pay attentions that MPLS LSP is the same, so we don’t create it again. In order to map BGP-based VPWS to a certain LSP, we create pw-template with “prefer-provisioned-sdp” option, which has configured the same “sdp-group” as SDP itself. Also in pw-template we configure VC-TYPE and other parameters. In the EPIPE context the most important is BGP auto-discovery and BGP-VPWS section. As I’ve said, route-target must be the same at both ends of VPWS, whereas VE-IDs must be mirrored.

In Cisco IOS XR there are two major differences (besides BGP and BGP-related parameters). First of all, the interface is configured in another way. Actually it’s correct way how to configure it and in LDP-based VPWS it also should be configured so, but due to Cisco IOS XRv limitations I’ve configured it in another way. The second difference is that he were configure “mp2mp” service, not “p2p”. VPN-ID is an arbitrary value in this case, because you see, it isn’t configured in Nokia (Alcatel-Lucent) SR OS. It plays crucial role in BGP-based VPLS, but here it isn’t relevant, though it must be configured in Cisco IOS XR.

Also pay attention that here we change service-MTU in Nokia (Aclatel-Lucent) SR OS. Cisco IOS XR treats MTU in LDP-based and BGP-based VPWS in different way.

“Show” must go on! Let’s check the output of the most useful show commands from Nokia (Alcatel-Lucent) SR OS, which are related to our BGP-based VPWS (Kompella):

A:SR1# show service id 2 base
============================================================================
Service Basic Information
============================================================================
Service Id : 2 Vpn Id : 0
Service Type : Epipe
Name : (Not Specified)
Description : (Not Specified)
Customer Id : 2 Creation Origin : manual
Last Status Change: 10/20/2016 10:27:52
Last Mgmt Change : 10/20/2016 10:27:52
Test Service : No
Admin State : Up Oper State : Up
MTU : 1500
Vc Switching : False
SAP Count : 1 SDP Bind Count : 1
Per Svc Hashing : Disabled
Force QTag Fwd : Disabled
—————————————————————————-
Service Access & Destination Points
—————————————————————————-
Identifier Type AdmMTU OprMTU Adm Opr
—————————————————————————-
sap:1/1/2:333 q-tag 1518 1518 Up Up
sdp:11:4294967294 S(10.255.255.33) BgpVpws 1518 1518 Up Up
=============================================================================

You see that SDP type is “BgpVpws” and VC-ID is automatically generated number, whereas SDP number is “11”, what corresponds to the manually configured one. Now, SDP details:

A:SR1# show service id 2 sdp detail
============================================================================
Services: Service Destination Points Details
============================================================================
—————————————————————————-
Sdp Id 11:4294967294 -(10.255.255.33)
—————————————————————————-
Description : (Not Specified)
SDP Id : 11:4294967294 Type : BgpVpws
PW-Template Id : 1
VC Type : VLAN VC Tag : 0
Admin Path MTU : 1518 Oper Path MTU : 1518
Delivery : MPLS
Far End : 10.255.255.33
Tunnel Far End : n/a LSP Types : RSVP
Hash Label : Disabled Hash Lbl Sig Cap : Disabled
Oper Hash Label : Disabled
Entropy Label : Disabled
—-
Admin State : Up Oper State : Up
MinReqd SdpOperMTU : 1504
Acct. Pol : None Collect Stats : Disabled
Ingress Label : 262142 Egress Label : 24016
Ingr Mac Fltr-Id : n/a Egr Mac Fltr-Id : n/a
Ingr IP Fltr-Id : n/a Egr IP Fltr-Id : n/a
Ingr IPv6 Fltr-Id : n/a Egr IPv6 Fltr-Id : n/a
Admin ControlWord : Preferred Oper ControlWord : True
Admin BW(Kbps) : 0 Oper BW(Kbps) : 0
BFD Template : None
BFD-Enabled : no BFD-Encap : ipv4
Last Status Change : 10/20/2016 10:27:52 Signaling : BGP
Last Mgmt Change : 10/20/2016 10:27:52
Endpoint : _tmnx_BgpVpws-2 Precedence : 4
PW Status Sig : Enabled
Force Vlan-Vc : Disabled Force Qinq-Vc : Disabled
Class Fwding State : Down
Flags : None
Local Pw Bits : None
Peer Pw Bits : None
Peer Fault Ip : None
Peer Vccv CV Bits : None
Peer Vccv CC Bits : None
—————————————————————————-
RSVP/Static LSPs
—————————————————————————-
Associated LSP List :
Lsp Name : SR1_to_XR3
Admin State : Up Oper State : Up
Time Since Last Tr*: 02h40m09s
—————————————————————————-
============================================================================

Also BGP information is very useful for troubleshooting:

A:SR1# show service id 2 bgp
============================================================================
BGP Information
============================================================================
Route Dist : 10.255.255.11:1
Oper Route Dist : 10.255.255.11:1
Oper RD Type : configured
Rte-Target Import : 65000:1 Rte-Target Export: 65000:1
Oper RT Imp Origin : configured Oper RT Import : 65000:1
Oper RT Exp Origin : configured Oper RT Export : 65000:1
PW-Template Id : 1
BFD Template : None
BFD-Enabled : no BFD-Encap : ipv4
Import Rte-Tgt : None
—————————————————————————-
============================================================================
!
!
A:SR1# show service id 2 bgp-vpws
============================================================================
BGP VPWS Information
============================================================================
Admin State : Enabled
VE Name : SR1 VE Id : 11
PW Tmpl used : 1
Remote-Ve Information
—————————————————————————-
Remote VE Name : XR3 Remote VE Id : 33
============================================================================

I’m sure, you remember that besides VC-TYPE and VC-ID (in BGP case VE-IDs must match) also Service-MTU mast match. In Martini VPWS we’ve checked LDP to see MTU. Here we have to check announced BGP routes:

A:SR1# show router bgp routes l2-vpn detail
============================================================================
BGP Router ID:10.255.255.11 AS:65000 Local AS:65000
============================================================================
Legend –
Status codes : u – used, s – suppressed, h – history, d – decayed, * – valid
l – leaked, x – stale, > – best, b – backup, p – purge
Origin codes : i – IGP, e – EGP, ? – incomplete
============================================================================
BGP L2VPN Routes
============================================================================
Original Attributes
Route Type : VPWS
Route Dist. : 10.255.255.33:1
VeId : 33 Block Size : 10
Base Offset : 10 Label Base : 24015
CSV : 0000FFBF
Nexthop : 10.255.255.33
From : 10.255.255.33
Res. Nexthop : n/a
Local Pref. : 100 Interface Name : NotAvailable
Aggregator AS : None Aggregator : None
Atomic Aggr. : Not Atomic MED : None
AIGP Metric : None
Connector : None
Community : l2-vpn/vrf-imp:Encap=4: Flags=-C: MTU=1500: PREF=0
target:65000:1
Cluster : No Cluster Members
Originator Id : None Peer Router Id : 10.255.255.33
Flags : Used Valid Best IGP
Route Source : Internal
AS-Path : No As-Path
Route Tag : 0
Neighbor-AS : N/A
Orig Validation: N/A
Source Class : 0 Dest Class : 0
Add Paths Send : Default
Last Modified : 00h24m34s

Now it’s Cisco IOS XR turn to show, how BGP-based VPWS works from its point of view:

RP/0/0/CPU0:XR3#show l2vpn discovery
Service Type: VPWS, Connected
List of VPNs (1 VPNs):
XC Group: CUSTOMER_A, MP2MP VPWS-BGP, id: 0, signaling protocol: BGP
List of Local Edges (1 Edges):
Local Edge ID: 33, Label Blocks (1 Blocks)
Label base Offset Size Time Created
———- —— —- ——————-
24015 10 10 10/18/2016 04:33:53
Status Vector: bf ff
List of Remote Edges (1 Edges):
Remote Edge ID: 11, NLRIs (1 NLRIs)
Label base Offset Size Peer ID Time Created
———- —— —- ————— ——————-
262142 33 1 10.255.255.11 10/18/2016 04:33:53
Status Vector: 80
!
!
Group CUSTOMER_A, XC VPWS-BGP.33:11, state is up; Interworking none
Local CE ID: 33, Remote CE ID: 11, Discovery State: Advertised
AC: GigabitEthernet0/0/0/0.333, state is up
Type VLAN; Num Ranges: 1
VLAN ranges: [333, 333]
MTU 1500; XC ID 0x2; interworking none
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
drops: illegal VLAN 0, illegal length 0
PW: neighbor 10.255.255.11, PW ID 2162699, state is up ( established )
PW class not set, XC ID 0xff000002
Encapsulation MPLS, Auto-discovered (BGP), protocol BGP
Source address 10.255.255.33
PW type Ethernet VLAN, control word enabled, interworking none
PW backup disable delay 0 sec
Sequencing not set
MPLS Local Remote
———— —————————– —————————-
Label 24016 262142
MTU 1500 1500
Control word enabled enabled
PW type Ethernet VLAN Ethernet VLAN
CE-ID 33 11
———— —————————– —————————-
MIB cpwVcIndex: 4278190082
Create time: 18/10/2016 04:33:53 (01:02:30 ago)
Last time status changed: 18/10/2016 04:34:16 (01:02:07 ago)
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0

You may see that PW-IDs (or VC-IDs) have different value at SR1 and XR3, though they work well. All BGP information you can check in BGP RIB:

RP/0/0/CPU0:XR3#show bgp l2vpn vpws mp2mp CUSTOMER_A:VPWS-BGP
Address Family: L2VPN VPWS
————————–
BGP router identifier 10.255.255.33, local AS number 65000
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 28
BGP NSR Initial initsync version 2 (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 Rcvd Label Local Label
Route Distinguisher: 10.255.255.33:1 (default for vrf CUSTOMER_A:VPWS-BGP)
*>i11:33/32 10.255.255.11 262142 nolabel
*> 33:10/32 0.0.0.0 nolabel 24015
Processed 2 prefixes, 2 paths

MTU is announced in the extended community field, so you need to check detail information of interesting routes to figure it out:

RP/0/0/CPU0:XR3#show bgp l2vpn vpws mp2mp CUSTOMER_A:VPWS-BGP 11:33/32 | inc Ext
Extended community: L2VPN:4:2:1500 RT:65000:1
!
!
RP/0/0/CPU0:XR3#show bgp l2vpn vpws mp2mp CUSTOMER_A:VPWS-BGP 33:10/32 | inc Ext
Extended community: L2VPN:4:2:1500 RT:65000:1

As I’ve already said in the end of LDP-based VPWS part, Cisco IOS XR has limitations regarding L2VPN data plane. That’s why we can only check control plane (if signaling works correct), but we can’t make any pings, traceroute and so on.

The final configs are here:

Lessons learned

If you have carefully compared the outputs of MTU in different commands, you can spot inconsistency of MTU value. Take a look first of all at Nokia (Alcatel-Lucent) SR OS side:

A:SR1# show service id 1 base | match MTU
MTU : 1514
!
!
A:SR1# show service id 2 base | match MTU
MTU : 1500

Service-MTU in VSR (SR 7750) stands for actual maximum size of L2 packet (including L2 header). You remember, we have configured service-mtu at SR1 in the BGP-based VPWS, and left the default value in LDP-based one. Now it’s time of Cisco IOS XR:

RP/0/0/CPU0:XR3#show l2vpn xconnect detail | inc “Group|MPLS|MTU”
Group CUSTOMER_A, XC VPWS-LDP, state is up; Interworking none
MTU 1500; XC ID 0x1; interworking none
Encapsulation MPLS, protocol LDP
MPLS Local Remote
Group ID 0x100 unknown
MTU 1500 1500
Group CUSTOMER_A, XC VPWS-BGP.33:11, state is up; Interworking none
MTU 1500; XC ID 0x2; interworking none
Encapsulation MPLS, Auto-discovered (BGP), protocol BGP
MPLS Local Remote
MTU 1500 1500

You see that values are the same. Probably this is bug of Cisco IOS XR (or XRv deployment)/ But in the LDP-based VPWS only IP MTU is calculated (1500 bytes = 1514 bytes (Ethernet frame) – 14 bytes (Ethernet header), whereas in BGP-based VPWS 1500 bytes is L2 MTU including Ethernet header.

In order to solve this problem, you should always check what is announced in LDP and BGP messages and check errors, if they exist.

Conclusion

MPLS is very popular technology and number one choice for communication service provider (CSP) networks mainly due to its service’s framework. For sure Traffic Engineering and protection (secondary path or fast reroute) is also important, but the ability to transfer any kind of data (Ethernet, TDM, ATM, IP and so on) over the same network makes MPLS incredible tool. In the example above I’ve used RSVP-TE based LSP, but you can take any other option to build MPLS forwarding plane (LDP, BGP-LU, SPRING). From the service prospective you also have two options, what to use to signal the service (BGP or LDP). Such number of choices gives you high level of flexibility to build VPWS that matches your design and expertise. Take care and good bye!

Support us





BR,

Anton Karneliuk