Routing

Hi All,

I am a bit confused to when the command "vrf-lable-table" is needed under the routing instances and why. I know it has to do something with the Juniper architecture.

For example,from my experience these are the cases we had to use it, to solve things....

1) if a network is stub (connecting a LAN), i.e. no routing-options or protocols under routing-instanced, we have to use it to work.

2) if in a routing instance there are 2 or more interfaces, then "sometimes", we had to use it to work

3) if we need to see logged traffic or monitor traffic, we had to use it......

Please do not send me the JUNOS manual explanation, it dosn't add much to my knowledge....

Also, are there any limitations to as how many times to use it? any other alternatives?

Regards.

The "vrf-table-lable" command is a basically a software implementation of the vt- interface.  Therefore, the other option is to install a tunnel or other services PIC which supports the vt- interface.  However, VTL has the advantage of not using the bandwidth on the services PIC or even needing the PIC at all.  This could be desireable, for instance, if you have a lot of MLPPP customers on an LS PIC and don't want a problem with MLPPP to affect VRF customers who don't even run MLPPP.  Or, of course if you don't have any kind of service PIC in your PE router.

Both VTL and vt- interfaces allow the router to consolidate the labels for VRF where they are used and therefore can potentially reduce the number of labels used for a particular router a lot.  As you mentioned, they also allow more visibility to the IP traffic which would not have been possible otherwise.

I do not recall any scaling issues with VTL, but talk to your friendly neighborhood SE for that type of information.  One limitation that I do recall are that you cannot use it if the core interface is channelized, meaning that if your PE-P link is something like a T1 on a CT3, the VRF cannot forward to the backbone (although PE-CE links would be fine).  Also, if your core link is a multiaccess link such as Frame-Relay, ATM or Vlans, you may lose some of your statistics information on the input for the logical interfaces.  The physcal interface should be accurate though.  I do not believe either of these two limitations affect the vt- interface.

Hope that helps.

Ok. This helps.

Is it safe to assume that we can use it in every routing-instance?

What are the cases that must be used, as a rule of thumb? Since it is a software implementation of VT, how come there are no scaling issues on the Router Processor?

Where can I find more information on the limitations that you mentioned?

Regards.

---

@pavlosd wrote:
Please do not send me the JUNOS manual explanation, it dosn't add much to my knowledge....

---

Ok these links are not for you but for the others guys :

- "Configuring Traffic Filtering Based on the IP Header": https://www.juniper.net/techpubs/software/junos/junos80/swconfig80-vpns/html/vpnl3-config27.html

- "Other Limitations": https://www.juniper.net/techpubs/software/junos/junos80/swconfig80-vpns/html/vpnl3-config29.html

---

@pavlosd wrote:

How come there are no scaling issues on the Router Processor?

---

 

One year ago, I asked the question to the Juniper. It seems that the performances of the router are not impacted. This statement is processed by the ASIC of the forwarding engine.

Howdy,

I know you said not to send JUNOS manual links, but they've actually done a reasonable job of documenting this feature as of 9.0.  I know earlier versions did not give nearly as much detail, but if you look in the VPN guide index, it gives you the main use of filtering IP traffic, but also gets into the label consolidation a little, as well as offering the use of the vt- interface as an alternative.

http://www.juniper.net/techpubs/software/junos/junos90/swconfig-vpns/filtering-traffic-based-on-the-ip-header.html#id-10978770

The limitations I mentioned (and a few more) are listed here:

http://www.juniper.net/techpubs/software/junos/junos90/swconfig-vpns/other-limitations.html#id-10993840

As far as using it in every routing-instance, I believe it should be safe.  As I mentioned before, I do not remember any scaling problems.  However, I will say that I know several VPN service providers who add VTL as part of their standard routing-instance configuration.

As for scaling issues on the "Route Processor" I would expect VTL to help scaling because the router does not have to allocate as many labels (assuming you meant the Routing Engine).  If your question was more about forwarding performance, this should not really be a problem either because of the design of the Packet Forwarding Engine where all of the forwarding is done in hardware. 

I believe one way to look at it could be that VTL implements the LSI (Label switching interface?) in a similar way to aggregated SONET or aggregated Ethernet interfaces to serve as a software place holder for a second lookup in the PFE.  An extra PFE lookup in most Juniper hardware is relatively cheap from a performance perspective since they tend to over-engineer for extra lookups for various reasons.  However, the type of lookup available is limited by the interface on the PE-P (or PE-PE link) "core-facing" interfaces, so either the router can forward with no problems or it just won't forward the traffic at all, hence the list of interfaces listed with limitations.

The biggest 2 cases where VTL or vt- interfaces must be used are:

   -when broadcast media is put in the routing instance, because ARP functionality does not work with MPLS natively.

   -to filter the IP (v4 or v6) traffic egressing the PE-CE link.

Other than that, it is generally a VPN network optimization feature.

Once again, I hope this was everything you were looking for.

Thanks that solved a lot of my questions.

I have to admit that JUNOS Documentation is keep improving.

Regards.