Enable AdminPolicyBasedExternalRoute (APBER) to leverage secondary/additional network interfaces on OpenShift nodes for egress traffic.

Current Implementation & Logical Flow

Currently, when an AdminPolicyBasedExternalRoute is deployed:

1. Logical Router Policy: A policy is created on the ovn_cluster_router for the affected Pod. This redirects egress traffic (destined outside the pod network) to the OVN Gateway Router of the node.

      2. ECMP Route: The Gateway Router adds an ECMP route for the Pod IP using the nextHop defined in the APBER.

     3.  SNAT Behavior: On the Gateway Router, the Pod IP is SNATed using the node's br-ex IP (primary interface).

The Problem: Primary Interface Hardcoding

Even if the gatewayIP defined in the APBER belongs to a different subnet associated with a secondary interface, the traffic is forced through br-ex.

• Connectivity Dependency: This only works if there is L3 routability/cross-connectivity between the br-ex subnet and the target gateway subnet.

• OVN Gateway Mode Parity: This behavior is consistent across both Shared Gateway Mode and Local Gateway Mode (routingViaHost: true).

• Limitation: Users cannot natively isolate egress traffic to a specific secondary physical interface or a dedicated segment of the network.

Proposed Enhancement

We request the ability to direct APBER traffic through a node's secondary interface. Key requirements include:

1. Secondary Interface Egress: Allow the egress traffic to exit via an interface other than br-ex when the nextHop resides on a secondary subnet.

      2. SNAT Flexibility: Ensure SNAT uses the IP of the egress interface (or a specified IP) rather than defaulting to the primary node IP.

      3. VRF Support: Provide an option to associate the APBER logic with a specific VRF table on the host. This would allow the node to make routing decisions based on isolated routing tables, ensuring strict traffic separation for multi-homed nodes.