Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

BGP Egress Traffic Engineering

Egress Peer Traffic Engineering Using BGP Labeled Unicast Overview

In a data center environment, which mimics an ISP BGP-free core, the ingress nodes tunnel the service traffic to an egress router that is also the AS boundary router. Egress peer traffic engineering allows a central controller to instruct an ingress router in a domain to direct the traffic towards a specific egress router and a specific external interface to reach a particular destination out of the network. Egress peer traffic engineering allows for the selection of the best advertised egress route and mapping of the selected best route to a specific egress point. In case of load balancing at the ingress, this feature ensures optimum utilization of the advertised egress routes.

The ingress router controls the egress peer selection by pushing the corresponding MPLS label on an MPLS label stack for traffic engineering the links between ASs. AS boundary routers automatically install the IPv4 or IPv6 peer /32 or /128 route to an established external BGP peer that is configured with the egress traffic engineering feature into the inet.3 forwarding table. These routes have a forwarding action of pop and forward, that is, remove the label, and forward the packet to the external BGP peer.

AS boundary routers advertise the IPv4 or IPv6 peer /32 or/128 route to the ingress BGP peers with self IPv4 next hop. Ingress BGP peers have a transport tunnel, such as MPLS LDP to reach the AS boundary router. Thus, all the network exit points are advertised to the MPLS network cloud as labeled BGP routes. The AS boundary routers advertise service routes with these exit points as protocol next hops. The AS boundary routers readvertise the service routes from the external BGP peers towards the core without altering the next-hop addresses. However, the ingress routers resolve the protocol next hop in the service routes to map to the correct transport tunnel to the egress peer interface. Thus, the ingress routers map traffic for a specific service prefix to a specific egress router or load-balance the traffic across available egress devices. This feature allows the ingress router to direct the service traffic towards a specific egress peer.

In addition to egress peer traffic engineering, this feature provides MPLS fast reroute (FRR) for each egress device it advertises to the MPLS IPv4 network cloud. You can configure one or more backup devices for the primary egress AS boundary router. Junos OS automatically installs the backup path in addition to the primary path into the MPLS forwarding table of the established egress BGP peer that has egress peer traffic engineering configured. The AS boundary router switches to the backup path when the primary link fails and provides MPLS FRR . The specified backup path is through another directly connected external BGP peer or a remote next hop. You can also configure a backup path using ip lookup in an inet6.0 table. However, the remote-nexthop and ip-forward backup options are mutually exclusive.

See Also

Configuring Egress Peer Traffic Engineering by Using BGP Labeled Unicast and Enabling MPLS Fast Reroute

Egress peer traffic engineering (TE) allows a central controller to instruct an ingress router in a domain to direct traffic towards a specific egress router and a specific external interface to reach a particular destination out of the network for optimum utilization of the advertised egress routes during load balancing.

BGP segregates the network into layers, such as transport and service layers. The BGP labeled unicasts form the transport layer, and the BGP unicast subsequent address family identifier (SAFI) add path routes form the service layer. The AS boundary router triggers the transport layer BGP labeled unicast label-switched paths (LSPs) that provide a route to the egress peers. The service layer add path routes use these egress peers as protocol next hop. The AS boundary routers optionally provide MPLS fast reroute (FRR) at the transport layer, which must be utilized because service layer peering issues are common. Therefore, you can specify one or more backup devices for the primary egress AS boundary router. Junos OS automatically installs the backup path in addition to the primary path into the MPLS forwarding table of the established egress BGP peer that has egress peer TE configured. The backup path provides FRR when the primary link fails.

  1. To enable egress peer TE using BGP labeled unicast:

    Enable egress peer TE at the AS boundary router for the egress BGP peer.

    For example, enable egress peer TE on the egress BGP peer.

  2. To enable FRR for the egress traffic on BGP labeled unicast LSP:
    1. Define a template with backup paths on the egress BGP peer to enable MPLS fast reroute.

      You can define more than one template and several BGP groups, or peers can use the same defined template. All addresses listed in one template must belong to the same IP address family as the egress BGP peer.

      For example, define a backup path template to enable MPLS fast reroute.

    2. Configure another directly connected external BGP peer as a backup path.

      For example, configure the peer backup path for the defined template customer1.

    3. Configure IP forwarding on the AS boundary router as the fast reroute backup path.

      Junos OS looks up the backup path in the inet6.0 table.

      You can specify the routing instance for which you are configuring backup paths on the egress BGP peer. If you do not specify a routing instance, the device configures the backup path for the master instance. Optionally, you can configure a foo routing instance as the ip-forward backup option.

      You cannot use this option with the remote-nexthop option.

      For example, configure ip forwarding instance foo for the defined template customer1.

      Junos OS looks up the backup path in the foo.inet6.0 table.

    4. Specify a remote next-hop address as the backup path for the egress BGP peer.

      The egress peer TE AS boundary router tunnels the traffic to this remote next-hop address.

      For example, if you want to configure a remote next hop for the defined template customer1, enter:

    5. Specify the defined template at a BGP group or neighbor level.

      For example, specify the template customer1 defined previously as the backup-path for BGP neighbor 200.200.201.1.

See Also

Example: Configuring Egress Peer Traffic Engineering Using BGP Labeled Unicast

This example shows how to configure egress peer traffic engineering using BGP labeled unicast. Egress peer traffic engineering allows a central controller to instruct an ingress router in a domain to direct traffic towards a specific egress router and a specific external interface to reach a particular destination out of the network. In case of load balancing at the ingress, this feature ensures optimum utilization of the advertised egress routes.

Requirements

This example uses the following hardware and software components:

  • Nine MX Series routers

  • Junos OS Release 14.2R4 or later

Overview

Beginning with Junos OS Release 14.2R4, you can enable traffic engineering (TE) of service traffic, such as MPLS LSP traffic between autonomous systems (ASs) using BGP labeled unicast for optimum utilization of the advertised egress routes during load balancing.

Configure egress peer TE to direct core service traffic such as MPLS RSVP to a specific egress BGP peer. The ingress BGP peer can traffic-engineer the core inet unicast and inet6 unicast service traffic using BGP labeled unicast towards a specific egress BGP peer.

Note:

You cannot configure egress peer TE for external BGP multihop peers. The ARP routes in inet.3 are installed for peer /32 and /128 routes only.

Topology

Figure 1 shows the sample topology. Router R3 and Router R4 are the AS boundary routers. Egress peer TE is enabled on R3. The ingress Router R0 directs traffic destined to a remote network to Router R3, which has egress peer TE enabled.

Figure 1: Configuring Egress Peer Traffic Engineering Using BGP Labeled UnicastConfiguring Egress Peer Traffic Engineering Using BGP Labeled Unicast

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 configuration mode.

Router R0

Router R1

Router R2

Router R3

Router R4

Router R5

Router R6

Router R7

Router R8

Configuring Router R3

Step-by-Step Procedure

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

To configure Router R3:

Note:

Repeat this procedure for other routers after modifying the appropriate interface names, addresses, and other parameters.

  1. Configure the interfaces with IPv4 and IPv6 addresses.

  2. Configure the loopback addresses.

  3. Configure the router ID and autonomous system (AS) number.

  4. Configure the RSVP protocol for all interfaces except the management interface.

  5. Configure the MPLS protocol for all interfaces except the management interface.

  6. Configure IBGP peering sessions on the core-facing interface.

  7. Configure EBGP peering sessions on interfaces facing external edge routers.

  8. Enable egress peer traffic engineering for external BGP group Peer1-lan-1 and for the IPv6 group Peer1-lan-1-v6.

  9. Configure the OSPF protocol as the IGP.

  10. Define a policy for exporting ARP routes to route reflectors.

  11. Apply the policy exp-arp-to-rrs for exporting ARP routes to route reflectors to the external BGP group, ebgp-v6.

  12. Define prefix lists with IPv4 and IPv6 routes.

  13. Define a policy to export IPv4 and IPv6 routes to the server.

  14. Apply the policy to export IPv4 and IPv6 peer routes.

  15. Define a per-packet load-balancing policy.

  16. Apply the per-packet load-balancing policy.

Results

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

Verification

Confirm that the configuration is working properly.

Identifying the Label and the Protocol Next Hop

Purpose

Get the label number of the packet transported from R0 to R6 and the next hop from the routing table for route 10.17.17.2.

Action

From operational mode, run the show route 10.17.17.2 extensive active-path command on Router R0.

Meaning

Both the packet label 299888 and the next hop 10.200.202.2 are displayed in the output.

Verifying the Path of Packet with Label 299888

Purpose

Trace the path of the label 299888 and verify that the VPN entry is present in the mpls.0 routing table.

Action
Meaning

The label 299888 with VPN entry and next hop 10.200.202.2 is present in the mpls.0 routing table.

Verifying That Egress Peer Traffic Engineering Is Enabled on Router R3

Purpose

Verify that the egress peer traffic engineering is configured on Router R3.

Action
Meaning

The output indicates that BGP egress peer traffic engineering is enabled on Router R3.

See Also

Segment Routing Traffic Engineering at BGP Ingress Peer Overview

This feature enables BGP to support a segment routing policy for traffic engineering at ingress routers. The controller can specify a segment routing policy consisting of multiple paths to steer labeled or IP traffic. The segment routing policy adds an ordered list of segments to the header of a packet for traffic steering. BGP installs the candidate routes of the segment routing policy into routing tables bgp.inetcolor.0 or bgp.inet6color.0. BGP selects one route from the candidate routes for a particular segment routing traffic engineering policy, and installs it in the new routing tables inetcolor.0 or inet6color.0. This feature supports both statically configured as well as BGP-installed segment routing traffic engineering policies in the forwarding table at ingress routers.

Understanding Segment Routing Policies

In segment routing the controller allows the ingress nodes in a core network to steer traffic through explicit paths while eliminating the state for the explicit paths in intermediate nodes. An ordered list of segments associated with the segment routing policy is added to the header of a data packet. These segment lists or lists of segment identifiers (SIDs) represent paths in the network, which are the best candidate paths selected from multiple candidate paths learned from various sources. An ordered list of segments is encoded as a stack of labels. This feature enables steering a packet toward a specific path depending on the network or customer requirements. The traffic can be labeled or IP traffic and is steered with a label swap or a destination-based lookup toward these segment routing traffic engineering paths. You can configure static policies at ingress routers to steer traffic even when the link to the controller fails. Static segment routing policies are useful to ensure traffic steering when the controller is down or unreachable.

BGP’s Role in Route Selection from a Segment Routing Policy

When BGP receives an update for segment routing traffic engineering subsequent address family identifier (SAFI) from the controller, BGP performs some basic checks and validation on these updates. Segments that are not MPLS labels are considered invalid. If the updates are valid then BGP installs the segment routing traffic engineering policy in the routing tables bgp.inetcolor.0 and bgp.inet6color.0 and these are subsequently installed in the routing tables inetcolor.0 or inet6color.0. These routing tables use attributes such as distinguisher, endpoint address, and color as the key.

Starting in Junos OS Release 20.2R1, Junos OS provides support for controller based BGP-SRTE routes are installed as segment routing traffic-engineered (SPRING-TE) routes. BGP installs the segment routing traffic engineering policy in the routing tables bgp.inetcolor.0 and bgp.inet6color.0 and these are subsequently installed in the routing tables inetcolor.0 or inet6color.0 by SPRING-TE.

The policy action color: color-mode:color-value is configured at the [edit policy-options community name members] hierarchy level to attach color communities when exporting prefixes from inet-unicast and inet6-unicast address families.

To enable BGP IPv4 segment routing traffic engineering capability for an address family, include the segment-routing-te statement at the [edit protocols bgp family inet] hierarchy level.

To enable BGP IPv6 segment routing traffic engineering capability for an address family include the segment-routing-te statement at the [edit protocols bgp family inet6] hierarchy level.

Note:

Starting in Release 18.3R1, Junos OS supports collection of traffic statistics for both ingress IP and transit MPLS traffic in a network configured with segment routing traffic engineering policy. To enable collection of traffic statistics include the telemetry statement at the [edit protocols source-packet-routing] hierarchy level.

Statically Configured Segment Routing Policies

Static policies can be configured at ingress routers to allow routing of traffic even when the link to the controller fails. Configure sr-preference at the [edit protocols source-packet-routing] hierarchy level to choose a statically configured segment routing traffic engineering policy forwarding entry over a BGP-signaled segment routing traffic engineering forwarding entry. The top label of the segment identifier label stack is swapped with the interior gateway protocol (IGP) top label for resolution.

A static segment routing traffic engineering policy can contain multiple paths with or without weighted ECMP. If IGP configuration has weighted ECMP configured, then the forwarding path provides hierarchical weighted equal-cost multipath (ECMP). However, if weighted ECMP is not configured, equal balance is applied to all the segment routing traffic engineering paths.

Supported and Unsupported Features

Junos OS supports the following features with BGP segment routing traffic engineering:

  • For PTX Series, this feature is supported for FPC-PTX-P1-A with enhanced chassis mode.

  • Weighted ECMP and hierarchical weighted ECMP.

  • MPLS fast reroute (FRR) is supported for the paths in segment routing traffic engineering policies. IGP backup paths corresponding to the top label are installed to the routing table when available for segment routing traffic engineering policy paths.

The following limitations apply to BGP segment routing traffic engineering::

  • BGP and static segment routing traffic engineering policies are only supported for the master instance.

  • The segment routing traffic engineering paths that are explicitly configured using static policies or learned through BGP are limited to lists of segment identifiers that represent absolute MPLS labels only.

  • A maximum of 128 segment lists are supported for static segment routing traffic engineering policies.

  • The BGP segment routing traffic engineering SAFI is not supported for peers in routing instances.

  • The BGP segment routing traffic engineering network layer reachability information (NLRI) cannot be imported to other routing tables using routing information base (RIB) groups (RIBs are also known as routing tables).

  • Traffic statistics are not supported for traffic traversing the segment routing policy.

  • The processing of time-to-live (TTL) MPLS label segment identifiers is not supported.

  • Nonstop active routing is not supported.

  • Class-of-service (CoS) policies work on the top label.

  • Only non-VPN CoS rewrite CLI commands are supported; for example, EXP rewrite for the top label is supported.

  • For an ingress packet, a maximum of eight labels can be parsed, and Layer 2 or Layer 3 MPLS payload fields are used in the load-balancing hash calculation. If label depth in the ingress packet is more than eight labels, then MPLS payload is not parsed and Layer 2 and Layer 3 MPLS payload fields are not used in the load-balancing hash calculation.

  • The maximum label stack depth support is five. You must configure maximum-labels to limit the label depth of segment routing traffic engineering policies. If maximum-labels is not configured, meaningful defaults apply that restrict the maximum label depth to five.

  • The color attribute must be specified in segment routing traffic engineering LSP configuration. Hence the ingress routes are downloaded to inetcolor{6}.0 tables.

  • When there are multiple static segment routing traffic engineering policies with the same Endpoint, color preference but different binding segment identifiers are present, the route corresponding to the lesser binding segment identifier is installed in the mpls.0 table.

  • Mixed segment identifiers are not supported: the segment identifiers in the segment routing traffic engineering segment list must be exclusively IPv4 or IPv6.

  • You must explicitly configure MPLS maximum-labels on an interface to accommodate more than five labels; otherwise more than five labels might result in packet drops.

  • The default limits of the supported parameters are listed below in Table 1:

    Table 1: Supported Parameters for Segment Routing Traffic Engineering

    Parameter

    Limit

    Maximum number of labels supported

    5

    Maximum number of paths in segment routing traffic engineering policy

    8

    Number of BGP segment routing traffic engineering policies

    32,000

    Number of static segment routing traffic engineering policies

    32,000

See Also

Configuring Ingress Traffic Engineering with Segment Routing in a BGP Network

Starting in Junos OS Release 17.4R1, a BGP speaker supports traffic steering based on a segment routing policy. The controller can specify a segment routing policy consisting of multiple paths to steer labeled or IP traffic. This feature enables BGP to support a segment routing policy for traffic engineering at ingress routers. The segment routing policy adds an ordered list of segments to the header of a packet for traffic steering. Static policies can be configured at ingress routers to allow routing of traffic even when the link to the controller fails.

Note:

This feature is supported on PTX Series with FPC-PTX-P1-A. For devices that have multiple FPCs, you must configure enhanced mode on the chassis.

Before you begin configuring BGP to receive segment routing traffic engineering policy from the controller, do the following tasks:

  1. Configure the device interfaces.

  2. Configure OSPF or any other IGP protocol.

  3. Configure MPLS and segment routing labels..

  4. Configure BGP.

  5. Configure segment routing on the controller and all other routers.

To configure traffic engineering for BGP segment routing:

  1. Enable BGP IPv4 segment routing traffic engineering capability for an address family. This feature is available only for inet, inet unicast, inet6, and inet6 unicast network layer reachability information (NLRI) families.

    For example, enable segment routing for a particular BGP group as follows:

  2. Configure segment routing global block (SRGB). Junos OS uses this label block for steering the packets to a remote destination. Configure the start label and SRGB index range.

    For example, configure the start label and the SRGB index range with the following values:

  3. Configure the policy action to attach color communities when exporting prefixes from inet-unicast and inet6-unicast address families.

    For example, configure the following color attributes for a BGP community:

  4. Configure the source routing LSP for steering traffic at the ingress router. Specify the attributes such as the tunnel endpoint, color, binding segment identifier, and preference for traffic engineering. Configuring binding segment identifier installs the route in the MPLS tables.

    For example, you can configure the attributes as follows:

  5. Configure weighted ECMP for the primary segment list of a segment routing path. If the forwarding interface is also configured with weighted ECMP then Junos OS applies hierarchical weighted ECMP. If you do not configure the weight percentage, then only IGP weights are applied on the forwarding interfaces.

    For example, you can configure the routing paths and weights as follows:


  6. Configure the segment routing preference for routes received for this tunnel. This segment routing preference value overrides the global segment routing preference value and is used to select between candidate segment routing policies installed by different protocols such as static and BGP.

    For example, you can configure the sr preference as follows:

  7. Configure static policies at ingress routers to allow routing of traffic even when the link to the controller fails. Specify one or more nexthop labels. The successfully resolved LSPs are used to resolve BGP payload prefixes that have the same color and endpoint.

    For example, configure two segment lists sr1, sr4 and specify labels for steering segment routing traffic at an ingress router as follows:

    Note:

    If BGP and static segment routing are configured together for traffic engineering, then by default Junos OS chooses statically configured segment routing policies.

  8. Configure segment routing preference overide to replace the received segment routing traffic engineering preference value with the configured override value. Segment routing policy preference can change based on certain tie-breaking rules involving sr-preference-override, sr-preference, and admin-preference.

    For example, configure the following value for BGP segment routing preference override:

See Also

Enabling Traffic Statistics Collection for BGP Labeled Unicast

Starting in Junos OS Release 18.1R1, you can enable traffic statistics collection for BGP labeled unicast traffic at the ingress router in a network configured with segment routing. Traffic statistics are collected based on the label stack. For example, if there are two routes with the same label stack but different next-hops then traffic statistics are aggregated for these routes because the label stack is the same. Traffic statistics can be periodically collected and saved to a specified file based on the label stack received in the BGP route update. By default, traffic statistics collection is disabled. Enabling traffic statistics collection triggers a BGP import policy. Traffic statistics collection is supported only for IPv4 and IPv6 address families.

Before you begin configuring BGP to collect traffic statistics, do the following tasks:

  1. Configure the device interfaces.

  2. Configure OSPF or any other IGP protocol.

  3. Configure MPLS and LDP.

  4. Configure BGP.

  5. Configure segment routing on the controller and all other routers.

In a network configured with segment routing, each node and link is assigned a segment identifier (SID), which is advertised through IGP or BGP. In an MPLS network, each segment is assigned a unique segment label that serves as the SID for that segment. Each forwarding path is represented as a segment routing label-switched path (LSP). The segment routing LSP is represented with a stack of SID labels at ingress. The ingress router can impose these labels to route the traffic. With BGP labeled unicast a controller can program the ingress router to steer traffic and advertise a prefix with a label stack.

To enable traffic statistics collection for BGP labeled unicast at ingress:

  1. Enable collection of traffic statistics of labeled unicast IPv4 and IPv6 families for specific BGP groups or BGP neighbors.
  2. Configure periodic traffic statistics collection for BGP label-switched paths in a segmented routing network and save the statistics to a file.
    1. Specify the filename to save the collected traffic statistics collected at a specified time interval.
    2. Specify the time interval in seconds for collecting traffic statistics. You can specify a number from 60 to 65535 seconds.

See Also

Understanding SRv6 Network Programming and Layer 3 Services over SRv6 in BGP

Benefits of SRv6 Network Programming

  • BGP leverages the segment routing capability of devices to set up Layer 3 VPN tunnels. IPv4 packets can be transported through an SRv6 ingress node even if the transit routers are not SRv6-capable. This eliminates the need to deploy segment routing on all nodes in an IPv6 network.

  • Network programming depends entirely on the IPv6 header and the header extension to transport a packet, eliminating the need for protocols such as MPLS. This ensures a seamless deployment without any major hardware or software upgrade in a core IPv6 network.

  • Junos OS supports all function behaviors on a single segment identifier (SID) and can inter-operate in both insert mode and encapsulation mode. This allows a single device to simultaneously play the provider (P) router and the provider edge (PE) router roles.

SRv6 Network Programming in BGP Networks

Network programming is the capability of a network to encode a network program into individual instructions that are inserted into the IPv6 packet headers. The Segment Routing Header (SRH) is a type of IPv6 routing extension header that contains a segment list encoded as an SRv6 SID. An SRv6 SID consists of the locator, which is an IPv6 address, and a function that defines a particular task for each SRv6-capable node in the SRv6 network. SRv6 network programming eliminates the need for MPLS and provides flexibility to leverage segment routing.

Note:

Ensure that you use a unique SID, which BGP uses to allocate an SRv6 SID.

To configure IPv4 transport over the SRv6 core, include the end-dt4-sid sid statement at the [edit protocols bgp source-packet-routing srv6 locator name] hierarchy level.

To configure IPv6 transport over the SRv6 core, include the end-dt6-sid sid statement at the [edit routing protocols bgp source-packet-routing srv6 locator name] hierarchy level.

To configure IPv6 transport over the SRv6 core, include the end-dt46-sid sid statement at the [edit routing protocols bgp source-packet-routing srv6 locator name] hierarchy level. The end-dt4-sid statement denotes the endpoint SID with de-encapsulation and IPv4 table lookup and the end dt6-sid statement is the endpoint with de-encapsulation and IPv6 table lookup. BGP allocates these values for IPv4 and IPv6 Layer3 VPN service SIDs.

Layer 3 VPN Services over the SRv6 Core

When connecting to the egress PE, the ingress PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 service SID associated with the related BGP route update. The egress PE sets the next hop to one of its IPv6 addresses that is also the SRv6 locator from which the SRv6 service SID is allocated. Multiple routes can resolve through the same segment routing policy.

Figure 2: SRv6 Packet EncapsulationSRv6 Packet Encapsulation

Starting in Junos OS Release 20.4R1, you can configure BGP-based Layer 3 service over the SRv6 core. You can enable Layer 3 overlay services with BGP as the control plane and SRv6 as the dataplane. SRv6 network programming provides flexibility to leverage segment routing without deploying MPLS. Such networks depend only on the IPv6 headers and header extensions for transmitting data.

Note:

Ensure that the end-dt4-sid sid and the end-dt6-sid sid are the last SIDs in the segment list, or the destination address of the packet with no SRH header.

To configure IPv4 VPN services over the SRv6 core, include the end-dt4-sid statement at the [edit routing-instances instance-name protocols bgp source-packet-routing srv6 locator name] hierarchy level.

The end dt46 SID must be the last segment in a segment routing policy, and a SID instance must be associated with an IPv4 FIB table and an IPv6 FIB table.

Advertising Layer 3 VPN Services to BGP Peers

BGP advertises the reachability of prefixes of a particular service from an egress PE device to ingress PE nodes. BGP messages exchanged between PE devices carry SRv6 service SIDs, which BGP uses to interconnect PE devices to form VPN sessions. For Layer 3 VPN services where BGP uses a per-VRF SID allocation, the same SID is shared across multiple network layer reachability information (NLRI) address families.

To advertise SRv6 services to BGP peers at the egress node, include the advertise-srv6-service statement at the [edit protocols bgp family inet6 unicast] hierarchy level.

Egress PE devices that support SRv6-based Layer 3 services advertise overlay service prefixes along with a service SID. The BGP ingress node receives these advertisements and adds the prefix to the corresponding virtual routing and forwarding (VRF) table.

To accept SRv6 services at the ingress node, include the accept-srv6-service statement at the [edit protocols bgp family inet6 unicast] hierarchy level.

Supported and Unsupported Features for SRv6 Network Programming in BGP

Junos OS supports the following features with SRv6 Network Programming in BGP:

  • Ingress devices support seven SIDs in the reduced mode including the VPN SID

  • Egress devices support seven SIDs including the VPN SID

  • Endpoint with de-encapsulation and specific IP table lookup (End.DT46 SID)

Junos OS does not support the following features in conjunction with SRv6 Network Programming in BGP:

  • Fragmentation and reassembly in SRv6 tunnels

  • VPN options B and C

  • Detection of duplicate SIDs

See Also

Example: Configuring Layer 3 Services over SRv6 in BGP Networks

This example shows how to configure SRv6 network programming and Layer 3 VPN services in BGP Networks. SRv6 network programming provides flexibility to leverage segment routing without deploying MPLS. This feature is useful for service providers whose networks are predominantly IPv6 and have not deployed MPLS.

Requirements

This example uses the following hardware and software components:

  • Five MX Series routers with MPC7E, MPC8E, or MPC9E line cards

  • Junos OS Release 20.4R1 or later

Overview

Starting in Junos OS Release 20.4R1, you can configure BGP-based Layer 3 services over the SRv6 core network. With SRv6 network programming, networks depend only on the IPv6 headers and header extensions for transmitting data. You can enable Layer 3 overlay services with BGP as the control plane and SRv6 as the dataplane.

Topology

In Figure 3, Router R0 is the ingress and Router R1 and R2 are the egress routers that support IPv4-only customer edge devices. Routers R3 and R4 comprise an IPv6-only provider core network. All routers belong to the same autonomous system. IS-IS is the interior gateway protocol configured to support SRv6 in the IPv6 core routers R3 and R4. In this example, BGP is configured on routers R0, R1, and R2. Router R0 is configured as an IPv6 route reflector with IBGP peering sessions to both Router R1 and Router R2. The egress Router R1 advertises the L3VPN SID to ingress Router R0, which accepts and updates the VRF table.

Figure 3: Layer 3 Services over SRv6 in BGP NetworksLayer 3 Services over SRv6 in BGP Networks

R1 is configured with 3011::1 as end-sid and all the BGP routes are advertised with 3011::1 as next hop to Router R0. Router R0 has two paths to R1, the primary path through R3 and the backup path through R4. In Router R0 , the primary path is with default metric and the backup path is configured with metric 50. Here are some of the routes that are advertised from Router R1 to R0:

IPv4

21.0.0.0
IPv6

2001:21::
IPv4 VPN

31.0.0.0
IPv6 VPN

2001:31::

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 configuration mode.

Router R0

Router R1

Router R2

Router R3

Router R4

Configure Router R0

Step-by-Step Procedure

To configure SRv6 network programming with Layer 3 VPN services, perform the following steps on Router R0:

  1. Configure the device interfaces to enable IP transport.

  2. Configure the router ID and autonomous system (AS) number to propagate routing information within a set of routing devices that belong to the same AS.

  3. Enable SRv6 globally and the locator address to indicate the SRv6 capability of the router. SRv6 SID is an IPv6 address that consists of the locator and a function. The routing protocols advertise the locator addresses.

  4. Configure an external routing instance VPN1 for both IPv4 and IPv6 traffic. Configure the BGP protocol for VPN1 to enable peering and traffic transport between the provider edge devices.

  5. Configure the VPN type and a unique route distinguisher for each PE router participating in the routing instance.

  6. Configure the end-dt4 and end-dt6 SID values for enabling the Layer 3 VPN services.

  7. Define a policy to load-balance packets.

  8. Apply the per-packet policy to enable load balancing of traffic.

  9. Define a policy adv_global to accept routes advertised from R1.

  10. Configure BGP on the core-facing interface to establish internal and external peering sessions.

  11. Enable the device to advertise the SRv6 services to BGP peers and to accept the routes advertised by the egress provider edge (PE) devices.

  12. Enable IS-IS as the interior gateway protocol (IGP) for routing traffic between the core provider routers.

  13. Configure the end-dt4 and end-dt6 SID value for the prefix segments. End-dt4 is the endpoint SID with decapsulation and IPv4 table lookup and end-dt6 is the endpoint with decapsulation and IPv6 table lookup. BGP allocates these for IPv4 and IPv6 Layer3 VPN services SIDs.

Results

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

When done configuring the device, enter commit from the configuration mode.

Verification

Confirm that the configuration is working properly.

Verify that the advertised IPv4 route is installed in the IPv4 table

Purpose

Verify that ingress router R0 has learned the route to the IPv4 prefix 20.0.0.0 from the egress router R1.

Action

From operational mode, run the show route 20.0.0.0 command on router R0.

Meaning

The output confirms that the IPv4 prefix 20.0.0.0 is installed in the inet.0 table.

Verify that SRv6 SID is installed in the IPv4 Table

Purpose

Verify that ingress Router R0 has received and accepted the SRv6 end-dt4 SID 3001::2 from the egress Router R1.

Action

From operational mode, run the show route 20.0.0.0 extensive command on Router R0.

Meaning

The output displays the SRv6 SID and confirms that an SRv6 tunnel is established between Routers R0 and R1.

Verify that the IPv6 VPN route is installed in the VPN table

Purpose

Verify that ingress router R0 has learned the route to the VPN IPv6 prefix 2001::30::/126 from the egress router R1.

Action

From operational mode, run the show route 2001:30:: command on router R0.

Meaning

The output confirms that the route details for the prefix 2001:30::/126 are installed in the vpn.inet6.0 table.

Verify that the IPv4 VPN route is installed in the VPN table

Purpose

Verify that ingress router R0 has learned the route to the VPN IPv4 prefix 30.0.0.0 from the egress router R1.

Action

From operational mode, run the show route 30.0.0.0 command on router R0.

Meaning

The output confirms that the IPv4 prefix 30.0.0.0 is installed in the vpn.inet.0 table.

See Also

Understanding SR-TE Policy for SRv6 Tunnel

Benefits of SRv6 TE Policy

  • SRv6 TE provides flexibility to leverage segment routing without deploying MPLS. Such networks depend only on the IPv6 headers and header extensions for transmitting data. This is useful for service providers whose networks are predominantly IPv6 and have not deployed MPLS.
  • Ensures a seamless deployment without any major hardware or software upgrade in a core IPv6 network, thereby enhancing scalability.
  • Utilizes IS-IS SRv6 SIDs to form the segment lists. Therefore, it leverages the TI-LFA paths of IS-IS SRv6 SIDs and can form backup paths based on the IGP.
  • Leverages IS-IS weighted equal cost multipath (ECMP) and can also have its own ECMPs on individual segment lists to form hierarchical weighted ECMPs that performs load balancing at a granular level.

SRv6 TE Policy Overview

An SR-TE policy contains one or more SR-TE tunnels either configured statically or contributed by different tunnel sources namely PCEP, BGP-SRTE, DTM. Starting in Junos OS Release 21.3R1, Junos OS supports SRv6 data plane with statically configured SR-TE policy.

In an SRv6 TE policy:

  • IS-IS configuration populates the core.
  • SRv6 TE tunnel configuration populates the transport.
  • BGP network layer reachability information (NLRI) populates the service.

After the creation of the SRv6 TE data plane, you can enable Layer 3 overlay services with BGP as the control plane and SRv6 as the data plane. The desired payload can be of IPv4 or IPv6.

Figure 4 depicts an SRv6 TE topology in which R1 is the ingress node with SRv6 TE policy configured to R6. R6 is the egress node with Layer 3 VPN services to BGP peers configured. The core constitutes IS-IS SRv6. The egress Router R6 advertises the L3VPN SID to ingress Router R1, which accepts and updates the VRF table. R6 is configured with 2001:db8:0:a6::d06 as end-sid and the L3VPN service is exported towards CE7 to R1 with 2001:db8:0:a6::d06 as next hop. There are two segment lists: <R4, R5, R6> and <R2, R3, R6>.

Figure 4: SRv6 TE Sample TopologySRv6 TE Sample Topology

What is a Segment Routing Extension Header (SRH)?

A Segment Identifier represents a specific segment in a segment routing domain. In an IPv6 network, the SID-type used is a 128-bit IPv6 address also referred to as an SRv6 Segment or SRv6 SID. SRv6 stacks up these IPv6 addresses instead of MPLS labels in a segment routing extension header. The Segment Routing Extension Header (SRH) is a type of IPv6 routing extension header. Typically, the SRH contains a segment list encoded as an SRv6 SID. An SRv6 SID consists of the following parts:

  • Locator— Locator is the first part of a SID that consists of the most significant bits representing the address of a particular SRv6 node. The locator is very similar to a network address that provides a route to its parent node. The IS-IS protocol installs the locator route in the inet6.0 routing table. IS-IS routes the segment to its parent node, which subsequently performs a function defined in the other part of the SRv6 SID. You can also specify the algorithm associated with this locator.

  • Function—The other part of the SID defines a function that is performed locally on the node that is specified by the locator. There are several functions that have already been defined in the Internet draft draft-ietf-spring-srv6-network-programming-07draft, SRv6 Network Programming. However, we have implemented the following functions are available on Junos OS that are signalled in IS-IS. IS-IS installs these function SIDs in the inet6.0 routing table.

    • End— An endpoint function for SRv6 instantiation of a Prefix SID. It does not allow for decapsulation of an outer header for the removal of an SRH. Therefore, an End SID cannot be the last SID of a SID list and cannot be the Destination Address (DA) of a packet without an SRH (unless combined with the PSP, USP or USD flavors).

    • End.X— An endpoint X function is an SRv6 instantiation of an adjacent SID. It is a variant of the endpoint function with Layer 3 cross-connect to an array of Layer 3 adjacencies.

    You can specify End SID behavior such as Penultimate Segment Pop (PSP), Ultimate Segment Pop (USP) or Ultimate Segment Decapsulation (USD).

    • PSP— When the last SID is written in the destination address, the End and End.X functions with the PSP flavor pop the top-most SRH. Subsequent stacked SRHs may be present but are not processed as part of the function.

    • USP— When the next header is an SRH and there are no more segments left, the IS-IS protocol pops the top SRH, looks up the updated destination address and forwards the packet based on match table entry.

    • USD— When the next Header in the packet is 41 or is an SRH and there are no more segments left, then IS-IS pops the outer IPv6 header and its extension headers, looks up the exposed inner IP destination address and forwards the packet to the matched table entry.

For example, you can have an SRv6 SID where 2001::19:db8:AC05:FF01:FF01: is the locator and A000:B000:C000:A000 is the function:

Table 2: 128-bit SRv6 SID

Locator

Function

2001::db8:19:AC05:FF01:FF01

A000:B000:C000:A000

TI-LFA for SRv6 TE

Topology Independent- Loop Free Alternate (TI-LFA) establishes a Fast Reroute (FRR) path that is aligned to a post-convergence path. An SRv6-capable node inserts a single segment into the IPv6 header or multiple segments into the SRH. Multiple SRHs can significantly raise the encapsulation overhead, which can sometimes be more than the actual packet payload. Therefore, by default, Junos OS supports SRv6 TE tunnel encapsulation with reduced SRH. The point-of-local repair (PLR) adds the FRR path information to the SRH containing the SRv6 SIDs.

The TI-LFA backup path is represented as a group of SRv6 SIDs inside an SRH. At the ingress router, IS-IS encapsulates the SRH in a fresh IPv6 header. However, at transit routers, IS-IS inserts the SRH into the data traffic in the following manner:

  • Encap Mode— In the encap mode, the original IPv6 packet is encapsulated and transported as the inner packet of an IPv6-in-IPv6 encapsulated packet. The outer IPv6 packet carries the SRH with the segment list. The original IPv6 packet travels unmodified in the network. By default, Junos OS supports SRv6 tunnel encapsulation in reduced SRH. However, you can choose one of the following tunnel encapsulation methods:

    • Reduced SRH (default)— With the reduced SRH mode, ifbecause there is only one SID, there is no SRH added and the last SID is copied into the IPV6 destination address. You cannot preserve the entire SID list in the SRH with a reduced SRH.

    • Non-reduced SRH— You can configure the non-reduced SRH tunnel encapsulation mode when you and might still want to preserve the entire SID list in the SRH.

Because the core network of statically configured SRv6 TE LSP is formed by IS-IS SRv6, the IS-IS SRv6 TILFA can be leveraged using SRv6 TE segments.

Layer 3 VPN Services over the SRv6 Core

When connecting to the egress PE, the ingress PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 service SID associated with the related BGP route update. The egress PE sets the next hop to one of its IPv6 addresses that is also the SRv6 locator from which the SRv6 service SID is allocated. Multiple routes can resolve through the same segment routing policy.

Figure 5: SRv6 Packet EncapsulationSRv6 Packet Encapsulation

Starting in Junos OS Release 20.4R1, you can configure BGP-based Layer 3 service over the SRv6 core. You can enable Layer 3 overlay services with BGP as the control plane and SRv6 as the dataplane.

Advertising Layer 3 VPN Services to BGP Peers

BGP advertises the reachability of prefixes of a particular service from an egress PE device to ingress PE nodes. BGP messages exchanged between PE devices carry SRv6 service SIDs, which BGP uses to interconnect PE devices to form VPN sessions. For Layer 3 VPN services where BGP uses a per-VRF SID allocation, the same SID is shared across multiple network layer reachability information (NLRI) address families.

Egress PE devices that support SRv6-based Layer 3 services advertise overlay service prefixes along with a service SID. The BGP ingress node receives these advertisements and adds the prefix to the corresponding virtual routing and forwarding (VRF) table.

Supported and Unsupported Features for SRv6 Network Programming in SR-TE

SRv6 TE currently supports::

  • IPv4 and IPv6 payloads.

  • Upto 6 SIDs in reduced mode at the ingress router and upto 5 SIDs in non-reduced mode at the ingress.

  • Encapsulation mode on the ingress router.

  • preserve-nexthop-hierarchy configuration under resolver for platform layer to be able to combine SIDs from SR-TE and IGP routes.

SRv6 TE currently does not support::

  • Local CSPF capabilities for SRv6 policies.

  • IPv4-colored tunnel endpoint.

  • sBFD and Telemetry.

  • PCE initiated and delegated SRv6 LSPs.

  • Auto-translation with SRv6 SIDs.

  • LDP tunneling with an SRv6 policy.

  • Logical Systems.

  • SR-TE binding SID for an SR-TE tunnel.

  • Ping or OAM for SRTE SRv6.

  • Any Static IPv4 route over SRv6 TE tunnel.

  • Insert mode for SRv6 TE.

  • SRv6 flexible algorithm for SRv6 TE LSPs.

See Also

Example: Configuring Static SR-TE Policy for an SRv6 Tunnel

Overview

This example shows how to configure static SR-TE policy for an SRv6 Tunnel. This SRv6 TE policy is useful for service providers whose networks are predominantly IPv6 and have not deployed MPLS. Such networks depend only on the IPv6 headers and header extensions for transmitting data. SRv6 network programming provides flexibility to leverage segment routing without deploying MPLS.

Topology

The following illustration depicts an SRv6 TE topology in which the device R1 and device R6 are the ingress and egress routers that support IPv4 or IPv6 devices CE1 and CE2. The devices R2, R3, R4, and R5 comprise an IPv6 only provider core network. All the devices belong to the same autonomous system. IS-IS is the interior gateway protocol in the IPv6 core and is configured to support SRv6. In this example the egress device R6 advertises the L3VPN SID to the ingress device R1, which accepts and updates the VRF table. The device R6 is configured with 2001:db8:0:a6::d06 as end-sid and the L3VPN service is exported towards CE7 to R1 with 2001:db8:0:a6::d06 as next hop. There are two segment lists: <R4, R5, R6> and <R2, R3, R6>.

Figure 6: SRv6 TE TopologySRv6 TE Topology

Requirements

This example uses the following hardware and software components:

  • Six MX Series routers.

  • Junos OS Release 21.3R1 or later.

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

Device R1

Device R2

Device R3

Device R4

Device R5

Device R6

Device CE0

Device CE7

Configuring Device R1

Step-by-Step Procedure

To configure a static SR-TE policy for an SRV6 tunnel over an IS-IS SRv6 core, perform the following steps on the R1 device:

  1. Configure the device interfaces to enable IP transport.

  2. Configure the loopback interface with IPv4 and IPv6 addresses that is used as router ID for BGP sessions.

  3. Configure the router ID and autonomous system (AS) number to propagate routing information within a set of routing devices that belong to the same AS.

  4. Configure BGP on the core-facing interface to establish internal and external peering sessions.

  5. Configure an external routing instance to_CE0 for both IPv4 and IPv6 traffic. Configure the BGP protocol for to_CE0 to enable peering and traffic transport between the provider edge devices.

  6. Configure the resolution-map map1 with ip-color mode. Configure the BGP protocol to use multiple paths and define a policy mpath-resolve that includes the multipath-resolve action and import the policy to resolve all the available paths of IBGP multipath route.

  7. Configure an import and export policy for the R1 device's VRF table.

  8. Configure the VPN type and a unique route distinguisher for each PE router participating in the routing instance.

  9. Define a policy to load-balance packets and apply the per-packet policy to enable load balancing of traffic.
  10. Define a policy v4vpn1_res_map1 and v6vpn1_res_map1 to accept the routes advertised from R1.
  11. Disable level 2, enable IS-IS as the interior gateway protocol (IGP) for routing traffic between the core devices.
  12. Enable TI-LFA for the IS-IS protocol.
  13. Configure the IPv6 index value of the node segment.

  14. Enable SRv6 globally and the locator address to indicate the SRv6 capability of the router. SRv6 SID is an IPv6 address that consists of the locator and a function. The routing protocols advertise the locator addresses.

  15. Enable preserve nexthop hierarchy for SR-TE route flavors and enable platform merge for SRv6 chain nexthops.

  16. Configure the end-dt4 and end-dt6 SID values for enabling the Layer 3 VPN services.

  17. Enable the device to advertise the SRv6 services to BGP peers and to accept the routes advertised by the egress devices.

  18. Configure the End-Sid function for the prefix segments. Specify a flavor, that is the behavior of the End-SID function as per your network requirements. Penultimate Segment Pop (PSP), Ultimate Segment Pop (USP), and Ultimate Segment Decapsulation (USP) are the three available flavors for SRv6 functions.

    Note:

    Ensure that the locator and the End-SID are in the same subnet to avoid a commit error.

  19. Configure End-X-SID function on the point-to-point (P2P) interface for the adjacency segments. Specify one or more flavor for the End-X-SID.

    Note:

    Ensure that the Locator and End-X-SID are in the same subnet to avoid a commit error. You must enable SRv6 and configure the locator at the [edit routing-options] before mapping locators to interfaces.

  20. Configure the SRv6 segment lists end-sids-segment and end-x-sids-segment-last-sid-end-sid between <R4, R5, R6> and <R2, R3, R6>.

  21. Configure the SRv6-TE tunnel between R1 and R6 with end-sids-segment weight 40 and end-x-sids-segment-last-sid-end-sid weight 30 for uncolored paths (nc_path_R1R6) and colored paths (c_path_R1R6).

Results

Check the results of the configuration:

When done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying SPRING traffic-engineered LSP

Purpose

Verifying SPRING traffic-engineered LSP on the ingress device R1

Action

From operational mode, run the show spring-traffic-engineering lsp command on the device R1.

Meaning

The output displays the SPRING traffic-engineered LSPs on the ingress device.

Verifying Transport RIB populated by SR-TE

Purpose

Verifying Transport RIB populated by SR-TE.

Action

From operational mode, run the show route protocol spring-te extensive command on the device R1.

Meaning

The output displays colored and uncolored SR-TE transport routes, with each route having three SRv6-TE segment-lists. The output also signifies that the colored and uncolored routes segment-lists follow reduced SRH encapsulation mode.

Verifying BGP Service IPv4 route over uncolored SR-TE SRv6 route End.DT4

Purpose

Verify the BGP Service IPv4 route resolves over uncolored SR-TE SRv6 route End.DT4

Action

From operational mode, run the show route 10.100.10.7 extensive expanded-nh command on the device R1.

Meaning

The output confirms that the BGP VPN IPv4 service prefix 10.100.10.7/32 is installed in the vpn.inet.0 table that resolves over uncolored SRv6-TE policy.

Verifying BGP Service IPv6 route over colored SR-TE SRv6 route End.DT6

Purpose

Verify that the BGP VPN IPv6 service route resolves over colored SRv6-TE policy.

Action

From operational mode, run the show route 2001:db8:7:255::7/128 extensive expanded-nh command on the device R1.

Meaning

The output confirms that the BGP VPN IPv6 service prefix 2001:db8:7:255::7/128 is installed in the vpn.inet6.0 table that resolves over colored SRv6-TE policy.

Verifying IPv4 Connectivity Between CE0 and CE7

Purpose

Generate pings to verify IPv4 connectivity between the CE devices over the IPv6 provider core.

Action

From operational mode, run the ping 10.100.10.7 command on the device CE0.

Meaning

The output confirms IPv4 connectivity is working between the CE device networks. This provides verification that SRv6 tunneling over an IPv6 provider core is working properly in this example.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
Junos OS Release 20.2R1
Starting in Junos OS Release 20.2R1, Junos OS provides support for controller based BGP-SRTE routes are installed as segment routing traffic-engineered (SPRING-TE) routes
18.3R1
Starting in Release 18.3R1, Junos OS supports collection of traffic statistics for both ingress IP and transit MPLS traffic in a network configured with segment routing traffic engineering policy. To enable collection of traffic statistics include the telemetry statement at the [edit protocols source-packet-routing] hierarchy level.
change-completed