Filtering Packets in Layer 3 VPNs Based on IP Headers

Including the vrf-table-label statement in the configuration for a routing instance makes it possible to map the inner label to a specific VRF routing table; such mapping allows the examination of the encapsulated IP header at an egress VPN router. You might want to enable this functionality so that you can do either of the following:

Forward traffic on a PE-router-to-CE-device interface, in a shared medium, where the CE device is a Layer 2 switch without IP capabilities (for example, a metro Ethernet switch).
The first lookup is done on the VPN label to determine which VRF table to refer to, and the second lookup is done on the IP header to determine how to forward packets to the correct end hosts on the shared medium.
Perform egress filtering at the egress PE router.
The first lookup on the VPN label is done to determine which VRF routing table to refer to, and the second lookup is done on the IP header to determine how to filter and forward packets. You can enable this functionality by configuring output filters on the VRF interfaces.
When you include the vrf-table-label statement in the configuration of a VRF routing table, a label-switched interface (LSI) logical interface label is created and mapped to the VRF routing table. Any routes in such a VRF routing table are advertised with the LSI logical interface label allocated for the VRF routing table. When packets for this VPN arrive on a core-facing interface, they are treated as if the enclosed IP packet arrived on the LSI interface and are then forwarded and filtered based on the correct table.

To filter traffic based on the IP header, include the vrf-table-label statement:

vrf-table-label;

You can include the statement at the following hierarchy levels:

[edit routing-instances routing-instance-name]
[edit logical-systems logical-system-name routing-instances routing-instance-name]

You can include the vrf-table-label statement for both IPv4 and IPv6 Layer 3 VPNs. If you include the statement for a dual-stack VRF routing table (where both IPv4 and IPv6 routes are supported), the statement applies to both the IPv4 and IPv6 routes and the same label is advertised for both sets of routes.

The following sections provide more information about traffic filtering based on the IP header:

Egress Filtering Options

You can enable egress filtering (which allows egress Layer 3 VPN PE routers to perform lookups on the VPN label and IP header at the same time) by including the vrf-table-label statement at the [edit routing-instances instance-name] hierarchy level. There is no restriction on including this statement for CE-router-to-PE-router interfaces, but there are several limitations on other interface types, as described in subsequent sections in this topic.

You can also enable egress filtering by configuring a VPN tunnel (VT) interface on routing platforms equipped with a Tunnel Services Physical Interface Card (PIC). When you enable egress filtering this way, there is no restriction on the type of core-facing interface used. There is also no restriction on the type of CE-router-to-PE-router interface used.

Support on Aggregated and VLAN Interfaces for IP-Based Filtering

Support for the vrf-table-label statement over aggregated and VLAN interfaces is available on the routers summarized in Table 4.

Table 4: Support for Aggregated and VLAN Interfaces

Interfaces	J Series Router in Switching Mode	M Series Router Without an Enhanced FPC	M Series Router with an Enhanced FPC	M320 Router	T Series Router
Aggregated	N/A	No	Yes	Yes	Yes
VLAN	Yes	No	Yes	Yes	Yes

Note: The vrf-table-label statement is not supported for Aggregated Gigabit Ethernet, 10-Gigabit Ethernet, and VLAN physical interfaces on M120 routers.

Support on ATM and Frame Relay Interfaces for IP-Based Filtering

Support for the vrf-table-label statement over Asynchronous Transfer Mode (ATM) and Frame Relay interfaces is available on the routers summarized in Table 5.

Table 5: Support for ATM and Frame Relay Interfaces

Interfaces	J Series Router	M Series Router Without an Enhanced FPC	M Series Router with an Enhanced FPC	M320 Router	T Series Router
ATM1	N/A	No	No	No	No
ATM2 intelligent queuing (IQ)	N/A	No	Yes	Yes	Yes
Frame Relay	Yes	No	Yes	Yes	Yes
Channelized	N/A	No	No	No	No

When you include the vrf-table-label statement, be aware of the following limitations with ATM or Frame Relay interfaces:

The vrf-table-label statement is supported on ATM interfaces, but with the following limitations:
- ATM interfaces can be configured on the M320 router and the T Series routers, and on M Series routers with an enhanced FPC.
- The interface can only be a PE router interface receiving traffic from a P router.
- The router must have an ATM2 IQ PIC.
The vrf-table-label statement is also supported on Frame Relay encapsulated interfaces, but with the following limitations:
- Frame Relay interfaces can be configured on the M320 router and the T Series routers, and on M Series routers with an enhanced FPC.
- The interface can only be a PE router interface receiving traffic from a P router.

Support on Ethernet, SONET/SDH, and T1/T3/E3 Interfaces for IP-Based Filtering

Support for the vrf-table-label statement over Ethernet, SONET/SDH, and T1/T3/E3 interfaces is available on the routers summarized in Table 6.

Table 6: Support for Ethernet, SONET/SDH, and T1/T3/E3 Interfaces

Interfaces	J Series Router	M Series Router Without an Enhanced FPC	M Series Router with an Enhanced FPC	M320 Router	T Series Router
Ethernet	Yes	Yes	Yes	Yes	Yes
SONET/SDH	N/A	Yes	Yes	Yes	Yes
T1/T3/E3	Yes	Yes	Yes	Yes	Yes

Only the following Ethernet PICs support the vrf-table-label statement on M Series routers without an Enhanced FPC:

1-port Gigabit Ethernet
2-port Gigabit Ethernet
4-port Fast Ethernet

Support on SONET/SDH and DS3/E3 Channelized Enhanced Intelligent Queuing Interfaces for IP-Based Filtering

Support for the vrf-table-label statement for the specified channelized IQE interfaces is available on M320 routers with Enhanced III FPCs as summarized in Table 7.

Table 7: Support for Channelized IQE Interfaces on M320 Routers with Enhanced III FPCs

Interfaces	M320 Routers with Enhanced III FPCs
OC12	Yes
STM4	Yes
OC3	Yes
STM1	Yes
DS3	Yes
E3	Yes

The following IQE Type-1 PICs are supported:

1-port OC12/STM4 IQE with SFP
4-port OC3/STM1 IQE with SFP
4-port DS3/E3 IQE with BNC
2-port Channelized OC3/STM1 IQE with SFP, with no SONET partitions
1-port Channelized OC12/STM4 IQE with SFP, with no SONET partitions

The following constraints are applicable with respect to a router configuration utilizing logical systems:

Multiport IQE PIC interfaces constraints—On multiport IQE PICs, such as the 2-port Channelized OC3/STM1 IQE with SFP, if the port 1 interface is configured as one logical system with its own routing-instance and the port 2 interface is configured as a different logical system with its own routing instances such that there are core-facing logical interfaces on both port 1 and port 2, then you cannot configure the vrf-table-label statement on routing-instance in both logical systems. Only one set of LSI labels are supported; the last routing instance with the vrf-table-label statement configured is committed.
Frame Relay encapsulation and logical interfaces across logical systems constraints—Similar to the multiport PIC with logical systems, if you try to configure one logical interface of an IQE PIC with Frame Relay encapsulation in one logical system and configure another logical interface on the same IQE PIC in the second logical system, the configuration will not work for all the vrf-table-label statement configured instances. It will only work for the instances configured in one of the logical systems.

Both the above constraints occur because the router configuration maintains one LSI tree in the Packet Forwarding Engine per logical system, which is common across all streams. The stream channel table lookup is then adjusted to point to the LSI tree. In the case of multiport type-1 IQE PICs, all physical interfaces share the same stream. Therefore, the logical interfaces (multiport or not) obviously share the same stream. Consequently, the LSI binding is at the stream level. Hence, provisioning logical interfaces under the same stream provisioned to be core-facing and supporting a different set of routing instances with the vrf-table-label statement is not supported.

Support on Multilink PPP and Multilink Frame Relay Interfaces for IP-Based Filtering

Support for the vrf-table-label statement over Multilink Point-to-Point Protocol (MLPPP) and Multilink Frame Relay (MLFR) interfaces is available on the routers summarized in Table 8.

Table 8: Support for Multilink PPP and Multilink Frame Relay Interfaces

Interfaces	J Series Router	M Series Router Without an Enhanced FPC	M Series Router with an Enhanced FPC	M320	T Series Router	MX Series Router
MLPPP	Yes	No	Yes	No	No	No
End-to-End MLFR (FRF.15)	Yes	No	Yes	No	No	No
UNI/NNI MLFR (FRF.16)	Yes	No	No	No	No	No

M Series routers must have an AS PIC to support the vrf-table-label statement over MLPPP and MLFR interfaces. The vrf-table-label statement over MLPPP interfaces is not supported on M120 routers.

Support for IP-Based Filtering of Packets with Null Top Labels

You can include the vrf-table-label statement in the configuration for core-facing interfaces receiving MPLS packets with a null top label, which might be transmitted by some vendors’ equipment. These packets can be received only on the M320 router, the M10i router, and T Series Core routers using one of the following PICs:

1-port Gigabit Ethernet with SFP
2-port Gigabit Ethernet with SFP
4-port Gigabit Ethernet with SFP
10-port Gigabit Ethernet with SFP
1-port SONET STM4
4-port SONET STM4
1-port SONET STM16
1-port SONET STM16 (non-SFP)
4-port SONET STM16
1-port SONET STM64

The following PICs can receive packets with null top labels, but only when installed in an M120 router or an M320 router with an Enhanced III FPC:

1-port 10-Gigabit Ethernet
1-port 10-Gigabit Ethernet IQ2

General Limitations on IP-Based Filtering

The following limitations apply when you include the vrf-table-label statement:

The time-to-live (TTL) value in the MPLS header is not copied back to the IP header of packets sent from the PE router to the CE router.
You cannot include the statement in a routing instance configuration that also includes a virtual loopback tunnel interface; the commit operation fails in this case.
You cannot include the statement in source class usage (SCU) or destination class usage (DCU) configurations. For information about SCU and DCU configuration, see the Junos Network Interfaces Configuration Guide.
You can include the statement in the configuration for Multilink Frame Relay (MLFR FRF.16) encapsulated PE-router-to-P-router interfaces only on J Series routers.
When you include the statement, MPLS packets with label-switched interface (LSI) labels that arrive on core-facing ATM or Frame Relay interfaces, or on aggregated Ethernet interfaces configured with VLANs or Ethernet interfaces configured with VLANs, are not counted at the logical interface level.
You cannot include the statement in the configuration of a VRF routing instance if the PE-router-to-P-router interface is any of the following interfaces:
- Aggregated SONET/SDH interface
- Channelized interface
- Tunnel interface (for example, generic routing encapsulation [GRE] or IP Security [IPsec])
- Circuit cross-connect (CCC) or translational cross-connect (TCC) encapsulated interface
- Logical tunnel interface
- Virtual private LAN service (VPLS) encapsulated interface
  Note: All CE-router-to-PE-router and PE-router-to-CE-router interfaces are supported.
You cannot include the vrf-table-label statement in the configuration of a VRF routing instance if the PE-router-to-P-router PIC is one of the following PICs:
- 10-port E1
- 8-port Fast Ethernet
- 12-port Fast Ethernet
- 48-port Fast Ethernet
- ATM PIC other than the ATM2 IQ