[c-nsp] Using MPLS PEs as gateways for access layer

[Ryan L]

Thanks again guys... your input is much appreciated.

To answer re: size, the deployment is not too big. For the near-term,
looking at global + 1 VRF between 2 locations, holding about ~10-15
prefixes per site... so somewhere around the 30 mark with everything/global
transport included.

I'd expect this to go to 2-3 VRFs within a year's time, and probably expand
to 3 sites.

Initially, each of the 2 sites will have 2x 6500s, all 4 iBGP peered up...
L3 gateways for end hosts on them and ToR access aggregation. Looking at
replacing the 6500s next year to a slightly more robust solution (not sure
what yet), but while 1 VRF is fairly manageable via vrf-lite stitch, I
wanted to get ahead of any growth (because there will be) and design this
to scale up easily. L3VPN seems like the right choice even though it's not
the typical "MPLS Design" with my PEs doing FHRP for everything inside the
VPN.


On Wed, Nov 30, 2016 at 7:00 AM, Andrew Miehs <andrew at 2sheds.de> wrote:

> I see no reason why this shouldn't work. We had separate P routers due
> to our physical topology, but this would have worked with only PEs.
> Not that the Sup720s need to support MPLS, so you require at least the
> 3B iirc.
>
> How many 6500s and VRFs are you talking about using?
>
> Also note, with the Sup720, you wont be able to GRE/IPsec the MPLS
> traffic over your transit links.
>
>
> -- Andrew
>
>
>
>
> On Wed, Nov 30, 2016 at 10:23 PM, Ryan L <ryan.nsplist at gmail.com> wrote:
> > Thanks guys, this is good information.
> >
> > I will be using some 6500s with Sup720 - for the time being - on this
> > particular application.
> >
> > Just to make sure I've properly articulated, the PE routers at each site
> > are my only layer 3 termination point, and would also be doing transit
> > routing between locations via iBGP over my IGP as well (so technically P
> > router duties as well?) -- more or less every job except for the access
> > aggregation, which would go ToR.
> >
> > On Wed, Nov 30, 2016 at 3:26 AM, Phil Mayers <p.mayers at imperial.ac.uk>
> > wrote:
> >
> >> On 30/11/16 00:14, Ryan L wrote:
> >>
> >>> Hey all,
> >>>
> >>> Apologies if this is a muppet question, but still getting my bearings
> with
> >>> MPLS. Most L3VPN designs I've checked out don't really address this
> >>> specific design...
> >>>
> >>> I've got a multi-tenant network that would either be done w/VRF-lite or
> >>> L3VPN, but I don't have a CE router, per se.
> >>>
> >>> Is it somewhat accepted design to run L3VPN in a scenario where the
> PEs in
> >>>
> >>
> >> I don't know about "accepted" but PE-only (no CE) as well as collapsed
> >> P/PE can work - we do both in a campus MPLS L3VPN environment on a mix
> of
> >> older sup720, newer sup2t/6880 and N7k M1 hardware, as well as Juniper
> SRX
> >> in packet-mode for smaller sites. We've tested on other platforms and
> >> vendors as well, and found it to generally work.
> >>
> >> Be aware that in clients-on-PE designs the traffic will probably be
> >> arriving via an aggregate label & subsequent IP lookup, which on some
> >> platforms might require a 2nd pass through the forwarding pipeline,
> which
> >> may or may not be an issue.
> >>
> >> Also some kit is weird about doing label pop in combination with
> "egress"
> >> features like ACLs or QoS.
> >>
> >> If you are considering a merchant silicon platform I would pay
> particular
> >> attention to these kinds of issues; forwarding to adjacent clients via
> MPLS
> >> pop, IP lookup is quite different to MPLS pop + L2 rewrite, the latter
> >> being what takes place with a PE-CE static or dynamic route.
> >>
> >> Most of these are likely non-issues with VRF lite because the arriving
> >> traffic is just vlan-tagged IP so usually nothing special. Downside is
> of
> >> course you're having the pain of running VRF-lite which for anything
> other
> >> than a trivial number of very static VRFs is painful - but we used to do
> >> PE-only VRF-lite, and it worked there too.
> >>
> >> _______________________________________________
> >> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/cisco-nsp
> >> archive at http://puck.nether.net/pipermail/cisco-nsp/
> >>
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>