This chapter describes key elements of SR Linux routing functions: network-instances, support for standard routing protocols including BGP and IS-IS, as well as ACLs, routing policies. and Quality of Service.
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:
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 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) since 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:
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 since 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:
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
Failure detection features
Convergence features
Graceful restart
Dynamic/unconfigured BGP neighbors
Address family support
Multipath/ECMP
See the SR Linux Configuration Basics Guide for a BGP configuration example. See the SR Linux Advanced Solutions Guide for a sample BGP underlay routing example.
The SR Linux IS-IS manager application includes support for the following features:
See the SR Linux Configuration Basics Guide for an IS-IS 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 numerical sequence identifier that determines its order relative to other statements in that policy. 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 SR Linux Configuration Basics Guide for a list of valid match conditions and policy actions, as well as configuration examples.
Static and BGP 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.
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, or 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:
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 on configuring ACLs, see the SR Linux Configuration Basics Guide.
SR Linux supports 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 Quality of Service chapter of the SR Linux Configuration Basics Guide for details about how transit and router-originated traffic is processed, and for configuration information.