Network Configuration¶

Infix aims to support all Linux Networking constructs. The YANG models used to describe the system are chosen to fit well and leverage the underlying Linux kernel's capabilities. The ietf-interfaces.yang model forms the base, extended with ietf-ip.yang and other layer-3 IETF models. The layer-2 bridge and aggregate models are defined by Infix to exploit the unique features not available in IEEE models.

Important

When issuing leave to activate your changes, remember to also save your settings, copy running-config startup-config. See the CLI Introduction for a background.

Interface LEGO®¶

The network building blocks available in Linux are akin to the popular LEGO® bricks.

Linux Networking Blocks

There are two types of relationships that can link two blocks together:

Lower-to-upper: Visually represented by an extruding square connected upwards to a square socket. An interface can only have a single lower-to-upper relationship, i.e., it can be attached to a single upper interface like a bridge or a LAG. In iproute2 parlance, this corresponds to the interface's master setting
Upper-to-lower: Visually represented by an extruding semicircle connected downwards to a semicircle socket. The lower interface in these relationships accepts multiple upper-to-lower relationships from different upper blocks. E.g., multiple VLANs and IP address blocks can be connected to the same lower interface

Stacking order dependencies

An interface may simultaneously have a lower-to-upper relation to some other interface, and be the target of one or more upper-to-lower relationships. It is valid, for example, for a physical port to be attached to a bridge, but also have a VLAN interface stacked on top of it. In this example, traffic assigned to the VLAN in question would be diverted to the VLAN interface before entering the bridge, while all other traffic would be bridged as usual.

Type	Yang Model	Description
bridge	infix-if-bridge	SW implementation of an IEEE 802.1Q bridge
ip	ietf-ip, infix-ip	IP address to the subordinate interface
vlan	infix-if-vlan	Capture all traffic belonging to a specific 802.1Q VID
lag	infix-if-lag	Link aggregation, static and IEEE 802.3ad (LACP)
lo	ietf-interfaces	Software loopback interface
eth	ieee802-ethernet-interface	Physical Ethernet device/port.
	infix-ethernet-interface
veth	infix-if-veth	Virtual Ethernet pair, typically one end is in a container
common	ietf-interfaces,	Properties common to all interface types
	infix-interfaces

Data Plane¶

The blocks you choose, and how you connect them, defines your data plane. Here we see an example of how to bridge a virtual port with a physical LAN.

Example of a 4-port switch with a link aggregate and a VETH pair to a container

Depending on the (optional) VLAN filtering of the bridge, the container may have full or limited connectivity with outside ports, as well as the internal CPU.

In fact the virtual port connected to the bridge can be member of several VLANs, with each VLAN being an interface with an IP address inside the container.

Thanks to Linux, and technologies like switchdev, that allow you to split a switching fabric into unique (isolated) ports, the full separation and virtualization of all Ethernet layer properties are possible to share with a container. Meaning, all the building blocks used on the left hand side can also be used freely on the right hand side as well.

General¶

General interface settings include type, enable, custom MAC address, and text description. Other settings have their own sections, below.

The type is important to set when configuring devices remotely because unlike the CLI, a NETCONF or RESTCONF session cannot guess the interface type for you. The operating system provides an override of the available interface types.

An enabled interface can be inspected using the operational datastore, nodes admin-state and oper-state show the status, . Possible values are listed in the YANG model.

The custom-phys-address can be used to set an interface's MAC address. This is an extension to the ietf-interfaces YANG model, which defines phys-address as read-only⁴. The following shows the different configuration options.

The description is saved as Linux ifalias on an interface. It is a free-form string, useful for describing purpose or just adding comments for remote debugging, e.g., using the operational datastore.

Caution

There is no validation or safety checks performed by the system when using custom-phys-address. In particular the offset variant can be dangerous to use -- pay attention to the meaning of bits in the upper-most octet: local bit, multicast/group, etc.

Fixed custom MAC¶

admin@example:/config/> edit interface veth0a
admin@example:/config/interface/veth0a/> set custom-phys-address static 00:ab:00:11:22:33

=> 00:ab:00:11:22:33

Chassis MAC¶

Chassis MAC, sometimes also referred to as base MAC. In these two examples it is 00:53:00:c0:ff:ee.

admin@example:/config/> edit interface veth0a
admin@example:/config/interface/veth0a/> set custom-phys-address chassis

=> 00:53:00:c0:ff:ee

Chassis MAC, with offset¶

When constructing a derived address it is recommended to set the locally administered bit. Same chassis MAC as before.

admin@example:/config/> edit interface veth0a
admin@example:/config/interface/veth0a/> set custom-phys-address chassis offset 02:00:00:00:00:02

=> 02:53:00:c0:ff:f0

Bridging¶

This is the most central part of the system. A bridge is a switch, and a switch is a bridge. In Linux, setting up a bridge with ports connected to physical switch fabric, means you manage the actual switch fabric!

MAC Bridge¶

In Infix ports are by default not switch ports, unless the customer specific factory config sets it up this way. To enable switching, with offloading if you have a switch chipset, between ports you create a bridge and then add ports to that bridge. Like this:

admin@example:/> configure
admin@example:/config/> edit interface br0
admin@example:/config/interface/br0/> up
admin@example:/config/> set interface eth0 bridge-port bridge br0
admin@example:/config/> set interface eth1 bridge-port bridge br0
admin@example:/config/> leave

Here we add two ports to bridge br0: eth0 and eth1.

Tip

The CLI has several built-in helpers governed by convention. E.g., naming bridges brN, where N is a number, the type is inferred automatically and unlocks all bridge features. Other conventions are vethNA, where N is a number and A is a letter ('a' for access port and 'b' for bridge side is common), and ethN.M for VLAN M on top of ethN, or dockerN for a IP masquerading container bridge.

Note, this inference only works with the CLI, configuring networking over NETCONF or RESTCONF requires setting the type explicitly.

A MAC bridge with two ports

It is possible to create multiple MAC bridges, however, it is currently⁵ not recommended to use more than one MAC bridge on products with Marvell LinkStreet switching ASICs. A VLAN filtering bridge should be used instead.

VLAN Filtering Bridge¶

By default bridges in Linux do not filter based on VLAN tags. This can be enabled when creating a bridge by adding a port to a VLAN as a tagged or untagged member. Use the port default VID (PVID) setting to control VLAN association for traffic ingressing a port untagged (default PVID: 1).

admin@example:/config/> edit interface br0
admin@example:/config/interface/br0/> up
admin@example:/config/> set interface eth0 bridge-port bridge br0
admin@example:/config/> set interface eth0 bridge-port pvid 10
admin@example:/config/> set interface eth1 bridge-port bridge br0
admin@example:/config/> set interface eth1 bridge-port pvid 20
admin@example:/config/> edit interface br0
admin@example:/config/interface/br0/> set bridge vlans vlan 10 untagged eth0
admin@example:/config/interface/br0/> set bridge vlans vlan 20 untagged eth1

This sets eth0 as an untagged member of VLAN 10 and eth1 as an untagged member of VLAN 20. Switching between these ports is thus prohibited.

A VLAN bridge with two VLANs

To terminate a VLAN in the switch itself, either for switch management or for routing, the bridge must become a (tagged) member of the VLAN.

admin@example:/config/interface/br0/> set bridge vlans vlan 10 tagged br0
admin@example:/config/interface/br0/> set bridge vlans vlan 20 tagged br0

To route or to manage via a VLAN, a VLAN interface needs to be created on top of the bridge, see section VLAN Interfaces below for more on this topic.

Note

In some use-cases only a single management VLAN on the bridge is used. For the example above, if the bridge itself is an untagged member only in VLAN 10, IP addresses can be set directly on the bridge without the need for dedicated VLAN interfaces on top of the bridge.

Multicast Filtering and Snooping¶

Multicast filtering in the bridge is handled by the bridge itself. It can filter both IP multicast and MAC multicast. For IP multicast it also supports "snooping", i.e., IGMP and MLD, to automatically reduce the broadcast effects of multicast. See the next section for a summary of the terminology used.

Important

Currently there is no way to just enable multicast filtering without also enabling snooping. This may change in the future, in which case a filtering enabled setting will be made available along with the existing snooping setting.

When creating your bridge you must decide if you need a VLAN filtering bridge or a plain bridge (see previous section). Multicast filtering is supported for either, but take note that it must be enabled and set up per VLAN when VLAN filtering is enabled -- there are no global multicast settings in this operating mode.

In the following example we have a regular 8-port bridge without VLAN filtering. We focus on the multicast specific settings:

admin@example:/> configure
admin@example:/config/> edit interface br0
admin@example:/config/interface/br0/> set bridge multicast snooping
admin@example:/config/interface/br0/> set ipv4 address 192.168.2.1 prefix-length 24
admin@example:/config/interface/br0/> leave
admin@example:/> copy running-config startup-config

Here we enable snooping and set a static IPv4 address so that the switch can take part in IGMP querier elections. (MLD querier election currently not supported.) We can inspect the current state:

admin@example:/> show ip multicast
Multicast Overview
Query Interval (default): 125 sec
Router Timeout          : 255
Fast Leave Ports        :
Router Ports            :
Flood Ports             : e0, e1, e2, e3, e4, e5, e6, e7

Interface       VID  Querier                     State  Interval  Timeout  Ver
br0                  192.168.2.1                    Up       125     None    3

Bridge          VID  Multicast Group       Ports
br0                  224.1.1.1             e3, e2
br0                  ff02::6a              br0

This is a rather small LAN, so our bridge has already become the elected IGMP querier. We see it is ours because the timeout is None, and we recognize the IP address the system has detected, as ours. We can also see two ports that have joined the same IPv4 multicast group, 224.1.1.1, and one join from the system itself for the IPv6 group ff02::6a.

Now, let us see what happens when we add another bridge, this time with VLAN filtering enabled. We skip the boring parts about how to move ports e4-e7 to br1 and assign them to VLANs, and again, focus on the multicast bits only:

admin@example:/> configure
admin@example:/config/> edit interface br1
admin@example:/config/interface/br1/> set bridge vlans vlan 1 multicast snooping
admin@example:/config/interface/br1/> set bridge vlans vlan 2 multicast snooping
admin@example:/config/interface/br1/> leave
admin@example:/> copy running-config startup-config

Let us see what we get:

admin@example:/> show ip multicast
Multicast Overview
Query Interval (default): 125 sec
Router Timeout          : 255
Fast Leave Ports        : e5
Router Ports            : e1, e2, e5, e6, e7
Flood Ports             : e1, e2, e3, e4, e5, e6, e7, e8

Interface       VID  Querier                     State  Interval  Timeout  Ver
br0                  192.168.2.1                    Up       125     None    3
br1               1  0.0.0.0                        Up       125     None    3
br1               2  0.0.0.0                        Up       125     None    3

Bridge          VID  Multicast Group       Ports
br0                  224.1.1.1             e2
br0                  ff02::fb              br0
br0                  ff02::6a              br0
br0                  ff02::1:ff00:0        br0
br1               1  224.1.1.1             e5
br1               2  224.1.1.1             e7
br1               1  ff02::fb              br1
br1               1  ff02::1:ff00:0        br1

In this setup we have a lot more going on. Multiple multicast router ports have been detected, and behind the scenes someone has also added an IGMP/MLD fast-leave port.

Terminology & Abbreviations¶

IGMP: Internet Group Membership Protocol, multicast subscription for IPv4, for details see RFC3376
MLD: Multicast Listener Discovery (Protocol), multicast subscription for IPv6, for details see RFC3810
Unknown/Unregistered multicast: multicast groups that are not in the multicast forwarding database (MDB)
Known/Registered multicast: multicast groups that are in the multicast forwarding database (MDB)
MDB: the multicast forwarding database, consists of filters for multicast groups, directing where multicast is allowed to egress. A filter entry consists of a group and a port list. The bridge filters with a unique database per VLAN, in the same was as the unicast FDB
Join/Leave: the terminology used in earlier versions of the two protocols to subscribe and unsubscribe to a multicast group. For more information, see Membership Report
Membership Report A membership report is sent by end-devices and forwarded by switches to the elected querier on the LAN. They consist of multiple "join" and "leave" operations on groups. They can also, per group, list which senders to allow or block. Switches usually only support the group subscription, and even more common also only support filtering on the MAC level³
Querier election: the process of determining who is the elected IGMP/MLD querier on a LAN. Lowest numerical IP address wins, the special address 0.0.0.0 (proxy querier) never wins
Proxy querier: when no better querier exists on a LAN, one or more devices can send proxy queries with source address 0.0.0.0 (or :: for IPv6). See Query Interval, below, why this is a good thing
Query interval: the time in seconds between two queries from an IGMP/MLD querier. It is not uncommon that end-devices do not send their membership reports unless they first hear a query
Fast Leave: set on a bridge port to ensure multicast is pruned as quickly as possible when a "leave" membership report is received. In effect, this option marks the port as directly connected to an end-device. When not set (default), a query with timeout is first sent to ensure no unintentional loss of multicast is incurred
Router port: can be both configured statically and detected at runtime based on connected devices, usually multicast routers. On a router port all multicast is forwarded, both known and unknown
Flood port: set on a bridge port (default: enabled) to ensure all unknown multicast is forwarded
Router timeout: the time in seconds until a querier is deemed to have been lost and another device (switch/router) takes over. In the tables shown above, a None timeout is declared when the current device is the active querier

Tip

The reason why multicast flooding is enabled by default is to ensure safe co-existence with MAC multicast, which is common in industrial networks. It also allows end devices that do not know of IGMP/MLD to communicate over multicast as long as the group they have chosen is not used by other IGMP/MLD aware devices on the LAN.

As soon as an IGMP/MLD membership report to "join" a group is received the group is added to the kernel MDB and forwarding to other ports stop. The only exception to this rule is multicast router ports.

If your MAC multicast forwarding is not working properly, it may be because an IP multicast group maps to the same MAC address. Please see RFC 1112 for details. Use static multicast router ports, or static multicast MAC filters, to mitigate.

Forwarding of IEEE Reserved Group Addresses¶

Addresses in the range 01:80:C2:00:00:0X are used by various bridge signaling protocols, and are not forwarded by default. Still, it is sometimes useful to let the bridge forward such packets, this can be done by specifying protocol names or the last address nibble as decimal value 0..15:

admin@example:/config/> edit interface br0 bridge
admin@example:/config/interface/br0/bridge/> set ieee-group-forward     # Tap the ? ley for alternatives
  [0..15]  List of IEEE link-local protocols to forward, e.g., STP, LLDP
  dot1x    802.1X Port-Based Network Access Control.
  lacp     802.3 Slow Protocols, e.g., LACP.
  lldp     802.1AB Link Layer Discovery Protocol (LLDP).
  stp      Spanning Tree (STP/RSPT/MSTP).
admin@example:/config/interface/br0/bridge/> set ieee-group-forward

The following example configures bridge br0 to forward LLDP packets.

admin@example:/config/interface/br0/bridge/> set ieee-group-forward lldp
admin@example:/config/interface/br0/bridge/>

Link Aggregation¶

A link aggregate, or lag, allows multiple physical interfaces to be combined into a single logical interface, providing increased bandwidth (in some cases) and redundancy (primarily). Two modes of qualifying lag member ports are available:

static: Active members selected based on link status (carrier)
lacp: IEEE 802.3ad Link Aggregation Control Protocol

In LACP mode, LACPDUs are exchanged by the link partners to qualify each lag member, while in static mode only carrier is used. This additional exchange in LACP ensures traffic can be forwarded in both directions.

Traffic distribution, for both modes, across the active lag member ports is determined by the hash policy¹. It uses an XOR of the source, destination MAC addresses and the EtherType field. This, IEEE 802.3ad-compliant, algorithm will place all traffic to a particular network peer on the same link. Meaning there is no increased bandwidth for communication between two specific devices.

Tip

Similar to other interface types, naming your interface lagN, where N is a number, allows the CLI to automatically infer the interface type as LAG.

Basic Configuration¶

Creating a link aggregate interface and adding member ports:

admin@example:/> configure
admin@example:/config/> edit interface lag0
admin@example:/config/interface/lag0/> set lag mode static
admin@example:/config/interface/lag0/> end
admin@example:/config/> set interface eth7 lag-port lag lag0
admin@example:/config/> set interface eth8 lag-port lag lag0
admin@example:/config/> leave

A static lag responds only to link (carrier) changes of member ports. E.g., in this example egressing traffic is continuously distributed over the two links until link down on one link is detected, triggering all traffic to be steered to the sole remaining link.

LACP Configuration¶

LACP mode provides dynamic negotiation of the link aggregate. Key settings include:

admin@example:/> configure
admin@example:/config/> edit interface lag0
admin@example:/config/interface/lag0/> set lag mode lacp
admin@example:/config/interface/lag0/> set lag lacp mode passive
admin@example:/config/interface/lag0/> set lag lacp rate fast
admin@example:/config/interface/lag0/> set lag lacp system-priority 100

LACP mode supports two operational modes:

active: Initiates negotiation by sending LACPDUs (default)
passive: Waits for peer to initiate negotiation

Note

At least one end of the link must be in active mode for negotiation to occur.

The LACP rate setting controls protocol timing:

slow: LACPDUs sent every 30 seconds, with 90 second timeout (default)
fast: LACPDUs sent every second, with 3 second timeout

Link Flapping¶

To protect against link flapping, debounce timers can be configured to delay link qualification. Usually only the up delay is needed:

admin@example:/config/interface/lag0/lag/link-monitor/> edit debounce
admin@example:/config/interface/lag0/lag/link-monitor/debounce/> set up 500
admin@example:/config/interface/lag0/lag/link-monitor/debounce/> set down 200

Operational Status, Overview¶

Like other interfaces, link aggregates are also available in the general interfaces overview in the CLI admin-exec context. Here is the above static mode aggregate:

admin@example:/> show interfaces
INTERFACE       PROTOCOL   STATE       DATA
lo              ethernet   UP          00:00:00:00:00:00
                ipv4                   127.0.0.1/8 (static)
                ipv6                   ::1/128 (static)
.
.
.
lag0            lag        UP          static: balance-xor, hash: layer2
│               ethernet   UP          00:a0:85:00:02:00
├ eth7          lag        ACTIVE
└ eth8          lag        ACTIVE

Same aggregate, but in LACP mode:

admin@example:/> show interfaces
INTERFACE       PROTOCOL   STATE       DATA
lo              ethernet   UP          00:00:00:00:00:00
                ipv4                   127.0.0.1/8 (static)
                ipv6                   ::1/128 (static)
.
.
.
lag0            lag        UP          lacp: active, rate: fast (1s), hash: layer2
│               ethernet   UP          00:a0:85:00:02:00
├ eth7          lag        ACTIVE      active, short_timeout, aggregating, in_sync, collecting, distributing
└ eth8          lag        ACTIVE      active, short_timeout, aggregating, in_sync, collecting, distributing

Operational Status, Detail¶

In addition to basic status shown in the interface overview, detailed LAG status can be inspected:

admin@example:/> show interfaces name lag0
name                : lag0
index               : 25
mtu                 : 1500
operational status  : up
physical address    : 00:a0:85:00:02:00
lag mode            : static
lag type            : balance-xor
lag hash            : layer2
link debounce up    : 0 msec
link debounce down  : 0 msec
ipv4 addresses      :
ipv6 addresses      :
in-octets           : 0
out-octets          : 2142

Same aggregate, but in LACP mode:

admin@example:/> show interfaces name lag0
name                : lag0
index               : 24
mtu                 : 1500
operational status  : up
physical address    : 00:a0:85:00:02:00
lag mode            : lacp
lag hash            : layer2
lacp mode           : active
lacp rate           : fast (1s)
lacp aggregate id   : 1
lacp system priority: 65535
lacp actor key      : 9
lacp partner key    : 9
lacp partner mac    : 00:a0:85:00:03:00
link debounce up    : 0 msec
link debounce down  : 0 msec
ipv4 addresses      :
ipv6 addresses      :
in-octets           : 100892
out-octets          : 111776

Member ports provide additional status information:

Link failure counter: number of detected link failures
LACP state flags: various states of LACP negotiation:
active: port is actively sending LACPDUs
short_timeout: using fast rate (1s) vs. slow rate (30s)
aggregating: port is allowed to aggregate in this LAG
in_sync: port is synchronized with partner
collecting: port is allowed to receive traffic
distributing: port is allowed to send traffic
defaulted: using default partner info (partner not responding)
expired: partner info has expired (no LACPDUs received)
Aggregator ID: unique identifier for this LAG group
Actor state: LACP state flags for this port (local)
Partner state: LACP state flags from the remote port

Example member port status:

admin@example:/> show interfaces name eth7
name                : eth7
index               : 8
mtu                 : 1500
operational status  : up
physical address    : 00:a0:85:00:02:00
lag member          : lag0
lag member state    : active
lacp aggregate id   : 1
lacp actor state    : active, short_timeout, aggregating, in_sync, collecting, distributing
lacp partner state  : active, short_timeout, aggregating, in_sync, collecting, distributing
link failure count  : 0
ipv4 addresses      :
ipv6 addresses      :
in-octets           : 473244
out-octets          : 499037

Example: Switch Uplink with LACP¶

LACP mode provides the most robust operation, automatically negotiating the link aggregate and detecting configuration mismatches.

A common use case is connecting a switch to an upstream device:

admin@example:/> configure
admin@example:/config/> edit interface lag0
admin@example:/config/interface/lag0/> set lag mode lacp

Enable fast LACP for quicker fail-over:

admin@example:/config/interface/lag0/> set lag lacp rate fast

Add uplink ports

admin@example:/config/interface/lag0/> end
admin@example:/config/> set interface eth7 lag-port lag lag0
admin@example:/config/> set interface eth8 lag-port lag lag0

Enable protection against "link flapping".

admin@example:/config/interface/lag0/> edit lag link-monitor
admin@example:/config/interface/lag0/lag/link-monitor/> edit debounce
admin@example:/config/interface/lag0/lag/link-monitor/debounce/> set up 500
admin@example:/config/interface/lag0/lag/link-monitor/debounce/> set down 200
admin@example:/config/interface/lag0/lag/link-monitor/debounce/> top

Add to bridge for switching

admin@example:/config/interface/lag0/lag/link-monitor/debounce/> end
admin@example:/config/> set interface lag0 bridge-port bridge br0
admin@example:/config/> leave

VLAN Interfaces¶

Creating a VLAN can be done in many ways. This section assumes VLAN interfaces created atop another Linux interface. E.g., the VLAN interfaces created on top of the Ethernet interface or bridge in the picture below.

VLAN interface on top of Ethernet or Bridge interfaces

A VLAN interface is basically a filtering abstraction. When you run tcpdump on a VLAN interface you will only see the frames matching the VLAN ID of the interface, compared to all the VLAN IDs if you run tcpdump on the lower-layer interface.

admin@example:/> configure
admin@example:/config/> edit interface eth0.20
admin@example:/config/interface/eth0.20/> show
type vlan;
vlan {
  tag-type c-vlan;
  id 20;
  lower-layer-if eth0;
}
admin@example:/config/interface/eth0.20/> leave

The example below assumes bridge br0 is already created, see VLAN Filtering Bridge.

admin@example:/> configure
admin@example:/config/> edit interface vlan10
admin@example:/config/interface/vlan10/> set vlan id 10
admin@example:/config/interface/vlan10/> set vlan lower-layer-if br0
admin@example:/config/interface/vlan10/> leave

As conventions, a VLAN interface for VID 20 on top of an Ethernet interface eth0 is named eth0.20, and a VLAN interface for VID 10 on top of a bridge interface br0 is named vlan10.

Note

If you name your VLAN interface foo0.N or vlanN, where N is a number, the CLI infers the interface type automatically.

Physical Ethernet Interfaces¶

Ethernet Settings and Status¶

Physical Ethernet interfaces provide low-level settings for speed/duplex as well as packet status and statistics.

By default, Ethernet interfaces defaults to auto-negotiating speed/duplex modes, advertising all speed and duplex modes available. In the example below, the switch would by default auto-negotiate speed 1 Gbit/s on port eth1 and 100 Mbit/s on port eth4, as those are the highest speeds supported by H1 and H2 respectively.

4-port Gbit/s switch connected to Gbit and Fast Ethernet Hosts

The speed and duplex status for the links can be listed as shown below, assuming the link operational status is 'up'.

admin@example:/> show interfaces name eth1
name                : eth1
index               : 2
mtu                 : 1500
operational status  : up
auto-negotiation    : on
duplex              : full
speed               : 1000
physical address    : 00:53:00:06:11:01
ipv4 addresses      :
ipv6 addresses      : 
in-octets           : 75581
out-octets          : 43130
...
admin@example:/> show interfaces name eth4
name                : eth4
index               : 5
mtu                 : 1500
operational status  : up
auto-negotiation    : on
duplex              : full
speed               : 100
physical address    : 00:53:00:06:11:04
ipv4 addresses      :
ipv6 addresses      : 
in-octets           : 75439
out-octets          : 550704
...
admin@example:/>

Configuring fixed speed and duplex¶

Auto-negotiation of speed/duplex mode is desired in almost all use-cases, but it is possible to disable auto-negotiation and specify a fixed speed and duplex mode.

Important

When setting a fixed speed and duplex mode, ensure both sides of the link have matching configuration. If speed does not match, the link will not come up. If duplex mode does not match, the result is reported collisions and/or bad throughput.

The example below configures port eth3 to fixed speed 100 Mbit/s half-duplex mode.

admin@example:/> configure
admin@example:/config/> edit interface eth3 ethernet
admin@example:/config/interface/eth3/ethernet/> set speed 0.1
admin@example:/config/interface/eth3/ethernet/> set duplex half
admin@example:/config/interface/eth3/ethernet/> set auto-negotiation enable false
admin@example:/config/interface/eth3/ethernet/> show
auto-negotiation {
  enable false;
}
duplex half;
speed 0.1;
admin@example:/config/interface/eth3/ethernet/> leave
admin@example:/>

Speed metric is in Gbit/s. Auto-negotiation needs to be disabled in order for fixed speed/duplex to apply. Only speeds 0.1(100 Mbit/s) and 0.01 (10 Mbit/s) can be specified. 1 Gbit/s and higher speeds require auto-negotiation to be enabled.

Ethernet statistics¶

Ethernet packet statistics⁶ can be listed as shown below.

admin@example:/> show interfaces name eth1
name                : eth1
index               : 2
mtu                 : 1500
operational status  : up
auto-negotiation    : on
duplex              : full
speed               : 1000
physical address    : 00:53:00:06:11:0a
ipv4 addresses      :
ipv6 addresses      : 
in-octets           : 75581
out-octets          : 43130

eth-in-frames                : 434
eth-in-multicast-frames      : 296
eth-in-broadcast-frames      : 138
eth-in-error-fcs-frames      : 0
eth-in-error-oversize-frames : 0
eth-out-frames               : 310
eth-out-multicast-frames     : 310
eth-out-broadcast-frames     : 0
eth-out-good-octets          : 76821
eth-in-good-octets           : 60598
admin@example:/>

VETH Pairs¶

A Virtual Ethernet (VETH) pair is basically a virtual Ethernet cable. A cable can be "plugged in" to a bridge and the other end can be given to a container, or plugged into another bridge.

The latter example is useful if you have multiple bridges in the system with different properties (VLAN filtering, IEEE group forwarding, etc.), but still want some way of communicating between these domains.

admin@example:/> configure
admin@example:/config/> edit interface veth0a
admin@example:/config/interface/veth0a/> set veth peer veth0b
admin@example:/config/interface/veth0a/> end
admin@example:/config/> diff
interfaces {
+  interface veth0a {
+    type veth;
+    veth {
+      peer veth0b;
+    }
+  }
+  interface veth0b {
+    type veth;
+    veth {
+      peer veth0a;
+    }
+  }
}
admin@example:/config/>

Tip

This is another example of the automatic inference of the interface type from the name. Any name can be used, but then you have to set the interface type to veth manually.

Management Plane¶

This section details IP Addresses And Other Per-Interface IP settings.

Infix support several network interface types, each can be assigned one or more IP addresses, both IPv4 and IPv6 are supported. (There is no concept of a "primary" address.)

IP on top of network interface examples

IPv4 Address Assignment¶

Multiple address assignment methods are available:

Type	Yang Model	Description
static	ietf-ip	Static assignment of IPv4 address, e.g., 10.0.1.1/24
link-local	infix-ip	Auto-assignment of IPv4 address in 169.254.x.x/16 range
dhcp	infix-dhcp-client	Assignment of IPv4 address by DHCP server, e.g., 10.0.1.1/24

Note

The DHCP address method is only available for LAN interfaces (Ethernet, virtual Ethernet (veth), bridge, link aggregates, etc.)

Supported DHCP (request) options, configurability (Cfg) and defaults, are listed below. Configurable options can be disabled on a per client interface basis, some options, like clientid and option 81, are possible to set the value of as well.

Opt	Name	Cfg	Description
1	`netmask`	No	Request IP address and netmask
3	`router`	Yes	Default route(s), see also option 121 and 249
6	`dns-server`	Yes	DNS server(s), static ones take precedence
12	`hostname`	Yes	DHCP cannot set hostname, only for informing server
15	`domain`	Yes	Default domain name, for name resolution
28	`broadcast`	Yes	Broadcast address, calculated if disabled
42	`ntp-server`	Yes	NTP server(s), static ones take precedence
50	`address`	Yes	Request (previously cached) address
61	`client-id`	Yes	Default MAC address (and option 12)
81	`fqdn`	Yes	Similar to option 12, request FQDN update in DNS
119	`search`	Yes	Request domain search list
121	`classless-static-route`	Yes	Classless static routes
249	`ms-classless-static-route`	Yes	Microsoft static route, same as option 121

Default: router, dns-server, domain, broadcast, ntp-server, search, address, classless-static-route, ms-classless-static-route

When configuring a DHCP client, ensure that the NTP client is enabled for the ntp-server DHCP option to be processed correctly. If the NTP client is not enabled, any NTP servers provided by the DHCP server will be ignored. For details on how to enable the NTP client, see the NTP Client Configuration section.

Important

Per RFC3442, if the DHCP server returns both a Classless Static Routes option (121) and Router option (3), the DHCP client must ignore the latter.

IPv6 Address Assignment¶

Multiple address assignment methods are available:

Type	Yang Model	Description
static	ietf-ip	Static assignment of IPv6 address, e.g., 2001:db8:0:1::1/64
link-local	ietf-ip²	(RFC4862) Auto-configured link-local IPv6 address (fe80::0 prefix + interface identifier, e.g., fe80::ccd2:82ff:fe52:728b/64)
global auto-conf	ietf-ip	(RFC4862) Auto-configured (stateless) global IPv6 address (prefix from router + interface identifier, e.g., 2001:db8:0:1:ccd2:82ff:fe52:728b/64

Both for link-local and global auto-configuration, it is possible to auto-configure using a random suffix instead of the interface identifier.

Examples¶

Switch example (eth0 and lo)

admin@example:/> show interfaces
INTERFACE       PROTOCOL   STATE       DATA
eth0            ethernet   UP          02:00:00:00:00:00
                ipv6                   fe80::ff:fe00:0/64 (link-layer)
lo              ethernet   UP          00:00:00:00:00:00
                ipv4                   127.0.0.1/8 (static)
                ipv6                   ::1/128 (static)
admin@example:/>

To illustrate IP address configuration, the examples below uses a switch with a single Ethernet interface (eth0) and a loopback interface (lo). As shown above, these examples assume eth0 has an IPv6 link-local address and lo has static IPv4 and IPv6 addresses by default.

Static and link-local IPv4 addresses¶

Setting static IPv4 (and link-local IPv4)

admin@example:/> configure
admin@example:/config/> edit interface eth0 ipv4
admin@example:/config/interface/eth0/ipv4/> set address 10.0.1.1 prefix-length 24
admin@example:/config/interface/eth0/ipv4/> set autoconf enabled true
admin@example:/config/interface/eth0/ipv4/> diff
+interfaces {
+  interface eth0 {
+    ipv4 {
+      address 10.0.1.1 {
+        prefix-length 24;
+      }
+      autoconf {
+        enabled true;
+      }
+    }
+  }
+}
admin@example:/config/interface/eth0/ipv4/> leave
admin@example:/> show interfaces
INTERFACE       PROTOCOL   STATE       DATA
eth0            ethernet   UP          02:00:00:00:00:00
                ipv4                   169.254.1.3/16 (random)
                ipv4                   10.0.1.1/24 (static)
                ipv6                   fe80::ff:fe00:0/64 (link-layer)
lo              ethernet   UP          00:00:00:00:00:00
                ipv4                   127.0.0.1/8 (static)
                ipv6                   ::1/128 (static)
admin@example:/>

As shown, the link-local IPv4 address is configured with set autconf enabled true. The resulting address (169.254.1.3/16) is of type random (ietf-ip.yang).

The IPv4LL client also supports a request-address setting which can be used to "seed" the client's starting address. If the address is free it will be used, otherwise it falls back to the default algorithm.

admin@example:/config/interface/eth0/ipv4/> set autoconf request-address 169.254.1.2

Use of DHCP for IPv4 address assignment¶

Using DHCP for IPv4 address assignment

admin@example:/> configure
admin@example:/config/> edit dhcp-client
admin@example:/config/dhcp-client/> set client-if eth0
admin@example:/config/dhcp-client/> leave
admin@example:/> show interfaces
INTERFACE       PROTOCOL   STATE       DATA
eth0            ethernet   UP          02:00:00:00:00:00
                ipv4                   10.1.2.100/24 (dhcp)
                ipv6                   fe80::ff:fe00:0/64 (link-layer)
lo              ethernet   UP          00:00:00:00:00:00
                ipv4                   127.0.0.1/8 (static)
                ipv6                   ::1/128 (static)
admin@example:/>

The resulting address (10.1.2.100/24) is of type dhcp.

Disabling IPv6 link-local address(es)¶

The (only) way to disable IPv6 link-local addresses is by disabling IPv6 on the interface.

admin@example:/> configure
admin@example:/config/> edit interface eth0 ipv6
admin@example:/config/interface/eth0/ipv6/> set enabled false
admin@example:/config/interface/eth0/ipv6/> leave
admin@example:/> show interfaces
INTERFACE       PROTOCOL   STATE       DATA
eth0            ethernet   UP          02:00:00:00:00:00
lo              ethernet   UP          00:00:00:00:00:00
                ipv4                   127.0.0.1/8 (static)
                ipv6                   ::1/128 (static)
admin@example:/>

Static IPv6 address¶

Setting static IPv6

admin@example:/> configure
admin@example:/config/> edit interface eth0 ipv6
admin@example:/config/interface/eth0/ipv6/> set address 2001:db8::1 prefix-length 64
admin@example:/config/interface/eth0/ipv6/> leave
admin@example:/> show interfaces
INTERFACE       PROTOCOL   STATE       DATA
eth0            ethernet   UP          02:00:00:00:00:00
                ipv6                   2001:db8::1/64 (static)
                ipv6                   fe80::ff:fe00:0/64 (link-layer)
lo              ethernet   UP          00:00:00:00:00:00
                ipv4                   127.0.0.1/8 (static)
                ipv6                   ::1/128 (static)
admin@example:/>

Stateless Auto-configuration of Global IPv6 Address¶

Auto-configuration of global IPv6

Stateless address auto-configuration of global addresses is enabled by default. The address is formed by concatenating the network prefix advertised by the router (here 2001:db8:0:1::0/64) and the interface identifier. The resulting address is of type link-layer, as it is formed based on the interface identifier (ietf-ip.yang).

admin@example:/> show interfaces
INTERFACE       PROTOCOL   STATE       DATA
eth0            ethernet   UP          02:00:00:00:00:00
                ipv6                   2001:db8:0:1:0:ff:fe00:0/64 (link-layer)
                ipv6                   fe80::ff:fe00:0/64 (link-layer)
lo              ethernet   UP          00:00:00:00:00:00
                ipv4                   127.0.0.1/8 (static)
                ipv6                   ::1/128 (static)
admin@example:/>

Disabling auto-configuration of global IPv6 addresses can be done as shown below.

admin@example:/> configure
admin@example:/config/> edit interface eth0 ipv6
admin@example:/config/interface/eth0/ipv6/> set autoconf create-global-addresses false
admin@example:/config/interface/eth0/ipv6/> leave
admin@example:/> show interfaces
INTERFACE       PROTOCOL   STATE       DATA
eth0            ethernet   UP          02:00:00:00:00:00
                ipv6                   fe80::ff:fe00:0/64 (link-layer)
lo              ethernet   UP          00:00:00:00:00:00
                ipv4                   127.0.0.1/8 (static)
                ipv6                   ::1/128 (static)
admin@example:/>

Random Link Identifiers for IPv6 Stateless Autoconfiguration¶

Auto-configuration of global IPv6

By default, the auto-configured link-local and global IPv6 addresses are formed from a link-identifier based on the MAC address.

admin@example:/> show interfaces
INTERFACE       PROTOCOL   STATE       DATA
eth0            ethernet   UP          02:00:00:00:00:00
                ipv6                   2001:db8:0:1:0:ff:fe00:0/64 (link-layer)
                ipv6                   fe80::ff:fe00:0/64 (link-layer)
lo              ethernet   UP          00:00:00:00:00:00
                ipv4                   127.0.0.1/8 (static)
                ipv6                   ::1/128 (static)
admin@example:/>

To avoid revealing identity information in the IPv6 address, it is possible to specify use of a random identifier (ietf-ip.yang and RFC8981).

admin@example:/> configure
admin@example:/config/> edit interface eth0 ipv6
admin@example:/config/interface/eth0/ipv6/> set autoconf create-temporary-addresses true
admin@example:/config/interface/eth0/ipv6/> leave
admin@example:/> show interfaces
INTERFACE       PROTOCOL   STATE       DATA
eth0            ethernet   UP          02:00:00:00:00:00
                ipv6                   2001:db8:0:1:b705:8374:638e:74a8/64 (random)
                ipv6                   fe80::ad3d:b274:885a:9ffb/64 (random)
lo              ethernet   UP          00:00:00:00:00:00
                ipv4                   127.0.0.1/8 (static)
                ipv6                   ::1/128 (static)
admin@example:/>

Both the link-local address (fe80::) and the global address (2001:) have changed type to random.

IPv4 forwarding¶

To be able to route (static or dynamic) on the interface it is required to enable forwarding. This setting controls if packets received on this interface can be forwarded.

admin@example:/config/> edit interface eth0
admin@example:/config/interface/eth0/> set ipv4 forwarding
admin@example:/config/interface/eth0/> leave
admin@example:/>

IPv6 forwarding¶

Due to how the Linux kernel manages IPv6 forwarding, we can not fully control it per interface via this setting like how IPv4 works. Instead, IPv6 forwarding is globally enabled when at least one interface enable forwarding, otherwise it is disabled.

The following table shows the system IPv6 features that the forwarding setting control when it is Enabled or *Disabled:

IPv6 Feature	Enabled	Disabled
IsRouter set in Neighbour Advertisements	Yes	No
Transmit Router Solicitations	No	Yes
Router Advertisements are ignored	Yes	Yes
Accept Redirects	No	Yes

admin@example:/config/> edit interface eth0
admin@example:/config/interface/eth0/> set ipv6 forwarding
admin@example:/config/interface/eth0/> leave
admin@example:/>

Routing support¶

Currently supported YANG models:

YANG Model	Description
ietf-routing	Base model for all other models
ietf-ipv4-unicast-routing	Static IPv4 unicast routing
ietf-ipv6-unicast-routing	Static IPv6 unicast routing
ietf-ospf	OSPF routing
infix-routing	Infix deviations and extensions

The base model, ietf-routing, is where all the other models hook in. It is used to set configuration and read operational status (RIB tables) in the other models.

Note

The standard IETF routing models allows multiple instances, but Infix currently only support one instance per routing protocol! In the examples presented here, the instance name default is used.

IPv4 Static routes¶

The standard IETF model for static routes reside under the static control plane protocol. For our examples we use the instance name default, you can use any name.

For a route with destination 192.168.200.0/24 via 192.168.1.1:

admin@example:/> configure
admin@example:/config/> edit routing control-plane-protocol static name default
admin@example:/config/routing/control-plane-protocol/static/name/default/> set ipv4 route 192.168.200.0/24 next-hop next-hop-address 192.168.1.1
admin@example:/config/routing/control-plane-protocol/static/name/default/> leave
admin@example:/>

For a "floating" static route with destination 10.0.0.0/16 via a backup router 192.168.1.1, using the highest possible distance:

admin@example:/> configure
admin@example:/config/> edit routing control-plane-protocol static name default
admin@example:/config/routing/control-plane-protocol/static/name/default/> set ipv4 route 10.0.0.0/16 next-hop next-hop-address 192.168.1.1 route-preference 254
admin@example:/config/routing/control-plane-protocol/static/name/default/> leave
admin@example:/>

Tip

Remember to enable IPv4 forwarding for the interfaces you want to route between.

IPv6 Static routes¶

admin@example:/> configure
admin@example:/config/> edit routing control-plane-protocol static name default
admin@example:/config/routing/control-plane-protocol/static/name/default/> set ipv6 route 2001:db8:3c4d:200::/64 next-hop next-hop-address 2001:db8:3c4d:1::1
admin@example:/config/routing/control-plane-protocol/static/name/default/> leave
admin@example:/>

OSPFv2 Routing¶

The system supports OSPF dynamic routing for IPv4, i.e., OSPFv2. To enable OSPF and set one active interface in area 0:

admin@example:/config/> edit routing control-plane-protocol ospfv2 name default
admin@example:/config/routing/control-plane-protocol/ospfv2/name/default/> set ospf area 0.0.0.0 interface e0 enabled
admin@example:/config/routing/control-plane-protocol/ospfv2/name/default/> leave
admin@example:/>

Tip

Remember to enable IPv4 forwarding for all the interfaces you want to route between.

OSPF area types¶

In addition to regular OSPF areas, area types NSSA and Stub are also supported. To configure an NSSA area with summary routes:

admin@example:/config/> edit routing control-plane-protocol ospfv2 name default
admin@example:/config/routing/control-plane-protocol/ospfv2/name/default/> set ospf area 0.0.0.1 area-type nssa-area
admin@example:/config/routing/control-plane-protocol/ospfv2/name/default/> set ospf area 0.0.0.1 summary true
admin@example:/config/routing/control-plane-protocol/ospfv2/name/default/> leave
admin@example:/>

Bidirectional Forwarding Detection (BFD)¶

It is possible to enable BFD per OSPF interface to speed up detection of link loss.

admin@example:/config/> edit routing control-plane-protocol ospfv2 name default
admin@example:/config/routing/control-plane-protocol/ospfv2/name/default/ospf/> set area 0.0.0.0 interface e0 bfd enabled true
admin@example:/config/routing/control-plane-protocol/ospfv2/name/default/> leave
admin@example:/>

OSPF interface settings¶

We have already seen how to enable OSPF per interface (enabled true) and BFD for OSPF per interface (bfd enabled true). These and other OSPF interface settings are done in context of an OSFP area, e.g., area 0.0.0.0. Available commands can be listed using the ? mark.

admin@example:/config/routing/control-plane-protocol/ospfv2/name/default/> edit ospf area 0.0.0.0
admin@example:/config/routing/control-plane-protocol/ospfv2/name/default/ospf/area/0.0.0.0/> edit interface e0
admin@example:/config/routing/control-plane-protocol/ospfv2/name/default/ospf/area/0.0.0.0/interface/e0/> set ?
  bfd                  BFD interface configuration.
  cost                 Interface's cost.
  dead-interval        Interval after which a neighbor is declared down
  enabled              Enables/disables the OSPF protocol on the interface.
  hello-interval       Interval between Hello packets (seconds).  It must
  interface-type       Interface type.
  passive              Enables/disables a passive interface.  A passive
  retransmit-interval  Interval between retransmitting unacknowledged Link
  transmit-delay       Estimated time needed to transmit Link State Update
admin@example:/config/routing/control-plane-protocol/ospfv2/name/default/ospf/area/0.0.0.0/interface/e0/> set

For example, setting the OSPF interface type to point-to-point for an Ethernet interface can be done as follows.

admin@example:/config/routing/control-plane-protocol/ospfv2/name/default/ospf/area/0.0.0.0/interface/e0/> set interface-type point-to-point
admin@example:/config/routing/control-plane-protocol/ospfv2/name/default/ospf/area/0.0.0.0/interface/e0/>

OSPF global settings¶

In addition to area and interface specific settings, OSPF provides global settings for route redistribution and OSPF router identifier.

admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf
admin@example:/config/routing/control-plane-protocol/ospfv2/name/default/ospf/> set ?
  area                     List of OSPF areas.
  default-route-advertise  Distribute default route to network
  explicit-router-id       Defined in RFC 2328.  A 32-bit number
  redistribute             Redistribute protocols into OSPF
admin@example:/config/routing/control-plane-protocol/ospfv2/name/default/ospf/> set

Explicit router ID: By default the router will pick an IP address from one of its OSPF interfaces as OSPF router ID. An explicit ID is used to get a deterministic behavior, e.g., set explicit-router-id 1.1.1.1.
Redistribution: set redistribute static and set redistribute connected can be used to include static or connected routes into the OSPF routing domain. These routes are redistributed as external type-2 (E2) routes.
Advertising default route: An OSPF router can be made to distribute a default route into the OSPF domain by command set default-route-advertise enabled. This route is distributed as long as the router itself has an active default route in its routing table. By adding command set default-route-advertise always the router will distribute a default route even when it lacks a default route. The default route will be distributed as an external type-2 (E2) route.

Debug OSPFv2¶

Using NETCONF and the YANG model ietf-routing it is possible to read the OSPF routing table, neighbors and more, that may be useful for debugging the OSPFv2 setup. The CLI has various OSPF status commands such as show ospf neighbor, show ospf interface and show ospf routes.

admin@example:/> show ospf neighbor

Neighbor ID     Pri State           Up Time         Dead Time Address         Interface                        RXmtL RqstL DBsmL
10.1.1.2          1 Full/-          3h46m59s          30.177s 10.1.1.2        e0:10.1.1.1                          0     0     0
10.1.1.3          1 Full/-          3h46m55s          34.665s 10.1.1.3        e1:10.1.1.1                          0     0     0

admin@example:/>

View routing table¶

The routing table can be inspected from the operational datastore, XPath /routing/ribs, using sysrepocfg, NETCONF/RESTCONF, or using the CLI.

IPv4 routing table¶

This CLI example shows the IPv4 routing table with a few connected routes and some routes learned from OSPF. See the next section for an explanation of route preferences (PREF).

The > at the start of a line marks a selected route (in the IETF YANG model referred to as active), if there are more than one route with the same destination the * marks the next-hop used and installed in the kernel FIB (the YANG model refers to this as installed).

admin@example:/> show ip route
   DESTINATION            PREF NEXT-HOP         PROTO     UPTIME
>* 0.0.0.0/0             110/2 10.0.23.1        ospfv2   4h2m43s
>* 10.0.0.1/32        110/4000 10.0.13.1        ospfv2   4h2m43s
   10.0.0.3/32           110/0 lo               ospfv2   4h2m57s
>* 10.0.0.3/32             0/0 lo               direct   4h2m58s
   10.0.13.0/30       110/2000 e5               ospfv2   4h2m57s
>* 10.0.13.0/30            0/0 e5               direct   4h2m58s
   10.0.23.0/30          110/1 e6               ospfv2   4h2m57s
>* 10.0.23.0/30            0/0 e6               direct   4h2m58s
   192.168.3.0/24        110/1 e2               ospfv2   4h2m57s
>* 192.168.3.0/24          0/0 e2               direct   4h2m58s
admin@example:/>

IPv6 routing table¶

This CLI example show the IPv6 routing table.

admin@example:/> show ipv6 route
   DESTINATION                      PREF NEXT-HOP              PROTO     UPTIME
>* ::/0                              1/0 2001:db8:3c4d:50::1   static   0h1m20s
>* 2001:db8:3c4d:50::/64             0/0 e6                    direct   0h1m20s
>* 2001:db8:3c4d:200::1/128          0/0 lo                    direct   0h1m20s
 * fe80::/64                         0/0 e7                    direct   0h1m20s
 * fe80::/64                         0/0 e6                    direct   0h1m20s
 * fe80::/64                         0/0 e5                    direct   0h1m20s
 * fe80::/64                         0/0 e4                    direct   0h1m20s
 * fe80::/64                         0/0 e3                    direct   0h1m20s
 * fe80::/64                         0/0 e2                    direct   0h1m20s
>* fe80::/64                         0/0 e1                    direct   0h1m20s
admin@example:/>

Route Preference¶

The operating system leverages FRRouting (Frr) as routing engine for both static and dynamic routing. Even routes injected from a DHCP client, and IPv4 link-local (IPv4) routes, are injected into Frr to let it weigh all routes before installing them into the kernel routing table (sometimes referred to as FIB).

Routes have different weights made up from a distance and a metric. The kernel routing table only talks about metric, which unfortunately is not the same -- this is one of the reasons why the term route preference is used instead. It is recommended to use the CLI, or any of the other previously mentioned YANG based front-ends, to inspect the routing table.

Default distances used (lower numeric value wins):

Distance	Protocol
0	Kernel routes, i.e., connected routes
1	Static routes
5	DHCP routes
110	OSPF
254	IPv4LL (ZeroConf) device routes
255	Route will not be used or redistributed

Hence, a route learned from OSPF may be overridden by a static route set locally. By default, even a route to the same destination, but with a different next-hop, learned from a DHCP server wins over an OSPF route.

The distance used for static routes and DHCP routes can be changed by setting a different routing preference value.

Note

The kernel metric is an unsigned 32-bit value, which is read by Frr as (upper) 8 bits distance and 24 bits metric. But it does not write it back to the kernel FIB this way, only selected routes are candidates to be installed in the FIB by Frr.

Source protocol¶

The source protocol describes the origin of the route.

Protocol	Description
kernel	Added when setting a subnet address on an interface
static	User created, learned from DHCP, or IPv4LL
ospfv2	Routes learned from OSPFv2

The YANG model ietf-routing support multiple ribs but only two are currently supported, namely ipv4 and ipv6.

(source MAC XOR destination MAC XOR EtherType) MODULO num_links ↩
Link-local IPv6 addresses are implicitly enabled when enabling IPv6. IPv6 can be enabled/disabled per interface in the ietf-ip YANG model. ↩
For example, IPv4 groups are mapped to MAC multicast addresses by mapping the low-order 23-bits of the IP address in the low-order 23 bits of the Ethernet address 01:00:5E:00:00:00. Meaning, more than one IP multicast group maps to the same MAC multicast group. ↩
A YANG deviation was previously used to make it possible to set phys-address, but this has been replaced with the more flexible custom-phys-address. ↩
MAC bridges on Marvell Linkstreet devices are currently limited to a single MAC database, this may be a problem if the same MAC address appears in different MAC bridges. ↩
Ethernet counters are described in ieee802-ethernet-interface.yang and infix-ethernet-interface.yang. There is a dedicated document on Ethernet Counters that provide additional details on the statistics support. ↩