Chapter 4. Secondary networks

Procedure

1. Edit the Pod resource definition. If you are editing an existing Pod resource, run the following command to edit its definition in the default editor. Replace <name> with the name of the Pod resource to edit.

   $ oc edit pod <name>

2. In the Pod resource definition, add the k8s.v1.cni.cncf.io/networks parameter to the pod metadata mapping. The k8s.v1.cni.cncf.io/networks accepts a JSON string of a list of objects that reference the name of NetworkAttachmentDefinition custom resource (CR) names in addition to specifying additional properties.

   metadata:
     annotations:
       k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]'
   # ...

   where:

   <network>

   Replace with a JSON object as shown in the following examples. The single quotes are required.

   In the following example the annotation specifies which network attachment will have the default route, using the default-route parameter.

   apiVersion: v1
   kind: Pod
   metadata:
     name: example-pod
     annotations:
       k8s.v1.cni.cncf.io/networks: '[
       {
         "name": "net1"
       },
       {
         "name": "net2",
         "default-route": ["192.0.2.1"]
       }]'
   spec:
     containers:
     - name: example-pod
       command: ["/bin/bash", "-c", "sleep 2000000000000"]
       image: centos/tools

   where:

   net1, net2

   Specifies the name of the NetworkAttachmentDefinition resource that defines the secondary network to associate with the pod.

   192.0.2.1

   Specifies a value of a gateway for traffic to be routed over if no other routing entry is present in the routing table. If more than one default-route key is specified, this will cause the pod to fail to become active.

   The default route will cause any traffic that is not specified in other routes to be routed to the gateway.

   Important

   Setting the default route to an interface other than the default network interface for OpenShift Container Platform may cause traffic that is anticipated for pod-to-pod traffic to be routed over another interface.

   To verify the routing properties of a pod, the oc command may be used to execute the ip command within a pod.

   $ oc exec -it <pod_name> -- ip route

   Note

   You may also reference the pod’s k8s.v1.cni.cncf.io/network-status to see which secondary network has been assigned the default route, by the presence of the default-route key in the JSON-formatted list of objects.

   To set a static IP address or MAC address for a pod you can use the JSON formatted annotations. This requires you create networks that specifically allow for this functionality. This can be specified in a rawCNIConfig for the CNO.

3. Edit the CNO CR by running the following command:

   $ oc edit networks.operator.openshift.io cluster

   The following YAML describes the configuration parameters for the CNO:

   Cluster Network Operator YAML configuration

   name: <name>
   namespace: <namespace>
   rawCNIConfig: '{
     ...
   }'
   type: Raw

   where:

   name

   Specifies a name for the secondary network attachment that you are creating. The name must be unique within the specified namespace.

   namespace

   Specifies the namespace to create the network attachment in. If you do not specify a value, then the default namespace is used.

   rawCNIConfig

   Specifies the CNI plugin configuration in JSON format, which is based on the following template.

   The following object describes the configuration parameters for utilizing static MAC address and IP address using the macvlan CNI plugin:

   macvlan CNI plugin JSON configuration object using static IP and MAC address

   {
     "cniVersion": "0.3.1",
     "name": "<name>",
     "plugins": [{
         "type": "macvlan",
         "capabilities": { "ips": true },
         "master": "eth0",
         "mode": "bridge",
         "ipam": {
           "type": "static"
         }
       }, {
         "capabilities": { "mac": true },
         "type": "tuning"
       }]
   }

   where:

   name

   Specifies the name for the secondary network attachment to create. The name must be unique within the specified namespace.

   plugins

   Specifies an array of CNI plugin configurations. The first object specifies a macvlan plugin configuration and the second object specifies a tuning plugin configuration.

   ips

   Specifies that a request is made to enable the static IP address functionality of the CNI plugin runtime configuration capabilities.

   master

   Specifies the interface that the macvlan plugin uses.

   mac

   Specifies that a request is made to enable the static MAC address functionality of a CNI plugin.

   The above network attachment can be referenced in a JSON formatted annotation, along with keys to specify which static IP and MAC address will be assigned to a given pod.

4. Edit the pod by entering the following command:

   $ oc edit pod <name>

   macvlan CNI plugin JSON configuration object using static IP and MAC address

   apiVersion: v1
   kind: Pod
   metadata:
     name: example-pod
     annotations:
       k8s.v1.cni.cncf.io/networks: '[
         {
           "name": "<name>",
           "ips": [ "192.0.2.205/24" ],
           "mac": "CA:FE:C0:FF:EE:00"
         }
       ]'

   where:

   metadata.name

   Specifies the name for the secondary network attachment to create. The name must be unique within the specified namespace.

   metadata.annotations.k8s.v1.cni.cncf.io/ips

   Specifies an IP address including the subnet mask.

   metadata.annotations.k8s.v1.cni.cncf.io/mac

   Specifies the MAC address.

   Note

   Static IP addresses and MAC addresses do not have to be used at the same time. You can use them individually, or together.

Procedure

1. Edit the Network.operator.openshift.io CR by running the following command:

   $ oc edit network.operator.openshift.io cluster

2. Include the additionalNetworks section shown in this example YAML extract within the spec definition of the CR:

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   # ...
   spec:
     additionalNetworks:
     - name: whereabouts-shim
       namespace: default
       rawCNIConfig: |-
         {
          "name": "whereabouts-shim",
          "cniVersion": "0.3.1",
          "type": "bridge",
          "ipam": {
            "type": "whereabouts"
          }
         }
       type: Raw
   # ...

3. Save the file and exit the text editor.

4. Verify that the whereabouts-reconciler daemon set deployed successfully by running the following command:

   $ oc get all -n openshift-multus | grep whereabouts-reconciler

   pod/whereabouts-reconciler-jnp6g 1/1 Running 0 6s
   pod/whereabouts-reconciler-k76gg 1/1 Running 0 6s
   daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 6s

Procedure

1. Run the following command to create a ConfigMap object named whereabouts-config in the openshift-multus namespace with a specific cron expression for the IP reconciler:

   $ oc create configmap whereabouts-config -n openshift-multus --from-literal=reconciler_cron_expression="*/15 * * * *"

   This cron expression indicates the IP reconciler runs every 15 minutes. Adjust the expression based on your specific requirements.

   Note

   The whereabouts-reconciler daemon set can only consume a cron expression pattern that includes five asterisks. Red  Hat does not support the sixth asterisk, which is used to denote seconds.

2. Retrieve information about resources related to the whereabouts-reconciler daemon set and pods within the openshift-multus namespace by running the following command:

   $ oc get all -n openshift-multus | grep whereabouts-reconciler

   pod/whereabouts-reconciler-2p7hw                   1/1     Running   0             4m14s
   pod/whereabouts-reconciler-76jk7                   1/1     Running   0             4m14s
   daemonset.apps/whereabouts-reconciler          6         6         6       6            6           kubernetes.io/os=linux   4m16s

3. Run the following command to verify that the whereabouts-reconciler pod runs the IP reconciler with the configured interval:

   $ oc -n openshift-multus logs whereabouts-reconciler-2p7hw

   2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_33_54.1375928161": CREATE
   2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_33_54.1375928161": CHMOD
   2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..data_tmp": RENAME
   2024-02-02T16:33:54Z [verbose] using expression: */15 * * * *
   2024-02-02T16:33:54Z [verbose] configuration updated to file "/cron-schedule/..data". New cron expression: */15 * * * *
   2024-02-02T16:33:54Z [verbose] successfully updated CRON configuration id "00c2d1c9-631d-403f-bb86-73ad104a6817" - new cron expression: */15 * * * *
   2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/config": CREATE
   2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_26_17.3874177937": REMOVE
   2024-02-02T16:45:00Z [verbose] starting reconciler run
   2024-02-02T16:45:00Z [debug] NewReconcileLooper - inferred connection data
   2024-02-02T16:45:00Z [debug] listing IP pools
   2024-02-02T16:45:00Z [debug] no IP addresses to cleanup
   2024-02-02T16:45:00Z [verbose] reconciler success

1. Whereabouts takes an address range in classless inter-domain routing (CIDR) notation, such as 192.168.2.0/24, and assigns IP addresses within that range, such as 192.168.2.1 to 192.168.2.254.
2. Whereabouts assigns an IP address, the lowest value address in a CIDR range, to a pod and tracks the IP address in a data store for the lifetime of that pod.
3. When the pod is removed, Whereabouts frees the address from the pod so that the address is available for assignment.

Procedure

1. Confirm that the Whereabouts Controller is running by entering the following command.

   $ oc get pods -n openshift-multus | grep whereabouts-controller

   whereabouts-controller-5cbfd6c475-fr7d7        1/1     Running            0               22s
   ...

   Important

   If the Whereabouts Controller is not running, the Fast IPAM does not work.

2. Create a NAD file for your cluster and add the Fast IPAM details to the file as demonstrated in the following example configuration:

   apiVersion: "k8s.cni.cncf.io/v1"
   kind: NetworkAttachmentDefinition
   metadata:
     name: wb-ipam
     namespace: openshift-multus
   spec:
     config: '{
   	"cniVersion": "0.3.0",
   	"name": "wb-ipam-cni-name",
   	"type": "bridge",
   	"bridge": "cni0",
   	"ipam": {
     	"type": "whereabouts",
     	"range": "10.5.0.0/20",
     	"node_slice_size": "/24"
       }
     }'
   # ...

   where:

   namespace

   The namespace where CNO deploys the NAD.

   name

   The name of the Whereabouts IPAM CNI plugin.

   type

   The type of IPAM CNI plugin, such as whereabouts.

   range

   The IP address range for the IP pool that the Whereabouts IPAM CNI plugin uses for allocating IP addresses to pods.

   node_slice_size

   Sets the slice size of IP addresses available to each node.

3. Add the Whereabouts IPAM CNI plugin annotation details to the YAML file for the pod:

   apiVersion: v1
   kind: Pod
   metadata:
     name: samplepod
     annotations:
     k8s.v1.cni.cncf.io/networks: openshift-multus/wb-ipam
   spec:
     containers:
     - name: samplecontainer
     command: ["/bin/bash", "-c", "trap : TERM INT; sleep infinity & wait"]
     image: registry.redhat.io/ubi9/ubi-minimal
   # ...

   where:

   name

   The name of the pod.

   k8s.v1.cni.cncf.io/networks

   The annotation details that references the Whereabouts IPAM CNI plugin name that exists in the openshift-multus namespace.

   - name

   The name of the container for the pod.

   command

   Defines the entry point for the container and controls the behavior of the container in the Whereabouts IPAM CNI plugin.

4. Apply the NAD file configuration to pods that exist on nodes that run in your cluster:

   $ oc create -f <NAD_file_name>.yaml

Verification

1. Show the IP address details of the pod by entering the following command:

   $ oc describe pod <pod_name>

   ...
   k8s.v1.cni.cncf.io/network-status:
     [{
         "name": "ovn-kubernetes",
         "interface": "eth0",
         "ips": [
             "10.128.3.174"
         ],
         "mac": "0a:58:0a:80:03:ae",
         "default": true,
         "dns": {}
     },{
         "name": "openshift-multus/wb-ipam",
         "interface": "net1",
         "ips": [
             "10.5.0.1"
         ],
         "mac": "1a:04:6f:a4:15:3c",
         "dns": {}
     }]
   k8s.v1.cni.cncf.io/networks: openshift-multus/wb-ipam
   ...

2. Access the pod and confirm its interfaces by entering the following command:

   $ oc exec <pod_name> -- ip a

   ...
   3: net1@if439: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
       link/ether 1a:04:6f:a4:15:3c brd ff:ff:ff:ff:ff:ff link-netnsid 0
       inet 10.5.0.1/20 brd 10.5.15.255 scope global net1
          valid_lft forever preferred_lft forever
       inet6 fe80::1804:6fff:fea4:153c/64 scope link
          valid_lft forever preferred_lft forever
   ...

   where:

   inet: Pod is attached to the 10.5.0.1 IP address on the net1 interface as expected.

3. Check that the node selector pool exists in the openshift-multus namespace by entering the following command. The expected output shows the name of the node selector pool, such as nodeslicepool, and the creation age in minutes, such as `32m.

   $ oc get nodeslicepool -n openshift-multus

   Example output

   NAME               AGE
   wb-ipam-cni-name   32m

Procedure

1. Set type to whereabouts.

2. Use ipRanges to allocate IP addresses as shown in the following example:

   cniVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     additionalNetworks:
     - name: whereabouts-shim
       namespace: default
       type: Raw
       rawCNIConfig: |-
         {
          "name": "whereabouts-dual-stack",
          "cniVersion": "0.3.1,
          "type": "bridge",
          "ipam": {
            "type": "whereabouts",
            "ipRanges": [
                     {"range": "192.168.10.0/24"},
                     {"range": "2001:db8::/64"}
                 ]
          }
         }

3. Attach the secondary network to a pod. For more information, see "Adding a pod to a secondary network".

Procedure

1. Create a dedicated container namespace where you want to deploy your pod by using the following command:

   $ oc new-project test-namespace

2. Create an SR-IOV node policy.

   1. Create an SriovNetworkNodePolicy object, and then save the YAML in the sriov-node-network-policy.yaml file:

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetworkNodePolicy
      metadata:
       name: sriovnic
       namespace: openshift-sriov-network-operator
      spec:
       deviceType: netdevice
       isRdma: false
       needVhostNet: true
       nicSelector:
         vendor: "15b3"
         deviceID: "101b"
         rootDevices: ["00:05.0"]
       numVfs: 10
       priority: 99
       resourceName: sriovnic
       nodeSelector:
          feature.node.kubernetes.io/network-sriov.capable: "true"

      where:

      vendor

      The vendor hexadecimal code of the SR-IOV network device. The value 15b3 associates with a Mellanox NIC.

      deviceID

      The device hexadecimal code of the SR-IOV network device.

      Note

      The SR-IOV network node policy configuration example, with the setting deviceType: netdevice, is tailored specifically for Mellanox Network Interface Cards (NICs).

   2. Apply the YAML configuration by running the following command:

      $ oc apply -f sriov-node-network-policy.yaml

      Note

      Applying the YAML configuration might take time because of a node reboot operation.

3. Create an SR-IOV network:

   1. Create the SriovNetwork custom resource (CR) for the additional secondary SR-IOV network attachment as demonstrated in the following example CR. Save the YAML as a sriov-network-attachment.yaml file:

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetwork
      metadata:
       name: sriov-network
       namespace: openshift-sriov-network-operator
      spec:
       networkNamespace: test-namespace
       resourceName: sriovnic
       spoofChk: "off"
       trust: "on"

   2. Apply the YAML by running the following command:

      $ oc apply -f sriov-network-attachment.yaml

4. Create the VLAN secondary network.

   1. Using the following YAML example, create a file named vlan100-additional-network-configuration.yaml:

      apiVersion: k8s.cni.cncf.io/v1
      kind: NetworkAttachmentDefinition
      metadata:
        name: vlan-100
        namespace: test-namespace
      spec:
        config: |
          {
            "cniVersion": "0.4.0",
            "name": "vlan-100",
            "plugins": [
              {
                "type": "vlan",
                "master": "ext0",
                "mtu": 1500,
                "vlanId": 100,
                "linkInContainer": true,
                "ipam": {"type": "whereabouts", "ipRanges": [{"range": "1.1.1.0/24"}]}
              }
            ]
          }

      where:

      master

      The VLAN configuration needs to specify the master name. You can specify the name in the networks annotation of a pod.

      linkInContainer

      The linkInContainer parameter must be specified.

   2. Apply the YAML file by running the following command:

      $ oc apply -f vlan100-additional-network-configuration.yaml

5. Create a pod definition by using the earlier specified networks.

   1. Using the following YAML configuration example, create a file named pod-a.yaml file:

      Note

      The manifest example includes the following resources:

      • Namespace with security labels
      • Pod definition with appropriate network annotation

      apiVersion: v1
      kind: Namespace
      metadata:
        name: test-namespace
        labels:
          pod-security.kubernetes.io/enforce: privileged
          pod-security.kubernetes.io/audit: privileged
          pod-security.kubernetes.io/warn: privileged
          security.openshift.io/scc.podSecurityLabelSync: "false"
      ---
      apiVersion: v1
      kind: Pod
      metadata:
        name: nginx-pod
        namespace: test-namespace
        annotations:
          k8s.v1.cni.cncf.io/networks: '[
            {
              "name": "sriov-network",
              "namespace": "test-namespace",
              "interface": "ext0"
            },
            {
              "name": "vlan-100",
              "namespace": "test-namespace",
              "interface": "ext0.100"
            }
          ]'
      spec:
        securityContext:
          runAsNonRoot: true
        containers:
          - name: nginx-container
            image: nginxinc/nginx-unprivileged:latest
            securityContext:
              allowPrivilegeEscalation: false
              capabilities:
                drop: ["ALL"]
            ports:
              - containerPort: 80
            seccompProfile:
              type: "RuntimeDefault"

      where:

      interface

      The name to be used as the master interface for the VLAN interface.

   2. Apply the YAML file by running the following command:

      $ oc apply -f pod-a.yaml

6. Get detailed information about the nginx-pod within the test-namespace by running the following command:

   $ oc describe pods nginx-pod -n test-namespace

   Name:         nginx-pod
   Namespace:    test-namespace
   Priority:     0
   Node:         worker-1/10.46.186.105
   Start Time:   Mon, 14 Aug 2023 16:23:13 -0400
   Labels:       <none>
   Annotations:  k8s.ovn.org/pod-networks:
                   {"default":{"ip_addresses":["10.131.0.26/23"],"mac_address":"0a:58:0a:83:00:1a","gateway_ips":["10.131.0.1"],"routes":[{"dest":"10.128.0.0...
                 k8s.v1.cni.cncf.io/network-status:
                   [{
                       "name": "ovn-kubernetes",
                       "interface": "eth0",
                       "ips": [
                           "10.131.0.26"
                       ],
                       "mac": "0a:58:0a:83:00:1a",
                       "default": true,
                       "dns": {}
                   },{
                       "name": "test-namespace/sriov-network",
                       "interface": "ext0",
                       "mac": "6e:a7:5e:3f:49:1b",
                       "dns": {},
                       "device-info": {
                           "type": "pci",
                           "version": "1.0.0",
                           "pci": {
                               "pci-address": "0000:d8:00.2"
                           }
                       }
                   },{
                       "name": "test-namespace/vlan-100",
                       "interface": "ext0.100",
                       "ips": [
                           "1.1.1.1"
                       ],
                       "mac": "6e:a7:5e:3f:49:1b",
                       "dns": {}
                   }]
                 k8s.v1.cni.cncf.io/networks:
                   [ { "name": "sriov-network", "namespace": "test-namespace", "interface": "ext0" }, { "name": "vlan-100", "namespace": "test-namespace", "i...
                 openshift.io/scc: privileged
   Status:       Running
   IP:           10.131.0.26
   IPs:
     IP:  10.131.0.26

Procedure

1. Create a dedicated container namespace where you want to deploy your pod by entering the following command:

   $ oc new-project test-namespace

2. Using the following YAML configuration example, create a bridge NetworkAttachmentDefinition custom resource definition (CRD) file named bridge-nad.yaml:

   apiVersion: "k8s.cni.cncf.io/v1"
   kind: NetworkAttachmentDefinition
   metadata:
     name: bridge-network
   spec:
     config: '{
       "cniVersion": "0.4.0",
       "name": "bridge-network",
       "type": "bridge",
       "bridge": "br-001",
       "isGateway": true,
       "ipMasq": true,
       "hairpinMode": true,
       "ipam": {
         "type": "host-local",
         "subnet": "10.0.0.0/24",
         "routes": [{"dst": "0.0.0.0/0"}]
       }
     }'

3. Run the following command to apply the NetworkAttachmentDefinition CRD to your OpenShift Container Platform cluster:

   $ oc apply -f bridge-nad.yaml

4. Verify that you successfully created a NetworkAttachmentDefinition CRD by entering the following command. The expected output shows the name of the NAD CRD and the creation age in minutes.

   $ oc get network-attachment-definitions

5. Using the following YAML example, create a file named ipvlan-additional-network-configuration.yaml for the IPVLAN secondary network configuration:

   apiVersion: k8s.cni.cncf.io/v1
   kind: NetworkAttachmentDefinition
   metadata:
     name: ipvlan-net
     namespace: test-namespace
   spec:
     config: '{
       "cniVersion": "0.3.1",
       "name": "ipvlan-net",
       "type": "ipvlan",
       "master": "net1",
       "mode": "l3",
       "linkInContainer": true,
       "ipam": {"type": "whereabouts", "ipRanges": [{"range": "10.0.0.0/24"}]}
     }'

   where:

   master

   Specifies the ethernet interface to associate with the network attachment. The ethernet interface is subsequently configured in the pod networks annotation.

   linkInContainer

   Specifies that the master interface exists in the container network namespace.

6. Apply the YAML file by running the following command:

   $ oc apply -f ipvlan-additional-network-configuration.yaml

7. Verify that the NetworkAttachmentDefinition CRD has been created successfully by running the following command. The expected output shows the name of the NAD CRD and the creation age in minutes.

   $ oc get network-attachment-definitions

8. Using the following YAML configuration example, create a file named pod-a.yaml for the pod definition:

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-a
     namespace: test-namespace
     annotations:
       k8s.v1.cni.cncf.io/networks: '[
         {
           "name": "bridge-network",
           "interface": "net1" 

   1

   
         },
         {
           "name": "ipvlan-net",
           "interface": "net2"
         }
       ]'
   spec:
     securityContext:
       runAsNonRoot: true
       seccompProfile:
         type: RuntimeDefault
     containers:
     - name: test-pod
       image: quay.io/openshifttest/hello-sdn@sha256:c89445416459e7adea9a5a416b3365ed3d74f2491beb904d61dc8d1eb89a72a4
       securityContext:
         allowPrivilegeEscalation: false
         capabilities:
           drop: [ALL]

   where:

   k8s.v1.cni.cncf.io/networks,interface

   Specifies the name to be used as the master for the IPVLAN interface.

9. Apply the YAML file by running the following command:

   $ oc apply -f pod-a.yaml

Verification

1. Verify that the pod is running by using the following command:

   $ oc get pod -n test-namespace

   NAME    READY   STATUS    RESTARTS   AGE
   pod-a   1/1     Running   0          2m36s

2. Show network interface information about the pod-a resource within the test-namespace by running the following command:

   $ oc exec -n test-namespace pod-a -- ip a

   1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
       link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
       inet 127.0.0.1/8 scope host lo
          valid_lft forever preferred_lft forever
       inet6 ::1/128 scope host
          valid_lft forever preferred_lft forever
   3: eth0@if105: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default
       link/ether 0a:58:0a:d9:00:5d brd ff:ff:ff:ff:ff:ff link-netnsid 0
       inet 10.217.0.93/23 brd 10.217.1.255 scope global eth0
          valid_lft forever preferred_lft forever
       inet6 fe80::488b:91ff:fe84:a94b/64 scope link
          valid_lft forever preferred_lft forever
   4: net1@if107: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
       link/ether be:da:bd:7e:f4:37 brd ff:ff:ff:ff:ff:ff link-netnsid 0
       inet 10.0.0.2/24 brd 10.0.0.255 scope global net1
          valid_lft forever preferred_lft forever
       inet6 fe80::bcda:bdff:fe7e:f437/64 scope link
          valid_lft forever preferred_lft forever
   5: net2@net1: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
       link/ether be:da:bd:7e:f4:37 brd ff:ff:ff:ff:ff:ff
       inet 10.0.0.1/24 brd 10.0.0.255 scope global net2
          valid_lft forever preferred_lft forever
       inet6 fe80::beda:bd00:17e:f437/64 scope link
          valid_lft forever preferred_lft forever

   This output shows that the network interface net2 associates with the physical interface net1.