Updating node network configuration

You can update the node network configuration, such as adding or removing interfaces from nodes, by applying NodeNetworkConfigurationPolicy manifests to the cluster.

About nmstate

OpenShift Container Platform uses nmstate to report on and configure the state of the node network. This makes it possible to modify network policy configuration, such as by creating a Linux bridge on all nodes, by applying a single configuration manifest to the cluster.

Node networking is monitored and updated by the following objects:

NodeNetworkState

Reports the state of the network on that node.

NodeNetworkConfigurationPolicy

Describes the requested network configuration on nodes. You update the node network configuration, including adding and removing interfaces, by applying a NodeNetworkConfigurationPolicy manifest to the cluster.

NodeNetworkConfigurationEnactment

Reports the network policies enacted upon each node.

OpenShift Container Platform supports the use of the following nmstate interface types:

  • Linux Bridge

  • VLAN

  • Bond

  • Ethernet

If your OKD cluster uses OVN-Kubernetes as the network plugin, you cannot attach a Linux bridge or bonding to the default interface of a host because of a change in the host network topology of OVN-Kubernetes. As a workaround, use a secondary network interface connected to your host or switch to the OpenShift SDN network plugin.

Managing policy from the web console

You can manage the policy from the web console by accessing the list of created policies in NodeNetworkConfigurationPolicy page under Networking menu. This page enables you to create, update, monitor, and delete the policies.

Monitoring the policy status

You can monitor the policy status from the NodeNetworkConfigurationPolicy page. This page displays all the policies created in the cluster in a tabular format, with the following columns:

Name

The name of the policy created.

Matched nodes

The count of nodes where the policies are applied. This could be either a subset of nodes based on the node selector or all the nodes on the cluster.

Node network state

The enactment state of the matched nodes. You can click on the enactment state and view detailed information on the status.

To find the desired policy, you can filter the list either based on enactment state by using the Filter option, or by using the search option.

Creating a policy

You can create a policy by using either a form or YAML in the web console.

Procedure

  1. Navigate to Networking → NodeNetworkConfigurationPolicy.

  2. In the NodeNetworkConfigurationPolicy page, click Create, and select From Form option.

    In case there are no existing policies, you can alternatively click Create NodeNetworkConfigurationPolicy to createa policy using form.

    To create policy using YAML, click Create, and select With YAML option. The following steps are applicable to create a policy only by using form.

  3. Optional: Check the Apply this NodeNetworkConfigurationPolicy only to specific subsets of nodes using the node selector checkbox to specify the nodes where the policy must be applied.

  4. Enter the policy name in the Policy name field.

  5. Optional: Enter the description of the policy in the Description field.

  6. Optional: In the Policy Interface(s) section, a bridge interface is added by default with preset values in editable fields. Edit the values by executing the following steps:

    1. Enter the name of the interface in Interface name field.

    2. Select the network state from Network state dropdown. The default selected value is Up.

    3. Select the type of interface from Type dropdown. The available values are Bridge, Bonding, and Ethernet. The default selected value is Bridge.

      Addition of a VLAN interface by using the form is not supported. To add a VLAN interface, you must use YAML to create the policy. Once added, you cannot edit the policy by using form.

    4. Optional: In the IP configuration section, check IPv4 checkbox to assign an IPv4 address to the interface, and configure the IP address assignment details:

      1. Click IP address to configure the interface with a static IP address, or DHCP to auto-assign an IP address.

      2. If you have selected IP address option, enter the IPv4 address in IPV4 address field, and enter the prefix length in Prefix length field.

        If you have selected DHCP option, uncheck the options that you want to disable. The available options are Auto-DNS, Auto-routes, and Auto-gateway. All the options are selected by default.

    5. Optional: Enter the port number in Port field.

    6. Optional: Check the checkbox Enable STP to enable STP.

    7. Optional: To add an interface to the policy, click Add another interface to the policy.

    8. Optional: To remove an interface from the policy, click minus icon next to the interface.

    Alternatively, you can click Edit YAML on the top of the page to continue editing the form using YAML.

  7. Click Create to complete policy creation.

Updating the policy

Updating the policy by using form

Procedure

  1. Navigate to Networking → NodeNetworkConfigurationPolicy.

  2. In the NodeNetworkConfigurationPolicy page, click the kebab icon placed next to the policy you want to edit, and click Edit.

  3. Edit the fields that you want to update.

  4. Click Save.

Addition of a VLAN interface using the form is not supported. To add a VLAN interface, you must use YAML to create the policy. Once added, you cannot edit the policy using form.

Updating the policy by using YAML

Procedure

  1. Navigate to Networking → NodeNetworkConfigurationPolicy.

  2. In the NodeNetworkConfigurationPolicy page, click the policy name under the Name column for the policy you want to edit.

  3. Click the YAML tab, and edit the YAML.

  4. Click Save.

Deleting the policy

Procedure

  1. Navigate to Networking → NodeNetworkConfigurationPolicy.

  2. In the NodeNetworkConfigurationPolicy page, click the kebab icon placed next to the policy you want to delete, and click Delete.

  3. In the pop-up window, enter the policy name to confirm deletion, and click Delete.

Managing policy by using the CLI

Creating an interface on nodes

Create an interface on nodes in the cluster by applying a NodeNetworkConfigurationPolicy manifest to the cluster. The manifest details the requested configuration for the interface.

By default, the manifest applies to all nodes in the cluster. To add the interface to specific nodes, add the spec: nodeSelector parameter and the appropriate <key>:<value> for your node selector.

You can configure multiple nmstate-enabled nodes concurrently. The configuration applies to 50% of the nodes in parallel. This strategy prevents the entire cluster from being unavailable if the network connection fails. To apply the policy configuration in parallel to a specific portion of the cluster, use the maxUnavailable field.

Procedure

  1. Create the NodeNetworkConfigurationPolicy manifest. The following example configures a Linux bridge on all worker nodes and configures the DNS resolver:

    1. apiVersion: nmstate.io/v1
    2. kind: NodeNetworkConfigurationPolicy
    3. metadata:
    4.   name: br1-eth1-policy (1)
    5. spec:
    6.   nodeSelector: (2)
    7.     node-role.kubernetes.io/worker: "" (3)
    8.   maxUnavailable: 3 (4)
    9.   desiredState:
    10.     interfaces:
    11.       - name: br1
    12.         description: Linux bridge with eth1 as a port (5)
    13.         type: linux-bridge
    14.         state: up
    15.         ipv4:
    16.           dhcp: true
    17.           enabled: true
    18.           auto-dns: false
    19.         bridge:
    20.           options:
    21.             stp:
    22.               enabled: false
    23.           port:
    24.             - name: eth1
    25.     dns-resolver: (6)
    26.       config:
    27.         search:
    28.         - example.com
    29.         - example.org
    30.         server:
    31.         - 8.8.8.8
    1Name of the policy.
    2Optional: If you do not include the nodeSelector parameter, the policy applies to all nodes in the cluster.
    3This example uses the node-role.kubernetes.io/worker: “” node selector to select all worker nodes in the cluster.
    4Optional: Specifies the maximum number of nmstate-enabled nodes that the policy configuration can be applied to concurrently. This parameter can be set to either a percentage value (string), for example, “10%”, or an absolute value (number), such as 3.
    5Optional: Human-readable description for the interface.
    6Optional: Specifies the search and server settings for the DNS server.

  2. Create the node network policy:

    1. $ oc apply -f br1-eth1-policy.yaml (1)
    1File name of the node network configuration policy manifest.

Additional resources

Confirming node network policy updates on nodes

A NodeNetworkConfigurationPolicy manifest describes your requested network configuration for nodes in the cluster. The node network policy includes your requested network configuration and the status of execution of the policy on the cluster as a whole.

When you apply a node network policy, a NodeNetworkConfigurationEnactment object is created for every node in the cluster. The node network configuration enactment is a read-only object that represents the status of execution of the policy on that node. If the policy fails to be applied on the node, the enactment for that node includes a traceback for troubleshooting.

Procedure

  1. To confirm that a policy has been applied to the cluster, list the policies and their status:

    1. $ oc get nncp

  2. Optional: If a policy is taking longer than expected to successfully configure, you can inspect the requested state and status conditions of a particular policy:

    1. $ oc get nncp <policy> -o yaml

  3. Optional: If a policy is taking longer than expected to successfully configure on all nodes, you can list the status of the enactments on the cluster:

    1. $ oc get nnce

  4. Optional: To view the configuration of a particular enactment, including any error reporting for a failed configuration:

    1. $ oc get nnce <node>.<policy> -o yaml

Removing an interface from nodes

You can remove an interface from one or more nodes in the cluster by editing the NodeNetworkConfigurationPolicy object and setting the state of the interface to absent.

Removing an interface from a node does not automatically restore the node network configuration to a previous state. If you want to restore the previous state, you will need to define that node network configuration in the policy.

If you remove a bridge or bonding interface, any node NICs in the cluster that were previously attached or subordinate to that bridge or bonding interface are placed in a down state and become unreachable. To avoid losing connectivity, configure the node NIC in the same policy so that it has a status of up and either DHCP or a static IP address.

Deleting the node network policy that added an interface does not change the configuration of the policy on the node. Although a NodeNetworkConfigurationPolicy is an object in the cluster, it only represents the requested configuration.
Similarly, removing an interface does not delete the policy.

Procedure

  1. Update the NodeNetworkConfigurationPolicy manifest used to create the interface. The following example removes a Linux bridge and configures the eth1 NIC with DHCP to avoid losing connectivity:

    1. apiVersion: nmstate.io/v1
    2. kind: NodeNetworkConfigurationPolicy
    3. metadata:
    4.   name: <br1-eth1-policy> (1)
    5. spec:
    6.   nodeSelector: (2)
    7.     node-role.kubernetes.io/worker: "" (3)
    8.   desiredState:
    9.     interfaces:
    10.     - name: br1
    11.       type: linux-bridge
    12.       state: absent (4)
    13.     - name: eth1 (5)
    14.       type: ethernet (6)
    15.       state: up (7)
    16.       ipv4:
    17.         dhcp: true (8)
    18.         enabled: true (9)
    1Name of the policy.
    2Optional: If you do not include the nodeSelector parameter, the policy applies to all nodes in the cluster.
    3This example uses the node-role.kubernetes.io/worker: “” node selector to select all worker nodes in the cluster.
    4Changing the state to absent removes the interface.
    5The name of the interface that is to be unattached from the bridge interface.
    6The type of interface. This example creates an Ethernet networking interface.
    7The requested state for the interface.
    8Optional: If you do not use dhcp, you can either set a static IP or leave the interface without an IP address.
    9Enables ipv4 in this example.

  2. Update the policy on the node and remove the interface:

    1. $ oc apply -f <br1-eth1-policy.yaml> (1)
    1File name of the policy manifest.

Example policy configurations for different interfaces

Example: Linux bridge interface node network configuration policy

Create a Linux bridge interface on nodes in the cluster by applying a NodeNetworkConfigurationPolicy manifest to the cluster.

The following YAML file is an example of a manifest for a Linux bridge interface. It includes samples values that you must replace with your own information.

  1. apiVersion: nmstate.io/v1
  2. kind: NodeNetworkConfigurationPolicy
  3. metadata:
  4.   name: br1-eth1-policy (1)
  5. spec:
  6.   nodeSelector: (2)
  7.     kubernetes.io/hostname: <node01> (3)
  8.   desiredState:
  9.     interfaces:
  10.       - name: br1 (4)
  11.         description: Linux bridge with eth1 as a port (5)
  12.         type: linux-bridge (6)
  13.         state: up (7)
  14.         ipv4:
  15.           dhcp: true (8)
  16.           enabled: true (9)
  17.         bridge:
  18.           options:
  19.             stp:
  20.               enabled: false (10)
  21.           port:
  22.             - name: eth1 (11)
1Name of the policy.
2Optional: If you do not include the nodeSelector parameter, the policy applies to all nodes in the cluster.
3This example uses a hostname node selector.
4Name of the interface.
5Optional: Human-readable description of the interface.
6The type of interface. This example creates a bridge.
7The requested state for the interface after creation.
8Optional: If you do not use dhcp, you can either set a static IP or leave the interface without an IP address.
9Enables ipv4 in this example.
10Disables stp in this example.
11The node NIC to which the bridge attaches.

Example: VLAN interface node network configuration policy

Create a VLAN interface on nodes in the cluster by applying a NodeNetworkConfigurationPolicy manifest to the cluster.

The following YAML file is an example of a manifest for a VLAN interface. It includes samples values that you must replace with your own information.

  1. apiVersion: nmstate.io/v1
  2. kind: NodeNetworkConfigurationPolicy
  3. metadata:
  4.   name: vlan-eth1-policy (1)
  5. spec:
  6.   nodeSelector: (2)
  7.     kubernetes.io/hostname: <node01> (3)
  8.   desiredState:
  9.     interfaces:
  10.     - name: eth1.102 (4)
  11.       description: VLAN using eth1 (5)
  12.       type: vlan (6)
  13.       state: up (7)
  14.       vlan:
  15.         base-iface: eth1 (8)
  16.         id: 102 (9)
1Name of the policy.
2Optional: If you do not include the nodeSelector parameter, the policy applies to all nodes in the cluster.
3This example uses a hostname node selector.
4Name of the interface.
5Optional: Human-readable description of the interface.
6The type of interface. This example creates a VLAN.
7The requested state for the interface after creation.
8The node NIC to which the VLAN is attached.
9The VLAN tag.

Example: Bond interface node network configuration policy

Create a bond interface on nodes in the cluster by applying a NodeNetworkConfigurationPolicy manifest to the cluster.

OpenShift Container Platform only supports the following bond modes:

  • mode=1 active-backup

  • mode=2 balance-xor

  • mode=4 802.3ad

  • mode=5 balance-tlb

  • mode=6 balance-alb

The following YAML file is an example of a manifest for a bond interface. It includes samples values that you must replace with your own information.

  1. apiVersion: nmstate.io/v1
  2. kind: NodeNetworkConfigurationPolicy
  3. metadata:
  4.   name: bond0-eth1-eth2-policy (1)
  5. spec:
  6.   nodeSelector: (2)
  7.     kubernetes.io/hostname: <node01> (3)
  8.   desiredState:
  9.     interfaces:
  10.     - name: bond0 (4)
  11.       description: Bond with ports eth1 and eth2 (5)
  12.       type: bond (6)
  13.       state: up (7)
  14.       ipv4:
  15.         dhcp: true (8)
  16.         enabled: true (9)
  17.       link-aggregation:
  18.         mode: active-backup (10)
  19.         options:
  20.           miimon: '140' (11)
  21.         port: (12)
  22.         - eth1
  23.         - eth2
  24.       mtu: 1450 (13)
1Name of the policy.
2Optional: If you do not include the nodeSelector parameter, the policy applies to all nodes in the cluster.
3This example uses a hostname node selector.
4Name of the interface.
5Optional: Human-readable description of the interface.
6The type of interface. This example creates a bond.
7The requested state for the interface after creation.
8Optional: If you do not use dhcp, you can either set a static IP or leave the interface without an IP address.
9Enables ipv4 in this example.
10The driver mode for the bond. This example uses an active backup mode.
11Optional: This example uses miimon to inspect the bond link every 140ms.
12The subordinate node NICs in the bond.
13Optional: The maximum transmission unit (MTU) for the bond. If not specified, this value is set to 1500 by default.

Example: Ethernet interface node network configuration policy

Configure an Ethernet interface on nodes in the cluster by applying a NodeNetworkConfigurationPolicy manifest to the cluster.

The following YAML file is an example of a manifest for an Ethernet interface. It includes sample values that you must replace with your own information.

  1. apiVersion: nmstate.io/v1
  2. kind: NodeNetworkConfigurationPolicy
  3. metadata:
  4.   name: eth1-policy (1)
  5. spec:
  6.   nodeSelector: (2)
  7.     kubernetes.io/hostname: <node01> (3)
  8.   desiredState:
  9.     interfaces:
  10.     - name: eth1 (4)
  11.       description: Configuring eth1 on node01 (5)
  12.       type: ethernet (6)
  13.       state: up (7)
  14.       ipv4:
  15.         dhcp: true (8)
  16.         enabled: true (9)
1Name of the policy.
2Optional: If you do not include the nodeSelector parameter, the policy applies to all nodes in the cluster.
3This example uses a hostname node selector.
4Name of the interface.
5Optional: Human-readable description of the interface.
6The type of interface. This example creates an Ethernet networking interface.
7The requested state for the interface after creation.
8Optional: If you do not use dhcp, you can either set a static IP or leave the interface without an IP address.
9Enables ipv4 in this example.

Example: Multiple interfaces in the same node network configuration policy

You can create multiple interfaces in the same node network configuration policy. These interfaces can reference each other, allowing you to build and deploy a network configuration by using a single policy manifest.

The following example YAML file creates a bond that is named bond10 across two NICs and VLAN that is named bond10.103 that connects to the bond.

  1. apiVersion: nmstate.io/v1
  2. kind: NodeNetworkConfigurationPolicy
  3. metadata:
  4.   name: bond-vlan (1)
  5. spec:
  6.   nodeSelector: (2)
  7.     kubernetes.io/hostname: <node01> (3)
  8.   desiredState:
  9.     interfaces:
  10.     - name: bond10 (4)
  11.       description: Bonding eth2 and eth3 (5)
  12.       type: bond (6)
  13.       state: up (7)
  14.       link-aggregation:
  15.         mode: balance-rr (8)
  16.         options:
  17.           miimon: '140' (9)
  18.         port: (10)
  19.         - eth2
  20.         - eth3
  21.     - name: bond10.103 (4)
  22.       description: vlan using bond10 (5)
  23.       type: vlan (6)
  24.       state: up (7)
  25.       vlan:
  26.          base-iface: bond10 (11)
  27.          id: 103 (12)
  28.       ipv4:
  29.         dhcp: true (13)
  30.         enabled: true (14)
1Name of the policy.
2Optional: If you do not include the nodeSelector parameter, the policy applies to all nodes in the cluster.
3This example uses hostname node selector.
4Name of the interface.
5Optional: Human-readable description of the interface.
6The type of interface.
7The requested state for the interface after creation.
8The driver mode for the bond.
9Optional: This example uses miimon to inspect the bond link every 140ms.
10The subordinate node NICs in the bond.
11The node NIC to which the VLAN is attached.
12The VLAN tag.
13Optional: If you do not use dhcp, you can either set a static IP or leave the interface without an IP address.
14Enables ipv4 in this example.

Example: Network interface with a VRF instance node network configuration policy

Associate a Virtual Routing and Forwarding (VRF) instance with a network interface by applying a NodeNetworkConfigurationPolicy custom resource (CR).

Associating a VRF instance with a network interface is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

By associating a VRF instance with a network interface, you can support traffic isolation, independent routing decisions, and the logical separation of network resources.

In a bare-metal environment, you can announce load balancer services through interfaces belonging to a VRF instance by using MetalLB. For more information, see the Additional resources section.

The following YAML file is an example of associating a VRF instance to a network interface. It includes samples values that you must replace with your own information.

  1. apiVersion: nmstate.io/v1
  2. kind: NodeNetworkConfigurationPolicy
  3. metadata:
  4.   name: vrfpolicy (1)
  5. spec:
  6.   nodeSelector:
  7.     vrf: "true" (2)
  8.   maxUnavailable: 3
  9.   desiredState:
  10.     interfaces:
  11.       - name: ens4vrf (3)
  12.         type: vrf (4)
  13.         state: up
  14.         vrf:
  15.           port:
  16.             - ens4 (5)
  17.           route-table-id: 2 (6)
1The name of the policy.
2This example applies the policy to all nodes with the label vrf:true.
3The name of the interface.
4The type of interface. This example creates a VRF instance.
5The node interface to which the VRF attaches.
6The name of the route table ID for the VRF.

Additional resources

Capturing the static IP of a NIC attached to a bridge

Example: Linux bridge interface node network configuration policy to inherit static IP address from the NIC attached to the bridge

Create a Linux bridge interface on nodes in the cluster and transfer the static IP configuration of the NIC to the bridge by applying a single NodeNetworkConfigurationPolicy manifest to the cluster.

The following YAML file is an example of a manifest for a Linux bridge interface. It includes sample values that you must replace with your own information.

  1. apiVersion: nmstate.io/v1
  2. kind: NodeNetworkConfigurationPolicy
  3. metadata:
  4.   name: br1-eth1-copy-ipv4-policy (1)
  5. spec:
  6.   nodeSelector: (2)
  7.     node-role.kubernetes.io/worker: ""
  8.   capture:
  9.     eth1-nic: interfaces.name=="eth1" (3)
  10.     eth1-routes: routes.running.next-hop-interface=="eth1"
  11.     br1-routes: capture.eth1-routes | routes.running.next-hop-interface := "br1"
  12.   desiredState:
  13.     interfaces:
  14.       - name: br1
  15.         description: Linux bridge with eth1 as a port
  16.         type: linux-bridge (4)
  17.         state: up
  18.         ipv4: "{{ capture.eth1-nic.interfaces.0.ipv4 }}" (5)
  19.         bridge:
  20.           options:
  21.             stp:
  22.               enabled: false
  23.           port:
  24.             - name: eth1 (6)
  25.      routes:
  26.         config: "{{ capture.br1-routes.routes.running }}"
1The name of the policy.
2Optional: If you do not include the nodeSelector parameter, the policy applies to all nodes in the cluster. This example uses the node-role.kubernetes.io/worker: “” node selector to select all worker nodes in the cluster.
3The reference to the node NIC to which the bridge attaches.
4The type of interface. This example creates a bridge.
5The IP address of the bridge interface. This value matches the IP address of the NIC which is referenced by the spec.capture.eth1-nic entry.
6The node NIC to which the bridge attaches.

Additional resources

Examples: IP management

The following example configuration snippets demonstrate different methods of IP management.

These examples use the ethernet interface type to simplify the example while showing the related context in the policy configuration. These IP management examples can be used with the other interface types.

Static

The following snippet statically configures an IP address on the Ethernet interface:

  1. # ...
  2.     interfaces:
  3.     - name: eth1
  4.       description: static IP on eth1
  5.       type: ethernet
  6.       state: up
  7.       ipv4:
  8.         dhcp: false
  9.         address:
  10.         - ip: 192.168.122.250 (1)
  11.           prefix-length: 24
  12.         enabled: true
  13. # ...
1Replace this value with the static IP address for the interface.

No IP address

The following snippet ensures that the interface has no IP address:

  1. # ...
  2.     interfaces:
  3.     - name: eth1
  4.       description: No IP on eth1
  5.       type: ethernet
  6.       state: up
  7.       ipv4:
  8.         enabled: false
  9. # ...

Dynamic host configuration

The following snippet configures an Ethernet interface that uses a dynamic IP address, gateway address, and DNS:

  1. # ...
  2.     interfaces:
  3.     - name: eth1
  4.       description: DHCP on eth1
  5.       type: ethernet
  6.       state: up
  7.       ipv4:
  8.         dhcp: true
  9.         enabled: true
  10. # ...

The following snippet configures an Ethernet interface that uses a dynamic IP address but does not use a dynamic gateway address or DNS:

  1. # ...
  2.     interfaces:
  3.     - name: eth1
  4.       description: DHCP without gateway or DNS on eth1
  5.       type: ethernet
  6.       state: up
  7.       ipv4:
  8.         dhcp: true
  9.         auto-gateway: false
  10.         auto-dns: false
  11.         enabled: true
  12. # ...

DNS

Setting the DNS configuration is analagous to modifying the /etc/resolv.conf file. The following snippet sets the DNS configuration on the host.

  1. # ...
  2.     interfaces: (1)
  3.        ...
  4.        ipv4:
  5.          ...
  6.          auto-dns: false
  7.          ...
  8.     dns-resolver:
  9.       config:
  10.         search:
  11.         - example.com
  12.         - example.org
  13.         server:
  14.         - 8.8.8.8
  15. # ...
1You must configure an interface with auto-dns: false or you must use static IP configuration on an interface in order for Kubernetes NMState to store custom DNS settings.

You cannot use br-ex, an OVNKubernetes-managed Open vSwitch bridge, as the interface when configuring DNS resolvers.

Static routing

The following snippet configures a static route and a static IP on interface eth1.

  1. # ...
  2.     interfaces:
  3.     - name: eth1
  4.       description: Static routing on eth1
  5.       type: ethernet
  6.       state: up
  7.       ipv4:
  8.         dhcp: false
  9.         address:
  10.         - ip: 192.0.2.251 (1)
  11.           prefix-length: 24
  12.         enabled: true
  13.     routes:
  14.       config:
  15.       - destination: 198.51.100.0/24
  16.         metric: 150
  17.         next-hop-address: 192.0.2.1 (2)
  18.         next-hop-interface: eth1
  19.         table-id: 254
  20. # ...
1The static IP address for the Ethernet interface.
2Next hop address for the node traffic. This must be in the same subnet as the IP address set for the Ethernet interface.