Featured

VRF Table Label

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.

vrf-table-label-jpg

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 20.20.20.20/32 is allocated VPN label 299904:

vpn-b.inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
* 20.20.20.20/32 (1 entry, 1 announced)
BGP group core-as1 type Internal
Route Distinguisher: 172.16.0.2:2
VPN Label: 299904
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:1:2

The second prefix 12.12.12.12/32 is allocated VPN label 299888:

vpn-b.inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
* 12.12.12.12/32 (1 entry, 1 announced)
BGP group core-as1 type Internal
Route Distinguisher: 172.16.0.2:2
VPN Label: 299888
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:1:2

Configuration

The example below shows vpn-b with the vrf-table-label command added to the configuration:

routing-instances {
vpn-b {
instance-type vrf;
interface ae0.20;
route-distinguisher 172.16.0.2:2;
vrf-target target:1:2;
vrf-table-label;
}
}

Once the command is applied the two prefixes are checked again to verify the changes in label allocation:

vpn-b.inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
* 20.20.20.20/32 (1 entry, 1 announced)
BGP group core-as1 type Internal
Route Distinguisher: 172.16.0.2:2
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:1:2

The second prefix 12.12.12.12/32 is also allocated the same label:

vpn-b.inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
* 12.12.12.12/32 (1 entry, 1 announced)
BGP group core-as1 type Internal
Route Distinguisher: 172.16.0.2:2
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:1:2

Finally the output below shows the LSI interface which also allows ingress packets to be passed twice through the PFE for additional processing:

lab@r1> show interfaces terse lsi
Interface Admin Link Proto Local Remote
lsi up up
lsi.0 up up inet
iso

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.