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

[Andrew Miehs]

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/