MPLS L2VPN Martini between Juniper and Cisco

There are some nuances that you have to take into account if you need to interoperate MPLS L2VPN Martini (LDP VPWS) between Juniper (vMX) and Cisco (CSR1000v - IOS-XE). In this interoperability case, I’m going to use VC-type 4/tagged mode (i.e., which in a nutshell, is the mode where you can use SVLANs on the ingress PE to differentiate between your L2VPN customers). If you need further or specific information about this mode, I’d suggest you take a look at the RFC4448 1.

Introduction - L2VPN Martini

When it comes to the interoperability of L2VPN Martini, you have to keep in mind that these are the main attributes that must match by default, otherwise the PW won’t come UP:

  • VC-ID
  • PW signalling protocol
    • LDP and FEC 128 in this case, for instance, an example of a transport signaling mismatch would be if you tried to signal L2VPN Kompella (BGP VPWS) on one PE and L2VPN Martini (LDP VPWS) on the other PE
  • MTU of the AC (attachment circuit)
  • VC-type
    • tagged-mode a.k.a VC-type 4
    • raw-mode a.k.a VC-type 5

Network Design Tip
Some vendors allow you to ignore some mismatch types though. On Junos 15.1, it’s possible to ignore both MTU and VC-type mismatches 2. These ignore commands can remedy some network designs. For instance, the ignore MTU command could be handy if you had a PE which aggregates multiple PWs to several remote PEs and these remote PEs had different MTU values configured on their AC. In this case, it would be reasonable to use the ignore MTU command.

Topology

The topology that will be used for the configuration and the basic verification of this interoperability case is illustrated in Figure 1. As you can see, there are two PEs, vMX1 and CSR2, configured with L2VPN Martini and one SVLAN 1024, which is the AC of this L2 circuit/L2VPN. All core-facing interfaces are running MPLS/LDP/OSPF A0.

Figure 1

Configuration

For simplicity’s sake, the configuration presented in the following subsections are only related to L2VPN Martini.

Network Design Tip
As a network design best practice, make sure you’ve got set an appropriate MTU to account for all the encapsulation overhead in place on your MPLS backbone (which I omitted in the configuration snippet). Otherwise, you can experience silent packet drop, especially when transporting large data packets, if there isn’t enough room MTU-wise.

Juniper (Junos) configuration

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
protocols {
l2circuit {
neighbor 2.2.2.2 {
interface ge-0/0/3.1024 {
virtual-circuit-id 1024;
pseudowire-status-tlv;
}
}
}
ldp {
interface ge-0/0/0.0;
interface lo0.0;
}
}
interfaces {
ge-0/0/3 {
vlan-tagging;
mtu 1818;
encapsulation vlan-ccc;
unit 1024 {
encapsulation vlan-ccc;
vlan-id 1024;
}
}
}

Cisco (IOS-XE) configuration

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
!
l2vpn xconnect context PWID_1024_TO_VMX1
member GigabitEthernet4.1024
member pseudowire1024
!
interface pseudowire1024
encapsulation mpls
signaling protocol ldp
neighbor 1.1.1.1 1024
!
interface GigabitEthernet4
mtu 1800
no ip address
negotiation auto
!
interface GigabitEthernet4.1024
encapsulation dot1Q 1024
!

Before we start the verification, let’s double check all the main signaled attributes real quick:

Attribute vMX1 CSR2 Match exactly?
VC-ID 1024 1024 YES
PW Signaling protocol LDP and FEC 128 LDP and FEC 128 YES
MTU 1818 1800 NO
VC-type tagged-mode (implicitly derived since dot1q is set on access interface) tagged-mode (implicitly derived since dot1q is set on access interface) YES
SVLAN-ID 1024 1024 YES

Why the MTU value isn’t the same on both AC interfaces? Well, here’s where the fun begins due to particular details of vendor implementation. On IOS-XE, the MTU signaled is literally the explicit MTU value configured. In other words, on IOS-XE the MTU value configured doesn’t include the overhead of the L2 header encapsulation in place, whereas on Junos it does. So, in this case, assuming that you’d like to have a MTU of 1800 bytes of data, you’re expected to set extra 18 bytes (14 byte Ethernet header + 4 byte VLAN header of the encapsulation VLAN CCC) on the MTU configuration command. Alternatively, if for some reason, you’re not allowed to change the hardware MTU on the access interface, you can explicitly signal the MTU on the PW configuration. On Junon 15.1, you can find this under the VC-ID hierarchy:

1
2
3
4
admin@vMX1# ....2.2.2 interface ge-0/0/3.1024 virtual-circuit-id 1024 mtu ?
Possible completions:
<mtu> MTU to be advertised for this Layer 2 circuit
[edit]

On Cisco, IOS 15.5(3)S, you can set the signaled MTU under the PW interface:

1
2
3
4
5
6
CSR2(config)#int pseudowire 1024
CSR2(config-if)#mt
CSR2(config-if)#mtu ?
<64-65535> Maximum Transmission Unit value
CSR2(config-if)#mtu

Verification

Juniper (Junos) verification

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
admin@vMX1> show l2circuit connections extensive
Layer-2 Circuit Connections:
Legend for connection status (St)
EI -- encapsulation invalid NP -- interface h/w not present
MM -- mtu mismatch Dn -- down
EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down
CM -- control-word mismatch Up -- operational
VM -- vlan id mismatch CF -- Call admission control failure
OL -- no outgoing label IB -- TDM incompatible bitrate
NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration
BK -- Backup Connection ST -- Standby Connection
CB -- rcvd cell-bundle size bad SP -- Static Pseudowire
LD -- local site signaled down RS -- remote site standby
RD -- remote site signaled down HS -- Hot-standby Connection
XX -- unknown
Legend for interface status
Up -- operational
Dn -- down
Neighbor: 2.2.2.2
Interface Type St Time last up # Up trans
ge-0/0/3.1024(vc 1024) rmt Up May 21 21:27:39 2016 1
Remote PE: 2.2.2.2, Negotiated control-word: Yes (Null)
Incoming label: 299776, Outgoing label: 18
Negotiated PW status TLV: Yes
local PW status code: 0x00000000, Neighbor PW status code: 0x00000000
Local interface: ge-0/0/3.1024, Status: Up, Encapsulation: VLAN
Flow Label Transmit: No, Flow Label Receive: No
Connection History:
May 21 21:27:39 2016 status update timer
May 21 21:27:39 2016 PE route changed
May 21 21:27:39 2016 Out lbl Update 18
May 21 21:27:39 2016 In lbl Update 299776
May 21 21:27:39 2016 loc intf up ge-0/0/3.1024
admin@vMX1> show interfaces ge-0/0/3.1024 extensive
Logical interface ge-0/0/3.1024 (Index 331) (SNMP ifIndex 524)
(Generation 140)
Flags: Up SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.1024 ]
Encapsulation: VLAN-CCC
Traffic statistics:
Input bytes : 674
Output bytes : 750
Input packets: 9
Output packets: 9
Local statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Transit statistics:
Input bytes : 674 0 bps
Output bytes : 750 0 bps
Input packets: 9 0 pps
Output packets: 9 0 pps
Protocol ccc, MTU: 1818, Generation: 156, Route table: 0
Flags: Is-Primary
admin@vMX1> show route table l2circuit.0 extensive next-hop 2.2.2.2
l2circuit.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
2.2.2.2:CtrlWord:4:1024:Local/96 (1 entry, 1 announced)
TSI:
LDP Neighbor 2.2.2.2, State: Active
*L2CKT Preference: 7
Next hop type: Indirect
Address: 0x973077c
Next-hop reference count: 1
Next hop type: Router
Next hop: 10.0.12.2 via ge-0/0/0.0, selected
Session Id: 0x0
Protocol next hop: 2.2.2.2
Indirect next hop: 0x96e4110 - INH Session ID: 0x0
State: <Active Int>
Age: 26:43 Metric2: 1
Validation State: unverified
Task: l2 circuit
Announcement bits (1): 0-LDP
AS path: I
VC Label 299776, MTU 1800, VLAN ID 1024
PW Status Code 0x0
Flow Label T Bit 0, Flow Label R Bit 0
Indirect next hops: 1
Protocol next hop: 2.2.2.2 Metric: 1
Indirect next hop: 0x96e4110 - INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.0.12.2 via ge-0/0/0.0
Session Id: 0x0
2.2.2.2/32 Originating RIB: inet.3
Metric: 1 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.0.12.2 via ge-0/0/0.0

Cisco (IOS-XE) verification

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
CSR2#show mpls l2transport vc 1024
Local intf Local circuit Dest address VC ID Status
------------- -------------------------- --------------- ---------- ----------
Gi4.1024 Eth VLAN 1024 1.1.1.1 1024 UP
CSR2#show mpls l2transport vc 1024 detail
Local interface: Gi4.1024 up, line protocol up, Eth VLAN 1024 up
Destination address: 1.1.1.1, VC ID: 1024, VC status: up
Output interface: Gi1, imposed label stack {299776}
Preferred path: not configured
Default path: active
Next hop: 10.0.12.1
Create time: 00:27:06, last status change time: 00:26:41
Last label FSM state change time: 00:26:41
Signaling protocol: LDP, peer 1.1.1.1:0 up
Targeted Hello: 2.2.2.2(LDP Id) -> 1.1.1.1, LDP is UP
Graceful restart: not configured and not enabled
Non stop routing: not configured and not enabled
Status TLV support (local/remote) : enabled/supported
LDP route watch : enabled
Label/status state machine : established, LruRru
Last local dataplane status rcvd: No fault
Last BFD dataplane status rcvd: Not sent
Last BFD peer monitor status rcvd: No fault
Last local AC circuit status rcvd: No fault
Last local AC circuit status sent: No fault
Last local PW i/f circ status rcvd: No fault
Last local LDP TLV status sent: No fault
Last remote LDP TLV status rcvd: No fault
Last remote LDP ADJ status rcvd: No fault
MPLS VC labels: local 18, remote 299776
Group ID: local 9, remote 0
MTU: local 1800, remote 1800
Remote interface description:
Remote VLAN id: 1024
Sequencing: receive disabled, send disabled
Control Word: On (configured: autosense)
SSO Descriptor: 1.1.1.1/1024, local label: 18
Dataplane:
SSM segment/switch IDs: 8194/4096 (used), PWID: 1
VC statistics:
transit packet totals: receive 9, send 9
transit byte totals: receive 674, send 948
transit packet drops: receive 0, seq error 0, send 0

Data plane verification

So far so good, the control plane looks solid. Let’s move on and check the data plane now. From CE1’s perspective, it’s OK. It’s possible to ping CE2:

1
2
3
4
5
6
7
8
9
10
admin@CEs:CE1> ping 192.168.12.2 rapid
PING 192.168.12.2 (192.168.12.2): 56 data bytes
!!!!!
--- 192.168.12.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.999/5.948/7.693/0.924 ms
admin@CEs:CE1> traceroute 192.168.12.2
traceroute to 192.168.12.2 (192.168.12.2), 30 hops max, 40 byte packets
1 192.168.12.2 (192.168.12.2) 5.918 ms 7.972 ms 4.987 ms

If you don’t have access to your CE devices, you can verify from your PE. Also, let’s make sure that this PW can successfully transport 1800 bytes of data over the MPLS backbone:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
CSR2#ping mpls pseudowire 1.1.1.1 1024 size 1800
Sending 5, 1800-byte MPLS Echos to 1.1.1.1,
timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/75/144 ms
Total Time Elapsed 382 ms

Sweet! There you go, we just transported 1800 bytes of data. In fact, on the MPLS backbone, as you can see in Figure 2, there are 1822 bytes on wire because of the overhead encapsulation (new Ethernet header + VC-Label + MPLS ControlWord).

Side Note
Keep in mind that since these PEs are directly connected, they both make use of PHP, otherwise we would’ve seen more 4 bytes of overhead of the LSP transport label

Figure 2

Summary

All in all, L2VPN Martini works smoothly between Juniper and Cisco. Always make sure you match the main signaled attributes, which are VC-ID, signaling protocol, MTU and VC-type. Also, before setting up L2VPN martini, do some research to find out how the vendor implementation signals the MTU of the AC because this is usually the trickiest part.

References