[c-nsp] How does the egress PE determine which VRF the VPN label is for?

[Rodney Dunn]

On Wed, Sep 24, 2008 at 11:17:27AM +1000, Andy Saykao wrote:
> Argh  cool. Thanks for that explaination Rodney.
> 
> You wrote: "based on the local VPN label allocated for either all
> connected or that specific route. A table is maintained to map them. "
> 
> Is there a command to view this "table" to check the mappings or is this
> something internal to the PE router?

sh mpls for 
sh ip bgp 

for the global and VRF.

Rodney

> 
> Thanks.
> 
> Andy
>  
> 
> -----Original Message-----
> From: Rodney Dunn [mailto:rodunn at cisco.com] 
> Sent: Wednesday, 24 September 2008 11:01 AM
> To: Andy Saykao
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] How does the egress PE determine which VRF the VPN
> label is for?
> 
> On Wed, Sep 24, 2008 at 09:57:12AM +1000, Andy Saykao wrote:
> > Given the scenario in which the packet has reached the egress PE, how 
> > does the router then determine which VRF the packet is destined for 
> > based on the remaining VPN label? I understand the concept of there 
> > being two labels, an IGP label and a VPN label. I'm just not sure how 
> > the egress PE is able to deduce that the VPN label is for a particular
> 
> > VRF.
> > 
> > Eg:
> > 
> > PE1 -> P1 -> P2 -> PE2
> > 
> > *** First, a CEF lookup is performed on PE1 at the time the IP packet 
> > enters the ingress PE from an interface belonging to VRF TEST and 
> > shows that the following tags/labels {4771 44169} are pushed onto the 
> > IP packet.
> > 
> > PE1#sh ip cef vrf TEST 172.16.66.2
> > 172.16.66.2/32, version 58, epoch 0, cached adjacency 203.10.x.x 0 
> > packets, 0 bytes
> >   tag information set
> >     local tag: VPN-route-head
> >     fast tag rewrite with Gi0/0.11, 203.10.x.x, tags imposed: {4771 
> > 44169}
> >   Flow: Origin AS 0, Peer AS 0, mask 32
> >   via 210.15.x.x, 0 dependencies, recursive
> >     next hop 203.10.x.x, GigabitEthernet0/0.11 via 210.15.x.x/32
> >     valid cached adjacency
> >     tag rewrite with Gi0/0.11, 203.10.x.x, tags imposed: {4771 44169}
> > 
> > *** The label packet then uses the IGP label to determine the LSP and 
> > ends up at PE2 with just the VPN label left {44169}.
> > 
> > *** PE2 checks it's mpls forwarding table and finds the following
> entry:
> > 
> > PE2#sh mpls forwarding-table label 44169
> > Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
> > tag    tag or VC   or Tunnel Id      switched   interface
> > 44169  Aggregate   172.16.66.2/32[V] 5752
> > 
> > *** From the book "MPLS Fundamentals", it says - "Aggregate means that
> 
> > the aggregating LSR needs to remove the label of the incoming packet 
> > and must do an IP lookup to determine the more specific prefix to use 
> > for forwarding this IP packet."
> > 
> > What I don't get from that explaination is:
> > 
> > - What is involved in doing an "IP lookup" as the next step?
> 
> It means the aggregate just tells the PE that the ip address is
> connected and in a particular VRF. There are different ways to implement
> it. per prefix lables, aggregats for only connected in a vrf, etc.
> 
> 
> > - How does the router figure out that the prefix 172.16.66.2 is a 
> > route belonging to VRF TEST?
> 
> based on the local VPN label allocated for either all connected or that
> specific route. A table is maintained to map them. That's why you can do
> 'sh ip bgp vpnv4 vrf blah and it show the vpnv4 label.
> 
> > - Is it something to do with MP-BGP because when I do a BGP lookup on 
> > the prefix, I see the word "aggregate" followed by the VRF name. How 
> > does this information then tie in with what's contained in the mpls 
> > forwarding table to deduce that it's VRF TEST we want.
> 
> Different protocols can insert labels in the lfib. ie: ldp, bgp, etc.
> BGP can allocate a lable for VPNV4 prefixes and then advertise that to
> remote PE's to tell them what label to send with. Then ldp sends labels
> hop by hop to get to the PE's loopback (outer label as we call it).
> 
> > 
> > PE2#sh ip bgp vpnv4 rd 4854:100660 172.16.66.2 BGP routing table entry
> 
> > for 4854:100660:172.16.66.2/32, version 811
> > Paths: (1 available, best #1, table TEST)
> >   Advertised to peer-groups:
> >      NS-MPLS-VPN
> >   Local
> >     0.0.0.0 from 0.0.0.0 (203.17.x.x)
> >       Origin incomplete, metric 0, localpref 100, weight 32768, valid,
> 
> > sourced, best
> >       Extended Community: RT:4854:100660,
> >       mpls labels in/out 44169/aggregate(TEST)
> > 
> > Everything is working fine - I'm just trying to understand the little 
> > intricate details of MPLS VPN's that make them work, so I can picture 
> > it in my mind.
> > 
> > Thanks.
> > 
> > Andy
> 
> This email and any files transmitted with it are confidential and intended
>  solely for the use of the individual or entity to whom they are addressed. 
> Please notify the sender immediately by email if you have received this 
> email by mistake and delete this email from your system. Please note that
>  any views or opinions presented in this email are solely those of the
>  author and do not necessarily represent those of the organisation. 
> Finally, the recipient should check this email and any attachments for 
> the presence of viruses. The organisation accepts no liability for any 
> damage caused by any virus transmitted by this email.
>