Hi Ben, Yes. This is a use case where you have a remote hardware VTEP that does not support OVSDB.
Regarding the second point, it is bidir. First, one need to create a chassis entry in SB for each remote VXLAN HW VTEP. That would make the traffic arrive to the processing pipeline, otherwise it would not arrive. Then, one needs to add a flow that would take that packet to a port.That's a bit hacky, by doable. In a nutshell, (for other readers) OVN switches traffic based on dest port. However, VXLAN packet would not have a destination port. For example, one could intercept traffic at table 8, resubmit to table 200. In table 200, there would be rules that would determine destination port, metadata updates, and the packet is resubmitted to table 9. ovs-ofctl add-flow br-int 'table=8, priority=0, actions=resubmit(,200)' ovs-ofctl add-flow br-int 'table=200, priority=0, actions=resubmit(,9)' Second, one adds an entry on the logical switch in SB db and maps it to the previously created VTEP. Now you have a bidir communication. Thank you for your answer regarding ovn-controller. That is what I was looking for 😊 The section of code responsible for it would have been better 😊 joking! I totally understand the point of it being "one off". Regards, Paul ________________________________ From: Ben Pfaff <[email protected]> Sent: Tuesday, August 21, 2018 1:55 PM To: Paul Greenberg Cc: [email protected] Subject: Re: [ovs-discuss] Tunnel packets from unknown VTEPs On Tue, Aug 21, 2018 at 03:45:34PM +0000, Paul Greenberg wrote: > Currently, when a VXLAN packet comes to a host, but the source ip > (chassis) of the packet is not in OVN SB database, packets are being > dropped prior to getting to openvswitch. > > How to make the packets reach the switch? It would be necessary to make ovn-controller add a VXLAN port without specifying a remote_ip. This would require changes to the ovn-controller C sources. But this question raises two kinds of other issues. First, OVN uses VXLAN only for connecting to hardware switches, which in OVN are only useful for incorporating bare-metal physical hardware into a logical network. That's a pretty specialized use case. Second, this would only be useful for one-way connectivity, because OVN wouldn't have any idea when it should send packets back the other way.
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
