Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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.

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.

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 Unicast
 Configuring 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 17.17.17.2.

Action

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

user@R0> show route 17.17.17.2 extensive active-path

Meaning

Both the packet label 299888 and the next hop 200.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

user@R3> show route table mpls.0 protocol vpn active-path label 299888 detail

Meaning

The label 299888 with VPN entry and next hop 200.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

user@R3> show route protocol arp detail match-prefix 200.200.202.2

Meaning

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

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.

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 static segment routing traffic engineering paths that are explicitly configured or learned through BGP are limited to lists of segment identifiers that represent absolute MPLS labels only.

  • A maximum of eight segment lists are supported for both BGP and 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-segment-list-depth to limit the label depth of segment routing traffic engineering policies. If maximum-segment-list-depth 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 transmission unit (MTU) on an interface to accommodate more than five labels; otherwise more than five labels might result in packet drops.

  • The 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

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:

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.
Release History Table
Release
Description
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.