ilgtech75 at gmail.com
Sun Feb 25 14:54:21 UTC 2018
Sorry Grant, I think I replied directly to you the first time around. I
forgot the Reply All.
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?
Correct, *INLINE_IPS* filtering and dropping traffic. To the IPS VM it
would look like two ethernet interfaces that were members of a transparent
Aside: Why are you passing the traffic through a bridge instead of giving
the interface directly to the VM?
Here goes.. apologies for the lengthy explanation:
It all comes down to port count..I don’t want to run any more hardware than
I’m trying to do a concept build for an All in 1 kind of thing. It hinges
around virtualization of a couple OS’s.
This is meant for a SOHO environment with 25-50 users where load wouldn’t
likely be much of an issue at all.
I’m running a supermicro server with Ubuntu 16.04 / libvirt based
hypervisor, an 8 core Atom based proc, 32 gigs of ram
4 built in Intel nic’s onboard.
5 VM’s were planned to run as guests on this hardware. One Ubuntu guest
running LogAnalyzer/syslog server, one Ubuntu guest running NFSEN, one vyOS
router, and a Suricata based IPS porting it’s logs out via Syslog to the
LogAnalyzer instance. Lastly a tiny instance of Ubuntu running Arpwatch to
detect / log new hosts plugging into a customer network.
There are 4 intel nic’s that come onboard with the server. (My desire is to
avoid adding NIC’s.)
There would be 2 OVS logical bridges vbridge0 and vbridge1
One nic was to go to the mgmt of the host. 2 nics were to be bridged / linked
to separate trunk ports on a Cisco 48 port 3750G to handle all traffic
going to the guests I mentioned and internal user traffic connected to the
vbridge1. The 3750g would handle access layer for physical computers
running on the LAN.
The internal VM guests including the IPS would have nics that would be tap
interfaces. Like this:
ovs-vsctl add-port vswitch0 vnic0 tag=10 -- ovs-vsctl set interface vnic0
type=internal (vnic0 being the tap IF).
The IPS will be a transparent bridge between the Logical OVS bridges. (a
bridge within a bridge within a bridge ;D ) <== I might run into hiccups
here as I don't know how OVS will react to a VM bridging two logical
Tap interfaces comes up via the /*etc*/network/interfaces on the host.
(the ones coming into the IPS would be tuned the same for the driver
manipulation and the rest would be basic)
(I’d also have to do the same for the virtio nics in the IPS VM to get
continuity of nic behavior in all areas of the connectivity)
iface vnic0 inet manual
pre-up ip tuntap add vnic0 mode tap user foo
up ip link set dev vnic0 up
post-up ifconfig vnic0 mtu 1520
post-up ifconfig vnic0 promisc
post-up ethtool -G vnic0 rx 4096
post-up ethtool -K vnic0 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 vnic0 rx-flow-hash udp4 sdfn
post-up ethtool -N vnic0 rx-flow-hash udp6 sdfn
post-up ethtool -C vnic0 rx-usecs 1 rx-frames 0
post-up ethtool -C vnic0 adaptive-rx off
post-down ip link del dev vnic0
The last host port was planned to be bridged directly to the WAN interface
meant for the WAN side of the vyOS router so I could plug it into the WAN
directly for sake of ease.
My concept is my own hair brained idea but I think it can be done without
too much headache. Once perfected it would just be an install process.
I just want to make sure that as traffic comes into the host, that the host
nic driver isn’t modifying the packets before they hit the IPS. This may
not even work but if it does, I could potentially save a bunch of money in
discreet server costs and cut down on power use immensely. A single
supermicro server like this with 6 terabytes of raid 5 space is less than
1500 USD. A cisco 3750G is cheap these days. Or upgrade to a 2960-X which
is a defacto standard Cisco Access layer switch these days.
I could hand off an entire fully capable enterprise class router/traffic
shaper/vpn capable/ips capable/netflow capable network server for a couple
of thousand and sell maintenance / monitoring of said systems monthly. So
that’s the WHY in this whole thing. Small office environments are my target
Sorry….. too much information??
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.
After reviewing those two links I came to mostly the same conclusion albeit
I haven’t had a chance to put that theory to the test.
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.
I’ll have to set this up and do the testing to be sure even for myself.
Thanks again for your input!
On Sun, Feb 25, 2018 at 12:05 AM, Grant Taylor via discuss <
ovs-discuss at openvswitch.org> wrote:
> 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.
> 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
> 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
>> 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
> 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
> 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?
> You're welcome.
> I hope I helped thin the mud a bit.
> Grant. . . .
> unix || die
> discuss mailing list
> discuss at openvswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss