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

[Andy Saykao]

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?

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.