In default topology we do attach enp6s0 to crc VM with "make crc_attach_default_interface" and configure this interface for use for network isolation and MetalLB by creating net-attach-def with mode: macvlan.

ovn-controller CR supports adding nicMappings(nicMappings: {"datacentre": "enp6s0"}) to create net-attach-def with host-device plugin, but this requires a dedicated nic. Using the same nic i.e enp6s0 for ovn-controller make some functions stop to work, like DNS service(DNSMasq CR) which relies on 192.168.122.1 as forwarder stops to work. Also newer pods(like ansibleee) fails to start as enp6s0 is no longer available on the host.

With using nicMappings(nicMappings: {"ctplane": "enp6s0"}) net-attach-def(ctlplane) created already for Network Isolation and MetalLB

• This attaches macvlan port inside ovn-controller pods with IP allocated from pool
• Flows are configured on this chassis but SNAT from VM(without FIP) do not work as reply is not received back
• Looks like a side effect of macvlan(bridge mode as traffic for other mac are not forwarded) as if changing the mac of the ctlplane interface inside the pod to the mac of router gateway port connectivity worked fine.
• macvlan(passthru mode)  works but with it same dns issues are seen(i.e ctlplane network cannot be used for metallb services or to attach additional nic to other pods). Worked around it with(switch DNS service IP on internalapi or other network and use it on edpm nodes, use forwarder other than 192.168.122.1 or not use --no-resolv with dns pod to use pod's local forwarder).
• Also 192.168.122.1 configured as default gateway with https://github.com/openstack-k8s-operators/install_yamls/commit/051524048c093d8e511a61317c6df11190e32209 , so seems may impact other functionalities used by it.

This spike is to evaluate options if same NIC Can be utilized for OVN-Controller pods to provide external connectivity and without impacting other functionalities.

Some background in other story https://issues.redhat.com/browse/OSP-25243