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

[Rodney Dunn]

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
> 
>  
> 
>  
> 
> 
>  
> 
>  
> 
> Probably an easy question, but what is the next step that a router takes
> to find the next interface or next hop it needs to send the VPN label
> to?
> 
> 
> 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.
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/