[j-nsp] Practical VPLS examples (SRX and J series)

[Pavel Lunin]

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
>