Re: [ovs-discuss] password in plain text?!
On 02/01/2019 03:44 AM, Riccardo Ravaioli wrote: Why is the mailing list memberships reminder sending me my password in plain text? That's not too nice... :) That is how Mailman operates. (At least the 2.x versions that I've subscribed to.) Can that be fixed? You can modify your subscriber preferences to not receive the monthly reminder email, which includes your password. You can take your concerns about the fact that Mailman is storing passwords in an unhashed to the Mailman maintainers. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] ARP issues with KVM and OVS..?
On 1/4/19 3:19 PM, Alexander Witte wrote: Hi! Hi Alex, Environment: KVM Fedora I have a weird issue where a VM can ping one way through the open vswitch but the other way doesn't seem to want to go through. The setup is like this: VM1 --> OVS --> VM2. VM1 has two interfaces: interfaceA is tagging a VLAN in the VM. InterfaceB has no tagging anywhere. So VM1 interfaceA is adding 802.1Q VLAN tagging inside the guest OS. Correct? Is OvS doing any filtering? Or is it trying to handle all traffic, tagged and untagged from the guest as best as it can? VM2 has two interfaces: interfaceA is being tagged (in OVS) with the same VLAN as VM1. Interface B has no VLAN. So VM2 interfaceA is untagged and OvS is assigning a Port VLAN ID (PVID) to the untagged traffic that's coming into OvS. Correct? Is OvS doing any filtering? Are interfaces A and interfaces B in the same VLAN in OvS? Or are they in different VLANs? Interface B can ping through both ways fine. InterfaceA can ONLY ping through Centos --> Cisco. Pinging in the other direction does not work. Please clarify what CentOS & Cisco are in this context. You've been saying VM1 & VM2. Are CentOS & Cisco the names of the VMs (respectively?)? Or are you also trying to connect from OvS out to the real world and talk to a physical Cisco device? We traced it to arp replies not making it back through the OVS in one direction. Pretty weird. Please elaborate on which way traffic works. Also, please elaborate on what tcpdump (et al) shows on the interfaces when pinging either direction. I can ping one way but not the other way. What happens if you clear the ARP cache? Do things work? Or is this by chance a bigger issue? The OVS ports are being created dynamically. I'm defining some libvirt network XMLs that have portgroups in them that are assigned to an OVS. Then I do a virt-install to create the VMs which places the NICs in the portgroups on the OVS. So I create the OVS ports dynamically when the VM boots. OVS-VSCTL show looks fine. If needed I can paste it here (just gotta clean it up a bit since I've been experimenting). Sadly, I don't know enough about how libvirt interfaces with OvS to comment. Though I should do some reading as I'd like to start using it with libvirt. - I'd appreciate any pointers you have handy to what you followed. (I've not gone looking yet.) I'm curious if this is common issue/user mistake or are there some gotchas when doing this with KVM virtual machines...? Do these need to be hardcoded as TAP interfaces or INTERNAL interfaces. I would be quite surprised if you needed to hard code anything, be it TAP or internal interfaces. I would /think/ that you would want to use internal interfaces. At least that's what I use for all my manually created network namespaces (proto containers). If this is not a common problem/resolution are there any specific commands I can run to paste here to give any willing helper some more insight? I'd like to see the pertinent parts of the output from "ovs-vsctl show" while both VM1 and VM2 are running and connected. Please state which OvS interfaces belong to which VM & associated guest interface. Things I've tried: -Removing the VLAN tag. I would expect that you would need to remove the tagging from the guest OS in VM1 and the port tagging from the OvS port connected to VM2. -Separating the two interfaces to separate OpenvSwitches. I would think that you could connect the interfaces to the same OvS as long as they were in non-overlapping VLANs. I.e. interfaces A playing with VID 11 and interfaces B in VLAN . Any help is greatly appreciated! I don't know if it's related at all. But I've had a problem creep into my sandbox workstation configuration (it's probably a kernel nob that i fobbed without realizing it) where I have to disable Rx & Tx offload on my OvS (internal) interface. If I don't do that, (I /think/) I am able to ARP & ping, but TCP (I notice it with SSH) connections establish and then subsequently stall & ultimately fail to pass traffic. Disabling Rx & Tx offload on the OvS (internal) interface returns things to normal. Note: This is the OvS (internal) interface from the host, not the OvS interfaces for the guests. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Single nic server and ovn
On 12/19/2018 02:51 PM, Vasiliy Tolstov wrote: I know about that, but if ovs have panics/crushes or misconfigured i can' get access to my server via ethernet Fair concern. I've not personally experienced problems with OvS. But I'm not pushing it. You might consider something like MACVLAN and / or IPVLAN. Let them provide one connection for the local system and another connection for OvS. I know you can also do things with Linux native bridges, but that seems sort of antithetical to the purpose of OvS and this discussion list. ¯\_(ツ)_/¯ -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Single nic server and ovn
On 12/18/2018 11:56 PM, Vasiliy Tolstov wrote: Hi, i have some servers that have only one nic for network. As i understand for ovn i need to add this interface to ovs bridge. But for host access i need some ip address on server and also if ovs or ovn is down or something else with this services i can't connect to server. I have multiple machines with a single interface (or single logical that is multiple physicals bonded). It works well. How to deal with such case? Or only one thing is to create localnet port in ovn? I add the interface(s) to OvS and use an internal OvS port to assign my IP(s) to. 5ff87006-3e41-4204-94f5-ad44a8f9d5a8 Bridge "eth0" Port "eth0" Interface "eth0" type: internal Port "lab1" tag: 101 Interface "lab1" type: internal I have my management IP(s) on the eth0 internal (logical) interface. I then use other internal ports for various different things. It works great. IMHO, OvS is somewhat better, especially when bonding and using VLANs. OvS handles those more cleanly than needing to create a bond interface and VLAN sub-interfaces on top of the bond. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Physical interface vs interface under OVS bridge Performance/throughput impact
On 11/15/2018 07:48 AM, Ben Pfaff wrote: No. (Why would running OVS in the simplest way increase the performance cost?) Is it possible that there's slightly more overhead in the algorithm(s) of the simple L2 learning functionality of the "NORMAL" action? Compared to simple rules that explicitly match the frame and specify an action? (Assuming that there aren't any other flows before the aforementioned flows would match and act.) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] how to use ovs bridge without using OpenFlow switch?
On 10/04/2018 03:27 AM, Vikas Kumar wrote: Note: somewhere i read that ovs can be used as a simple ethernet bridge also. It is possible to use Open vSwitch as a bridge without an OpenFlow controller. The OvS bridge will default to (what OpenFlow calls) a "NORMAL" bridge. I think this is what you are asking for. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] What is the best way to map a VTEP flow to an internal port?
On 09/21/2018 02:48 PM, Ben Pfaff wrote: No. A port can be an internal port or a vxlan port. It can't be both. Thank you for the confirmation. Maybe you should use flows instead of OVSDB configuration. Flows can also direct packets from one port to another. I guess that this would be easy for a controller to set up. I have been testing OpenFlow rules to match the in_port to assign the tunnel_id. It seems to be working in my manual testing. I just need to figure out a way to automatically configure things. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] What is the best way to map a VTEP flow to an internal port?
Hi Ben, Thank you for the reply. On 09/17/2018 10:29 PM, Ben Pfaff wrote: Something like this? I have not tested it. ovs-vsctl add-port br0 port0 -- set interface port0 type=internal -- set port port0 tag=100 ovs-vsctl add-port br0 port1 -- set interface port1 type=internal -- set port port1 tag=101 ovs-vsctl add-port br0 vtep0 -- set interface vtep0 type=vxlan options:remote_ip=192.0.2.1 options:key=100 tag=100 ovs-vsctl add-port br0 vtep1 -- set interface vtep1 type=vxlan options:remote_ip=192.0.2.1 options:key=101 tag=101 If I'm reading this correctly, it looks like you're assigning VLANs to (internal) ports and VTEPs. Thus you are relying on VLANs. Is there no way to assign a VNI directly to the (internal) port? I don't foresee running out of VIDs per vSwitch. But I'm being lazy and applying parsimony and would like to avoid VLANs if they aren't necessary. I'd ideally like to apply options:key=123 to the (internal) port. But I think that failed when I tried it. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] What is the best way to map a VTEP flow to an internal port?
What is the best way to map a specific flow ID coming in a VTEP to a specific internal port? # ovs-vsctl add-br br0 # ovs-vsctl add-port br0 port0 -- set interface port0 type=internal -- set port port0 tag=100 # ovs-vsctl add-port br0 port1 -- set interface port1 type=internal -- set port port1 tag=101 # ovs-vsctl add-port br0 vtep0 -- set interface vtep0 type=vxlan options:remote_ip=192.0.2.1 options:key=flow I want VNI / flow 100 to go to port0 and VNI / flow 101 to go to port1. Do I need to map the VNIs to a VLAN (possibly via OpenFlow?) and then assign a VLAN to the internal port? Is there a way to associate an internal port with a specific VNI / flow like there is a a way to associate a specific VLAN (tag=$VID)? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Complex, for me at least, setup with multiple hosts
On 09/09/2018 02:12 PM, Vassilis Aretakis wrote: I have a LAN which is accessible by 3 servers. I would like to allow specific internet hosts to use this lan. Okay. Because I want ot have multiple links and All hosts to receive multicast etc. I thought of using multiple openvswitches on the hosts which has access to this lan, and use also VXLAN to make a mesh network (MAybe I am thinking wrong). I don't know if I would call what I'm thinking of as a mesh per say. Certainly wouldn't call it a full mesh. It sounds like you want to create an OvS on each of the three servers, each with eth1 as a member port, and a OvS on each of the VMs. Then add OvS VTEPs between: - Server1 & VM1 - Server1 & VM2 - Server2 & VM1 - Server2 & VM2 - Server3 & VM1 - Server3 & VM2 I think you want to NOT have VTEPs between the servers or the VMs. It's my understanding that your goal / motivation is to get multicast traffic from the private LAN to the VMs. Correct? I think that you are going to want to do /something/ to prevent loops. I think the minimum is STP. Hopefully the private LAN switch is the root. I'm guessing that STP will pick one of the links between the servers and each VM as the forwarding link and put the links to the other servers into a blocking state. I'm sure there are other things you can do with SDN to prevent the looping too. That should extend the broadcast domain from the private LAN to the VMs. I don't know what or how multicast will effect this. When I began with building this with double GRE tunnels I ended up causing a mess instead of me Mesh. Okay. If you see the diagram example, I tried to make VM1 and VM2 to be able to access PRIVATE LAN, but I failed. would you have a suggested setup? in order to pass traffic using SRV1/2/3? Private LAN ---+--- - - - | +--+--+--+---+--+--+ | | | eth1 | | | | | +--+ | | | || | | |br0 | | | || | | | +--+ | | | | | vm1 +-+ | +--+--+--+ | : | | : | Server1 | : | | : | +--+ | : | | eth0 | | : +-+--+---+-+ : | V ---+--- - - -X InternetL ---+--- - - -A | N +-+--+---+-+ : | | eth0 | | : | +--+ | : | | : | VM1| : | | : | +--+--+--+ | : | | | s1 +-+ | | +--+ | | | || | | |br0 | | | || | +--++--+ Server1:vm1 and VM1:s1 are the interconnected VTEPs. Obviously the OvSs on the systems would have additional VXLAN connections as described above. That would make br0 on VM1 be an extension of the Private LAN. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] tap ports...
On 03/07/2018 12:56 PM, Ben Pfaff wrote: Q: I created a tap device tap0, configured an IP address on it, and added it to a bridge, like this:: $ tunctl -t tap0 $ ip addr add 192.168.0.123/24 dev tap0 $ ip link set tap0 up $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 tap0 I expected that I could then use this IP address to contact other hosts on the network, but it doesn't work. Why not? This does not relate to my question any more than the term collisions of "tap" and "OVS". A: The short answer is that this is a misuse of a "tap" device. Use an internal" device implemented by Open vSwitch, which works differently and is designed for this use. To solve this problem with an internal device, instead run: I am quite happily using internal ports for VMs. Internal ports will not work for thinks like OpenVPN User-Mode Linux. Both OpenVPN and UML expect to open the unix socket file (descriptor) and receive Ethernet frames. They do not work with a traditional network interface, like an OVS "internal" port. Even more simply, you can take advantage of the internal port that every bridge has under the name of the bridge:: $ ovs-vsctl add-br br0 $ ip addr add 192.168.0.123/24 dev br0 $ ip link set br0 up I agree with the statement, but it has no relation to my question. In more detail, a "tap" device is an interface between the Linux (or BSD) network stack and a user program that opens it as a socket. I'm very well aware of that. That is the exact behavior that I'm wanting. When the "tap" device transmits a packet, it appears in the socket opened by the userspace program. Conversely, when the userspace program writes to the "tap" socket, the kernel TCP/IP stack processes the packet as if it had been received by the "tap" device. That is exactly what my understanding of a tap interface is used for. It's close cousin, the tun interface, behaves quite similar, save for the fact that it operates at layer 3 with IP packets between the interface and the unix socket. Consider the configuration above. Given this configuration, if you "ping" an IP address in the 192.168.0.x subnet, the Linux kernel routing stack will transmit an ARP on the tap0 device. I would expect such transmitted ping (or more likely an associated ARP request) to come out the unix socket that a user space program like OpenVPN or UML would process. - Unrelated to my question. Open vSwitch userspace treats "tap" devices just like any other network device; that is, it doesn't open them as "tap" sockets. That's what I expected. That means that the ARP packet will simply get dropped. I'd think the dropping or not has more to do with what opens the tap's associated unix socket and very little to do with OVS. - In the case you are describing. You might wonder why the Open vSwitch kernel module doesn't intercept the ARP packet and bridge it. Nope, not at all. After all, Open vSwitch intercepts packets on other devices. The answer is that Open vSwitch only intercepts received packets, but this is a packet being transmitted. The same thing happens for all other types of network devices, except for Open vSwitch "internal" ports. If you, for example, add a physical Ethernet port to an OVS bridge, configure an IP address on a physical Ethernet port, and then issue a "ping" to an address in that subnet, the same thing happens: an ARP gets transmitted on the physical Ethernet port and Open vSwitch never sees it. This is what I would expect. (You should not do that, as documented at the beginning of this section.) IMHO the start of your reply gave an example alternative example, and this paragraph confirmed what I expected would be the case. However, that being said, I have had plenty of times that I have done this very thing with Linux kernel native bridges for various reasons. Frequently the service IP would live on a bridge and the maintenance IP (in a different subnet) lived on the underlying Ethernet interface. It worked perfectly fine. Granted, I had to be aware of the caveat that you outlined. - My point being, there are times when it is okay (maybe sub-optimal) to put an IP on a member interface instead of the bridge device itself. It can make sense to add a "tap" device to an Open vSwitch bridge, if some userspace program (other than Open vSwitch) has opened the tap socket. This is the EXACT type of scenario that I was asking about. OpenVPN and UML (et al) opening the unix socket with their associated network interfaces connected to an OVS bridge. This is the case, for example, if the "tap" device was created by KVM (or QEMU) to simulate a virtual NIC. In such a case, when OVS bridges a packet to the "tap" device, the kernel forwards that packet to KVM in userspace, which passes it along to the VM, and in the other direction, when the VM sends a packet, KVM writes it to the "tap" socket, which causes OVS to rec
[ovs-discuss] tap ports...
Can OVS create tap ports like OpenVPN or KVM (Qemu) or User Mode Linux use? I.e. an Ethernet interface inside OVS and a socket that applications can glom onto and use. I think I can create the tap interfaces manually (via tunctl or ip tuntap…) and then add them to a bridge. However I feel like this is unnecessary and may very well be something that OVS can do without the separate devices. Hence my question if OVS can create (internal) tap interfaces, much the same way that it can create (internal) vEth (like) interfaces. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OpenVswitch
On 02/28/2018 09:00 PM, Chris Boley wrote:
I've been tinkering with OVS on Ubuntu 16.04 with the libvirt hypervisor.
Tinkering ~> learning is always a good thing.
I've gotten the XML based networks defined in the hypervisor and I've
gotten the host to understand it's interfacing with OVS.
:-)
So I'm hitting some sticking points that are starting to make me feel
well.. "thick".
That's a weekly, if not daily, occurrence for me.
I built the bridge.
"sudo ovs-vsctl add-br vbridge0"
I set up an external bond port on the bridge.
ovs-vsctl add-bond vbridge0 vbond0 eth0 eth1 lacp=active
other_config:lacp_time=fast trunks=2,3 *#*#I'm kind of confused about
the trunks=2,3 part Do I really need that to pass the tagged frames to
the Cisco Switch?
See Scott's reply.
That's brings up the bond "vbond0 tied to my vswitch0
Does it actually bring the vbond0 interface up? Or just create it?
My config in my cisco switch is a standard 2 port etherchannel.
with the good ole:
switchport trunk encapsulation dot1q
switchport mode trunk
Switch#sh mac ad
Switch#sh mac address-table | i Po1
2 5254.0071.b1b6 DYNAMIC Po1 << here's my VM
1 0004.23d7.bd0c DYNAMIC Po1
1 0004.23d7.bd0d DYNAMIC Po1
I have my libvirt network defined, when I do an "ovs-vsctl show" it
looks like this:
cboley@VMHOST:~$ sudo ovs-vsctl show
126a4b57-4837-42a9-95d6-d818b35e95bd
Bridge "vbridge0"
Port "vbond0"
trunks: [2, 3]
Interface "eth1"
Interface "eth2"
Port "vbridge0"
Interface "vbridge0"
type: internal
Port "vnet0"
tag: 2
Interface "vnet0"
ovs_version: "2.5.2"
That all seems reasonable enough.
What I'm "thick" about is the fact that unless I run the following
commands my bridge just won't work.
manually at the CLI of the VM host I must run.
ifconfig vbridge0 up
I'd expect that you would need to bring the vbridge0 interface up.
Hence my question above.
modprobe 8021q <<< I know why that's happening and it's an easy fix..
just stick it in the interfaces file.
vconfig add vbridge0 2
vconfig add vbridge0 3
Won't this create two additional VLAN sub-interfaces? vbridge0.2 and
vbridge0.3
Are you actually using those interfaces? Or are you by chance defining
them and not actually using them?
I sort of feel like bringing the vbridge0 interface up is the crux.
Also, doesn't OVS handle 802.1q VLAN tagging internally? Won't that
work without the 802.1q module loaded in the kernel?
After I do that my VM's have conectivity.
ACK
So after all that said, I know my vbridge0 doesn't come up without
help.. I'm not an expert, I'm just muttling through info.
Muddling and tinkering are good things. Just learn the why along the way.
I've been using a lot of helpful info from blog.scottlowe.org
BTW. His info really saved my tail with libvirt.
Yep, I've learned a LOT from Scott's blog, and I have good interactions
with him on Twitter.
Should I assume it's to just create the bridge and the bond in the
interfaces file manually like this instead?
I'm used to OVS creating network interfaces that the OS then works with.
This includes bringing the interfaces up ("ifconfig $interface up" or
"ip link set dev $interface up") and assigning IP addresses to them.
OVS has always remembered the existence of the interface and reproduced
that upon reboot.
OR can I create the vbridge0 under and OVS command and make it come up
automatically with OVS commands that I'm missing?
I'm not aware of a way to have OVS bring an interface up. I've always
done that with the OS native tools. - Perhaps that's just my ignorance.
Though, given that the interface was up when OVS shuts down, and OVS
remembers the state, I'm inclined to think that OVS can't actually set
the interfaces up.
BTW.. I'm not reinvening anything and can't take credit for this idea.
Some really smart person (not me ;D ) posted this:
https://zcentric.com/2014/07/07/openvswitch-kvm-libvirt-ubuntu-vlans-the-right-way/
$ReadingList++
Any guidance on how I can or should proceed would be greatly appreciated!
Thanks in advance...
I don't know if it will help or not, but that's my take on things.
--
Grant. . . .
unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OpenVswitch
On 02/25/2018 07:54 AM, Chris Boley wrote: Sorry Grant, I think I replied directly to you the first time around. I forgot the Reply All. Things happen. Correct, *INLINE_IPS* filtering and dropping traffic. To the IPS VM it would look like two ethernet interfaces that were members of a transparent bridge. Well, /almost/ transparent bridge. ;-) Here goes.. apologies for the lengthy explanation: It all comes down to port count..I don’t want to run any more hardware than necessary. Okay. I think I was assuming that you would be bringing a physical port in, adding it to a bridge, which would then have another port connected to the VM. Thus the inquiry about bypassing the bridging and just connecting the physical port to the VM directly. …continuing to read your reply… 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. ACK HOST: 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. I'd like to know more details about the Supermicro server as it may fit desires that I have. ;-) GUESTS: 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. Okay. I think I track most of that. I'm having trouble placing NFSEN at the moment. I want to say I ran across it while messing with NetFlow years ago. …reading… There are 4 intel nic’s that come onboard with the server. (My desire is to avoid adding NIC’s.) Fair. 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. Unless I'm missing something, that's three ports and vbridge1. I'm not seeing the 4th port or vbridge0 yet. … 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). Okay. Aside: Do you need the second ovs-vsctl? I thought you could run all of that as one command with the double dash separating commands to ovs-vsctl. (Maybe that's what you're doing and it didn't translate well to email.) 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 bridges?? I'm still not seeing vbirdge0 connected to anything other than the output of the IPS VM. I don't feel like we've gone quite as far as Inception. Maybe we need to give the switch stack a kick. ;-) 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) Okay. 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. Is this where vbridge0 comes into play? If vbridge0 is just to connect eth0 to the VyOS guest VM, i.e. the following ASCII diagram, this is where I'm suggesting foregoing the bridge. [eth0]---[vbridge0]---[VyOS] I'd be inclined to remove the bridge and just do this directly: [eth0]---[VyOS] Why does [vbridge0] need to be there? Is it doing anything other than enabling what is effectively a point-to-point connection between eth0 and VyOS? Are you wanting to leverage other features of OVS, i.e. insturmentation, of the data flowing between eth0 and VyOS? 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 defa
Re: [ovs-discuss] OpenVswitch
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 " 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 i
