[j-nsp] Interoperability between Juniper and Cisco on MPLS Martini

Josef Buchsteiner josefb at juniper.net
Mon Dec 29 08:01:29 EST 2003


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 at 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 at puck.nether.net
>> http://puck.nether.net/mailman/listinfo/juniper-nsp

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



More information about the juniper-nsp mailing list