Re: [ovs-discuss] OpenVswitch

[Grant Taylor via discuss]

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 -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

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

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 -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

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

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

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.

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

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss