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

[David Ball]

  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
>