The net1 interface on the egress router POD doesn't link to the secondary interface of the node but it is linked to the node's primary interface br-ex only. 

-  The following is my EgressRouter object which I created using the example given in our product documentation[1]. 


$ cat egressrouter-2.yaml 
apiVersion: network.operator.openshift.io/v1
kind: EgressRouter
metadata:
  name: egress-router-ens2
spec:
  networkInterface: {
    macvlan: {
      mode: "Bridge"
    }
  }
  addresses: [
    {
      ip: "192.168.50.71/24",
      gateway: "192.168.50.1"
    }
  ]
  mode: Redirect
  redirect: {
    redirectRules: [
      {
        destinationIP: "192.168.50.33",
        port: 80,
        protocol: TCP
      }
    ]
  }

- In the above configuration, the egress router uses the IP 192.168.50.71/24 for its net1 interface. 

- On the node, the secondary interface enp7s0 uses an IP address from 192.168.50.0/24 subnet. 

- But the macvlan configuration of net1 interface in the egress router POD is mapped to the bridge device br-ex(primary host network interface) instead of enp7s0. 

Output from POD's net namespace;
[root@worker-0 ~]# ip -d a s

# ip -d a s
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 promiscuity 0 minmtu 0 maxmtu 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 524280 tso_max_segs 65535 gro_max_size 65536 
    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
2: eth0@if741: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default 
    link/ether 0a:58:0a:83:00:a2 brd ff:ff:ff:ff:ff:ff link-netns da25c5db-9264-4787-b64d-83f0bf29b659 promiscuity 0 minmtu 68 maxmtu 65535 
    veth numtxqueues 16 numrxqueues 16 gso_max_size 65536 gso_max_segs 65535 tso_max_size 524280 tso_max_segs 65535 gro_max_size 65536 
    inet 10.131.0.162/23 brd 10.131.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::858:aff:fe83:a2/64 scope link 
       valid_lft forever preferred_lft forever
3: net1@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether ee:67:6e:c8:aa:2f brd ff:ff:ff:ff:ff:ff link-netns da25c5db-9264-4787-b64d-83f0bf29b659 promiscuity 0 minmtu 68 maxmtu 65535 
    macvlan mode bridge bcqueuelen 1000 usedbcqueuelen 1000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 
    inet 192.168.50.71/24 brd 192.168.50.255 scope global net1
       valid_lft forever preferred_lft forever
    inet6 fe80::ec67:6eff:fec8:aa2f/64 scope link 
       valid_lft forever preferred_lft forever



- Here the IF index 9(net1@if9) represents to br-ex on the node 

[root@worker-0 ~]# ip a s br-ex
9: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 52:54:00:49:a3:ac brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.9/24 brd 192.168.100.255 scope global noprefixroute br-ex
       valid_lft forever preferred_lft forever
    inet 169.254.169.2/29 brd 169.254.169.7 scope global br-ex
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe49:a3ac/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever


[root@worker-0 ~]# ip a s if9
9: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 52:54:00:49:a3:ac brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.9/24 brd 192.168.100.255 scope global noprefixroute br-ex
       valid_lft forever preferred_lft forever
    inet 169.254.169.2/29 brd 169.254.169.7 scope global br-ex
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe49:a3ac/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever



# cat /sys/class/net/br-ex/ifindex
9

# cat /sys/class/net/br-ex/iflink 
9

- Because of incorrect macvlan configuration, all egress traffic from the egress router POD leaves from the br-ex interface instead from the enp7s0 as a result result the destination IP is never reached because of reverse route issue. 

- In the following packet capture, we can clearly see that the ICMP  packet from egress router POD leaves from the br-ex interface and then from the enp1s0 interface.

- But enp7s0 interface receives the ICMP reply from the destination but the same packet is never replied to the router POD from br-ex. This is an expected behavior because the enp7s0 interface can't reply to br-ex.

[root@worker-0 /]# tcpdump -i any -nnn host 192.168.50.33 
11:16:44.638748 br-ex Out IP 192.168.50.71 > 192.168.50.33: ICMP echo request, id 13, seq 2, length 6411:16:44.638764 enp1s0 Out IP 192.168.50.71 > 192.168.50.33: ICMP echo request, id 13, seq 2, length 6411:16:44.639216 enp7s0 P   IP 192.168.50.33 > 192.168.50.71: ICMP echo reply, id 13, seq 2, length 64

11:16:45.662871 br-ex Out IP 192.168.50.71 > 192.168.50.33: ICMP echo request, id 13, seq 3, length 6411:16:45.662894 enp1s0 Out IP 192.168.50.71 > 192.168.50.33: ICMP echo request, id 13, seq 3, length 6411:16:45.663441 enp7s0 P   IP 192.168.50.33 > 192.168.50.71: ICMP echo reply, id 13, seq 3, length 64

11:16:46.686817 br-ex Out IP 192.168.50.71 > 192.168.50.33: ICMP echo request, id 13, seq 4, length 6411:16:46.686856 enp1s0 Out IP 192.168.50.71 > 192.168.50.33: ICMP echo request, id 13, seq 4, length 6411:16:46.687290 enp7s0 P   IP 192.168.50.33 > 192.168.50.71: ICMP echo reply, id 13, seq 4, length 64 

  - To give another try I added the config line master: "enp7s0" to the egress router object but this didn't make any difference as the net1 interface inside the POD still linked to the physical system's br-ex interface instead of enp7s0.   


$ cat egressrouter-2.yaml 
apiVersion: network.operator.openshift.io/v1
kind: EgressRouter
metadata:
  name: egress-router-ens2
spec:
  networkInterface: {
    macvlan: {
      mode: "Bridge",
      master: "enp7s0"
    }
  }
  addresses: [
    {
      ip: "192.168.50.71/24",
      gateway: "192.168.50.1"
    }
  ]
  mode: Redirect
  redirect: {
    redirectRules: [
      {
        destinationIP: "192.168.50.33",
        port: 80,
        protocol: TCP
      }
    ]
  }


- Output of NAD created by egressrouter

$ oc get network-attachment-definitions.k8s.cni.cncf.io egress-router-cni-nad -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    release.openshift.io/version: 4.13.18
  creationTimestamp: "2024-04-23T12:53:04Z"
  generation: 1
  name: egress-router-cni-nad
  namespace: demo
  ownerReferences:
  - apiVersion: network.operator.openshift.io/v1
    controller: true
    kind: EgressRouter
    name: egress-router-ens2
    uid: bcd4f0da-9ced-41a3-93b2-9ea85cf17573
  resourceVersion: "87076848"
  uid: a62bd2bf-dfed-4ddd-93de-04fbe24c1a77
spec:
  config: |-
    { "cniVersion": "0.4.0", "type": "egress-router", "name": "egress-router-cni-nad", "ip": { "addresses": [ "192.168.50.71/24" ], "destinations": ["80 TCP 192.168.50.33"],
    "gateway": "192.168.50.1" }, "log_file": "/tmp/egress-router-log", "log_level": "debug" }


     [1] https://docs.openshift.com/container-platform/4.13/networking/ovn_kubernetes_network_provider/deploying-egress-router-ovn-redirection.html

    OCP 4.12, 4.13, 4.14 

- On a OVN-K cluster having two physical network interfaces on the node, use the following egress router configuration to reproduce the issue. 

$ cat egressrouter-2.yaml 
apiVersion: network.operator.openshift.io/v1
kind: EgressRouter
metadata:
  name: egress-router-ens2
spec:
  networkInterface: {
    macvlan: {
      mode: "Bridge",
      master: "enp7s0"
    }
  }
  addresses: [
    {
      ip: "192.168.50.71/24",
      gateway: "192.168.50.1"
    }
  ]
  mode: Redirect
  redirect: {
    redirectRules: [
      {
        destinationIP: "192.168.50.33",
        port: 80,
        protocol: TCP
      }
    ]
  }



After the egress router POD is created, try pinging the destination IP from the egress router POD and notice that the packet from the egress router POD leaves from the br-ex interface from the node instead from the secondary interface.