SR Linux routing functions

On the SR Linux, you can configure one or more virtual routing instances, known as network instances. Each network instance has its own interfaces, its own protocol instances, its own route table, and its own FIB.

When a packet arrives on a subinterface associated with a network instance, it is forwarded according to the FIB of that network instance. Transit packets are normally forwarded out another subinterface of the network instance.

SR Linux supports the following types of network instances:

• default

• ip-vrf

• mac-vrf

The initial startup configuration for SR Linux has a single default network instance. By default, there are no ip-vrf or mac-vrf network instances; these must be created by explicit configuration. The ip-vrf network instances are the building blocks of Layer 3 IP VPN services, and mac-vrf network instances are the building blocks of EVPN services.

Within a network instance, you can configure BGP, OSPF, and IS-IS protocol options that apply only to that network instance. See the SR Linux Configuration Basics Guide for configuration information.

Within a network instance, you can configure static routes. Each static route is associated with an IPv4 prefix or an IPv6 prefix, which represents the packet destinations matched by the static route. Each static route belongs to a specific network instance. Different network instances can have overlapping routes (static or otherwise) because each network instance installs its own routes into its own set of route tables and FIBs.

Each static route must be associated with a statically configured next-hop group, which determines how matching packets are handled: either perform a blackhole discard action or a forwarding action. The next-hop group can specify a list of one or more next-hops, each identified by an IPv4 or IPv6 address and a resolve flag. If the resolve flag is set to false, only a direct route can be used to resolve the IPv4 or IPv6 next-hop address; if the resolve flag is set to true, any route in the FIB can be used to resolve the IPv4 or IPv6 next-hop address.

Each static route has a specified metric and preference. The metric is the IGP cost to reach the destination. The preference specifies the relative degree this static route is preferred compared to other static and non-static routes available for the same IP prefix in the same network instance.

A static route is installed in the FIB for the network instance if the following conditions are met:

• The route has the lowest preference value among all routes (static and non-static) for the IP prefix.

• The route has the lowest metric value among all static routes for the IP prefix.

If BGP is running in a network instance, all static routes of that same network instance are automatically imported into the BGP local RIB, so that they can be redistributed as BGP routes, subject to BGP export policies.

See the ‟Network instances” chapter of the SR Linux Configuration Basics Guide for configuration information.

You can specify aggregate routes for a network instance. Each aggregate route is associated with an IPv4 prefix or an IPv6 prefix, which represents the packet destinations matched by the aggregate route. As with static routes, each aggregate route belongs to a specific network instance, though different network instances can have overlapping routes because each network instance installs its own routes into its own set of route tables and FIBs.

An aggregate route can become active when it has one or more contributing routes. A route contributes to an aggregate route if all of the following conditions are met:

• The prefix length of the contributing route is greater than the prefix length of the aggregate route.

• The prefix bits of the contributing route match the prefix bits of the aggregate route up to the prefix length of the aggregate route.

• There is no other aggregate route that has a longer prefix length that meets the previous two conditions.

• The contributing route is actively used for forwarding and is not an aggregate route itself.

That is, a route can only contribute to a single aggregate route, and that aggregate route cannot recursively contribute to a less-specific aggregate route.

Aggregate routes have a fixed preference value of 130. If there is no route to the aggregate route prefix with a numerically lower preference value, then the aggregate route, when activated by a contributing route, is installed into the FIB with a blackhole next-hop. It is not possible to install an aggregate route into the route table or as a BGP route without also installing it in the FIB.

The aggregate routes are commonly advertised by BGP or another routing protocol so that the individual contributing routes no longer need to be advertised. This can speed up routing convergence and reduce RIB and FIB sizes throughout the network. If BGP is running in a network instance, all active aggregate routes of that network instance are automatically imported into the BGP local RIB so they can be redistributed as BGP routes, subject to BGP export policies.

See the ‟Network instances” chapter of the SR Linux Configuration Basics Guide for configuration information.

As with other functions on SR Linux, BGP operates as a modular application. The BGP manager application is responsible for running the BGP control plane. It subscribes to the IDB for configuration updates and listens for network instance and routing policy updates.

SR Linux supports the following BGP features:

Basic features

• Global AS configuration with local AS override per session. SR Linux always advertises 4-byte ASN capability.

• Local-address/source selection per neighbor

• EBGP and IBGP sessions

• Peer groups

• Configurable route table preference, with separate control for EBGP and IBGP routes

• Configurable TCP MSS per-neighbor

• EBGP split-horizon (always enabled)

• EBGP multihop

• BGP import and export policies

• IPv4/IPv6 default originate independent from default routes in the FIB

• AS path loop detection, with configurable threshold

• RFC 7606 error handling

• Tools commands to hard reset peer or soft reset with ROUTE_REFRESH

• Configurable trace options

• Routing policy actions to replace AS_PATH

• Options for handling the AS_PATH in received BGP routes

• BGP route reflection

Failure detection features

• Session KEEPALIVEs, with configurable hold-time and keepalive

• BGP next-hop tracking

• Fast failover (subinterface down)

• Bidirectional Forwarding Detection (BFD) for single-hop and multi-hop IPv4 and IPv6 sessions

Convergence features

• Configurable min-route-advertisement interval

• Rapid-withdrawal

• Option to wait for FIB install before advertising reachability

• Option to delay route advertisement until the address family has reached converged state (or timeout occurs)

Graceful restart

• Helper/receiving router role

• Restarting router role during warm restart

Dynamic/unconfigured BGP neighbors

• Accept incoming sessions from allowed prefix/AS ranges

Address family support

• IPv4 unicast address family with IPv4 next-hops

• IPv4 unicast address family with IPv6 next-hops: requires MP_REACH_NLRI encoding and RFC 5549 capability advertisement

• IPv6 unicast address family with IPv6 next-hops

• Configurable limits on received routes per session per-AF > log when any threshold is exceeded

Multipath/ECMP

• Each BGP route supports multiple ECMP next-hops

• Two-level ECMP: Level 1 selects BGP path/next-hop, Level 2 selects a next-hop of the route that resolves the BGP next-hop

• Max Level 1 next-hops per route and max Level 2 next-hops per BGP next-hop are configurable per NLRI address family

See the SR Linux Routing Protocols Guide for BGP configuration examples. See the SR Linux Advanced Solutions Guide for a BGP underlay routing example.

The SR Linux IS-IS manager application includes support for the following features:

• Level 1, Level 2, and Level 1/2 IS types

• Configurable Network Entity Title (NET) per IS-IS instance

• Support for IPv4/v6 routing

• ECMP support per destination

• IS-IS export policies (redistribution of other types of routes into IS-IS)

• Authentication of CSNP, PSNP, and IIH PDUs with authentication type and key, configurable per instance and per instance level. Authentication type and key for IIH PDUs are also configurable per interface and level.

• Support for authentication keychains

• Purge Originator ID TLV (RFC 6232)

• Options to ignore and suppress the attached bit

• Ability to set the overload bit immediately or to set the bit after each subsequent restart of the IS-IS manager application and leave it on for a configurable duration each time

• Control over the Link-State PDU (LSP) MTU size, with range from 490 bytes to 9490 bytes

• Configuration control over timers related to LSP lifetime, LSP refresh interval, SPF calculation triggers, and LSP generation

• Support for hello padding (strict, loose, and adaptive modes)

• Support for graceful restart, but only acting as a helper of the restarting router

• Level 1 to Level 2 route summarization

• BFD for fast failure detection

• Configurable hello timer/multiple per interface and level

• Support for wide metrics (configurable per level)

• Configurable route preference for each route type: Level 1-internal, Level 1-external, Level 2-internal and Level 2-external.

• Use of route policies to add/remove/replace one IS-IS route tag

• Multi-instance IS-IS (MI-ISIS), which allows multiple instances of IS-IS to operate on a single circuit

See the SR Linux Routing Protocols Guide for an IS-IS configuration example.

The SR Linux supports OSPFv2 and OSPFv3. The following features are supported:

• Reference bandwidth

• OSPF areas

• Stub areas

• Not So Stubby Areas (NSSAs)

• Passive interfaces

• Authentication

• Route policies

• Route redistribution to other protocols

• BFD for monitoring OSPF adjacencies

• Overload support and associated options

• Export policies (route redistribution from other protocols into OSPF, including ASBR support)

• Graceful restart

See the SR Linux Routing Protocols Guide for an OSPF configuration example.

The SR Linux supports policy-based routing. Policy-based routing controls the size and content of the routing tables, the routes that are advertised, and the best route to take to reach a destination. SR Linux routing policies allow for detailed control of IP routes learned and advertised by routing protocols such as BGP.

Each routing policy has a sequence of rules (called entries or statements) and a default action. Each statement has a numerical sequence identifier that determines its order relative to other statements in that policy. The statement supports both alphanumerical and numerical sequence identifiers. When a route is analyzed by a policy, it is evaluated by each statement in sequential order.

Each policy statement has zero or more match conditions and a base action (either accept or reject); the statement may also have route-modifying actions. A route matches a statement if it meets all of the specified match conditions.

The first statement that matches the route determines the actions that are applied to the route. If the route is not matched by any statements, the default action of the policy is applied. If there is no default action, then a protocol- and context-specific default action is applied.

See the ‟Routing policies” chapter in the SR Linux Routing Protocols Guide for a list of valid match conditions and policy actions, as well as configuration examples.

Static, BGP, OSPF, and IS-IS routes to IPv4 and IPv6 destinations are programmed into the datapath by their respective applications, with multiple IP ECMP next-hops. SR Linux load-balances packets across these IP ECMP next-hops.

When an IPv4/IPv6 packet is received on a subinterface, and it matches a route with a number of ECMP hops, the next-hop used to forward the packet is determined from a hash calculation based on the packet type (IPv4/IPv6, TCP/UDP).

SR Linux attempts to keep packets in the same flow on the same network path while distributing traffic so that each of the N ECMP next-hops carries approximately 1/Nth of the load.

On some platforms, SR Linux supports resilient hashing, which allows SR Linux to move as few flows as possible when removing or adding members to the ECMP set. Resilient hashing is particularly useful when the ECMP next-hops of an IP route correspond to network appliances or host servers that maintain state for the flows that they service, and moving flows would require state to be rebuilt.

An Access Control List (ACL) is an ordered set of rules that are evaluated on a packet-by-packet basis to determine whether access should be provided to a specific resource. ACLs can be used to drop unauthorized or suspicious packets from entering or leaving a routing device via specified interfaces.

SR Linux supports the following types of ACLs:

• Interface ACLs restrict the traffic allowed to pass through a specific set of subinterfaces. An interface ACL can be applied to the input and/or output traffic of one or more subinterfaces.

• CPM-filter ACLs filter IPv4 or IPv6 traffic that is locally terminating on the router, regardless of the subinterface, port, or line card where it enters.

• Capture-filter ACLs filter all transit and terminating IPv4 or IPv6 traffic that is arriving on any subinterface of the router. Traffic matching a capture-filter ACL can be copied to the control plane for packet capture and analysis.

• System filter ACLs evaluate traffic early in the ingress pipeline, at a stage before tunnel termination occurs and before interface filters are run. For VXLAN traffic, system filters can match and drop unauthorized VXLAN tunnel packets before they are decapsulated, based on information in the outer header.

The rules of each ACL policy are evaluated in sequential order. Filter evaluation stops at the first matching entry where all match conditions are met, at which point the actions specified in the ACL are applied to the packet.

For information about configuring ACLs, see the SR Linux ACL and Policy-Based Routing Guide.

SR Linux supports QoS policies for assigning traffic to forwarding classes or remarking traffic at egress before it leaves the router. DSCP classifier policies map incoming packets to the appropriate forwarding classes, and DSCP rewrite-rule policies mark outgoing packets with an appropriate DSCP value based on the forwarding class.

Each received packet is classified as belonging to one of eight forwarding classes. The classification depends on the packet type and subinterface configuration.

Egress queues are scheduled directly to the output port. In general, higher-numbered queues are serviced before lower-numbered queues.

Scheduling for each queue can be configured as either Strict Priority (SP) or Weighted Round-Robin (WRR). Queues configured as SP are served (in priority order, from highest forwarding class to lowest) before any of the WRR queues, even if some of the WRR queues carry higher forwarding-class traffic than some of the SP queues. After the SP queues are served, the WRR queues use the remaining bandwidth according to their configured weights.

See the SR Linux Quality of Service Guide for information about how transit and router-originated traffic is processed, and for configuration information.

Multiprotocol Label Switching (MPLS) provides the ability to set up connection-oriented paths over a connectionless IP network. MPLS facilitates network traffic flow and provides a mechanism to engineer network traffic patterns independently from routing tables.

Label Distribution Protocol (LDP) is a protocol used to distribute MPLS labels in non-traffic-engineered applications. LDP allows routers to establish label switched paths through a network by mapping network-layer routing information directly to data link layer-switched paths.

SR Linux supports the following MPLS and LDP functionality:

MPLS

• Statically configured MPLS forwarding entries

• Configurable label range

• MPLS label manager that shares the MPLS label space among client applications that require MPLS labels

LDP

• LDPv4 implementation compliant with RFC 5036

• LDP support in the default network-instance only

• Label distribution using DU (downstream unsolicited), ordered control

• Platform label space only

• Configurable label range (dynamic, non-shared label-block)

• Support for overload TLV when label-block has no free entries

• Configurable timers (hello-interval, hello-holdtime, keepalive-interval)

• Ingress LER, transit LSR, and egress LER roles for /32 IPv4 FECs

• Automatic FEC origination of the system0.0 /32 IPv4 address prefix

• /32 IPv4 FEC resolution using IGP routes, with longest prefix match option

• ECMP support with configurable next-hop limit (up to 64)

• Automatic installation of all LDP /32 IPv4 prefix FECs into TTM

• Per-peer configurable FEC limit

• Graceful restart helper capability

• BGP shortcuts for IPv4 traffic

• Protocol debug/trace-options

• LDP-IGP synchronization

• Advertise address mapping message for primary IPv4 address of the adjacent interface only.

• Non-configurable capability advertisement in INITIALIZATION messages only claiming support for:

  • State advertisement control (SAC) with interest in IPv4 prefix FECs only

  • Fault tolerance (Graceful Restart)

  • Nokia overload TLV

  • Unrecognized notification

• Split-horizon support: A label-mapping message is not advertised to a peer if the FEC matches an address sent by that peer in an Address Mapping message.

See the SR Linux MPLS Guide for configuration information.