Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Creating Unique VPN Routes Using VRF Tables

 

Understanding Virtual Routing and Forwarding Tables

To separate a VPN’s routes from routes in the public Internet or those in other VPNs, the PE router creates a separate routing table for each VPN, called a VPN routing and forwarding (VRF) table. The PE router creates one VRF table for each VPN that has a connection to a CE router. Any customer or site that belongs to the VPN can access only the routes in the VRF tables for that VPN.

Figure 1 illustrates the VRF tables that are created on the PE routers. The three PE routers have connections to CE routers that are in two different VPNs, so each PE router creates two VRF tables, one for each VPN.

Figure 1: VRF Tables
VRF Tables

Each VRF table is populated from routes received from directly connected CE sites associated with that VRF routing instance and from routes received from other PE routers that passed BGP community filtering and are in the same VPN.

Each PE router also maintains one global routing table (inet.0) to reach other routers in and outside the provider’s core network.

Each customer connection (that is, each logical interface) is associated with one VRF table. Only the VRF table associated with a customer site is consulted for packets from that site.

You can configure the router so that if a next hop to a destination is not found in the VRF table, the router performs a lookup in the global routing table, which is used for Internet access.

The Junos OS uses the following routing tables for VPNs:

  • bgp.l3vpn.0—Stores routes learned from other PE routers. Routes in this table are copied into a Layer 3 VRF when there is a matching route table. This table is present only on PE routers, and it does not store routes received from directly connected CE routers.

    When a PE router receives a route from another PE router, it places the route into its bgp.l3vpn.0 routing table. The route is resolved using the information in the inet.3 routing table. The resultant route is converted into IPv4 format and redistributed to all routing-instance-name.inet.0 routing tables on the PE router if it matches the VRF import policy.

    The bgp.l3vpn.0 table is also used to resolve routes over the MPLS tunnels that connect the PE routers. These routes are stored in the inet.3 routing table. PE-to-PE router connectivity must exist in inet.3 (not just in inet.0) for VPN routes to be resolved properly.

    When a router is advertising non-local VPN-IPv4 unicast routes and the router is a route reflector or is performing external peering, the VPN-IPv4 unicast routes are automatically exported into the VPN routing table (bgp.l3vpn.0). This enables the router to perform path selection and advertise from the bgp.l3vpn.0 routing table.

    To determine whether to add a route to the bgp.l3vpn.0 routing table, the Junos OS checks it against the VRF instance import policies for all the VPNs configured on the PE router. If the VPN-IPv4 route matches one of the policies, it is added to the bgp.l3vpn.0 routing table. To display the routes in the bgp.l3vpn.0 routing table, use the show route table bgp.l3vpn.0 command.

  • routing-instance-name.inet.0—Stores all unicast IPv4 routes received from directly connected CE routers in a routing instance (that is, in a single VPN) and all explicitly configured static routes in the routing instance. This is the VRF table and is present only on PE routers. For example, for a routing instance named VPN-A, the routing table for that instance is named VPN-A.inet.0.

    When a CE router advertises to a PE router, the PE router places the route into the corresponding routing-instance-name.inet.0 routing table and advertises the route to other PE routers if it passes a VRF export policy. Among other things, this policy tags the route with the route distinguisher (route target) that corresponds to the VPN site to which the CE belongs. A label is also allocated and distributed with the route. The bgp.l3vpn.0 routing table is not involved in this process.

    The routing-instance-name.inet.0 table also stores routes announced by a remote PE router that match the VRF import policy for that VPN. The PE router redistributed these routes from its bgp.l3vpn.0 table.

    Routes are not redistributed from the routing-instance-name.inet.0 table to the bgp.l3vpn.0 table; they are directly advertised to other PE routers.

    For each routing-instance-name.inet.0 routing table, one forwarding table is maintained in the router’s Packet Forwarding Engine. This table is maintained in addition to the forwarding tables that correspond to the router’s inet.0 and mpls.0 routing tables. As with the inet.0 and mpls.0 routing tables, the best routes from the routing-instance-name.inet.0 routing table are placed into the forwarding table.

    To display the routes in the routing-instance-name.inet.0 table, use the show route table routing-instance-name.inet.0 command.

  • inet.3—Stores all MPLS routes learned from LDP and RSVP signaling done for VPN traffic. The routing table stores the MPLS routes only if the traffic-engineering bgp-igp option is not enabled.

    For VPN routes to be resolved properly, the inet.3 table must contain routes to all the PE routers in the VPN.

    To display the routes in the inet.3 table, use the show route table inet.3 command.

  • inet.0—Stores routes learned by the IBGP sessions between the PE routers. To provide Internet access to the VPN sites, configure the routing-instance-name.inet.0 routing table to contain a default route to the inet.0 routing table.

    To display the routes in the inet.0 table, use the show route table inet.0 command.

The following routing policies, which are defined in VRF import and export statements, are specific to VRF tables.

  • Import policy—Applied to VPN-IPv4 routes learned from another PE router to determine whether the route should be added to the PE router’s bgp.l3vpn.0 routing table. Each routing instance on a PE router has a VRF import policy.

  • Export policy—Applied to VPN-IPv4 routes that are announced to other PE routers. The VPN-IPv4 routes are IPv4 routes that have been announced by locally connected CE routers.

VPN route processing differs from normal BGP route processing in one way. In BGP, routes are accepted if they are not explicitly rejected by import policy. However, because many more VPN routes are expected, the Junos OS does not accept (and hence store) VPN routes unless the route matches at least one VRF import policy. If no VRF import policy explicitly accepts the route, it is discarded and not even stored in the bgp.l3vpn.0 table. As a result, if a VPN change occurs on a PE router—such as adding a new VRF table or changing a VRF import policy—the PE router sends a BGP route refresh message to the other PE routers (or to the route reflector if this is part of the VPN topology) to retrieve all VPN routes so they can be reevaluated to determine whether they should be kept or discarded.

Understanding VRF Localization in Layer 3 VPNs

In a Layer 3 VPN, to separate routes of a VPN from routes in the public Internet or those in other VPNs, the PE router creates a separate routing table for each VPN, called a virtual routing and forwarding (VRF) table. Each VRF uses a route distinguisher and route target to differentiate other VPNs so that each VRF achieves a VPN in a public network. The PE router creates one VRF table for each VPN that has a connection to a CE router. Any customer or site that belongs to the VPN can access only the routes in the VRF tables for that VPN.

The PE routers in a Layer 3 VPN deployment have two types of line cards hosting the following interfaces:

  • CE-facing interfaces

  • Core-facing interfaces

Note

An FPC can be either core-facing or CE-facing.

The VRFs are present on these line cards and currently, in Junos OS, all the routes of all the VRFs are present on all line cards along with chained composite next hops on all the FPCs. This uses up the memory in each line card. Since traffic from CE-facing interfaces comes in only through the corresponding CE-facing FPCs, all the routes and next hops need not be present on all the line cards. VRF localization provides a mechanism for localizing routes of VRF to specific line cards to help maximize the number of routes that a router can handle. CE-facing interfaces localize all the routes of instance type VRF to a specific line card. If CE-facing interfaces are logical interfaces like AE or RLSQ or IRB, then a line card number has to be configured to localize routes. Core-facing line cards store all the VRF routes. These cards have to be configured as VPN core-facing default or VPN core-facing only. Core-facing line cards store routes of all the VRFs, and they are of the following types:

  • vpn-core-facing-default — The core-facing FPC installs all the routes and next hops of the VRF routes.

  • vpn-core-facing-only — The core-facing FPC installs all the routes and does not store next hops of the VRF routes.

Note

Core-facing FPCs can be configured as either core-facing-default or core-facing-only.

Maximizing VPN Routes Using VRF Localization for Layer 3 VPNs

Virtual routing and forwarding (VRF) localization provides a mechanism for localizing routes of VRF to specific line cards to help maximize the number of routes that a router can handle. CE-facing interfaces localize all the routes of instance type VRF to a specific line card. If the CE-facing interfaces are logical interfaces like AE/RLSQ/IRB, then the line card has to be configured to localize routes. Core-facing line cards store all the VRF routes. These cards have to be configured as VPN core-facing only or VPN core-facing default. To configure VRF localization, configure the localized-fib statement at the [edit routing-instances instance-name routing-options] hierarchy level and configure the vpn-localization statement at the [edit chassis fpc fpc-slot] hierarchy level. The show route vpn-localization command displays the localization information of all the VRFs in the system.

Before you begin to localize the VRF table:

  • Configure the interfaces.

  • Configure the routing and signaling protocols.

To configure VRF localization:

  1. Configure the chassis of the router.
    1. Configure the FPC slot as either VPN core-facing only or VPN core-facing default to store the VRF routes.

  2. Configure enhanced IP network service on the chassis.
  3. Create an instance type, configure the route distinguisher, and configure the VRF target community and VRF target label.
  4. Configure the multipath routing option to balance load independent of the protocol.
  5. Configure the specific FPC of CE-facing physical interfaces or specify the FPC slot number if the CE-facing interfaces are logical interfaces like AE or RSQL or IRB to localize the VRF routing instance routes.
    • Configure the specific FPC of CE-facing physical interfaces to localize the VRF routing instance routes.

    • Configure the FPC slot number of the CE-facing logical interfaces like AE or RSQL or IRB to localize the VRF routing instance routes.

  6. Configure the peer group of the BGP protocol for the routing instance.
  7. Configure the MVPN protocol for the routing instance.

Example: Improving Scalability Using VRF Localization for Layer 3 VPNs

This example shows how to configure VRF localization on MX Series routers, which enables you to improve the VPN scalability on MX Series routers.

Requirements

This example uses the following hardware and software components:

  • Five MX Series 5G Universal Routing Platforms

  • Junos OS Release 14.2 or later running on all devices

Before you begin:

  1. Configure the device interfaces.

  2. Configure the BGP protocol.

Overview

Starting with Junos OS Release 14.2, the VRF localization provides a mechanism for localizing routes of VRF to specific line cards which helps maximize the number of routes that a router can handle. CE-facing interfaces localize all the routes of instance type VRF to a specific line card. If the CE-facing interfaces are logical interfaces like AE or RLSQ or IRB, then the line card has to be configured to localize routes. Core-facing line cards store all the VRF routes. These cards have to be configured as VPN core-facing only or VPN core-facing default. To configure VRF localization, configure the localized-fib configuration statement at the [edit routing-instances instance-name routing-options] hierarchy level and configure vpn-localization at the [edit chassis fpc fpc-slot] hierarchy level. The show route vpn-localization command displays the localization information of all the VRFs in the system.

Topology

In the topology shown in Figure 2, VRF localization is configured on Device PE1.

Figure 2: Example VRF Localization
Example VRF Localization

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from the configuration mode.

CE1

PE1

P

PE2

CE2

Configuring Device PE1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure Device PE1:

  1. Specify the number of aggregated Ethernet interfaces to be created, configure the FPCs as vpn-core-facing-only, and enable enhanced IP network services.
  2. Configure the interfaces.
  3. Configure policy options to load balance the packets.
  4. Configure the RSVP protocol on the interface.
  5. Configure the MPLS protocol.
  6. Configure the BGP protocol for the mpbg group.
  7. Configure the OSPF protocol.
  8. Configure the LDP protocol on the interface.
  9. Create an instance type and configure the routing instances on the interface.
  10. Configure the route distinguisher, and configure the static LSP for the provider tunnel RSVP-TE.
  11. Configure the VRF target and the VRF target label for the routing instance.
  12. Configure the multipath routing option for a routing instance, and configure the localized fib routing option for the routing instance.
  13. Configure the group of BGP protocols for a routing instance.
  14. Configure the MVPN protocols.
  15. Configure the nonstop active routing and the autonomous system number for a routing option.
  16. Configure the load-balancing policy for the forwarding table and extended space for the chained composite next hop for the L3VPN of the forwarding table.

Results

From configuration mode, confirm your configuration by entering the show chassis, show interfaces, show policy-options, show protocols, show routing-instances, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying VRF Localization

Purpose

Verify the localization of VRF in a Layer 3 VPN.

Action

From operational mode, run the show route vpn-localization command for Device PE1.

user@PE1> show route vpn-localization

Meaning

The output shows the localization information of all the VRFs.

Verifying VRF Localization for a VPN

Purpose

Verify VRF localization for a VPN.

Action

From operational mode, run the show route vpn-localization vpn-name vpn-name command.

user@PE1> show route vpn-localization vpn-name vpn1

Meaning

The output shows the VPN localization of a VPN.

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.

You can also configure SCU accounting for Layer 3 VPNs configured with the vrf-table-label statement by also including the source-class-usage option. Include the source-class-usage statement at the [edit routing-instances routing-instance-name vrf-table-label] hierarchy level. The source-class-usage statement at this hierarchy level is supported only for the vrf instance type (Layer 3 VPNs). DCU is not supported for the vrf-table-label statement. For more information, see Enabling Source Class and Destination Class Usage.

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 1.

Table 1: Support for Aggregated and VLAN Interfaces

Interfaces

M Series Router Without an Enhanced FPC

M Series Router with an Enhanced FPC

M320 Router

T Series Router

Aggregated

No

Yes

Yes

Yes

VLAN

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

M Series Router Without an Enhanced FPC

M Series Router with an Enhanced FPC

M320 Router

T Series Router

ATM1

No

No

No

No

ATM2 intelligent queuing (IQ)

No

Yes

Yes

Yes

Frame Relay

No

Yes

Yes

Yes

Channelized

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

M Series Router Without an Enhanced FPC

M Series Router with an Enhanced FPC

M320 Router

T Series Router

Ethernet

Yes

Yes

Yes

Yes

SONET/SDH

Yes

Yes

Yes

Yes

T1/T3/E3

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 only available on M120 and M320 routers with Enhanced III FPCs as summarized in Table 4.

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

Interfaces

M120 Routers

with Enhanced III FPCs

M320 Routers

with Enhanced III FPCs

OC12

Yes

Yes

STM4

Yes

Yes

OC3

Yes

Yes

STM1

Yes

Yes

DS3

Yes

Yes

E3

Yes

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 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 5.

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

Interfaces

M Series Router Without an Enhanced FPC

M Series Router with an Enhanced FPC

M320

T Series Router

MX Series Router

MLPPP

No

Yes

No

No

No

End-to-End MLFR (FRF.15)

No

Yes

No

No

No

UNI/NNI MLFR (FRF.16)

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:

  • Firewall filters cannot be applied to interfaces included in a routing instance on which you have configured 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 vrf-table-label statement in a routing instance configuration that also includes a virtual loopback tunnel interface; the commit operation fails in this case.

  • When you include the statement, MPLS packets with label-switched interface (LSI) labels that arrive on core-facing interfaces are not counted at the logical interface level if the core-facing interface is any of the following:

    • ATM

    • Frame Relay

    • Ethernet configured with VLANs

    • Aggregated Ethernet configured with VLANs

  • For LMNR, Stoli, and I-Chip-based Packet Forwarding Engines, 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:

    Note

    The vrf-table-label statement is supported when the PE-router-to-P-router interface is a tunnel interface on a Junos Trio-based Packet Forwarding Engine, so no limitation applies.

    • 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

  • Label-switched interface (LSI) traffic statistics are not supported for Intelligent Queuing 2 (IQ2), Enhanced IQ (IQE), and Enhanced IQ2 (IQ2E) PICs on M Series routers.

Configuring a Label Allocation and Substitution Policy for VPNs

You can control label-advertisements on MPLS ingress and AS border routers (ASBRs). Labels can be assigned on a per–next-hop (by default) or on a per-table basis (by configuring the vrf-table-label statement). This choice affects all routes of a given routing instance. You can also configure a policy to generate labels on a per-route basis by specifying a label allocation policy.

To specify a label allocation policy for the routing instance, configure the label statement and specify a label allocation policy using the allocation option:

You can configure this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name routing-options]

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

Note

The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

To configure the label allocation policy, include the label-allocation statement at the [edit policy-options policy-statement policy-statement-name term term-name then] hierarchy level. You can configure the label allocation mode as either per-nexthop or per-table.

For a VPN option B ASBR, labels for transit routes are substituted for a local virtual tunnel label or vrf-table-label label. When a VRF table is configured on the ASBR (this type of configuration is uncommon for the option B model), the ASBR does not generate MPLS swap or swap and push state for transit routes. Instead, the ASBR re-advertises a local virtual-tunnel or vrf-table-label label and forwards that transit traffic based on IP forwarding tables. The label substitution helps to conserve labels on Juniper Networks routers.

However, this type of label substitution effectively breaks the MPLS forwarding path, which becomes visible when using an MPLS OAM command such as LSP ping. You can configure the way in which labels are substituted on a per-route basis by specifying a label substitution policy.

To specify a label substitution policy for the routing instance, configure the label statement and specify a label substitution policy using the substitution option:

You can configure this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name routing-options]

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

Note

The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

The label substitution policy is used to determine whether or not a label should be substituted on an ASBR router. The results of the policy operation are either accept (label substitution is performed) or reject (label substitution is not performed). The default behavior is accept. The following set command example illustrates how you can configure a reject label substitution policy: set policy-options policy-statement no-label-substitution term default then reject.