[j-nsp] Practical VPLS examples (SRX and J series)
Angel Bardarov ( M-Tel )
angel.bardarov at mobiltel.bg
Sat Nov 12 05:37:56 EST 2011
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 10000 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-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Pavel Lunin
Sent: Saturday, November 12, 2011 9:45 AM
To: David Ball
Cc: juniper-nsp at 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" <davidtball at 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 spokes....works 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 it....but, 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.williams at 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 at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
More information about the juniper-nsp
mailing list