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:
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
- Support on Aggregated and VLAN Interfaces for IP-Based Filtering
- Support on ATM and Frame Relay Interfaces for IP-Based Filtering
- Support on Ethernet, SONET/SDH, and T1/T3/E3 Interfaces for IP-Based Filtering
- Support on Multilink PPP and Multilink Frame Relay Interfaces for IP-Based Filtering
- Support for IP-Based Filtering of Packets with Null Top Labels
- General Limitations on IP-Based Filtering
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 1.
Table 1: 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 2.
Table 2: 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 3.
Table 3: 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 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 4.
Table 4: 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 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:
- An aggregated SONET/SDH interface
- A channelized interface
- A tunnel interface (for example, generic routing encapsulation [GRE] or IP Security [IPsec])
- A circuit cross-connect (CCC) or translational cross-connect (TCC) encapsulated interface
- A logical tunnel interface
- A 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:
- 10-port E1 PIC
- 8-port Fast Ethernet PIC
- 12-port Fast Ethernet PIC
- 48-port Fast Ethernet PIC
- ATM PIC other than the ATM2 IQ PIC
