[f-nsp] Transparent VLL through XMR and J-6350
Tomasz Szewczyk
tomeks at man.poznan.pl
Thu Apr 16 03:40:36 EDT 2009
Hi,
Some time ago I made successful interoperability test with XMR and
Juniper MX. Bellow is the config
interfaces {
ge-0/0/5 {
flexible-vlan-tagging;
native-vlan-id 513;
encapsulation flexible-ethernet-services;
unit 50 {
encapsulation vlan-ccc;
vlan-id 513;
}
}
ge-0/0/6 {
encapsulation ethernet-ccc;
unit 0;
}
ge-0/2/0 {
unit 0 {
family inet {
address 10.50.1.13/30;
}
family mpls;
}
}
xe-1/0/0 {
description ***XMR1***;
framing {
wan-phy;
}
unit 0 {
family inet {
address 10.50.1.25/30;
}
family mpls;
}
}
xe-1/1/0 {
description ***XMR2***;
framing {
wan-phy;
}
unit 0 {
family inet {
address 10.50.1.30/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 127.0.0.1/32;
address 10.0.0.2/32;
}
}
}
}
protocols {
rsvp {
interface ge-0/0/2.10;
interface ge-0/0/1.0
interface ge-0/0/0.10;
interface ge-0/2/0.0;
interface ge-0/0/0.0
interface xe-1/1/0.0;
interface xe-1/0/0.0;
}
mpls {
traffic-engineering bgp-igp-both-ribs;
standby;
label-switched-path xmr1 {
to 192.168.29.1;
}
label-switched-path xmr2 {
to 192.168.29.2;
}
path lsp1-primary {
10.50.1.22 strict;
}
path lsp1-secondary {
10.50.1.18 strict;
}
interface ge-0/0/2.10;
interface ge-0/0/1.0;
interface ge-0/0/0.10;
interface ge-0/2/0.0;
interface ge-0/0/0.0;
interface xe-1/0/0.0;
interface xe-1/1/0.0;
}
ospf {
traffic-engineering {
shortcuts;
}
area 0.0.0.0 {
interface ge-0/0/2.10;
interface lo0.0;
interface ge-0/0/1.0;
interface ge-0/0/0.10;
interface ge-0/2/0.0;
interface ge-0/0/0.0;
interface xe-1/0/0.0;
interface xe-1/1/0.0;
}
}
ldp {
transport-address router-id;
interface lo0.0;
}
l2circuit {
neighbor 192.168.29.1 {
interface ge-0/0/5.50 {
virtual-circuit-id 200;
}
}
neighbor 192.168.29.2 {
interface ge-0/0/6.0 {
virtual-circuit-id 201;
}
}
}
}
In my case I used loopback interfaces to establish targeted LDP session
for VLL (on both devices). You need to be careful if you want to change
MTU for VLL endpoints - as far as I remember there were some signaling
differences between XMR and Juniper (solved in new software).
Tomek
Brad Fleming pisze:
> I know this is a Foundry / Brocade list.. but does the config on the
> Juniper look correct? For some reason, I'm not getting any actual data
> through the VLL / CCC (tagged or untagged). Does anyone happen to have
> a REALLY basic config from a Brocade<->Juniper setup they would be
> willing to share? It would be greatly appreciated!
>
> Brad Fleming
>
> On Apr 14, 2009, at 8:49 PM, David Ball wrote:
>
>> Foundry has a slightly different take on making a service
>> 'transparent' (at least from what I was used to with JNPR). To make
>> it transparent, you change the tag-type to something that won't be
>> used by the customer (Foundry TAC recommended 9100) and then make the
>> port untagged in the VLL definition. So in your config below, looks
>> like you should just need to set 'tag-type 9100 ethe 1/20' and be on
>> your way.
>> I believe the tag-type 9100 is related to a Metro Ethernet Forum
>> recommendation regarding how QinQ should be handled (per 802.3ad).
>> I was able to get this working using XMR4 and a T640, so hopefully
>> your J-series acts the same.
>>
>> HTH,
>>
>> David
>>
>>
>> 2009/4/14 Brad Fleming <bdfleming at kanren.net>:
>>> Hello all,
>>> I'm new to the list but haven't found an answer to my question in the
>>> archives. If the topic has already been covered, my apologies.
>>> I'm attempting to build an MPLS VLL using the following gear:
>>> 1) Foundry / Brocade NetIron XMR running IronWare 4.0.00a
>>> 2) Juniper J-6350 running JunOS 9.4R1.8 (Enhanced Services)
>>> I'm having problems getting the VLL to pass both tagged and untagged
>>> traffic. For now, I'd be happy just getting untagged traffic across
>>> the link
>>> and tackle the multiple VLAN tags later. Little victories, if you will!
>>> :D Both devices claim the service is up but traffic does not dump
>>> out the
>>> other side.
>>> I'm 99.9% sure I'm missing something basic but I don't have a good
>>> configuration example for this setup.
>>> Any help or insight would be GREATLY appreciated! Thanks in advance!
>>> -brad fleming
>>> --
>>> Brad Fleming
>>> Network Engineer
>>> Kansas Research and Education Network
>>> Office: 785-856-9800 x.222
>>> Moblie: 785-865-7231
>>> NOC: 866-984-3662
>>>
>>>
>>>
>>> Here's a couple show commands:
>>> telnet at fake-ksu(config-mpls-vll-test)#show mpls vll
>>> Name VC-ID Vll-peer End-point State
>>> Tunnel-LSP
>>> test 2 164.113.199.108 untag e 1/20
>>> UP tnl0
>>>
>>> telnet at fake-ksu(config-mpls-vll-test)#
>>> brad# run show l2circuit connections extensive
>>> Layer-2 Circuit Connections:
>>> <<<deleted legend for brevity>>>
>>> Neighbor: 164.113.199.103
>>> Interface Type St Time last up #
>>> Up trans
>>> ge-0/0/1.0(vc 2) rmt Up Apr 15 05:11:58
>>> 2009 1
>>> Remote PE: 164.113.199.103, Negotiated control-word: No
>>> Incoming label: 299776, Outgoing label: 800000
>>> Local interface: ge-0/0/1.0, Status: Up, Encapsulation: ETHERNET
>>> Connection History:
>>> <<<deleted history for brevity>>>
>>>
>>>
>>> Here's the pertinent config from both devices:
>>> ------XMR:
>>> !
>>> router mpls
>>> !
>>> mpls-interface e1/1
>>> ldp-enable
>>> !
>>> vll test 2 raw-mode
>>> vll-mtu 9178
>>> vll-peer 164.113.199.108
>>> untag e 1/20
>>> !
>>> end of MPLS configuration
>>> -------J-6350:
>>> interfaces {
>>> ge-0/0/0 {
>>> description "link to NetIron";
>>> enable;
>>> mtu 9192;
>>> unit 0 {
>>> family inet {
>>> address 164.113.192.130/30;
>>> }
>>> family mpls;
>>> }
>>> }
>>> ge-0/0/1 {
>>> description "MPLS-enabled Drop Port -- to CE";
>>> mtu 9192;
>>> encapsulation ethernet-ccc;
>>> unit 0 {
>>> }
>>> }
>>> }
>>> lo0 {
>>> description loopback;
>>> unit 0 {
>>> family inet {
>>> address 164.113.199.108/32;
>>> }
>>> }
>>> }
>>> }
>>> protocols {
>>> mpls {
>>> interface all;
>>> }
>>> ospf {
>>> traffic-engineering;
>>> area 0.0.0.0 {
>>> interface ge-0/0/0.0;
>>> interface lo0.0;
>>> interface ge-0/0/1.0 {
>>> disable;
>>> }
>>> }
>>> }
>>> ldp {
>>> interface ge-0/0/0.0;
>>> interface ge-0/0/1.0 {
>>> disable;
>>> }
>>> interface all;
>>> }
>>> l2circuit {
>>> neighbor 164.113.199.103 {
>>> interface ge-0/0/1.0 {
>>> virtual-circuit-id 2;
>>> mtu 9178;
>>> }
>>> }
>>> }
>>> }
>>>
>>> _______________________________________________
>>> foundry-nsp mailing list
>>> foundry-nsp at puck.nether.net
>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>
>>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
fax: +48 61 8525954
More information about the foundry-nsp
mailing list