Re: [j-nsp] Practical VPLS examples (SRX and J series)
On Friday 11 November 2011 17:42:29 Mike Williams wrote:
So. VPLS. Point-to-multiple-point. Virtual LAN. Brilliant!
I managed build up the courage, and time, to have a crack at this today,
figuring it could take while.
However it took me less than an hour to convert my mesh of l2vpns to a VPLS
instance.
David, your from memory example was almost exactly perfect.
JUNOS gives you 2 options for the VPLS encapsulation (ethernet and
ethernet-vpls, as you suggested), however neither is valid!
Specifying no encapsulation works fine though.
[edit routing-instances VPLS_vr protocols vpls encapsulation-type]
'encapsulation-type ethernet'
Encapsulation type not valid for vpls
error: configuration check-out failed
Thanks everyone.
# show routing-instances VPLS_vr
instance-type vpls;
interface lt-0/0/0.5501;
route-distinguisher 500:5501;
vrf-target target:500:500;
protocols {
vpls {
site-range 15;
no-tunnel-services;
site rmdcjs1 {
site-identifier 1;
interface lt-0/0/0.5501;
}
}
}
# show interfaces lt-0/0/0
unit 501 {
encapsulation ethernet;
peer-unit 5501;
family inet {
address 10.250.250.1/27;
}
}
unit 5501 {
encapsulation ethernet-vpls;
peer-unit 501;
}
--
Mike Williams
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Practical VPLS examples (SRX and J series)
Hi,
At least in lab environment BGP AD + LDP signaling works well. You get the
advantage of autodiscovery and LDP signals VPLS instance labels individually
for each discovered PE - LDP builds targeted sessions between neighbors based
on autodiscovery, no manual configuration. In data plane the number of signaled
MPLS labels will depend on number of VPLS services and the number of
participating PEs in each service, no matter how big is your network.
In contrast BGP signaling always reserves an amount of MPLS labels equal to
site-range for each VPLS service. Some planning in advance is needed here -
if you put range 100 and you have 100 services that will eat 1 labels. And
there is no point in configuring range bigger than the total number of your
PEs. H-VPLS can reduce those numbers but you need appropriate network design to
cope with p2p nature of spoke attachments.
The parameter site-id gives an offset in the site-range block of labels and
that's why:
Note: The site range value must be greater than the largest site identifier.
Some years ago that wasn't even mentioned in documentation. On this topic I can
highly recommend the book MPLS-Enabled Applications: Emerging Developments and
New Technologies
BR,
Angel Bardarov
JNCIE-M #266
CCIE #21516
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Pavel Lunin
Sent: Saturday, November 12, 2011 9:45 AM
To: David Ball
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Practical VPLS examples (SRX and J series)
BTW, (although it's an offtopic quite a bit) let me ask if there is anyone
here who ever deployed/mantined LDP VPLS + external BGP autodiscovery in
real life for more or less large-scale network? How was it? Any gotchas
worth to be aware of?
12.11.2011 6:47 пользователь David Ball davidtb...@gmail.com написал:
We use both LDP- and BGP-signalled in our environment, with
LDP-signalled providing somewhat of a 'poor-man's hub and spoke'. The
spokes are configured to only build pseudowires to the hub, and the
hub builds back to all spokesworks for our particular use case.
Anyhow, BGP signalled.as Chris K mentioned, BGP signalling
alleviates the need to explicitly configure the IPs of your other
endpoint PEs in the VPLS. Instead, BGP advertises a site's route info
out with the VPLS's VRF target stuck on it, causing any other remote
sites also configured with that VRF target # to import them
automatically and learn about each other (simplistically). Tends to
scale better than LDP-signalled for that reason, and in large
networks, because of the number of pseudowires required for
LDP-signalled VPLS. It seems to me some BGP autodiscovery options may
have recently been added to LDP-signalled VPLS, but I haven't explored
them. Downside of both versus what you're doing now? With VPLS, you
learn MACs, so scale accordingly for your platform, though it sounds
like your CEs with be routers, so no biggy.
The site-range value must be at least as large as the number of
sites you have in the VPLS. So, if you pick 6 for the site range, you
can have 6 sites in itbut, those site-ids must be numbered 1-6.
Alternatively, you could use 100 as your site-range, and as long as no
site ID is larger than 100, you're good. We tend to leave a bit of
room in the site-range value to allow for customer expansion.
I'm almost certainly missing something in this config as I'm not
staring at a real one, but it should be close. Doesn't use tunnel
interfaces, but you get the drift.
[edit routing-instances]
myvpls {
instance-type vpls;
interface ge-1/2/3.4;
route-distinguisher x.x.x.x:yy;
vrf-target target:yourASN:uniqueCustIdentNum;
protocols vpls {
encapsulation [ethernet|ethernet-vlan];
no-tunnel-services;
site-range 6;
site siteNameHere {
site-identifier 1;
interface ge-1/2/3.4;
}
}
}
[edit interfaces ge-1/2/3]
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 4 {
encapsulation vlan-vpls;
vlan-id 4;
}
HTH,
David
On 11 November 2011 10:42, Mike Williams mike.willi...@comodo.com wrote:
So today I created a mesh of L2VPNs interconnecting virtual-routers on 5
SRX650s and J6350s.
I did the 3 650s as a trial, then added 2 J6350s later because, well, I
could.
Configuring a triangle of RSVP-signalled paths, BGP neighbours, and
logical
tunnels, wasn't too bad. Adding 2 more points made it almost maddeningly
confusing.
We'll be adding more sites sooner-or-later too, and my brain is unlikely
to
cope with anymore sites increasing the mesh exponentially.
So. VPLS. Point-to-multiple-point. Virtual LAN. Brilliant!
I haven't yet found any documentation that I can actually understand
though.
Note: The site range value must be greater than the largest site
identifier.
is especially confusing. Range is one number, bigger than any other
[j-nsp] Practical VPLS examples (SRX and J series)
So today I created a mesh of L2VPNs interconnecting virtual-routers on 5
SRX650s and J6350s.
I did the 3 650s as a trial, then added 2 J6350s later because, well, I could.
Configuring a triangle of RSVP-signalled paths, BGP neighbours, and logical
tunnels, wasn't too bad. Adding 2 more points made it almost maddeningly
confusing.
We'll be adding more sites sooner-or-later too, and my brain is unlikely to
cope with anymore sites increasing the mesh exponentially.
So. VPLS. Point-to-multiple-point. Virtual LAN. Brilliant!
I haven't yet found any documentation that I can actually understand though.
Note: The site range value must be greater than the largest site identifier.
is especially confusing. Range is one number, bigger than any other, hmm.
Could some kind gentle person provide a practical example of VPLS in action,
for the hard of thinking please?
In simple terms we have 5 devices directly connected to each other (full
mesh), and all 5 will have a CE (virtual-router) connected to it via ethernet
logical tunnels.
Thanks!
Currently I'm doing something like this (snipped for berevity);
# show routing-instances vr-l2vpn
instance-type l2vpn;
interface lt-0/0/0.5036;
interface lt-0/0/0.5077;
interface lt-0/0/0.5135;
interface lt-0/0/0.5136;
route-distinguisher 500:5034;
vrf-target target:500:500;
protocols {
l2vpn {
encapsulation-type ethernet;
site fsed {
site-identifier 34;
interface lt-0/0/0.5036 {
remote-site-id 2;
}
interface lt-0/0/0.5077 {
remote-site-id 33;
}
interface lt-0/0/0.5135 {
remote-site-id 101;
}
interface lt-0/0/0.5136 {
remote-site-id 102;
}
}
}
}
# show interfaces lt-0/0/0
unit 135 {
encapsulation ethernet;
peer-unit 5135;
family inet{
address 10.200.135.35/24;
}
}
unit 5135 {
encapsulation ethernet-ccc;
peer-unit 135;
family ccc {
filter {
input packet-mode-ccc;
}
}
}
# show protocols mpls
path-mtu {
rsvp mtu-signaling;
}
label-switched-path fsed-rmdcjs1 {
from a.b.c.d;
to w.x.y.z;
bandwidth 90m;
no-cspf;
fast-reroute;
primary fsed-rmdcjs1;
}
path fsed-rmdcjs1 {
e.f.g.h strict;
}
--
Mike Williams
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Practical VPLS examples (SRX and J series)
On 11/11/2011 11:42 AM, Mike Williams wrote: So. VPLS. Point-to-multiple-point. Virtual LAN. Brilliant! I haven't yet found any documentation that I can actually understand though. Note: The site range value must be greater than the largest site identifier. is especially confusing. Range is one number, bigger than any other, hmm. I believe this is because of the BGP auto-detection of sites. My guess is the logic actually runs up the numbers to range, so defining it to something reasonable speeds up the setup process. I'm still waiting on power for my lab to test vpls w/ BGP signalling, as it might screw up my production network and I'd like to see if I can shift to l2 signaling without dropping the peers. :) Jack ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Practical VPLS examples (SRX and J series)
In Juniper's BGP-based VPLS, you do not need to create pseudowires in-between the VPLS instances. As long as you have one master LSP (usuallyan RSVP one) in-between two PEs, BGP will then (by detecting which VPLS instance is announced from which device), automatically build an inner tunnel between the PEs to echange the VPLS traffic. In order to have this work automatically, we need to reserve a series of 'inner labels' (effectively) which can be used to differentiate sites and VPLS instances. (so when PE#1 sends traffic to PE#2, the latter devvice knows which VPLS domain it should go into). Contrast this with LDP-based VPLS, which requires manually configuring each neighbour in the VPLS domain by hand. - Chris. On 2011-11-12, at 7:01 AM, Jack Bates wrote: On 11/11/2011 11:42 AM, Mike Williams wrote: So. VPLS. Point-to-multiple-point. Virtual LAN. Brilliant! I haven't yet found any documentation that I can actually understand though. Note: The site range value must be greater than the largest site identifier. is especially confusing. Range is one number, bigger than any other, hmm. I believe this is because of the BGP auto-detection of sites. My guess is the logic actually runs up the numbers to range, so defining it to something reasonable speeds up the setup process. I'm still waiting on power for my lab to test vpls w/ BGP signalling, as it might screw up my production network and I'd like to see if I can shift to l2 signaling without dropping the peers. :) Jack ___ 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] Practical VPLS examples (SRX and J series)
We use both LDP- and BGP-signalled in our environment, with
LDP-signalled providing somewhat of a 'poor-man's hub and spoke'. The
spokes are configured to only build pseudowires to the hub, and the
hub builds back to all spokesworks for our particular use case.
Anyhow, BGP signalled.as Chris K mentioned, BGP signalling
alleviates the need to explicitly configure the IPs of your other
endpoint PEs in the VPLS. Instead, BGP advertises a site's route info
out with the VPLS's VRF target stuck on it, causing any other remote
sites also configured with that VRF target # to import them
automatically and learn about each other (simplistically). Tends to
scale better than LDP-signalled for that reason, and in large
networks, because of the number of pseudowires required for
LDP-signalled VPLS. It seems to me some BGP autodiscovery options may
have recently been added to LDP-signalled VPLS, but I haven't explored
them. Downside of both versus what you're doing now? With VPLS, you
learn MACs, so scale accordingly for your platform, though it sounds
like your CEs with be routers, so no biggy.
The site-range value must be at least as large as the number of
sites you have in the VPLS. So, if you pick 6 for the site range, you
can have 6 sites in itbut, those site-ids must be numbered 1-6.
Alternatively, you could use 100 as your site-range, and as long as no
site ID is larger than 100, you're good. We tend to leave a bit of
room in the site-range value to allow for customer expansion.
I'm almost certainly missing something in this config as I'm not
staring at a real one, but it should be close. Doesn't use tunnel
interfaces, but you get the drift.
[edit routing-instances]
myvpls {
instance-type vpls;
interface ge-1/2/3.4;
route-distinguisher x.x.x.x:yy;
vrf-target target:yourASN:uniqueCustIdentNum;
protocols vpls {
encapsulation [ethernet|ethernet-vlan];
no-tunnel-services;
site-range 6;
site siteNameHere {
site-identifier 1;
interface ge-1/2/3.4;
}
}
}
[edit interfaces ge-1/2/3]
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 4 {
encapsulation vlan-vpls;
vlan-id 4;
}
HTH,
David
On 11 November 2011 10:42, Mike Williams mike.willi...@comodo.com wrote:
So today I created a mesh of L2VPNs interconnecting virtual-routers on 5
SRX650s and J6350s.
I did the 3 650s as a trial, then added 2 J6350s later because, well, I could.
Configuring a triangle of RSVP-signalled paths, BGP neighbours, and logical
tunnels, wasn't too bad. Adding 2 more points made it almost maddeningly
confusing.
We'll be adding more sites sooner-or-later too, and my brain is unlikely to
cope with anymore sites increasing the mesh exponentially.
So. VPLS. Point-to-multiple-point. Virtual LAN. Brilliant!
I haven't yet found any documentation that I can actually understand though.
Note: The site range value must be greater than the largest site identifier.
is especially confusing. Range is one number, bigger than any other, hmm.
Could some kind gentle person provide a practical example of VPLS in action,
for the hard of thinking please?
In simple terms we have 5 devices directly connected to each other (full
mesh), and all 5 will have a CE (virtual-router) connected to it via ethernet
logical tunnels.
Thanks!
Currently I'm doing something like this (snipped for berevity);
# show routing-instances vr-l2vpn
instance-type l2vpn;
interface lt-0/0/0.5036;
interface lt-0/0/0.5077;
interface lt-0/0/0.5135;
interface lt-0/0/0.5136;
route-distinguisher 500:5034;
vrf-target target:500:500;
protocols {
l2vpn {
encapsulation-type ethernet;
site fsed {
site-identifier 34;
interface lt-0/0/0.5036 {
remote-site-id 2;
}
interface lt-0/0/0.5077 {
remote-site-id 33;
}
interface lt-0/0/0.5135 {
remote-site-id 101;
}
interface lt-0/0/0.5136 {
remote-site-id 102;
}
}
}
}
# show interfaces lt-0/0/0
unit 135 {
encapsulation ethernet;
peer-unit 5135;
family inet{
address 10.200.135.35/24;
}
}
unit 5135 {
encapsulation ethernet-ccc;
peer-unit 135;
family ccc {
filter {
input packet-mode-ccc;
}
}
}
# show protocols mpls
path-mtu {
rsvp mtu-signaling;
}
label-switched-path fsed-rmdcjs1 {
from a.b.c.d;
to w.x.y.z;
bandwidth 90m;
no-cspf;
fast-reroute;
primary fsed-rmdcjs1;
}
path fsed-rmdcjs1 {
e.f.g.h strict;
}
--
Mike Williams
___
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
Re: [j-nsp] Practical VPLS examples (SRX and J series)
BTW, (although it's an offtopic quite a bit) let me ask if there is anyone
here who ever deployed/mantined LDP VPLS + external BGP autodiscovery in
real life for more or less large-scale network? How was it? Any gotchas
worth to be aware of?
12.11.2011 6:47 пользователь David Ball davidtb...@gmail.com написал:
We use both LDP- and BGP-signalled in our environment, with
LDP-signalled providing somewhat of a 'poor-man's hub and spoke'. The
spokes are configured to only build pseudowires to the hub, and the
hub builds back to all spokesworks for our particular use case.
Anyhow, BGP signalled.as Chris K mentioned, BGP signalling
alleviates the need to explicitly configure the IPs of your other
endpoint PEs in the VPLS. Instead, BGP advertises a site's route info
out with the VPLS's VRF target stuck on it, causing any other remote
sites also configured with that VRF target # to import them
automatically and learn about each other (simplistically). Tends to
scale better than LDP-signalled for that reason, and in large
networks, because of the number of pseudowires required for
LDP-signalled VPLS. It seems to me some BGP autodiscovery options may
have recently been added to LDP-signalled VPLS, but I haven't explored
them. Downside of both versus what you're doing now? With VPLS, you
learn MACs, so scale accordingly for your platform, though it sounds
like your CEs with be routers, so no biggy.
The site-range value must be at least as large as the number of
sites you have in the VPLS. So, if you pick 6 for the site range, you
can have 6 sites in itbut, those site-ids must be numbered 1-6.
Alternatively, you could use 100 as your site-range, and as long as no
site ID is larger than 100, you're good. We tend to leave a bit of
room in the site-range value to allow for customer expansion.
I'm almost certainly missing something in this config as I'm not
staring at a real one, but it should be close. Doesn't use tunnel
interfaces, but you get the drift.
[edit routing-instances]
myvpls {
instance-type vpls;
interface ge-1/2/3.4;
route-distinguisher x.x.x.x:yy;
vrf-target target:yourASN:uniqueCustIdentNum;
protocols vpls {
encapsulation [ethernet|ethernet-vlan];
no-tunnel-services;
site-range 6;
site siteNameHere {
site-identifier 1;
interface ge-1/2/3.4;
}
}
}
[edit interfaces ge-1/2/3]
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 4 {
encapsulation vlan-vpls;
vlan-id 4;
}
HTH,
David
On 11 November 2011 10:42, Mike Williams mike.willi...@comodo.com wrote:
So today I created a mesh of L2VPNs interconnecting virtual-routers on 5
SRX650s and J6350s.
I did the 3 650s as a trial, then added 2 J6350s later because, well, I
could.
Configuring a triangle of RSVP-signalled paths, BGP neighbours, and
logical
tunnels, wasn't too bad. Adding 2 more points made it almost maddeningly
confusing.
We'll be adding more sites sooner-or-later too, and my brain is unlikely
to
cope with anymore sites increasing the mesh exponentially.
So. VPLS. Point-to-multiple-point. Virtual LAN. Brilliant!
I haven't yet found any documentation that I can actually understand
though.
Note: The site range value must be greater than the largest site
identifier.
is especially confusing. Range is one number, bigger than any other,
hmm.
Could some kind gentle person provide a practical example of VPLS in
action,
for the hard of thinking please?
In simple terms we have 5 devices directly connected to each other (full
mesh), and all 5 will have a CE (virtual-router) connected to it via
ethernet
logical tunnels.
Thanks!
Currently I'm doing something like this (snipped for berevity);
# show routing-instances vr-l2vpn
instance-type l2vpn;
interface lt-0/0/0.5036;
interface lt-0/0/0.5077;
interface lt-0/0/0.5135;
interface lt-0/0/0.5136;
route-distinguisher 500:5034;
vrf-target target:500:500;
protocols {
l2vpn {
encapsulation-type ethernet;
site fsed {
site-identifier 34;
interface lt-0/0/0.5036 {
remote-site-id 2;
}
interface lt-0/0/0.5077 {
remote-site-id 33;
}
interface lt-0/0/0.5135 {
remote-site-id 101;
}
interface lt-0/0/0.5136 {
remote-site-id 102;
}
}
}
}
# show interfaces lt-0/0/0
unit 135 {
encapsulation ethernet;
peer-unit 5135;
family inet{
address 10.200.135.35/24;
}
}
unit 5135 {
encapsulation ethernet-ccc;
peer-unit 135;
family ccc {
filter {
input packet-mode-ccc;
}
}
}
# show protocols mpls
path-mtu {
rsvp mtu-signaling;
}
label-switched-path fsed-rmdcjs1 {
from a.b.c.d;
to w.x.y.z;
