[ovs-discuss] OpenVswitch

Grant Taylor gtaylor at tnetconsulting.net
Sun Feb 25 05:05:11 UTC 2018


On 02/24/2018 01:52 PM, Chris Boley wrote:
> I wanted to set up OVS to support a couple of interfaces belonging to an 
> IPS VM.

Okay.

Is this going to be inline as in traffic flowing in one interface and 
out another interface to the rest of the network?  Thus a true Intrusion 
/Prevention/ System that will filter traffic?

Or are you really monitoring two different interfaces and action more 
like an Intrusion /Detection/ System?

> First, I'm only just learning about OVS so please forgive any dumb 
> questions I might submit due to my not understanding how this software 
> behaves.

We all start somewhere.

I'm rather new to OVS myself.

> I have in the past brought up a libvirt based VM and bridged a physical 
> host interface to the eth0 belonging to the virtual machine like this:

Aside:  Why are you passing the traffic through a bridge instead of 
giving the interface directly to the VM?

> auto br1               # eth0 on the IPSVM is tied to this bridge
> 
> iface br1 inet manual
> bridge_ports eno2
> post-up ifconfig eno2 mtu 1520
> post-up ifconfig eno2 promisc
> post-up ethtool -G eno2 rx 4096
> post-up ethtool -K eno2 rx off tx off sg off tso off ufo off gso off gro 
> off lro off rxvlan off txvlan off ntuple off rxhash off
> post-up ethtool -N eno2 rx-flow-hash udp4 sdfn
> post-up ethtool -N eno2 rx-flow-hash udp6 sdfn
> post-up ethtool -C eno2 rx-usecs 1 rx-frames 0
> post-up ethtool -C eno2 adaptive-rx off
> bridge_stp off
> bridge_maxwait 0
> post-down brctl delbr br1

To me, you're doing three very distinct things: 1) adding eno2 to a 
bridge (via ip or brctl, under the hood) 2) changing some interface 
settings with ifconfig, and 3) changing other interface settings with 
ethtool.

You may have a point (elsewhere in your message) about the interface 
inheriting some settings from the bridge, thus the need to (re)set them 
after associating the interface with the bridge.  I've never needed to 
do anything quite like this, so I can't comment.

> Now for the main part of the question.
> In:     ovs-vsctl add-port vbridge0 eno2
> 
> What's the stanza look like to give it all the ethtool options and 
> ifconfig options that I put on eno2 via the bridge commands as shown above?
> Is there a way to add "ovs-vsctl set interface <insert options here>" to 
> create an equivalent config?

IMHO you are replacing the Linux bridge with OVS, meaning #1 above.  I 
don't see why you can't still do #2 and #3 above like you have been. 
(Granted, you'll need to update syntax.)

> Or would I simply bring up the interface manually via 
> /etc/network/interfaces
> 
> Like:
> auto eno2
> iface eno2 inet manual
> post-up ifconfig $IFACE up
> post-up ifconfig $IFACE mtu 1520
> post-up ifconfig $IFACE promisc
> post-up ethtool -G $IFACE rx 4096
> post-up ethtool -K $IFACE rx off tx off sg off tso off ufo off gso off 
> gro off lro off rxvlan off txvlan off ntuple off rxhash off
> post-up ethtool -N $IFACE rx-flow-hash udp4 sdfn
> post-up ethtool -N $IFACE rx-flow-hash udp6 sdfn
> post-up ethtool -C $IFACE rx-usecs 1 rx-frames 0
> post-up ethtool -C $IFACE adaptive-rx off
> bridge_stp off
> bridge_maxwait 0
> pre-down ifconfig $IFACE down

That's what I've done with member interfaces for bridges or other higher 
layer networks before.  E.g. bridging VLAN (sub)interface of a bond 
connection across multiple physical NICs.

I don't think that OVS changes this much.  -  But I could be wrong.

> Then:  ovs-vsctl add-port vbridge0 eno2   #and it would maintain all the 
> attributes I brought it up with manually?

In my experience you won't actually need to ovs-vsctl add-port more than 
once.  I think OVSDB remembers that eno2 was part of vbridge0 and will 
automatically add it when OVS (re)starts.  -  At least that's been my 
experience.

> I've always operated under the pretense that when a bridge grabs an 
> interface, the interface becomes a slave to the bridge and has to assume 
> all of the bridges default settings.

You may be on to something here.  As stated above, I don't have any 
experience one way or the other.

> So I'm thinking that bringing up eno2 manually with all those settings 
> and adding the port eno2 after the fact would be a waste of time. I was 
> thinking I would have to get OVS to set the attributes to the interface 
> as it would be master over the slaved interface en02.

I can see how the bridge might reset something like MTU, but I doubt 
that the bridge will modify things like offloading, et al.

I'd make the changes, add the interface to the bridge, and then check 
the settings.  See if adding the interface to the bridge actually 
changed any of the settings that you care about.

> Clear as mudd?

You call that mud?

I've had dirtier water from a glass at the surface of the Mississippi.  ;-)

> I'm hoping what I wrote made sense.

I think I understood what you're asking about.

I hope that my reply makes sense and is not completely and totally 
inaccurate.

> I have concern about all the NIC attributes because IPS systems really 
> only perform correctly if all these attributes are applied to the 
> interface. If you don't tune the interface this way, you'll miss things 
> you're trying to detect with the IPS system.

I'll take your word for it.

I am going to ask again, why not assign eno2 directly to the VM?  Why 
pass it through a bridge at all?

> Thanks!

You're welcome.

I hope I helped thin the mud a bit.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20180224/a3a178a6/attachment-0001.p7s>


More information about the discuss mailing list