Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Color-Based Traffic Engineering Configuration

SUMMARY 

BGP Classful Transport Planes Overview

Benefits of BGP Classful Transport Planes

  • Network-slicing–Service and transport layers are decoupled from each other, laying the foundation for network-slicing and virtualization with the end-to-end slicing across multiple domains, thereby significantly reducing the CAPEX.

  • Inter-domain interoperability–Extends transport class deployment across co-operating domains so the different transport signaling protocols in each domain interoperate. Reconciles any differences between extended community namespaces that may be in use in each domain.
  • Colored resolution with fallback–Enables resolution over colored tunnels (RSVP, IS-IS flexible algorithm) with flexible fallback options over best-effort tunnels or any other color tunnel.

  • Quality-of-service–Customizes and optimizes the network to achieve the end-to-end SLA requirements.
  • Leveraging existing deployments–Supports well deployed tunneling protocols like RSVP along with new protocols, such as IS-IS flexible algorithm, preserving ROI and reducing OPEX.

Terminology of BGP Classful Transport Planes

This section provides a summary of commonly used terms for understanding BGP classful transport plane.

  • Service node–Ingress Provider Edge (PE) devices that send and receive service routes (Internet and Layer 3 VPN).

  • Border node–Device at the connection point of different domains (IGP areas or ASs).

  • Transport node–Device that sends and receives BGP-Labeled Unicast (LU) routes.

  • BGP-VPN–VPNs built using RFC4364 mechanisms.

  • Route Target (RT)–Type of extended community used to define VPN membership.

  • Route Distinguisher (RD)–Identifier used to distinguish to which VPN or virtual private LAN service (VPLS) a route belongs. Each routing instance must have a unique route distinguisher associated with it.

  • Resolution scheme–Used to resolve protocol next-hop address (PNH) in resolution RIBs providing fallback.

    They map the routes to the different transport RIBs in the system based on mapping community.

  • Service family–BGP address family used for advertising routes for data traffic, as opposed to tunnels.

  • Transport family –BGP address family used for advertising tunnels, which are in turn used by service routes for resolution.

  • Transport tunnel–A tunnel over which a service may place traffic, for example, GRE, UDP, LDP, RSVP, SR-TE, BGP-LU.

  • Tunnel domain–A domain of the network containing service nodes and border nodes under a single administrative control that has a tunnel between them. An end-to-end tunnel spanning several adjacent tunnel domains can be created by stitching the nodes together using labels.

  • Transport class–A group of transport tunnels offering the same type of service.

  • Transport class RT–A new format of route target used to identify a specific transport class.

    A new format of Route Target used to identify a specific transport class.
  • Transport RIB–At the service node and border node, a transport class has an associted transport RIB that holds its tunnel routes.

  • Transport RTI–A routing instance; container of transport RIB, and associated transport class Route Target and Route Distinguisher.

  • Transport plane–Set of transport RTIs importing same transport class RT. These are in turn stitched together to span across tunnel domain boundaries using a mechanism similar to Inter-AS option-b to swap labels at border nodes (nexthop-self), forming an end-to-end transport plane.

  • Mapping community–Community on a service route that maps to resolve over a transport class.

Understanding BGP Classful Transport Planes

You can use BGP classful transport planes to configure transport classes for classifying a set of transport tunnels in an intra-AS network based on the traffic engineering characteristics and use these transport tunnels to map service routes with the desired SLA and intended fallback.

BGP classful transport planes can extend these tunnels to inter-domain networks that span across multiple domains (ASs or IGP areas) while preserving the transport class. To do this, you must configure the BGP classful trasport transport layer BGP family between the border and service nodes.

In both inter-AS and intra-AS implementations, there can be many transport tunnels (MPLS LSPs, IS-IS flexible algorithm, SR-TE) created from the service and border nodes. The LSPs may be signaled using different signaling protocols in different domains, and can be configured with different traffic engineering characteristics (class or color). The transport tunnel endpoint also acts as the service endpoint and can be present in the same tunnel domain as the service ingress node, or in an adjacent or non-adjacent domain. You can use BGP classful transport planes to resove services over LSPs with certain traffic engineering charateristics either inside a single domain or across multiple domains.

BGP classful transport planes reuse the BGP-VPN technology, keeping the tunneling-domains loosely coupled and coordinated.

  • The network layer reachability information (NLRI) is RD:TunnelEndpoint used for path-hiding.
  • The route target indicates the transport class of the LSPs, and leaks routes to the corresponding transport RIB on the destination device.
  • Every transport tunneling protocol installs an ingress route into the transport-class.inet.3 routing table, models the tunnel transport class as a VPN route target, and collects the LSPs of the same transport class in the transport-class.inet.3 transport-rib routing table.
  • Routes in this routing instance are advertised in the BGP classful transport plane (inet transport) AFI-SAFI following procedures similar to RFC-4364.

  • When crossing inter-AS link boundary, you must follow Option-b procedures to stitch the transport tunnels in these adjacent domains.

    Similarly, when crossing intra-AS regions you must follow Option-b procedures to stitch the transport tunnels in the different TE-domains.

  • You can define resolution schemes to specify the intent on the variety of transport classes in a fallback order.

  • You can resolve service routes and BGP classful transport routes over these transport classes, by carrrying the mapping community on them.

The BGP classful transport family runs along side the BGP-LU transport layer family. In a seamless MPLS network running BGP-LU, meeting stringent SLA requirements of 5G is a challenge as the traffic engineering characteristics of the tunnels are not known or preserved across domain boundaries. BGP classful transport planes provide operationally easy and scalable means to advertise multiple paths for remote loopbacks along with the transport class information in the seamless MPLS architecture. In BGP classful tranport family routes, different SLA paths are represented using Transport Route-Target extended community, which carries the transport class color. This Transport Route-Target is used by the receiving BGP routers to associate the BGP classful transport route with the appropriate transport class. When re-advertising the BGP classful transport routes, MPLS swaps routes, inter connect the intra-AS tunnels of the same transport class, thereby forming an end-to-end tunnel that preserves the transport class.

Intra-AS Implementation of BGP Classful Transport Planes

Figure 1 illustrates a network topology with before-and-after scenarios of implementing BGP classful transport planes in an intra-AS domain. Devices PE11 and PE12 use RSVP LSPs as the transport tunnel and all transport tunnel routes are installed in inet.3 RIB. Implementing BGP classful transort planes enables RSVP transport tunnels to be color-aware similar to segment routing tunnels.

Figure 1: Intra-AS Domain: Before-and-After Scenarios For BGP Classful Transport Planes ImplementationIntra-AS Domain: Before-and-After Scenarios For BGP Classful Transport Planes ImplementationIntra-AS Domain: Before-and-After Scenarios For BGP Classful Transport Planes Implementation

To classify transport tunnels into BGP transport class in an intra-AS setup:

  1. Define the transport class at the service node (ingress PE devices), for example, gold and bronze, and assign color community values to the defined transport class.

    Sample configuration:

  2. Associate the transport tunnel to a specific transport class at the ingress node of the tunnels.

    Sample configuration:

Intra-AS BGP classful transport plane functionality:

  • BGP classful transport creates predefined transport RIBs per named transport class (gold and bronze) and auto derives mapping community from its color value (100 and 200).
  • Intra-AS transport routes are populated in transport RIBs by the tunneling protocol when it is associated with a transport class.

    In this example, RSVP LSP routes associated with transport class gold (color 100) and transport class bronze (color 200) are installed in the transport RIBs junos-rti-tc-<100>.inet.3 and junos-rti-tc-<200>.inet.3, respectively.

  • Service node (ingress PEs) match extended color community (color:0:100 and color:0:200) of service route against the mapping community in predefined resolution RIBs and resolve the protocol next hop (PNH) in corresponding transport RIBs (either junos-rti-tc-<100>.inet.3, or junos-rti-tc-<200>.inet.3).
  • BGP routes bind to a resolution scheme by carrying the assiocaited mapping community.
  • Each transport class automatically creates two predefined resolution schemes and automatically derives the mapping community.

    One resolution scheme is for resolving service routes that use Color:0:<val> as the mapping community.

    The other resolution scheme is for resolving transport routes that use Transport-Target:0:<val> as the mapping community.

  • If service route PNH cannot be resolved using RIBs listed in the predefined resolution scheme, then it can fall back to the inet.3 routing table.
  • You can also configure fallback between different colored transport RIBs by using user-defined resolution schemes under the [edit routing-options resolution scheme] configuration hierarchy.

Inter-AS Implementation of BGP Classful Transport Planes

In an inter-AS network, BGP-LU is converted to BGP classful transport network after configuring a minimum of two transport classes (gold and bronze) on all service nodes or PE devices and border nodes (ABRs and ASBRs).

To convert the transport tunnels into BGP classful transport:

  1. Define transport class at the service nodes (ingress PE devices) and the border nodes (ABRs and ASBRs), for example, gold and broze.

    Sample configuration:

  2. Associate the transport tunnels to a specific transport class at the ingress node of the tunnels (ingress PEs, ABRs,and ASBRs).

    Sample configuration:

    For RSVP LSPs

    For IS-IS flxible algorithm

  3. Enable new family for the BGP classful transport (inet transport) and BGP-LU (inet labeled-unicast) in the network.

    Sample configuration:

  4. Advertise service routes from the egress PE device with appropriate extended color community.

    Sample configuration:

Inter-AS BGP classful transport plane functionality:

  1. BGP classful transport planes create predefined transport RIBs per named transport class (gold and bronze) and automatically derives mapping community from its color value.
  2. Intra-AS transport routes are populated in transport RIBs by tunneling protocols when associated with a transport class.

    For example, transport tunnel routes associated with the transport class gold and bronze are installed in the transport RIBs junos-rti-tc-<100>.inet.3 and junos-rti-tc-<200>.inet.3, respectively.

  3. BGP classful transport planes use unique Route Distinguisher and Route Target when it copies the transport tunnel routes from each transport RIB to the bgp.transport.3 routing table.
  4. Border nodes advertise routes from bgp.transport.3 routing table to its peers in other domains if family inet transport is negotiated in the BGP session.
  5. Receiving border node installs these bgp-ct routes in the bgp.transport.3 routing table and copies these routes based on the transport Route Target to the appropriate transport RIBs.
  6. Service node matches the color community in the service route against a mapping community in the resolution schemes and resolves PNH in the corresponding transport RIB (either junos-rti-tc-<100>.inet.3, or junos-rti-tc-<200>.inet.3).
  7. Border nodes use predefined resolution schemes for transport route PNH resolution.
  8. Predefined or user defined, both resolution schemes support service route PNH resolution. Predefined uses inet.3 as fallback, and user-defined resolution scheme allows list of transport RIBs to be used in the order specified while resolving PNH.
  9. If service route PNH cannot be resolved using RIBs listed in the user-defined resolution scheme, then route is discarded.

BGP Classful Transport (BGP-CT) with Underlying Colored SR-TE Tunnels Overview

Benefits of BGP-CT with underlying colored SR-TE Tunnels

  • Solves scale concerns that may arise in the future as the network grows.
  • Provides inter-connectivity for domains that use different technologies.
  • Decouples services and the transport layers resulting in a completely distributed network.
  • Provides independent bandwidth management through an intra-domain traffic engineering controller for SR-TE.

Large networks that are growing and evolving continuously require a seamless segment routing architecture. Starting in Junos OS Release 21.2,R1 we support BGP-CT with underlying transport as colored SR-TE tunnels. BGP-CT can resolve service routes using the transport RIBs and compute the next hop. Services that are currently supported over BGP-CT can also use the underlying SR-TE colored tunnels for route resolution. The services can now use the underlying SR-TE colored tunnels such as the static colored, BGP SR-TE, programmable rpd and PCEP colored tunnels. BGP-CT uses the next-hop reachability to resolve service routes over the desired transport class.

To enable BGP-CT service route resolution over underlying SR-TE colored tunnels, include the use-transport-class statement at the [edit protocols source-packet-routing] hierarchy level.

Note:
  1. Enable the use-transport-class statement

    at the [edit protocols source-packet-routing] hierarchy level.

    along with the auto-create statement at the [edit routing-options transport-class] hierarchy level.
  2. We don't support RIB groups for colored SR-TE with use-transport-class and color-only SR-TE tunnels with this feature.

Example: Configuring Classful Transport Planes (Intra-Domain)

Before You Begin

Hardware and Software requirements

Junos OS Release 21.1R1 or later.

Note:

Only the provider edge routers (PE1 and PE2) require Junos OS Release support for the BGP-CT feature.

Estimated reading time

45 minutes

Estimated configuration time

1 hour

What to expect?

A working BGP-CT network with three service levels that map to diversely routed LSP paths. A Junos configuration that maps specific traffic (VPN customer routes) to the desired transport class using BGP color attribute extended communities. Basic LSP traffic engineering to force traffic classes on to diverse paths in the provider network

Business impact

Use this configuration example to configure and verify the BGP Classful Transport (BGP-CT) feature within a single autonomous network (intra-domain). BGP-CT maps customer routes to network paths that can be engineered to provide varying levels of performance. A typical use case for intra-domain BGP-CT is for a service provider to deploy BGP-CT to offer tiered VPN service levels to their customers.

Useful resources:

Know more

To better understand BGP-CT, see BGP Classful Transport Planes Overview

Juniper vLabs

Visit the Juniper virtual labs (vLabs) to reserve a pre-configured sandbox. Use the sandbox to interact with and understand the BGP-CT feature. You'll find the "Classful Transport Planes (Intra-Domain Scenario)" demonstration in the routing section .

Learn more

Junos Class of Service (JCOS) On-Demand

Functional Overview

Table 1 provides a quick summary of the configuration components deployed in this example.

Table 1: Classful Transport Planes Functional Overview

Routing and Signaling protocols

OSPF

All routers run OSPF as the IGP. All routers belong to area 0 (also called the backbone area). The single OSPF routing domain provides loopback connectivity in the provider network.

Internal and External BGP

The customer edge (CE) devices use EBGP peering to exchange routes with their provider edge device as part of a Layer 3 VPN service.

The PE devices use IBGP to exchange IPv4 Layer 3 VPN routes with the remote PE. These routes also carry a color community used to map traffic to the correct data plane tunnel. Our example does not use a route reflector, instead opting for direct PE-PE peering.

Note:

The provider router (P router) does not run BGP. Its part of a BGP-free core to promote scaling. The P device uses MPLS label based switching to transport the customer VPN traffic between the PE devices.

RSVP

Each PE devices signals three LSPs to the remote PE. These LSPs map to the corresponding service classes of gold, bronze, and Best-Effort (BE).

RSVP supports rich traffic engineering to force traffic onto desired paths in the provider network. These paths can in turn be engineered to provide varying Class of Service (CoS) handling need to enforce the SLA for each transport class.

Our basic topology provides three paths between the PE devices. We use a named path with an ERO to ensure diverse routing of the LSPs over the core. Junos supports a rich set of capabilities for traffic engineering. For details see MPLS Traffic Engineering Configuration

Note:

The classful transport feature is also supported with LSPs established through segment routing–traffic engineering (SR-TE) and IS-IS flex-algorithm tunnels.

MPLS

The provider network uses a MPLS based label switching data plane. The use of MPLS with TE paths ensures that each service class can be routed over disjoint paths with the desired performance levels. As noted above, MPLS also provides support for a BGP-free core.

Transport tunnels

Three MPLS tunnels (LSPs) are established between the PE devices:

Each tunnel is assigned to the following transport classes:

  • Gold

  • Bronze

  • Best-effort

    This is the default transport class. This class provides best-effort (BE) level service. Customers that are not mapped to any specific transport class, or those that are mapped to a transport class that is down, default to the BE service class and the associated LSP path.

Service family

Layer 3 VPN (family inet-vpn unicast

BGP-CT also works with other service families, such as BGP labeled Unicast, Flowspec, or Layer 2 VPN.

Primary verification tasks
  • Confirm overall network operation.
Verify working of IGP, RSVP, MPLS, BGP, and L3VPN.
  • Verify mapping of Layer 3 VPN customer traffic to a transport class.

Modify the network to effect traffic steering between transport class tunnels to simulate the failure of a service tunnel and subsequent fail over to the BE path/class.

Topology Overview

This configuration example is based on a simple MPLS-Based Layer 3 VPN with two customer edge (CE) devices that communicate over the service provider network. The network core has three provider (P) routers that transport the VPN customer traffic using labeled-based switching. The two provider edge (PE) devices provide a Layer 3 VPN service to their attached CEs. The PEs use RSVP signaled MPLS LSPs to transport VPN traffic over the core. See Example: Configure a Basic MPLS-Based Layer 3 VPN for background information on the operation and configuration of a MPLS-based L3VPN.

We focus on the left to right flow of traffic from CE1 to CE2, and how PE1 uses a BGP color community attached to routes learned from PE2 to map traffic sent to the remote CE over the desired LSP forwarding next hops. In our example, PE1 uses explicit route objects (ERO) to force the routing of these LSPs over diverse paths. We skip this step at PE2, allowing the LSPs to be routed based on IGP load balancing. In order to have traffic flow from CE1 to CE2, CE1 must have a route to reach CE2. The routes for CE2 travel in the opposite direction of the traffic it attracts from CE1. That is, the route to CE2's loopback travels from right to left.

In our example, the gold service class LSP is constrained to the PE1-P1-PE2 path. The bronze service class uses the PE1-P2-PE2 path. The best-effort LSP is routed along the PE1-P3-PE2 path. The topology diagram uses colored links to represent the three paths.

In our example, we add the protocols mpls icmp-tunneling statement. This is to allow the CE devices to trace the path through the provider network, even when that path involves MPLS switching as is the case for the Layer 3 VPN traffic. This option helps you confirm the expected forwarding path as a function of transport class is used.

Table 2 describes the role and functionality of each device in the context of this topology. Click on any device name to view its quick configuration.

Table 2: Intra-Domain Classful Transport Planes Topology Overview
Device Name

Role

Function
CE1 Local CE device (R1) . EBGP peer to PE1 router to advertise and learn CE device loopback addresses. Test service connectivity with pings to the loopback address of CE2.
CE2 Remote CE device (R7) EBGP peering to PE2 router to advertise and learn CE device loopback addresses.

Configures and attaches the color mapping community.

PE1 (DUT) local PE device (R2). PE1 maps the color tagged service routes that originate at CE2 to a cosponsoring transport class (TC). PE1 receives the color tags routes over its IBGP session to PE2.

In this example PE1 uses ERO based constraints to force diverse routing of its three LSPs over the provider's core.

PE2 Remote PE device (R6). PE2 re-advertises the color tagged routes received by CE2 to PE1 using IBGP. These routes uses the inet-vpn family to support a Layer 3 VPN services with color mapped TCs.
P1 P2 P3 Provider devices P1, P2, and P3 (R3, R4, and R5). The P1-P3 devices represent the service provider's core network. These are pure transit devices that perform MPLS label switching to transport the CE traffic sent over the L3 VPN.

Topology Illustrations

Figure 2: Service Mapping Using Classful Transport Planes Within a Network DomainService Mapping Using Classful Transport Planes Within a Network Domain

PE1 Configuration Steps

For information about navigating the CLI, see Using the CLI Editor in Configuration Mode

This section highlights the main configuration tasks needed to configure the PE1 device for this example. The first step is common to configuring a basic Layer 3 VPN service. The following set of steps are specific to adding the BGP-CT feature to your Layer 3 VPN. Both PE devices have a similar configuration, here we focus on PE1.

  1. First, provision the general Layer 3 VPN:

    1. Configure and number the loopback, core facing, and CE-facing interfaces for IPv4. Be sure to enable the mpls family on the core-facing interfaces connecting to the P devices to support MPLS switching.

    2. Configure an autonomous system number.

    3. Configure single area OSPF on the loopback and core-facing interfaces.

    4. Configure RSVP on the loopback and core-facing interfaces.

    5. Configure the IBGP peering session to the remote PE device, PE2. Include the inet-vpn address family to support an IPv4 Layer 3 VPN.

    6. Configure a VRF based routing-instance for the CE1 device. Use EBGP as the PE-CE routing protocol.

  2. Add classful transport planes to the Layer 3 VPN.

    Configure the gold and bronze transport-classes.

    This is a critical step in configuring the classful transport feature. These transport classes are mapped to RSVP signaled (and possibly traffic engineered) LSPs that traverse the provider core. The remote routes learned from CE2 are tagged with color communities that map to these transport classes, and in so doing, to the desired LSP between the PE devices.

  3. Configure three LSPs from PE1 to PE2 with constrained routing that forces each to traverse a different P router. Two of these LSPs map to the gold and bronze transport-classes. The gold LSP is routed through P1, the bronze through P2, and the best-effort through the P3 device.

    Once mapped to transport classes the service provider is able to place specific customer traffic, as indicated by a BGP color community, onto a specific LSP. With this color to LSP mapping the service provider can offer a tiered service with different SLAs.

    In our example we use a strict ERO to ensure the three LSPs are diversely routed over the three paths available in the topology.

  4. To facilitate fallback to the default service class (best-effort) tunnel, we configure the gold and bronze transport class tunnels with a lower global preference. In this example the preference value is changed from the default 7 to 5. This allows the use of the best-effort tunnel as a fallback in the event the gold or bronze tunnels become unusable. Setting a lower (more preferred) preference on the gold and bronze tunnels ensures they are selected for forwarding, even though the service route is able to resolve to the best-effort tunnel.

    Note:

    This section focused on the configuration needed on the PE1 device. It should be noted that for theclassful transport next-hop selection function to work at PE1, the remote CE2 device routes must be tagged with a color community. This tagging can occur on the remote PE2 device, or on the remote CE2 device. We show the latter approach here for completeness:

  5. Match the color community tags added at the remote CE2 to the transport class definitions for the bronze and gold TCs.

Verify Classful Transport Planes

Note:

In this section we focus on commands that demonstrate a working classful transport feature. See Appendix 1: Troubleshooting for commands used to verify the underlying functionality needed by the classful transport feature.

You'll use these commands to verify BGP classful transport works correctly.

Table 3: Classful Transport Planes Verification Commands
Command

Verification Task

show routing transport-class Verify transport classes and their associated attributes. This includes the mapping community and routing instance..
show route resolution scheme Display how service class routes are resolved to LSP next hops. Verify the resolution routing tables for a specific route.
show route receiving-protocol bgp pe2-loopback-address Verify that the VPN routes received by PE1 have a BGP color community attached.
show route and show route forwarding-table vpn vpn Verify transport tunnel selection by viewing the protocol nexthop (PNH) for the routes at PE1.
show mpls lsp statistics and show route forwarding-table Verify the transport tunnel used by a specific transport class route.

Verify Transport Classes and Transport Tunnels

Purpose

PE1 and PE2 use RSVP-signaled MPLS transport tunnels to support a Layer 3 VPN service that is capable of offering differentiated service levels. These service routes have their next hops resolved to a specific MPLS tunnel based on the corresponding service class. The service class is signaled by attaching a BGP color community to VPN customer routes.

In this part you confirm that all three of PE1's LSPs are operational, that they are mapped to the correct transport class, and that they are correctly routed over the provider's core.

Action

From operational mode, enter the show route 192.168.0.2 command.

Meaning

The output confirms that PE1 has learned three paths to the loopback of PE2 through OSPF. These routes are in the inet.0 table. You also note that all three LSPs are represented as viable next hops to reach PE2. Note that each of these LSPs is housed in a different routing table. The highlighted portion of the IP next hops (and the corresponding interface name) confirms the desired diverse LSP routing over the core. Traffic mapped to the gold path is sent to 10.1.23.2, while traffic for bronze and BE is sent to 10.1.24.2 and 10.1.25.2, respectively.

The following transport RIBs and transport tunnels are created.

  • junos-rti-tc-100.inet.3 for gold_lsp_to_pe2

  • junos-rti-tc-200.inet.3 for bronze_lsp_to_pe2

  • inet.3 for lsp_to_pe2

Verify Next Hop Resolution Schemes

Purpose

Verify the service routes resolution schemes, the associated mapping community, and how the next hop resolves over the contributing routing tables.

Action

From operational mode, enter the show route resolution scheme all command.

Meaning

Focusing on the IPv4 portions of the output, you see the junos-tc-100 (gold) transport class has two resolution schemes - junos-resol-schem-tc-100-v4-service and junos-resol-schem-tc-100-v4-transport – used for the service and transport routes, respectively.

The resolution scheme for gold service routes (junos-resol-schem-tc-100-v4-service) provides resolution over both the junos-rti-tc-100.inet.3 and the inet.3 routing tables (highlighted in the sample output). Listing both the service and BE resolution tables is how fallback occurs when the service class is down. Recall this is why we altered the preference value of the service LSPs (setting the preference to 5 rather than the default 7), to ensure the service route is always preferred over the BE fallback.

Verify Color Tagging and Next Hop Selection for CE2 Routes

Purpose

Confirm that PE2 advertises the loopback route for CE2 with a color community that selects the bronze service class (color 200).

Note:

In our example we configure the CE2 device to attach the color community. PE2 leaves this community in place when it re-advertises the route to PE1. This means the VPN customer is able to effect their own service class mappings. When desired the PE router can bleach or strip out any communities received from the CE. In this case the PE device needs to be configured to attach the desired color mapping community to CE routes before it re advertises them to PE1.

Action

From operational mode, enter the show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail command.

Display the forwarding table entry for the CE2 loopback in the VPN routing instance at PE1. Confirm the forwarding next hop matches the desired transport class (bronze). Use the show route forwarding-table vpn CE1_L3vpn destination 172.16.255.2 extensive command.

Meaning

The highlighted entries confirm traffic matching the CE2 loopback route is sent to 10.1.24.2 using the ge-0/0/2 interface. Recall from the EROs used for the LSPs, this interface and next hop is associated with the bronze LSP and transport class. The 299808 label is used to identify the service VRF. The outer RSVP transport label is 299872.

You quickly confirm this is the correct RSVP transport label for the bronze class with a show rsvp session detail name bronze_lsp_to_pe2 command

The highlighted portions call out that the bronze LSP is routed through the P2 device and is associated with the indicated RSVP transport label (299856) you previously confirmed in the VPN forwarding table for the CE2 loopback address.

Verify End-to-End Connectivity

Purpose

Verify end-to-end connectivity across the provider’s domain by pinging between CE1 to CE2. You examine MPLS traffic statistics to provide additional confirmation that the bronze transport class is used.

Action

From operational mode, enter the ping command.

From operational mode at PE1, enter the show mpls lsp statistics command.

Action

Trace the route from CE1 to CE2's loopback. Our configuration includes the icmp-tunneling statement to support an ICMP based trace route with MPLS hops in the provider core.

Meaning

The ping exchange is successful and the statistics confirm use of the bronze transport tunnel. This is expected given the route to CE2 has the 200 color community attached. The trace route results confirm the traffic is forwarded over a LSP, and that this LSP is forwarding through 10.1.24.2. This is the IP address assigned to the P2 device. The forwarding next hop and outer label value confirm this traffic is sent on the bronze service class LSP.

Confirm Fail Over to Best-Effort

Purpose

Bring the bronze transport LSP down to verify that the traffic sent to CE2 fails over to the BE path.

Action

Enter configuration mode and specify an invalid next hop as an ERO for the bronze transport tunnel. The inability to satisfy the ERO requirement brings the related LSP down.

Once the change is committed the bronze tunnel is shown down:

Repeat the ping and trace route commands from CE1 to CE2's loopback.

Again display MPLS statistics on PE1.

Meaning

The ping exchange still succeeds, albeit now on a best-effort path. On the PE the statistics confirm use of the best-effort transport tunnel. The trace route shows that PE1 now forwards to the 10.1.25.2 next hop through PE3. This confirms fail over from a colored transport class to the best-effort class in the event of transport tunnel failure.

Note:

In this section we effected fail over to the BE class by bringing down the LSP mapped to the bronze service class. As an alternative, consider changing the EBGP export policy on the CE2 device to have it attach the gold (100) color community. With this approach you expect to see ping traffic from CE1 to CE2 taking the gold LSP rather than failing over to BE. The below does the trick at CE2 if you prefer this approach. Be sure to commit the changes at CE2.

Appendix 1: Troubleshooting

Our verification section is based on an assumption that you have a working network, allowing the focus to be placed on confirming the operation of BGP-CT. The BGP-CT feature, in a MPLS-based Layer 3 VPN context, is dependent on a network with working interfaces, IGP, RSVP, MPLS, and BGP.

Table 4 provides guidance on what to look for if your BGP-CT solution is not working as expected. The table is structured from the bottom to the top, starting with basic interface connectivity and ending with successful BGP route exchange between the PE devices.

Note:

As part of this example you configure a loopback address and router ID. If the device previously had a different RID it can take some time for things to stabilize. Changing the RID is very disruptive and not something that happens often. When in a lab environment its suggested that you issue the restart routing operational mode command on all devices right after committing the new RID.

Table 4: Troubleshooting Steps
Functional Layer

Verification Approach

Interfaces and IP addressing Verify that all interfaces in your topology are operationally up. Verify you can ping both the local and remote end of each link. Like most networks, the protocols and services in this example require a working IPv4 infrastructure.
root@PE1> show interfaces terse | match "(ge-0/0/0|ge-0/0/1|ge-0/0/2|ge-0/0/3)" 
ge-0/0/0                up    up
ge-0/0/0.0              up    up   inet     172.16.1.2/30   
ge-0/0/1                up    up
ge-0/0/1.0              up    up   inet     10.1.23.1/24    
ge-0/0/2                up    up
ge-0/0/2.0              up    up   inet     10.1.24.1/24    
ge-0/0/3                up    up
ge-0/0/3.0              up    up   inet     10.1.25.1/24    

root@PE1> ping 10.1.23.2 count 1    
PING 10.1.23.2 (10.1.23.2): 56 data bytes
64 bytes from 10.1.23.2: icmp_seq=0 ttl=64 time=2.951 ms

--- 10.1.23.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.951/2.951/2.951/0.000 ms
          
root@PE1> ping 172.16.1.1 routing-instance CE1_L3vpn count 1 
PING 172.16.1.1 (172.16.1.1): 56 data bytes
64 bytes from 172.16.1.1: icmp_seq=0 ttl=64 time=2.755 ms

--- 172.16.1.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.755/2.755/2.755/0.000 ms
OSPF (IGP) Routing Confirm all provider devices have all expected OSPF adjacencies. Use the show ospf interfaces and show ospf neighbors operational mode commands. Display the routes for the provider loopback addresses and confirm valid OSPF paths for all remote loopback addresses (show route protocol ospf | match 192.168.0). Ping from the local loopback to the remote loopback addresses of all provider routers.

This example uses CSPF based LSPs. This requires that OSPF be configured with the traffic-engieering statement. If IS-IS is used as the IGP this statement is not needed.

root@PE1> show ospf interface 
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-0/0/1.0          BDR     0.0.0.0         192.168.0.11    192.168.0.1        1
ge-0/0/2.0          BDR     0.0.0.0         192.168.0.12    192.168.0.1        1
ge-0/0/3.0          DR      0.0.0.0         192.168.0.1     192.168.0.13       1
lo0.0               DRother 0.0.0.0         0.0.0.0         0.0.0.0            0

root@PE1> show ospf neighbor 
Address          Interface              State           ID               Pri  Dead
10.1.23.2        ge-0/0/1.0             Full            192.168.0.11     128    34
10.1.24.2        ge-0/0/2.0             Full            192.168.0.12     128    32
10.1.25.2        ge-0/0/3.0             Full            192.168.0.13     128    37

root@PE1> show route protocol ospf| match 192.168.0 
192.168.0.2/32     *[OSPF/10] 00:10:15, metric 2
192.168.0.11/32    *[OSPF/10] 00:18:40, metric 1
192.168.0.12/32    *[OSPF/10] 00:18:35, metric 1
192.168.0.13/32    *[OSPF/10] 00:10:15, metric 1
root@PE1> ping 192.168.0.2 source 192.168.0.1 count 1 
PING 192.168.0.2 (192.168.0.2): 56 data bytes
64 bytes from 192.168.0.2: icmp_seq=0 ttl=63 time=3.045 ms

--- 192.168.0.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.045/3.045/3.045/0.000 ms
MPLS and RSVP Verify all core interfaces are enabled for the mpls family. with a show interfaces terse command. Also verify that all provider interfaces are enabled under the protocols mpls and protocols RSVP hierarchies. Use the show mpls interfaces and show rsvp interfaces commands.
Note:

Be sure to confirm that the correct interface unit numbers are listed for the MPLS family and for each protocol. This example uses unit 0, which is the default unit number, on all interfaces.

root@PE1> show rsvp interface 
RSVP interface: 4 active
                          Active  Subscr- Static      Available   Reserved    Highwater
Interface          State  resv    iption  BW          BW          BW          mark
ge-0/0/1.0             Up       1   100%  1000Mbps    1000Mbps    0bps        0bps       
ge-0/0/2.0             Up       1   100%  1000Mbps    1000Mbps    0bps        0bps       
ge-0/0/3.0             Up       1   100%  1000Mbps    1000Mbps    0bps        0bps       
lo0.0                  Up       0   100%  0bps        0bps        0bps        0bps       

root@PE1> show mpls interface 
Interface        State       Administrative groups (x: extended)
ge-0/0/1.0       Up         <none>
ge-0/0/2.0       Up         <none>
ge-0/0/3.0       Up         <none>

On the PE routers confirm that the LSPs are correctly defined to egress at the remote PE device's loopback address. Verify the EROs and any other TE constraints are valid. Use the show mpls lsp and show rsvp session commands.

Note: Our examples uses CSPF based LSPs. This requires that the IGP supports a TE database (TED). If OSPF is the IGP be sure to include the traffic-engieering configuration statement. Alternatively, consider using the no-cspf statement in the LSP definition to remove CSPF from the equation.
root@PE1> show mpls lsp 
Ingress LSP: 3 sessions
To              From            State Rt P     ActivePath       LSPname
192.168.0.2     192.168.0.1     Up     0 *     bronze           bronze_lsp_to_pe2
192.168.0.2     192.168.0.1     Up     0 *     gold             gold_lsp_to_pe2
192.168.0.2     192.168.0.1     Up     0 *     best-effort      lsp_to_pe2
Total 3 displayed, Up 3, Down 0

Egress LSP: 3 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
192.168.0.1     192.168.0.2     Up       0  1 FF       3        - bronze_lsp_to_pe1
192.168.0.1     192.168.0.2     Up       0  1 FF       3        - gold_lsp_to_pe1
192.168.0.1     192.168.0.2     Up       0  1 FF       3        - lsp_to_pe1
Total 3 displayed, Up 3, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
BGP Use the show bgp summarycommand on the PE devices to confirm both their EBGP session to the CE, and the IBGP session to the remote PE are established. If BGP is down despite being able to ping, suspect bad peer definition. Recall that loopback peering (for IBGP) requires the local-address statement. For EBGP specify directly connected next hops and confirm the local AS number, under edit routing-options and the remote AS number, under the EBGP peer group, are specified.

Confirm the PE-PE session has the inet-vpn unicast family enabled. Use the show route command to confirm receipt of the remote CE route on the local PE. Use the detail switch to confirm proper color community attachment.

root@PE1> show bgp summary 
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0               
                       0          0          0          0          0          0
bgp.l3vpn.0          
                       2          2          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.1.1            64510         55         55       0       0       23:13 Establ
  CE1_L3vpn.inet.0: 1/2/2/0
192.168.0.2           65412         57         56       0       0       23:11 Establ
  inet.0: 0/0/0/0
  bgp.l3vpn.0: 2/2/2/0
  CE1_L3vpn.inet.0: 2/2/2/0

The show route advertising and receiving protocol commands are useful when confirming what routes a given BGP speaker advertises or receives, respectively.

root@PE1> show route advertising-protocol bgp 192.168.0.2 

CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.1.0/30           Self                         100        I
* 172.16.255.1/32         Self                         100        64510 I

root@PE1> show route receive-protocol bgp 192.168.0.2 

inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.2.0/30           192.168.0.2                  100        I
* 172.16.255.2/32         192.168.0.2                  100        64520 I

junos-rti-tc-100.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

junos-rti-tc-200.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  192.168.0.2:12:172.16.2.0/30                    
*                         192.168.0.2                  100        I
  192.168.0.2:12:172.16.255.2/32                    
*                         192.168.0.2                  100        64520 I
Layer 3 VPN Ensure that the IBGP session supports family inet-vpn routes. Confirm the routes advertised by remote PE are imported into the correct instance based on the route target. Ensure the import and export policy used in the routing instance of each PE match on and advertise the correct routes. Some of the displays in the BGP verification section confirm the receipt of remote CE routes and the importation of those routes into the VRF instance.
root@PE1> show bgp neighbor 192.168.0.2 | match nlri      
  NLRI for restart configured on peer: inet-unicast inet-vpn-unicast
  NLRI advertised by peer: inet-unicast inet-vpn-unicast
  NLRI for this session: inet-unicast inet-vpn-unicast
root@PE1> show route table CE1_L3vpn.inet      

root@PE1> show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail 
. . . 
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
* 172.16.255.2/32 (1 entry, 1 announced)
     Import Accepted
     Route Distinguisher: 192.168.0.2:12
     VPN Label: 299776
     Nexthop: 192.168.0.2
     Localpref: 100
     AS path: 64520 I 
     Communities: target:65412:12 color:0:200

root@PE1> show route table CE1_L3vpn.inet      

CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.0/30      *[Direct/0] 00:30:11
                    >  via ge-0/0/0.0
                    [BGP/170] 00:29:57, localpref 100
                      AS path: 64510 I, validation-state: unverified
                    >  to 172.16.1.1 via ge-0/0/0.0
172.16.1.2/32      *[Local/0] 00:30:11
                       Local via ge-0/0/0.0
172.16.2.0/30      *[BGP/170] 00:21:26, localpref 100, from 192.168.0.2
                      AS path: I, validation-state: unverified
                    >  to 10.1.25.2 via ge-0/0/3.0, label-switched-path lsp_to_pe2
172.16.255.1/32    *[BGP/170] 00:29:57, localpref 100
                      AS path: 64510 I, validation-state: unverified
                    >  to 172.16.1.1 via ge-0/0/0.0
172.16.255.2/32    *[BGP/170] 00:29:40, localpref 100, from 192.168.0.2
                      AS path: 64520 I, validation-state: unverified
                    >  to 10.1.24.2 via ge-0/0/2.0, label-switched-path bronze_lsp_to_pe2

Confirm the CE device is receiving and advertising the expected routes using the methods discussed for BGP troubleshooting.

Appendix 2: Set Commands on All Devices

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, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

CE1

CE2

PE1 (DUT)

PE2

P1

P2

P3

Appendix 3: Show Configuration Output on PE1

The Complete PE1 configuration in Curly Brace Format

BGP Classful Transport (BGP-CT) with Underlying Colored SR-TE Tunnels Overview

Benefits of BGP-CT with underlying colored SR-TE Tunnels

  • Solves scale concerns that may arise in the future as the network grows.
  • Provides inter-connectivity for domains that use different technologies.
  • Decouples services and the transport layers resulting in a completely distributed network.
  • Provides independent bandwidth management through an intra-domain traffic engineering controller for SR-TE.

Large networks that are growing and evolving continuously require a seamless segment routing architecture. Starting in Junos OS Release 21.2,R1 we support BGP-CT with underlying transport as colored SR-TE tunnels. BGP-CT can resolve service routes using the transport RIBs and compute the next hop. Services that are currently supported over BGP-CT can also use the underlying SR-TE colored tunnels for route resolution. The services can now use the underlying SR-TE colored tunnels such as the static colored, BGP SR-TE, programmable rpd and PCEP colored tunnels. BGP-CT uses the next-hop reachability to resolve service routes over the desired transport class.

To enable BGP-CT service route resolution over underlying SR-TE colored tunnels, include the use-transport-class statement at the [edit protocols source-packet-routing] hierarchy level.

Note:
  1. Enable the use-transport-class statement

    at the [edit protocols source-packet-routing] hierarchy level.

    along with the auto-create statement at the [edit routing-options transport-class] hierarchy level.
  2. We don't support RIB groups for colored SR-TE with use-transport-class and color-only SR-TE tunnels with this feature.

Color-Based Mapping of VPN Services Overview

You can specify color as a protocol next hop constraint (in addition to the IPv4 or IPv6 address) for resolving transport tunnels over static colored and BGP segment routing traffic-engineered (SR-TE) LSPs. This is called the color-IP protocol next hop resolution, where you are required to configure a resolution-map and apply to the VPN services. With this feature, you can enable color-based traffic steering of Layer 2 and Layer 3 VPN services.

Junos OS supports colored SR-TE LSPs associated with a single color. The color-based mapping of VPN services feature is supported on static colored LSPs and BGP SR-TE LSPs.

VPN Service Coloring

In general, a VPN service may be assigned a color on the egress router where the VPN NLRI is advertised, or on an ingress router where the VPN NLRI is received and processed.

You can assign a color to the VPN services at different levels:

  • Per routing instance.

  • Per BGP group.

  • Per BGP neighbor.

  • Per prefix.

  • Set of prefixes.

Once you assign a color, the color is attached to a VPN service in the form of BGP color extended community.

You can assign multiple colors to a VPN service, referred to as multi-color VPN services. In such cases, the smallest color value is considered as the color of the VPN service, and all other colors are ignored.

Multiple colors are assigned by egress and/or ingress devices through multiple policies in the following order:

  • BGP export policy on the egress device.

  • BGP import policy on the ingress device.

  • VRF import policy on the ingress device.

The two modes of VPN service coloring are:

Egress Color Assignment

In this mode, the egress device (that is, the advertiser of the VPN NLRI) is responsible for coloring the VPN service. To enable this mode, you can define a routing policy, and apply it in the VPN service’s routing-instance vrf-export, group export, or group neighbor export at the [edit protocols bgp] hierarchy level. The VPN NLRI is advertised by BGP with the specified color extended community.

For example:

OR

Note:

When you apply the routing policy as an export policy of a BGP group or BGP neighbor, you must include the vpn-apply-export statement at the BGP, BGP group, or BGP neighbor level in order for the policy to take an effect on the VPN NLRI.

The routing policies are applied to Layer 3 VPN prefix NLRIs, Layer 2 VPN NRLIs, and EVPN NLRIs. The color extended community is inherited by all the VPN routes, imported, and installed in the target VRFs on one or multiple ingress devices.

Ingress Color Assignment

In this mode, the ingress device (that is, the receiver of the VPN NLRI) is responsible for coloring the VPN service. To enable this mode, you can define a routing policy, and apply it to the VPN service’s routing-instance vrf-import, group import, or group neighbor import at the [edit protocols bgp] hierarchy level. All the VPN routes matching the routing policy is attached with the specified color extended community.

For example:

OR

Specifying VPN Service Mapping Mode

To specify flexible VPN service mapping modes, you must define a policy using the resolution-map statement, and refer the policy in a VPN service’s routing-instance vrf-import, group import, or group neighbor import at the [edit protocols bgp] hierarchy level. All the VPN routes matching the routing policy are attached with the specified resolution-map.

For example:

You can apply import policy to the VPN service’s routing-instance.

You can also apply the import policy to a BGP group or BGP neighbor.

Note:

Each VPN service mapping mode should have a unique name defined in the resolution-map. Only a single entry of IP-color is supported in the resolution-map, where the VPN route(s) are resolved using a colored-IP protocol next hop in the form of ip-address:color over the inetcolor.0 and inet6color.0 routing tables.

Color-IP Protocol Next Hop Resolution

The protocol next hop resolution process is enhanced to support colored-IP protocol next hop resolution. For a colored VPN service, the protocol next hop resolution process takes a color and a resolution-map, builds a colored-IP protocol next hop in the form of ip-address:color, and resolves the protocol next hop in the inetcolor.0 and inet6color.0 routing tables.

You must configure a policy to support multipath resolution of colored Layer 2 VPN, Layer 3 VPN, or EVPN services over colored LSPs. The policy must then be applied with the relevant RIB table as the resolver import policy.

For example:

Fallback to IP Protocol Next Hop Resolution

If a colored VPN service does not have a resolution-map applied to it, the VPN service ignores its color and falls back to the IP protocol next hop resolution. Conversely, if a non-colored VPN service has a resolution-map applied to it, the resolution-map is ignored, and the VPN service uses the IP protocol next hop resolution.

The fallback is a simple process from colored SR-TE LSPs to LDP LSPs, by using a RIB group for LDP to install routes in inet{6}color.0 routing tables. A longest prefix match for a colored-IP protocol next hop ensures that if a colored SR-TE LSP route does not exist, an LDP route with a matching IP address should be returned.

BGP Labeled Unicast Color-based Mapping over SR-TE and IS-IS Underlay

Starting in Junos OS Release 20.2R1, BGP Labeled Unicast (BGP-LU) can resolve IPv4 or IPv6 routes over segment routing–traffic engineering (SR-TE) with IS-IS underlay for both IPv4 and IPv6 address families. BGP-LU supports mapping a BGP community color and defining a resolution map for SR-TE. A colored protocol next hop is constructed and it is resolved on a colored SR-TE tunnel in the inetcolor.0 or inet6color.0 table. Thus BGP-LU resolves protocol next hop over SR-TE tunnels for packet transport. BGP uses inet.3 and inet6.3 tables for non-color based mapping.

Supported and Unsupported Features for Color-Based Mapping of VPN Services

The following features and functionality are supported with color-based mapping of VPN services:

  • BGP Layer 3 VPN

  • BGP Layer 2 VPN (Kompella Layer 2 VPN)

  • BGP EVPN

  • Resolution-map with a single IP-color option.

  • Colored IPv4 and IPv6 protocol next hop resolution.

  • Routing information base (also known as routing table) group based fallback to LDP LSP in inetcolor.0 or inet6color.0 routing tables.

  • Colored SR-TE LSP.

  • Virtual platforms.

  • 64-bit Junos OS.

  • Logical systems.

  • BGP Labeled Unicast

The following features and functionality are not supported with color-based mapping of VPN services:

  • Colored MPLS LSPs, such as RSVP, LDP, BGP-LU, static.

  • Layer 2 circuit

  • FEC-129 BGP auto-discovered and LDP-signaled Layer 2 VPN.

  • VPLS

  • MVPN

  • IPv4 and IPv6 using resolution-map.