[c-nsp] MPLS Routing with PBR

Adam Vitkovsky Adam.Vitkovsky at gamma.co.uk
Thu Jun 9 20:44:47 EDT 2016


> Curtis Piehler
> Sent: Thursday, June 09, 2016 7:35 PM
>
> I have quite a scenario here that we are working on testing in the lab but
> wanted to know if anyone has experience in this.
>
> In this scenario there are a few PE routers (ASR9K) connected to each other
> with a "firewall" connecting to one of the PE routers.  Two different PE
> routers have a customer router connected to them.  All the PE routers are
> talking MPLS, LDP and BGP exchaning labels.  The customer is in their own
> and has a VRF on all the PE routers so the PE routers are VRF aware.
>
> We attach an ACE to the ingress interface of the PE that the firewall connects
> to that matches on some sources and destinations setting a vrf nexthop of an
> interface hanging off of another PE router in the network.
> If the packet ends up traversing PE routers that are VRF aware of the
> customer on it's way to that final PE router will the in between PE routers
> pop the labels and subject the packet to normal VPNV4 routing table instead
> of just label switching entirely to the final PE router?
>
> The orignating PE router where the firewall is connecting to has a nexthop of
> the final PE router (not the in between routers).
>
Ok MPLS in a nutshell.
On an ingress PE (into the mpls cloud) a prefix in a VRF has a NH and a VPN label among other attributes.

That NH corresponds to an egress PE (the PE that advertised the prefix to the ingress PE) -ingress PE can look up what transport(top of the stack) label it needs to use so that when it sends the packet with this top label, the packet will make it all the way to the egress PE. See this transport label will be swapped at every leg of the path towards the egress PE, the point is all the intermediary nodes will just switch the packet according to the transport label designation towards the egress PE.

But once the packet finally arrives at the egress PE, the egress PE needs to know what to do with the incoming packet and that's what the VPN label is for.
See before ingress PE sends the packet on its way to the egress PE in addition to the transport label it will also add the VPN label to the bottom of the stack (so that the VPN label is hidden from all the madness that's gonna happen to the transport label while in flight).
Since it’s the egress PE that allocated this label in the first place, it is the only one who knows what the VPN label means.
So when egress PE receives the incoming packet with a familiar VPN label it knows right away, e.g. I see, yes this VPN label indicates I need to do IP lookup in VRF XYZ or yes please this VPN label means I need to switch the packet out this interface towards a CE.


adam



        Adam Vitkovsky
        IP Engineer

T:      0333 006 5936
E:      Adam.Vitkovsky at gamma.co.uk
W:      www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
---------------------------------------------------------------------------------------
 This email has been scanned for email related threats and delivered safely by Mimecast.
 For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------


More information about the cisco-nsp mailing list