On 2019-01-09 8:33 a.m., Christopher Hannon wrote:
Thanks for your reply, I think I understand your point regarding
hardware switching. Although wouldn't there need to be a layer 3
connection somewhere to pull a packet from one vlan to the other? I
guess I am not completely sure about how the vlans get connected
together. Would this be in OVS?
Yes, then things become more of a layer 3 mechanism. That is about all
I've come up with when up against a lower level hardware switch.
Possibly in swconfig or the iproute2 or ethtool there is a mechanism to
define them as access ports, each in their own vlan. But VLAN ids are
passed up in the skb structures, so don't know if that would work.
Maybe XDP performs operations before OVS picks up packets. But that is
getting deep into the weeds.
If you desire to use the default switch in OVS, then.... maybe very
difficult. I don't know if performing vlan pre-processing will help.
Something along the lines of pushing/popping vlan tags as in
https://mail.openvswitch.org/pipermail/ovs-discuss/2018-October/047617.html
But if you use the openflow side of things and program in your own
packet ops, you may get something closer. But you won't have the STP
side of things, unless you program that yourself as well.
On Tue, Jan 8, 2019 at 10:00 PM Raymond Burkholder <r...@oneunified.net
<mailto:r...@oneunified.net>> wrote:
One solution might be to supply a unique vlan between each pair of
switches:
vlan 111 s1,sw2
vlan 112 sw2,sw3
vlan 114 sw3,sw4
vlan 115 sw4,sw1
I *think* the issue is that with the lan ports all in the same
vlan, the hardware switch is switching packets, and not passing
the packets up to ovs. And if the hardware switch does not have
STP turned on, you will end up with the loop.
With the segregating vlans, packets should then be passed to OVS
for use in it's bridging functions.
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss