Re: [j-nsp] MX5-T VPLS fowarding problem
If you configure vlan-id none under the routing-instance, then all vlan tags will be remove before transport over MPLS, and automatically the correct tag will be pushed on egress towards CE. Effectively, the VPLS becomes a single broadcast domain also when there are different VLAN ID on different sites. http://www.juniper.net/techpubs/en_US/junos11.4/topics/task/configuration/layer-2-services-bridge-domains-and-vpls-routing-instances-configuring-vlan-ids-for.html -Original Message- On 03/29/2013 02:36 PM, sth...@nethelp.no wrote: I got an off-list message from Diogo saying that the logical interface (VLAN ID) on each side must be the same, unless you do some pop/push/swap magic. Changing that did solve the problem! I still don't see why though. I only use the VLAN locally on each site to separate the traffic between multiple customers in the access switches, so the VLAN tag should never be included in the actual frames forwarded between the routers. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5-T VPLS fowarding problem
I'm pretty sure tunnel-services is only required on M/T platforms. In those boxes you needed a tunnel PIC to allow VPLS to work. On MX series the functionality is built into the line cards. You do need to explicitly disable tunnel-services under routing-instances routing-instance-name protocols vpls: http://www.juniper.net/techpubs/en_US/junos12.2/topics/reference/configuration-statement/no-tunnel-services-edit-protocols-vpls.html The command set chassis fpc XX pic XX tunnel-services bandwidth 1g|10G lets you create LT interfaces that can be used to logically connect 2 Logical Systems or Virtual Routers together. Essentially, the MPC line cards in MX have built-in tunnel PICs. This lets you use them. https://www.juniper.net/techpubs/en_US/junos12.2/topics/example/logical-systems-connecting-lt.html You shouldn't need this for VPLS.Hope this helps. Serge From: Mathias Sundman math...@nilings.se To: Caillin Bathern caill...@commtelns.com Cc: juniper-nsp@puck.nether.net Sent: Friday, March 29, 2013 6:27:25 PM Subject: Re: [j-nsp] MX5-T VPLS fowarding problem On 03/29/2013 12:40 PM, Caillin Bathern wrote: First try adding set chassis fpc XX pic XX tunnel-services bandwidth 1g|10G. You then have tunnel services on the MX80. Can't remember if this has any caveats on being done to a live system though.. Can someone explain the benefits of using tunnel-services vs no-tunnel-services on the MX80 platform for VPLS services? With a 10G backbone using 3-4 of the built-in 10G interfaces, and an expected VPLS use of 1-4G of bandwidth, what would be the recommended config? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5-T VPLS fowarding problem
Hello, On Fri, Mar 29, 2013 at 11:27 PM, Mathias Sundman math...@nilings.se wrote: On 03/29/2013 12:40 PM, Caillin Bathern wrote: Can someone explain the benefits of using tunnel-services vs no-tunnel-services on the MX80 platform for VPLS services? tunnel-services are just a hack to allow two lookups per one frame received from mpls backbone using frame re-circulation: 1) label lookup to map frame to vpls instance, 2) mac lookup to forward frame to correct interface. Recirculation means that every frame must be processed TWICE. And it is possible that frame will cross fabric twice. For this reason, when you enable tunnel-services for fpc, you must put bandwidth limit (1g or 10g), and recirculated traffic will be policed. On older fpc it is mandatory for VPLS. On newer fpcs, it is possible to perform 1st lookup with IO manager on ingress linecard, and avoid recirculation. So, with vrf-table-label or with no-tunnel-services, there is single lookup, no performance penalty, only profit. Why tunnel-services may be needed? 1) older fpc (not mx). 2) SDH/ATM/local tunnels on ingress line-card doesn't allow IO manager to perform 1st lookup, so tunnel services will be required. With a 10G backbone using 3-4 of the built-in 10G interfaces, and an expected VPLS use of 1-4G of bandwidth, what would be the recommended config? use vrf-table-label of no-tunnel-services. -- wbr, Sergey Khalavchuk ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5-T VPLS fowarding problem
Hi Mathias,
First try adding set chassis fpc XX pic XX tunnel-services
bandwidth 1g|10G. You then have tunnel services on the MX80. Can't
remember if this has any caveats on being done to a live system though..
Also check show route forwarding-table table vpls70134 extensive to
check for forwarding entries.
Cheers,
Caillin
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mathias
Sundman
Sent: Friday, 29 March 2013 9:11 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] MX5-T VPLS fowarding problem
I've just built a new MPLS network consisting of 6 MX5-T routers using
RSVP signaled LSPs where all routers work a combined P/PE routers.
The core network has been running fine for several weeks. L3VPN works
fine.
Now I try to establish a VPLS Point-to-Point tunnel between two adjacent
routers called solir1 and solir2. Outside of xe-0/0/3 of each router
there is access switch called solis1 and solis2, where I for the testing
purpose has configured an IP in the same subnet on each of the switches:
solis1 config:
interface Vlan1144
ip address 10.155.9.1 255.255.255.0
!
interface TenGigabitEthernet1/49
description type=core,subtype=isc,peer=solir1,peerint=xe-0/0/3
switchport mode trunk
!
solis2 config:
interface Vlan1244
ip address 10.155.9.2 255.255.255.0
!
interface TenGigabitEthernet1/49
description type=core,subtype=isc,peer=solir2,peerint=xe-0/0/3
switchport mode trunk
!
solir1 config:
masun@solir1 show configuration groups | find vpls70134
vpls70134 {
interfaces {
xe-0/0/3 {
unit 1144 {
description vpls70134 Test VPLS solir1-solir2;
encapsulation vlan-vpls;
vlan-id 1144;
family vpls {
policer {
input vpls70134-100m;
output vpls70134-100m;
}
}
}
}
}
firewall {
policer vpls70134-100m {
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 1m;
}
then discard;
}
}
routing-instances {
vpls70134 {
instance-type vpls;
interface xe-0/0/3.1144;
route-distinguisher 49079:70134;
vrf-target target:49079:70134;
protocols {
vpls {
site-range 10;
mac-table-size {
1024;
}
mac-statistics;
no-tunnel-services;
site solis1-vpls70134 {
site-identifier 1;
interface xe-0/0/3.1144;
}
}
}
}
}
}
masun@solir1 show configuration interfaces xe-0/0/3 description
type=core,subtype=isc,peer=solis1,peerint=Te1/49;
enable;
traps;
vlan-tagging;
mtu 2000;
encapsulation flexible-ethernet-services;
masun@solir2 show configuration groups | find vpls70134
vpls70134 {
interfaces {
xe-0/0/3 {
unit 1244 {
description vpls70134 Test VPLS solir1-solir2;
encapsulation vlan-vpls;
vlan-id 1244;
family vpls {
policer {
input vpls70134-100m;
output vpls70134-100m;
}
}
}
}
}
firewall {
policer vpls70134-100m {
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 1m;
}
then discard;
}
}
routing-instances {
vpls70134 {
instance-type vpls;
interface xe-0/0/3.1244;
route-distinguisher 49079:70134;
vrf-target target:49079:70134;
protocols {
vpls {
site-range 10;
mac-table-size {
1024;
}
mac-statistics;
no-tunnel-services;
site solis2-vpls70134 {
site-identifier 2;
interface xe-0/0/3.1244;
}
}
}
}
}
}
masun@solir2 show configuration interfaces xe-0/0/3 description
type=core,subtype=isc,peer=solis2,peerint=Te1/49;
enable;
traps;
vlan-tagging;
mtu 2000;
encapsulation flexible-ethernet-services;
The VPLS connection is up on each side:
masun@solir2 show vpls connections
...
Instance: vpls70134
Local site: solis2-vpls70134 (2)
connection-site Type St Time last up # Up
trans
1 rmt Up Mar 28 16:11:30 2013
1
Remote PE:
Re: [j-nsp] MX5-T VPLS fowarding problem
Hi,
I got an off-list message from Diogo saying that the logical interface
(VLAN ID) on each side must be the same, unless you do some
pop/push/swap magic. Changing that did solve the problem! I still don't
see why though. I only use the VLAN locally on each site to separate the
traffic between multiple customers in the access switches, so the VLAN
tag should never be included in the actual frames forwarded between the
routers.
With that solved, yes, I could then put the chassis fpc 0 pic 0
tunnel-services back and remove no-tunnel-services from the vpls config
and it still rocks :)
If I have a 10G backbone, and would like to able to transport a number
of 1G VPLS circuits, should I set tunnel-services bandwidth to 10G, or
does that have a big negative performance impact on something else?
Thanks both to Diogo and Caillin for your replies.
On 03/29/2013 12:40 PM, Caillin Bathern wrote:
Hi Mathias,
First try adding set chassis fpc XX pic XX tunnel-services
bandwidth 1g|10G. You then have tunnel services on the MX80. Can't
remember if this has any caveats on being done to a live system though..
Also check show route forwarding-table table vpls70134 extensive to
check for forwarding entries.
Cheers,
Caillin
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mathias
Sundman
Sent: Friday, 29 March 2013 9:11 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] MX5-T VPLS fowarding problem
I've just built a new MPLS network consisting of 6 MX5-T routers using
RSVP signaled LSPs where all routers work a combined P/PE routers.
The core network has been running fine for several weeks. L3VPN works
fine.
Now I try to establish a VPLS Point-to-Point tunnel between two adjacent
routers called solir1 and solir2. Outside of xe-0/0/3 of each router
there is access switch called solis1 and solis2, where I for the testing
purpose has configured an IP in the same subnet on each of the switches:
solis1 config:
interface Vlan1144
ip address 10.155.9.1 255.255.255.0
!
interface TenGigabitEthernet1/49
description type=core,subtype=isc,peer=solir1,peerint=xe-0/0/3
switchport mode trunk
!
solis2 config:
interface Vlan1244
ip address 10.155.9.2 255.255.255.0
!
interface TenGigabitEthernet1/49
description type=core,subtype=isc,peer=solir2,peerint=xe-0/0/3
switchport mode trunk
!
solir1 config:
masun@solir1 show configuration groups | find vpls70134
vpls70134 {
interfaces {
xe-0/0/3 {
unit 1144 {
description vpls70134 Test VPLS solir1-solir2;
encapsulation vlan-vpls;
vlan-id 1144;
family vpls {
policer {
input vpls70134-100m;
output vpls70134-100m;
}
}
}
}
}
firewall {
policer vpls70134-100m {
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 1m;
}
then discard;
}
}
routing-instances {
vpls70134 {
instance-type vpls;
interface xe-0/0/3.1144;
route-distinguisher 49079:70134;
vrf-target target:49079:70134;
protocols {
vpls {
site-range 10;
mac-table-size {
1024;
}
mac-statistics;
no-tunnel-services;
site solis1-vpls70134 {
site-identifier 1;
interface xe-0/0/3.1144;
}
}
}
}
}
}
masun@solir1 show configuration interfaces xe-0/0/3 description
type=core,subtype=isc,peer=solis1,peerint=Te1/49;
enable;
traps;
vlan-tagging;
mtu 2000;
encapsulation flexible-ethernet-services;
masun@solir2 show configuration groups | find vpls70134
vpls70134 {
interfaces {
xe-0/0/3 {
unit 1244 {
description vpls70134 Test VPLS solir1-solir2;
encapsulation vlan-vpls;
vlan-id 1244;
family vpls {
policer {
input vpls70134-100m;
output vpls70134-100m;
}
}
}
}
}
firewall {
policer vpls70134-100m {
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 1m;
}
then discard;
}
}
routing-instances {
vpls70134 {
instance-type vpls;
interface xe-0/0/3.1244;
route-distinguisher 49079:70134;
Re: [j-nsp] MX5-T VPLS fowarding problem
I got an off-list message from Diogo saying that the logical interface (VLAN ID) on each side must be the same, unless you do some pop/push/swap magic. Changing that did solve the problem! I still don't see why though. I only use the VLAN locally on each site to separate the traffic between multiple customers in the access switches, so the VLAN tag should never be included in the actual frames forwarded between the routers. The BGP-based VPLS RFC (RFC 4761) specifies in section 4.1: Ethernet frames received from CE devices are encapsulated for transmission over the packet switched network connecting the PEs. The encapsulation is as in [7]. where reference 7 is RFC 4448, which in its turn says: In Ethernet PW operates in one of two modes: raw mode or tagged mode. In tagged mode, each frame MUST contain at least one 802.1Q [802.1Q] VLAN tag, and the tag value is meaningful to the NSPs at the two PW termination points. Tagged mode is what you get if you have a VLAN subinterface and you don't do anything specific to remove the tag. Thus you should *expect* the VLAN tag to be included. It would have been possible for Juniper to automatically translate VLAN IDs on output - this is what for instance Cisco does on single- tagged pseudowires. Such automatic translation means that the VLAN IDs don't have to match. However, Juniper has chosen not to do such automatic translation. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5-T VPLS fowarding problem
On 03/29/2013 02:36 PM, sth...@nethelp.no wrote: I got an off-list message from Diogo saying that the logical interface (VLAN ID) on each side must be the same, unless you do some pop/push/swap magic. Changing that did solve the problem! I still don't see why though. I only use the VLAN locally on each site to separate the traffic between multiple customers in the access switches, so the VLAN tag should never be included in the actual frames forwarded between the routers. The BGP-based VPLS RFC (RFC 4761) specifies in section 4.1: Ethernet frames received from CE devices are encapsulated for transmission over the packet switched network connecting the PEs. The encapsulation is as in [7]. OK, then I understand. I consider the customer switch/router that they attach outside my access-switch the CE Device, while the RFC consider the first device connected to the PE router the CE device regardless of how it's used, and I guess that's where the confusion is created. where reference 7 is RFC 4448, which in its turn says: In Ethernet PW operates in one of two modes: raw mode or tagged mode. In tagged mode, each frame MUST contain at least one 802.1Q [802.1Q] VLAN tag, and the tag value is meaningful to the NSPs at the two PW termination points. Tagged mode is what you get if you have a VLAN subinterface and you don't do anything specific to remove the tag. Thus you should *expect* the VLAN tag to be included. It would have been possible for Juniper to automatically translate VLAN IDs on output - this is what for instance Cisco does on single- tagged pseudowires. Such automatic translation means that the VLAN IDs don't have to match. However, Juniper has chosen not to do such automatic translation. My goal is to use Q-in-Q on the trunk between my PE router and my access-switch, and then q-tunnel mode on the customer port to allow him to transport any VLANs he want inside the VPLS tunnel. So, if I want to achieve that without having to use the same outer VLAN ID between my PE and access-switch on each side, what do I have todo? Can I just pop the ingress outer tag (my S-VLAN) and consider it a RAW mode PW, or will it not allow the customer VLANs to be transported then? or would I have to swap in incoming S-VLAN to a common VLAN between my PEs and then swap it back to the locally unique S-VLAN used at each site? Thx ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5-T VPLS fowarding problem
Simplest way is to swap on egress. Under your unit add output-vlan-map swap. As long as all your VPLS end points have the same number of tags (sounds like this do), the S-tag can be different on each end. Output swap will take care of everything. You could achieve the same thing with pop on ingress and push on egress but I just find that more complicated than it has to be. Serge From: Mathias Sundman math...@nilings.se To: sth...@nethelp.no Cc: juniper-nsp@puck.nether.net Sent: Friday, March 29, 2013 10:51:05 AM Subject: Re: [j-nsp] MX5-T VPLS fowarding problem On 03/29/2013 02:36 PM, sth...@nethelp.no wrote: I got an off-list message from Diogo saying that the logical interface (VLAN ID) on each side must be the same, unless you do some pop/push/swap magic. Changing that did solve the problem! I still don't see why though. I only use the VLAN locally on each site to separate the traffic between multiple customers in the access switches, so the VLAN tag should never be included in the actual frames forwarded between the routers. The BGP-based VPLS RFC (RFC 4761) specifies in section 4.1: Ethernet frames received from CE devices are encapsulated for transmission over the packet switched network connecting the PEs. The encapsulation is as in [7]. OK, then I understand. I consider the customer switch/router that they attach outside my access-switch the CE Device, while the RFC consider the first device connected to the PE router the CE device regardless of how it's used, and I guess that's where the confusion is created. where reference 7 is RFC 4448, which in its turn says: In Ethernet PW operates in one of two modes: raw mode or tagged mode. In tagged mode, each frame MUST contain at least one 802.1Q [802.1Q] VLAN tag, and the tag value is meaningful to the NSPs at the two PW termination points. Tagged mode is what you get if you have a VLAN subinterface and you don't do anything specific to remove the tag. Thus you should *expect* the VLAN tag to be included. It would have been possible for Juniper to automatically translate VLAN IDs on output - this is what for instance Cisco does on single- tagged pseudowires. Such automatic translation means that the VLAN IDs don't have to match. However, Juniper has chosen not to do such automatic translation. My goal is to use Q-in-Q on the trunk between my PE router and my access-switch, and then q-tunnel mode on the customer port to allow him to transport any VLANs he want inside the VPLS tunnel. So, if I want to achieve that without having to use the same outer VLAN ID between my PE and access-switch on each side, what do I have todo? Can I just pop the ingress outer tag (my S-VLAN) and consider it a RAW mode PW, or will it not allow the customer VLANs to be transported then? or would I have to swap in incoming S-VLAN to a common VLAN between my PEs and then swap it back to the locally unique S-VLAN used at each site? Thx ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5-T VPLS fowarding problem
On 03/29/2013 12:40 PM, Caillin Bathern wrote: First try adding set chassis fpc XX pic XX tunnel-services bandwidth 1g|10G. You then have tunnel services on the MX80. Can't remember if this has any caveats on being done to a live system though.. Can someone explain the benefits of using tunnel-services vs no-tunnel-services on the MX80 platform for VPLS services? With a 10G backbone using 3-4 of the built-in 10G interfaces, and an expected VPLS use of 1-4G of bandwidth, what would be the recommended config? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
