Section 1: VRF Attachment Circuit Label Allocation
Under normal operation as attachment circuits are added to a VRF Junos will allocate each attachment circuit an additional VPN label when advertising associated IP prefixes into the core MP-BGP protocol.
In certain network deployments this default behaviour could create an unwanted depletion of VPN labels, due to label space limitations (on some hardware), or in other cases PE routers could be carrying large amounts of VRF tables or attachment circuits, which could require a significant amount of VPNv4 memory space.
The vrf-table-label command can help solve these issues, as it can be used to optimise the operation of VPN label allocation in MP-BGP.
Section 1.1: Per VRF Label Allocation
To solve these issues when vrf-table-label is introduced a single VPN label is applied to all prefixes exported from a given VRF into MP-BGP.
This method of label allocation can significantly reduce the amount of labels used on PE, regardless of the amount of prefixes or attachment circuits contained within a given VRF.
Section 2: Reference Topology
I am going to demonstrate how Junos handles this within the CLI, and will also show how the control plane responds to label allocation before vrf-table-label is introduced, and after it has been introduced.
The following topology will be used to demonstrate how this feature works. We will use two CEs deployed across remote PEs and will announce a loopback prefix via eBGP into the core PEs from each CE.
Section 2.1: Demonstrating The Default Behaviour
The outputs below shows an IP prefix announced by eBGP from CE1 in to DC1-PE1
Each output shows a different VPN label being allocated from the two attachment circuits that are used as next hops for each prefix.
The first prefix 22.214.171.124/32 is allocated VPN label 299904:
The second prefix 126.96.36.199/32 is allocated VPN label 299888:
The example below shows vpn-b with the vrf-table-label command added to the configuration:
Once the command is applied the two prefixes are checked again to verify the changes in label allocation:
The second prefix 188.8.131.52/32 is also allocated the same label:
Finally the output below shows the LSI interface which also allows ingress packets to be passed twice through the PFE for additional processing:
Section 2: Additional Lookup Functionality
When adding vrf-table-label into the VRF configuration a software based LSI interface is created that can be used as additional means of passing a packet through the PFE.
The LSI interface can be used to provide an additional lookup process when a VPNv4 packet enters the PE from a remote site. This can be useful in scenarios where ingress firewall filters, CoS or additional policy or packet processing is required – to allow the LSI interface to provide a first lookup before ARP, or packet forwarding is carried out via a secondary pass through the PFE.
Note: On older Juniper routers a software lookup was used when a tunnel-services PIC was not present; the tunnel-service PIC provides a hardware based logical vt-interface for additional secondary look up capabilities. On newer MX routers however, the tunnel services is built into the line card and all of the processing is carried out within the PFE.
Section 2.1: Additional Security Functionality
This command is also used to overcome a security feature within Junos that prevents a multiaccess VRF attachment circuit from being advertised into MP-BGP.
Under normal operation a PE router will only announce a multipoint LAN interface when it receives a dynamic route that uses that interface as a next-hop, or a locally configured static route that uses the multiaccess interface as its next hop.
In cases where there is no static or dynamic routing the vrf-table-label command can be added to the VRF configuration. This overrides this default security feature, and forces the interface to be exported into MP-BGP, without the need for a dependent route.