Junos OS

 View Only


This community is currently under full moderation, meaning  all posts will be reviewed before appearing in the community. Please expect a brief delay—there is no need to post multiple times. If your post is rejected, you'll receive an email outlining the reason(s). We've implemented full moderation to control spam. Thank you for your patience and participation.

  • 1.  vrf-table-label

    Posted 12-08-2021 11:04
    Greetings all,
    I am a bit confused as to the purpose of the vrf-table-label command when it comes to MPLS configuration. For example, watching some instructional videos I see that when configuring MVPN that you must use this command which I do not know why, while in other configurations such as L2/L3 VPN i don't see it configured.
    From my understanding, this is to assign one VPN label to all routes in a VRF. So it sounds like a resource saver there but is there a practical purpose?


  • 2.  RE: vrf-table-label

    Posted 12-08-2021 16:07

    Imagine this L3VPN topology with BGP running between PE-CE links.



    CE1 ------ PE1 ------ P ------- PE2 ------ CE2



    CE2 advertises his loopback as a BGP route PE2. Based on that route, PE2 learns CE2's MAC address.

    PE2 advertises prefix CE2 as a VPN route to PE1, PE1 advertises it as an IP route to CE1.


    Now CE1 can ping CE2. When the packet reaches PE2 with a VPN label, PE2 pops the label and sends the packet out to CE2 – with CE2's MAC address, which it learnt when it received the above-mentioned BGP route from CE2. No vrf-table-label needed here.



    Now Imagine this L3VPN topology where CE1-PE1 is running BGP but there is no protocol running in PE2's routing instance, since it's connected to a switch behind which are several simple servers. The servers and PE2's VRF interface are all on the same subnet.



    CE1 ------ PE1 ------ P ------- PE2 --- SWITCH --- servers



    Since PE2 has not received any messages from the servers, he doesn't know any of their MAC addresses. But say he advertises his VRF interface's DIRECT route (equal to the subnet containing the VRF interface address as well as all the server addresses) as a VPN route to PE1, PE1 advertises it to CE1. Now CE1 has a route to reach any of the servers. When CE1 sends a packet to one of the servers, PE2 receives that packet with the expected VPN label. Normally he would remove the MPLS header and send the packet out its VRF interface without any IP lookup, but now what is he going to use as the destination MAC address? He never learnt the destination server's MAC address since he never received any message from it. So he has to drop the packet. To avoid this packet drop we can have PE2 configured with vrf-table-label, in which case the IP packet is sent to the VRF table for a second lookup on the destination IP address, which will then trigger an ARP request for that destination IP address, by which PE2 will learn the destination server's MAC address, which he can then use as the destination MAC address of the packet as it sends it out its VRF interface.



    The additional IP lookup also allows you to implement egress IP tools such as firewall filters on the VRF interface.







  • 3.  RE: vrf-table-label

    Posted 12-10-2021 05:41
    So the vrf-table-label is for instances when you have devices on a LAN that are not responding to ARP?
    Is it always better to configure vrf-table-label then as part of a base configuration when deploying l3vpns ?


  • 4.  RE: vrf-table-label

    Posted 12-10-2021 10:05


    Vrf-table-label is needed for forwarding because the PE has not learnt any of the LAN devices MAC addresses because he is not running any routing protocol with them.



    Juniper Business Use Only

  • 5.  RE: vrf-table-label

    Posted 12-10-2021 05:40
    I suggest you watch the learning byte training video vrf-table-label.


  • 6.  RE: vrf-table-label

    Posted 12-10-2021 16:51
    Thank you for this. I watched it last night and it definitely clears up the purpose. 
    Please let me know if I am wrong here but from what I was able to identify the reason for configuring this is
    1. So the PE router can look at the encapsulated IP header after it strips off the VPN label.
    2. To assign a VRF a label if it doesn't know how to resolve the next-hop to the CE.

    In regards to NG-MVPN, why would the PE need to examine the IP header?


  • 7.  RE: vrf-table-label

    Posted 12-12-2021 05:22
    Hi Michael.

    To forward the multicast packet, it needs to match the IP addresses with PIM state in its routing instance.