[c-nsp] MPLS Routing with PBR

Curtis Piehler cpiehler2 at gmail.com
Thu Jun 9 21:18:08 EDT 2016


Thanks for the explanation guys.
On Jun 9, 2016 8:44 PM, "Adam Vitkovsky" <Adam.Vitkovsky at gamma.co.uk> wrote:

> > 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