Thanks for the explanation guys. On Jun 9, 2016 8:44 PM, "Adam Vitkovsky" <adam.vitkov...@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.vitkov...@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 postmas...@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 > ------------------------------ > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/