On 29 May 2025, at 17:53, engineer2024 <engineerlinux2...@gmail.com> wrote:
This is not what I exactly asked. This scenario is specifically for the sriov ports. In this case, how the pkt from the physical nic go back to the same node ? Two questions.
1. For sriov vm ports , where does the DHCP responses come from ?
From the chassis where the external port is scheduled. This is why this type of port was called _external_. Where is this maintained in the OVN ? I know for non sriov ports or non direct vNIC types, the ovn controller on the compute node intercepts it and responds. So it never comes out of the compute node.
2. How to provide metadata service for sriov ports ?
Again, same concept as before. The ovn metadata agent running in the same node where the external port is scheduled will handle this.
The blogpost I linked before explains this in detail. I also recommend using tcpdump to understand the packet flow better.
For SRIOV ports, things like dhcp, metadata, routing… can’t be handled locally because the hypervisor is skipped. Therefore they are handled _externally_ by the OVN external port :) For non sriov ports the ovn metadata namespace does.
Hi, Hi, i have an openstack ovn setup. For sriov neutron ports, when the cms option is set on the compute node hosting the sriov nic, as shown below
"ovs-vsctl set Open_vSwitch . external-ids:ovn-cms-options=\"enable-chassis-as-extport-host\""
the port is getting the dhcp ip. Now, my question is, from where is the OVN responding to this external port's DHCP reqs ? I know for a normal tap port , it goes through br-int and then the ovn-controller gives the response. but the sriov port by passes the whole ovs and the host's kernel network stack. But where does it go to after it exits the physical VF interface, and how does OVN answer it ? How and where does OVN's inbuilt dhcp service maintained ?
DHCP will be answered wherever your external port is scheduled.
If you're seeing this behavior and you are 100% sure that the same compute node that has the SRIOV port is serving the DHCP requests to that instance then it means that the broadcast request is coming out from the SRIOV port and back in from the same switch presumably to the compute node through a different NIC and from there to br-ex (or similar?) -> br-int -> external-port. I'm not entirely sure about the return path though but you can possibly check with tcpdump :) Next, for sriov ports, the nova metadata service is also unreachable, as, it bypasses the ovn-meta namespace on the compute host connected to the br-int via veth cables. So injecting user data like ssh keys is not possible and failing...
Same... you should have the ovn-metadata-agent running where your external port is and this one will proxy the metadata request to nova and serve it back to your sriov instance wherever it is.
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
|
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
