Routing
Reply
Contributor
ralwarrag
Posts: 130
Registered: ‎09-21-2010
0
Accepted Solution

vrf-table-label why it's for ?

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

BR ,,,
Trusted Contributor
kurapati
Posts: 32
Registered: ‎01-23-2011

Re: vrf-table-label why it's for ?

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-la...

 

 

Pavan Kurapati
Contributor
ralwarrag
Posts: 130
Registered: ‎09-21-2010
0

Re: vrf-table-label why it's for ?

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

BR ,,,
Trusted Contributor
kurapati
Posts: 32
Registered: ‎01-23-2011

Re: vrf-table-label why it's for ?

[ Edited ]

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,

Pavan Kurapati
Contributor
ralwarrag
Posts: 130
Registered: ‎09-21-2010
0

Re: vrf-table-label why it's for ?

Big kudos from me :smileyhappy:

 

thanks alot for th explaination

BR ,,,
Contributor
aeroplane
Posts: 723
Registered: ‎06-30-2009
0

Re: vrf-table-label why it's for ?

Wow Great explaination!  One kudos from my side too :smileywink:

Contributor
niko_sianipar
Posts: 21
Registered: ‎11-25-2010
0

Re: vrf-table-label why it's for ?

Nice Info

 

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

 

Visitor
Ozair Siddiqui
Posts: 1
Registered: ‎04-27-2011
0

Re: vrf-table-label why it's for ?

great explaination.:smileyhappy:

Visitor
eng-mazen
Posts: 1
Registered: ‎04-20-2011
0

Re: vrf-table-label why it's for ?

Dear Pavan 

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

Regular Visitor
AmirSGH
Posts: 9
Registered: ‎06-19-2011
0

Re: vrf-table-label why it's for ?

many thanks good explanation

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.