Mailing List Archive

We just did a lot of interop-testing in the lab with Martini tunnels and
MPLS in general, with Cisco/Juniper/Riverstone boxen. Martini in both
Ethernet and Ethernet-VLAN mode works like a charm between the three in
most cases, although certain configs and version combinations
gives...interesting results. We only tested with S-train IOS versions
though, and most of the essential tests were done with IOS 12.0(25)S1,
so we were using the "xconnect" style syntax, not "mpls l2transport
route <blah>".

BTW, by looking at your config excerpts, the first thing that strikes me
is that you are using Martini in Ethernet-VLAN mode, but you are using
different VLAN-tags on each side of the tunnel. Since Ethernet-VLAN mode
includes the layer 2 encapsulation (including the VLAN tags) in the
packet sent over the tunnel, the VLAN-tags on the customer-facing ports
at both ends must match unless you have equipment that will do L2 tag
rewrite on said packets. Otherwise your VC will get established but no
packets will be passed since they have incorrect VLAN-tags on the egress
PE.

But it also seems that in your case, the VC is not even being set up
correctly. We had some problems with this in certain cases until we
mapped the Cisco-end Martini-interfaces to a pseudowire-class bound to a
given tunnel interface or remote-peer rather than letting the Cisco try
to figure things out for itself and choosing the right LSP.

Here are some extracts from a functioning lab-config that you can look
at (from a very simple config):

---
* Juniper, 6.0R2.3:

interfaces {
ge-0/0/0 {
vlan-tagging;
encapsulation vlan-ccc;
unit 513 {
encapsulation vlan-ccc;
vlan-id 513;
}
}
}
protocols {
rsvp {
interface so-1/2/0.0;
}
mpls {
label-switched-path To-Cisco-PE1 {
to 172.17.0.144;
}
interface so-1/2/0.0;
}
ldp {
interface lo0.0;
}
l2circuit {
neighbor 172.17.0.144 {
interface ge-0/0/0.513 {
virtual-circuit-id 47513;
no-control-word;
}
}
}
}

* Cisco, 12.0(25)S1:

!
pseudowire-class L2-To-PE2
encapsulation mpls
preferred-path interface Tunnel1 disable-fallback
!
interface Loopback1
ip address 172.17.0.144
!
interface Tunnel1
ip unnumbered Loopback1
tunnel destination 172.17.0.141
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 1 dynamic
!
interface FastEthernet0/0.513
encapsulation dot1Q 513
xconnect 172.17.0.141 47513 pw-class L2-To-PE2
!

---

/leg

On Wed, 2003-12-24 at 09:48, Alex Rubenstein wrote:
> I am trying to get a l2circuit working between a M40 and 7507.
>
> interface FastEthernet0/0/0.16
> encapsulation dot1Q 16
> mpls l2transport route 209.123.x.y 623
>
>
> and
>
>
>
> unit 623 {
> encapsulation vlan-ccc;
> vlan-id 623;
>
> l2circuit {
> neighbor 209.123.x.z {
> interface ge-6/1/0.623 {
> virtual-circuit-id 623;
> control-word;
>
>
>
> results:
>
> core2.xxx#sho mpls l2transport vc 623 detail
> Local interface: Fa0/0/0.16 up, line protocol up, Eth VLAN 16 up
> Destination address: 209.123.x.y, VC ID: 623, VC status: down
> Tunnel label: not ready, LFIB entry untagged
> Output interface: unknown, imposed label stack {}
> Create time: 01:23:09, last status change time: never
> Signaling protocol: LDP, peer 209.123.x.y:0 up
> MPLS VC labels: local 998, remote unassigned
> Group ID: local 1, remote unknown
> MTU: local 1500, remote unknown
> Remote interface description:
> Sequencing: receive disabled, send disabled
> VC statistics:
> packet totals: receive 0, send 0
> byte totals: receive 0, send 0
> packet drops: receive 0, send 0
>
>
> alex@gbr2.zzz> show l2circuit connections extensive
> Neighbor: 209.123.x.z
> Interface Type St Time last up # Up trans
> ge-6/1/0.623 (vc 623) rmt VC-Dn ----- 0
> Local interface: ge-6/1/0.623, Status: Up, Encapsulation: VLAN
> Remote PE: 209.123.x.z, Negotiated control-word: Yes (Null)
> Incoming label: 108000, Outgoing label: 998
> Time Event Interface/Lbl/PE
> Dec 24 02:28:38 2003 PE route changed
> Dec 24 02:28:38 2003 Out lbl Update 998
> Dec 24 02:28:38 2003 In lbl Update 108000
> Dec 24 02:28:38 2003 loc intf up ge-6/1/0.623
>
>
>
> 12.3.5a on the cisco, 5.7R2.4 on the M40.
>
> Any pointers, or any examples from people who have done this will be
> greatly appreciated.
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp

apart from the vlan-id mismatch I do have seen this symptom when
you were running into CSCea84931. In this case IOS was not
responding a withdraw with label-release. I do believe this is
solved in the IOS version you are running.

Anyway I miss the complete configuration on the Juniper side e.g
ldp and mpls stanza are not included. Also ldp tracing or l2ckt
tracing would help a lot to narrow this down

Josef



Monday, December 29, 2003, 10:42:49 AM, you wrote:
> We just did a lot of interop-testing in the lab with Martini tunnels and
> MPLS in general, with Cisco/Juniper/Riverstone boxen. Martini in both
> Ethernet and Ethernet-VLAN mode works like a charm between the three in
> most cases, although certain configs and version combinations
> gives...interesting results. We only tested with S-train IOS versions
> though, and most of the essential tests were done with IOS 12.0(25)S1,
> so we were using the "xconnect" style syntax, not "mpls l2transport
> route <blah>".

> BTW, by looking at your config excerpts, the first thing that strikes me
> is that you are using Martini in Ethernet-VLAN mode, but you are using
> different VLAN-tags on each side of the tunnel. Since Ethernet-VLAN mode
> includes the layer 2 encapsulation (including the VLAN tags) in the
> packet sent over the tunnel, the VLAN-tags on the customer-facing ports
> at both ends must match unless you have equipment that will do L2 tag
> rewrite on said packets. Otherwise your VC will get established but no
> packets will be passed since they have incorrect VLAN-tags on the egress
> PE.

> But it also seems that in your case, the VC is not even being set up
> correctly. We had some problems with this in certain cases until we
> mapped the Cisco-end Martini-interfaces to a pseudowire-class bound to a
> given tunnel interface or remote-peer rather than letting the Cisco try
> to figure things out for itself and choosing the right LSP.

> Here are some extracts from a functioning lab-config that you can look
> at (from a very simple config):

> ---
> * Juniper, 6.0R2.3:

> interfaces {
> ge-0/0/0 {
> vlan-tagging;
> encapsulation vlan-ccc;
> unit 513 {
> encapsulation vlan-ccc;
> vlan-id 513;
> }
> }
> }
> protocols {
> rsvp {
> interface so-1/2/0.0;
> }
> mpls {
> label-switched-path To-Cisco-PE1 {
> to 172.17.0.144;
> }
> interface so-1/2/0.0;
> }
> ldp {
> interface lo0.0;
> }
> l2circuit {
> neighbor 172.17.0.144 {
> interface ge-0/0/0.513 {
> virtual-circuit-id 47513;
> no-control-word;
> }
> }
> }
> }

> * Cisco, 12.0(25)S1:

> !
> pseudowire-class L2-To-PE2
> encapsulation mpls
> preferred-path interface Tunnel1 disable-fallback
> !
> interface Loopback1
> ip address 172.17.0.144
> !
> interface Tunnel1
> ip unnumbered Loopback1
> tunnel destination 172.17.0.141
> tunnel mode mpls traffic-eng
> tunnel mpls traffic-eng path-option 1 dynamic
> !
> interface FastEthernet0/0.513
> encapsulation dot1Q 513
> xconnect 172.17.0.141 47513 pw-class L2-To-PE2
> !

> ---

> /leg

> On Wed, 2003-12-24 at 09:48, Alex Rubenstein wrote:
>> I am trying to get a l2circuit working between a M40 and 7507.
>>
>> interface FastEthernet0/0/0.16
>> encapsulation dot1Q 16
>> mpls l2transport route 209.123.x.y 623
>>
>>
>> and
>>
>>
>>
>> unit 623 {
>> encapsulation vlan-ccc;
>> vlan-id 623;
>>
>> l2circuit {
>> neighbor 209.123.x.z {
>> interface ge-6/1/0.623 {
>> virtual-circuit-id 623;
>> control-word;
>>
>>
>>
>> results:
>>
>> core2.xxx#sho mpls l2transport vc 623 detail
>> Local interface: Fa0/0/0.16 up, line protocol up, Eth VLAN 16 up
>> Destination address: 209.123.x.y, VC ID: 623, VC status: down
>> Tunnel label: not ready, LFIB entry untagged
>> Output interface: unknown, imposed label stack {}
>> Create time: 01:23:09, last status change time: never
>> Signaling protocol: LDP, peer 209.123.x.y:0 up
>> MPLS VC labels: local 998, remote unassigned
>> Group ID: local 1, remote unknown
>> MTU: local 1500, remote unknown
>> Remote interface description:
>> Sequencing: receive disabled, send disabled
>> VC statistics:
>> packet totals: receive 0, send 0
>> byte totals: receive 0, send 0
>> packet drops: receive 0, send 0
>>
>>
>> alex@gbr2.zzz> show l2circuit connections extensive
>> Neighbor: 209.123.x.z
>> Interface Type St Time last up # Up trans
>> ge-6/1/0.623 (vc 623) rmt VC-Dn -----
>> Local interface: ge-6/1/0.623, Status: Up, Encapsulation: VLAN
>> Remote PE: 209.123.x.z, Negotiated control-word: Yes (Null)
>> Incoming label: 108000, Outgoing label: 998
>> Time Event Interface/Lbl/PE
>> Dec 24 02:28:38 2003 PE route changed
>> Dec 24 02:28:38 2003 Out lbl Update 998
>> Dec 24 02:28:38 2003 In lbl Update 108000
>> Dec 24 02:28:38 2003 loc intf up ge-6/1/0.623
>>
>>
>>
>> 12.3.5a on the cisco, 5.7R2.4 on the M40.
>>
>> Any pointers, or any examples from people who have done this will be
>> greatly appreciated.
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> http://puck.nether.net/mailman/listinfo/juniper-nsp

> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp