Network-instances

On the SR Linux device, 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.

The SR Linux supports three types of network-instances: default, ip-vrf, and mac-vrf. Type default is the default network-instance and only one of this type is supported. Type ip-vrf is the regular network-instance; you can create multiple network-instances of this type.

Type mac-vrf functions as a broadcast domain and is associated with an ip-vrf network-instance via an Integrated Routing and Bridging (IRB) to support tunneling of Layer 2 traffic across an IP network. See mac-vrf network-instance.

Initially, the SR Linux has a default network-instance and no ip-vrf or mac-vrf network-instances.

A management network-instance, which isolates management network traffic from other network-instances configured on the device, is created by default, with the mgmt0 port automatically added to it. See Configuring the management network-instance and Interfaces.

Basic network-instance configuration

The following example creates network-instance ‟black” and associates two network subinterfaces and one loopback subinterface with it.

The configuration administratively enables the network-instance, specifies a description, and assigns it a router ID. The router ID is optional and is used as a default router identifier for protocols running within the network-instance.

The network-instance is configured to export routes and neighbors to the Linux routing table.

--{ candidate shared default }--[  ]--
# info network-instance black
 network-instance black {
        description "Sample network instance" 
        type ip-vrf
        admin-state enable
        router-id 1.1.1.1
        interface ethernet-1/1.1 {
        }
        interface ethernet-1/2.1 {
        }
        interface lo0.1 {
        }
        protocols {
            linux {
                export-routes true
                export-neighbors true
            }
        ip-forwarding {
                receive-ipv4-check true
        }
 }

In the preceding example, the receive-ipv4-check parameter is set to true; if an IPv4 packet is received on a subinterface of this network-instance, and the IPv4 operational status of the subinterface is down, then the packet is discarded. When the receive-ipv4-check parameter is set to false, IPv4 packets are received on all subinterfaces of this network-instance that are up, even if they do not have IPv4 addresses.

Path MTU discovery

Path MTU discovery is the technique for determining the MTU size on the network path between hosts. On the SR Linux, path MTU discovery is enabled by default for all network-instances, and can be manually enabled or disabled per network-instance.

If path MTU discovery is disabled, the system drops the MTU for the session to the number of bytes specified by the min-path-mtu parameter when an ICMP fragmentation-needed message is received; by default the min-path-mtu setting is 552 bytes.

--{ * candidate shared default }--[  ]--
# info network-instance black
   network-instance black  {
     mtu {
       path-mtu-discovery true
       min-path-mtu 552
      }
   }

Static routes

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 (up to 128), 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.

You can use BFD to monitor reachability between the router and the configured next hops for a static route, making BFD sessions between the local router and the defined next hops a condition for an associated static route and next hops to be operationally active. See Configuring failure detection for static routes.

Configuring static routes

To configure static routes, you specify route prefixes to point to next-hop groups, along with the metric and preference.

The following example configures IPv4 and IPv6 static route prefixes to point to next-hop groups and specifies a preference and metric for each one:

--{ * candidate shared default }--[ network-instance black ]--
# info static-routes
        static-routes {
            route 192.168.18.0/24 {
                admin-state enable
                metric 1
                preference 5
                next-hop-group static-ipv4-grp
            }
            route 2001:1::192:168:18:0/64 {
                admin-state enable
                metric 1
                preference 6
                next-hop-group static-ipv6-grp
            }
        }

The following example configures the next-hop groups for the static routes:

--{ * candidate shared default }--[ network-instance black ]--
# info next-hop-groups
        next-hop-groups {
            group static-ipv4-grp {
                admin-state enable
                nexthop 1 {
                    ip-address 172.16.0.22
                }
                nexthop 2 {
                    ip-address 172.16.0.45
                    resolve true
                }
            }
            group static-ipv6-grp {
                admin-state enable
                blackhole {
                }
            }
        }
    }

In the preceding example, an IPv4 next-hop group is configured with two next-hops. The resolve true setting allows any route in the FIB to be used to resolve the IPv4 next-hop address, provided the resolution depth is not more than 2.

The IPv6 next-hop group is configured to perform a blackhole discard action for matching packets.

Configuring failure detection for static routes

BFD can be used as a failure detection mechanism for monitoring the reachability of next hops for static routes. When BFD is enabled for a static route, it makes an active BFD session between the local router and the defined next hops required as a condition for a static route to be operationally active.

BFD is enabled for specific next-hop groups; as a result, BFD is enabled for any static route that refers to the next-hop group. If multiple next hops are defined within the next-hop group, a BFD session is established between the local address and each next hop in the next-hop group.

A static route is considered operationally up if at least one of the configured next-hop addresses can establish a BFD session. If the BFD session fails, the associated next hop is removed from the FIB as an active next hop.

The following example enables BFD for a static route next-hop:

--{ * candidate shared default }--[ network-instance black ]--
# info next-hop-groups
    next-hop-groups {
        group static-ipv4-grp {
            admin-state enable
            nexthop 1 {
                failure-detection {
                    enable-bfd {
                        local-address 1.2.34.5
                    }
                }
            }
        }
    }

A BFD session is established between the address configured with the local-address parameter and each next-hop address before that next-hop address is installed in the forwarding table.

All next-hop BFD sessions share the same timer settings, which are taken from the BFD configuration for the subinterface where the address in local-address parameter is configured. See BFD.

Aggregate routes

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.

Configuring aggregate routes

The following example specifies an aggregate route. The aggregator address setting identifies the aggregating router. By default, this is the configured router ID of the BGP instance, or 0 if BGP is not enabled.

--{ * candidate shared default }--[ network-instance black ]--
# info aggregate-routes
        aggregate-routes {
            route 172.16.0.0/24 {
                aggregator {
                    address 1.1.1.1
                }
                summary-only true
                generate-icmp true
            }
        }

When the summary-only parameter is set to true, activation of an aggregate route automatically blocks the advertisement of all of its contributing routes by BGP.

The generate-icmp true setting causes the router to generate ICMP unreachable messages for the dropped packets.

Route preferences

A route can be learned by the router from different protocols, in which case, the costs are not comparable. When a route is learned from different protocols, the preference value is used to decide which route is installed in the forwarding table if several protocols calculate routes to the same destination. The route with the lowest preference value is selected.

Different protocols should not be configured with the same preference. If protocols are configured with the same preference, the tiebreaker is per the default preference table as defined in Route preference defaults by route type. If multiple routes are learned with an identical preference using the same protocol, the lowest cost route is used.

Table 1. Route preference defaults by route type

Route Type

Preference

Configurable

Direct attached

0

No

Static routes

5

Yes

OSPF internal

10

Yes1

IS-IS level 1 internal

15

Yes

IS-IS level 2 internal

18

Yes

OSPF external

150

Yes

IS-IS level 1 external

160

Yes

IS-IS level 2 external

165

Yes

BGP

170

Yes

Note:
  1. Preference for OSPF internal routes is configured with the preference command.

Displaying network-instance status

Use the show network-instance command to display status information about network-instances configured on the device.

To display information about all configured network-instances, including the router ID, description, administrative and operational state:

--{ show }--
# show network-instance summary
+---------+---------+--------+-------+------------+--------------------------------+
|  Name   |  Type   | Admin  | Oper  | Router id  |   Description                  |
|         |         | state  | state |            |                                |
+=========+=========+========+=======+============+================================+
| default | default | enable | up    | 5.5.5.5    | Sample network instance        |
| mgmt    | ip-vrf  | enable | up    |            | Management network instance    |
| red     | ip-vrf  | enable | up    |55.55.55.55 | Network instance for bgp tests |
+---------+---------+--------+-------+------------+--------------------------------+

To limit the display to a single network-instance:

--{ show }--
# show network-instance default summary
+---------+---------+--------+-------+---------+----------------------------+
|  Name   |  Type   | Admin  | Oper  | Router  |         Description        |
|         |         | state  | state |   id    |                            |
+=========+=========+========+=======+=========+============================+
| default | default | enable | up    | 5.5.5.5 | "Sample network instance"  |
+---------+---------+--------+-------+---------+----------------------------+

To display information about the interfaces attached to a network-instance:

--{ show }--
# show network-instance default interfaces
===================================================================
Net instance    : default
Interface       : ethernet-1/1.1
Oper state      : up
Ip mtu          : 1500
                  Prefix                      Origin        Status
  =================================================================
  192.35.1.0/31                             static
  2001:192:35:1::/127                       static       preferred
  fe80::201:5ff:feff:0/64                   link-layer   preferred
===================================================================
Net instance    : default
Interface       : lo0.1
Oper state      : up
                  Prefix                      Origin        Status
  =================================================================
  5.5.5.5/32                                static
  2001:5:5:5::5/128                         static       preferred
===================================================================

The command displays the operational state, IP MTU, and assigned IPv4/IPv6 prefix for each interface. If the operational state for an interface is down, the reason for the interface being down is shown.

mac-vrf network-instance

The network instance type mac-vrf is associated with a network-instance of type default or ip-vrf via an Integrated Routing and Bridging (IRB) interface.

The mac-vrf network-instance type functions as a broadcast domain. Each mac-vrf network-instance builds a bridge table composed of MAC addresses that can be learned via the data path on network-instance interfaces or via static configuration. You can configure the size of the bridge table for each mac-vrf network instance, as well as the aging for dynamically learned MAC addresses and other parameters related to the bridge table.

The mac-vrf network-instance type features a mac duplication mechanism that monitors MAC address moves across network-instance interfaces and across interfaces.

MAC selection

Each mac-vrf network-instance builds a bridge table to forward Layer 2 frames based on a MAC address lookup. The SR Linux selects the MAC addresses to be sent for installation to the line card (XDP), based on the following priority:

  1. Local application MACs

  2. Local static MACs

  3. EVPN static (MACs coming from a MAC/IP route with the static bit set)

  4. Local duplicate MACs

  5. Learned or EVPN-learned MACs

MAC duplication detection and actions

MAC duplication is the mechanism used by SR Linux for loop prevention. MAC duplication monitors MAC addresses that move between subinterfaces. It consists of detection, actions, and process restarts.

MAC duplication detection

Detection of duplicate MAC addresses is necessary when extending broadcast domains to multiple leaf nodes. SR Linux supports a MAC duplication mechanism that monitors MAC address moves across network-instance interfaces.

A MAC address is considered a duplicate when its number of detected moves is greater than a configured threshold within a configured time frame where the moves are observed. Upon exceeding the threshold, the system holds on to the prior local destination of the MAC and executes an action.

MAC duplication actions

The action taken upon detecting one or more MAC addresses as duplicate on a subinterface can be configured for the mac-vrf network instance or for the subinterface. The following are the configurable actions:

  • oper-down – When one or more duplicate MAC addresses are detected on the subinterface, the subinterface is brought operationally down.

  • blackhole – upon detecting a duplicate mac on the subinterface, the mac will be blackholed.

  • stop learning – Upon detecting a duplicate mac on the subinterface, the MAC address will not be relearned anymore on this or any subinterface. This is the default action for a mac-vrf network instance.

  • use-network-instance-action – (Available for subinterfaces only) Use the action specified for the mac-vrf network instance. This is the default action for a subinterface.

MAC duplication process restarts

When at least one duplicate MAC address is detected, the duplicate MAC addresses are visible in the state datastore and can be displayed with the info from state mac-duplication duplicate-entries CLI command.

Configurable hold-down-time

The info from state mac-duplication duplicate-entries command also displays the hold-down-time for each duplicate MAC address. When the hold-down-time expires for all of the duplicate MAC addresses for the subinterface, the oper-down or stop-learning action is cleared, and the subinterface is brought operationally up or starts learning again.

The hold-down-time is configurable from between 2 and 60 minutes. You can optionally specify indefinite for the hold-down-time, which prevents the oper-down or stop-learning action from being cleared after a duplicate MAC address is detected; in this case, you can manually clear the oper-down or stop-learning action by changing the mac-duplication configuration or using the tools network-instance bridge-table mac-duplication command.

Bridge table configuration

The bridge table, its MAC address limit, and maximum number of entries can be configured on a per mac-vrf or per-subinterface basis.

When the size of the bridge table exceeds its maximum number of entries, the MAC addresses are removed in reverse order of the priority listed in MAC selection.

You can also configure aging for dynamically learned MAC addresses and other parameters related to the bridge table.

Deleting entries from the bridge table

The SR Linux features commands to delete duplicate or learned MAC entries from the bridge table. For a mac-vrf or subinterface, you can delete all MAC entries, MAC entries with a blackhole destination, or a specific MAC entry.

The following example clears MAC entries in the bridge table for a mac-vrf network instance that have a blackhole destination:

--{ candidate shared default }--[  ]-- 
# tools network-instance mac-vrf-1 bridge-table mac-duplication delete-blackhole-macs

The following example deletes a specified learned MAC address from the bridge table for a mac-vrf network instance:

--{ candidate shared default }--[  ]-- 
# tools network-instance mac-vrf-1 bridge-table mac-learning delete-mac 00:00:00:00:00:04

The following example clears all duplicate MAC entries in the bridge table for a subinterface:

--{ candidate shared default }--[  ]-- 
# tools interface ethernet-1/1.1 bridge-table mac-duplication delete-all-macs

mac-vrf network instance configuration

The following example configures a mac-vrf network instance and settings for the bridge table. The bridge table is set to a maximum of 500 entries. Learned MAC addresses are aged out of the bridge table after 600 seconds.

MAC duplication detection is configured so that a MAC address is considered a duplicate when its number of detected moves across network instance interfaces is greater than 3 over a 5-minute interval. In this example, the MAC address is blackholed. After the hold-down-time of 3 minutes, the MAC address is flushed from the bridge table, and the monitoring process for the MAC address is restarted.

The example includes configuration for a static MAC address in the bridge table.

The mac-vrf network instance is associated with a bridged interface and an IRB interface.

--{ candidate shared default }--[  ]--
# info network-instance mac-vrf-1
 network-instance mac-vrf-1 {
        description "Sample mac-vrf network instance" 
        type mac-vrf
        admin-state enable
        interface ethernet-1/1.1 {
        }
        interface irb1.1 {
        }
        bridge-table {
            mac-limit {
                mac-limit 500
            }
            mac-learning {
                admin-state enable
                aging {
                    admin-state enable
                    age-time 600
                }
            }
            mac-duplication {
                admin-state enable
                monitoring-window 5
                num-moves 3
                hold-down-time 3
                action blackhole
            static-mac {
                address [mac1
                }
            }
            }
        }
 }