Routing

Dear all

I am not able to understand what is the use of “vrf-table-label “ and when it should be configure  as far as understand it’s to avoid the double lookup but how and why it’s not possible to have double lookup

Thanks a lot

Whenever you want two lookups to be performed (say egress filtering or you have shared medium at PE-CE), you need a tunnel PIC (aka vt- interface). The first lookup is done to identify the VRF (based on inner VPN label) and then the packet is looped back through tunnel interface to perform the second lookup. If you do not have a tunnel PIC, you can use this software hack "vrf'-table-label". When you enable vrf-table-label, an LSI interface is created with a specific label associated with the LSI interface. This will form your VPN label. When packet arrives with a VPN label, the LSI i/f is identified and the incoming i/f is changed to look as if it is coming from LSI interface so that second level lookup can be performed.

Please check the below Junos documentation at the below link for more information and documentation on the same

http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/vpns-filtering-packets-in-layer-3-vpns-based-on-ip-headers.html

Thanks a lot   for you greater info , I just need more clarification about the below point

1-      Why we need it especially for multi access interface PE-CE as per the documentation they mentioned in case if you have device that don’t have IP address ,

(I tried to configure VPN in olive and I was not able to ping from CE-CE until I configure vrf-table-label even  I the PE-CE have IP address so why is that ??)

2-      Please correct me if I am wrong in all the case  there will be double lookup  inner-label and IP lookup ( or IP lookup is not needed in case of regular vrf unless you have filtering )  

Thanks a lot  in advance

Best regards

Hi,

If you have multi access interface like ethernet, you will need to add relevant MAC address before sending it out. Say you have multiple CE routers connected to PE over same i/f behind a CE switch. Based on which CE router advertised the route, PE will need to add the relevant MAC address and hence will need multiple lookups (one for identifying the VRF and 2nd lookup for identifying the end router which advertised the route). 

If you have point-point link, PE can just pop the VPN label and send it to CE with out the need of doing an IP lookup.

Let me show by some example

                                |-----CE-B

CE-A--------R1-----R2------R3---|

                                |

R1 and R3 are PEs here

Here, assume CE-A and R1 connection is sonet with ppp encapsulation. Connection between R3 and CE-B is ethernet. You will need to set vrf-table-label on R3 but you need not set vrf-table-label on R1

Configs on R1 (without vrf-table-label)

Pavan@R1# show routing-instances
VPN-A {
    instance-type vrf;
    interface so-0/0/1.0;
    route-distinguisher 65221:111;
    vrf-target target:65221:111;
    protocols {
        bgp {
            group ext {
                type external;
                as-override;
                neighbor 10.1.1.2 {
                    peer-as 65000;
                }
            }
        }
    }
}

Configs on R3:

Pavan@R3# show routing-instances
VPN-A {
    instance-type vrf;
    interface ge-3/1/2.0;
    route-distinguisher 65221:112;
    vrf-target target:65221:111;
    vrf-table-label; <------
    protocols {
        bgp {
            group ext {
                type external;
                as-override;
                neighbor 20.1.1.2 {
                    peer-as 65000;
                }
            }
        }
    }
}

[edit]

I've advertised 191.1.1.0/24 from CE-A., If you see these routes on R1 (where no vrf-table-label is configured)

Pavan@R1# run show route advertising-protocol bgp 3.3.3.3 extensive

VPN-A.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
* 10.1.1.0/30 (1 entry, 1 announced)
 BGP group int type Internal
     Route Distinguisher: 65221:111
     VPN Label: 299824
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [65221] I
     Communities: target:65221:111

* 191.1.1.0/24 (1 entry, 1 announced)
 BGP group int type Internal
     Route Distinguisher: 65221:111
     VPN Label: 299840 <---------------------------------
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [65221] 65000 I
     Communities: target:65221:111

[edit]
Pavan@R1# run show route table mpls.0

mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0                  *[MPLS/0] 00:23:23, metric 1
                      Receive
1                  *[MPLS/0] 00:23:23, metric 1
                      Receive
2                  *[MPLS/0] 00:23:23, metric 1
                      Receive
299776             *[LDP/9] 00:20:05, metric 1
                    > to 120.1.1.2 via ge-2/1/1.0, Pop     
299776(S=0)        *[LDP/9] 00:20:05, metric 1
                    > to 120.1.1.2 via ge-2/1/1.0, Pop     
299792             *[LDP/9] 00:13:54, metric 1
                    > to 120.1.1.2 via ge-2/1/1.0, Swap 300352
299824             *[VPN/170] 00:02:06
                    > via so-0/0/1.0, Pop     
299840             *[VPN/170] 00:02:02
                    > to 10.1.1.2 via so-0/0/1.0, Pop       <----------

[edit]

You can see that the operation is Pop and ship to i/f so-0/0/1.0 for VPN label 299840

Check the same for R3 where vrf-table-label is enabled

===============================

I am pumping 181.1.1.0/24 from CE-B

Pavan@R3# run show route advertising-protocol bgp 1.1.1.1 extensive

VPN-A.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
* 20.1.1.0/24 (1 entry, 1 announced)
 BGP group int type Internal
     Route Distinguisher: 65221:112
     VPN Label: 16
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [65221] I
     Communities: target:65221:111

* 181.1.1.0/24 (1 entry, 1 announced)
 BGP group int type Internal
     Route Distinguisher: 65221:112
     VPN Label: 16 <--------------
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [65221] 65000 I
     Communities: target:65221:111

Pavan@R3# run show route table mpls.0

mpls.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0                  *[MPLS/0] 00:14:36, metric 1
                      Receive
1                  *[MPLS/0] 00:14:36, metric 1
                      Receive
2                  *[MPLS/0] 00:14:36, metric 1
                      Receive
16                 *[VPN/0] 00:14:36
                      to table VPN-A.inet.0, Pop     <----------------------------------
299904             *[LDP/9] 00:14:26, metric 1
                    > to 130.1.1.2 via ge-3/0/5.0, Pop     
299904(S=0)        *[LDP/9] 00:14:26, metric 1
                    > to 130.1.1.2 via ge-3/0/5.0, Pop     
299920             *[LDP/9] 00:14:26, metric 1
                    > to 130.1.1.2 via ge-3/0/5.0, Swap 300336

[edit]

Pavan@R3# run show route table VPN-A.inet.0 181.1.1.0/24

VPN-A.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

181.1.1.0/24       *[BGP/170] 00:24:17, localpref 100
                      AS path: 65000 I
                    > to 20.1.1.2 via ge-3/1/2.0

[edit]
Pavan@R3#

If you observe above, for VPN label 16, it is popping and sending to table VPN-A.inet.0 (instead of earlier case where it was sending out of ifl).

Note that VPN label 16 is special label allocated for LSI i/f (Created because of vrf-table-label)

Pavan@CE-B# run ping 191.1.1.1   
PING 191.1.1.1 (191.1.1.1): 56 data bytes
64 bytes from 191.1.1.1: icmp_seq=0 ttl=62 time=0.939 ms
^C
--- 191.1.1.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.939/0.939/0.939/0.000 ms

Pavan@CE-A# run ping 181.1.1.1 logical-system delany-LR1
PING 181.1.1.1 (181.1.1.1): 56 data bytes
64 bytes from 181.1.1.1: icmp_seq=0 ttl=61 time=0.660 ms
64 bytes from 181.1.1.1: icmp_seq=1 ttl=61 time=0.848 ms
64 bytes from 181.1.1.1: icmp_seq=2 ttl=61 time=25.814 ms
^C
--- 181.1.1.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.660/9.107/25.814/11.814 ms

Hope this helps

If you like the explanation kudos will be appreciated 🙂

Thanks,

Big kudos from me

thanks alot for th explaination

Wow Great explaination!  One kudos from my side too 😉

Nice Info

But the vrf-table-label has some limited/constraint regarding interface used by the interface to its upstream router.

great explaination.

Dear Pavan 

Great Explanation actually i searched alot about this point and you give me the best explanation.

many thanks good explanation

Hi,

I did a lab test without vrf-table-label enabled on PE router with shared medium.

As below, we see label 299968 next-hop is to 9.9.9.3, the IP address of CE, not to vrf table.

It is the same MPLS label operation Pop as well, however PE router don't forward any packet to CE.

I am not able to understand why PE router don't forward any packet to CE, if the mpls.0 table indicates the label 299968 operation is Pop and the next-hop is the interface IP address of CE 9.9.9.3?

ernest@pe2> show route table mpls.0

mpls.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0 *[MPLS/0] 08:39:20, metric 1
Receive
1 *[MPLS/0] 08:39:20, metric 1
Receive
2 *[MPLS/0] 08:39:20, metric 1
Receive
299968 *[VPN/170] 00:08:14 <<<<<<<<<<<<<<<<<<<<<<<<<
> to 9.9.9.3 via ge-1/0/0.902, Pop <<<<<<<<<<<<<<<<<<<<<<<<<

Ernest,

Is ARP resolved for 9.9.9.3?

Hi
Yes, ARP resoved for 9.9.9.3.

Here is a solution.

http://forums.juniper.net/t5/Routing/with-and-without-vrf-table-label-enabled-on-PE-router/m-p/157218#M7163

Ernest Lin

Awesome explanation.

Really excellent explanation , Many thanks Pavan:)

nice explnation