Scott, Grant. Sincerely, thanks for all your guidance.
I'm more of an network engineering guy with an inquisitive character and a
love for FOSS.
This one .. I have to tell you both has me stumped. Actually it's working.
Here's a couple of reasons why I'm stumped.
Kindly follow along.
OVS setup is minimal:
sudo ovs-vsctl add-br vbridge0
ovs-vsctl add-bond vbridge0 vbond0 eth0 eth1 lacp=active
other_config:lacp_time=fast
## I omitted the trunks=2,3 Scott your explanation made me feel it's
synonymous with (switchport trunk allowed vlan 2,3) -- Unnecessary for my
usage here.
>From my VM Host:
foobar@VMHOST:~$ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
post-up modprobe 8021q <<<< This is the fix BTW for whatever
reason >>>>
===================================================================================================
If you want to put your LibVirt Guest VM on an OVS interface similiar to
plugging into an edge port on a cisco switch in vlan 2 (switchport mode
access [Enter] switchport access vlan 2 [Enter] )
You really must have to make the kernel pre load the 8021q module
beforehand, otherwise the OVS I'm guessing doesn't have the tools to handle
the job? (It's only a swag...I'm probably wrong. don't shoot ;D )
I can reproduce libvirt guest working on my setup again and again reboot
after reboot by only doing one thing to fix it. ( modprobe 8021q)
Just fyi on the software particulars of my platform just in case there's
questions:
foobar@VMHOST:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
foobar@VMHOST:~$ uname -a
Linux VMHOST 4.13.0-36-generic #40~16.04.1-Ubuntu SMP Fri Feb 16 23:25:58
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Could it be because of systemd related issues???
Anyways..... back to the head scratching
=====================================================================================================
#bond port info
auto eth1
iface eth1 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
pre-down ifconfig $IFACE down
#Bond port info
auto eth2
iface eth2 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
pre-down ifconfig $IFACE down
===========================================================================
Showing the OPENVSWITCH Prior to starting VM.
foobar@VMHOST:~$ sudo ovs-vsctl show
[sudo] password for foobar:
126a4b57-4837-42a9-95d6-d818b35e95bd
Bridge "vbridge0"
Port "vbridge0"
Interface "vbridge0"
type: internal
Port "vbond0"
Interface "eth2"
Interface "eth1"
ovs_version: "2.5.2"
=================================================================================================================
Now let's look at the vbridge0:
foobar@VMHOST:~$ sudo ovs-vsctl list interface vbridge0
_uuid : 714594e9-101b-4854-a474-bf6125244df2
admin_state : down <<< According to OVS.. this bridge is down
--- I can tell you that the vbond0 is up however... Is it germain to the
situation? IDK?
bfd : {}
bfd_status : {}
cfm_fault : []
cfm_fault_status : []
cfm_flap_count : []
cfm_health : []
cfm_mpid : []
cfm_remote_mpids : []
cfm_remote_opstate : []
duplex : []
error : []
external_ids : {}
ifindex : 6
ingress_policing_burst: 0
ingress_policing_rate: 0
lacp_current : []
link_resets : 0
link_speed : []
link_state : down
lldp : {}
mac : []
mac_in_use : "00:04:23:d7:bd:0c"
mtu : 1500
name : "vbridge0"
ofport : 65534
ofport_request : []
options : {}
other_config : {}
statistics : {collisions=0, rx_bytes=0, rx_crc_err=0,
rx_dropped=229, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0,
tx_bytes=0, tx_dropped=0, tx_errors=0, tx_packets=0}
status : {driver_name=openvswitch}
type : internal
========================================================================================================================
Let's kick on the VM for giggles:
foobar@VMHOST:~$ virsh start ubuntu14.04
Domain ubuntu14.04 started
And now:
foobar@VMHOST:~$ sudo ovs-vsctl show
126a4b57-4837-42a9-95d6-d818b35e95bd
Bridge "vbridge0"
Port "vbridge0"
Interface "vbridge0"
type: internal
Port "vbond0"
Interface "eth2"
Interface "eth1"
Port "vnet0"
tag: 2
Interface "vnet0" <<< There's our libvirt guest
ovs_version: "2.5.2"
=========================================================================================================================
Checking vbridge0 again...
foobar@VMHOST:~$ sudo ovs-vsctl list interface vbridge0
_uuid : 714594e9-101b-4854-a474-bf6125244df2
admin_state : down <<< YEP we're still down!! But wait lets try and
ping the Guest VM......
bfd : {}
bfd_status : {}
cfm_fault : []
cfm_fault_status : []
cfm_flap_count : []
cfm_health : []
cfm_mpid : []
cfm_remote_mpids : []
cfm_remote_opstate : []
duplex : []
error : []
external_ids : {}
ifindex : 6
ingress_policing_burst: 0
ingress_policing_rate: 0
lacp_current : []
link_resets : 0
link_speed : []
link_state : down
lldp : {}
mac : []
mac_in_use : "00:04:23:d7:bd:0c"
mtu : 1500
name : "vbridge0"
ofport : 65534
ofport_request : []
options : {}
other_config : {}
statistics : {collisions=0, rx_bytes=0, rx_crc_err=0,
rx_dropped=407, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0,
tx_bytes=0, tx_dropped=0, tx_errors=0, tx_packets=0}
status : {driver_name=openvswitch}
type : internal
=========================================================================================================================
foobar@VMHOST:~$ ping xx.xx.xx.160
PING xx.xx.xx.160 (xx.xx.xx.160) 56(84) bytes of data.
64 bytes from xx.xx.xx.160: icmp_seq=1 ttl=64 time=0.978 ms
64 bytes from xx.xx.xx.160: icmp_seq=2 ttl=64 time=0.372 ms
WHAATT?? I thought my OVS bridge vbridge0 was down? Evidently not?
foobar@VMHOST:~$ ssh foo...@xx.xx.xx.160
<< First time SSH login of my guest.
The authenticity of host 'xx.xx.xx.160 (xx.xx.xx.160)' can't be established.
ECDSA key fingerprint is
SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'xx.xx.xx.160' (ECDSA) to the list of known
hosts.
foo...@xx.xx.xx.160's password:
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 4.4.0-98-generic i686)
* Documentation: https://help.ubuntu.com/
System information as of Thu Mar 1 22:11:52 EST 2018
System load: 0.56 Memory usage: 4% Processes: 111
Usage of /: 13.4% of 8.16GB Swap usage: 0% Users logged in: 0
Graph this data and manage this system at:
https://landscape.canonical.com/
New release '16.04.3 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
Last login: Thu Mar 1 21:59:58 2018 from xx.xx.xx.152
foobar@1404Base:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 52:54:00:71:b1:b6
<<< KVM based MAC address.
inet addr:xx.xx.xx.160 Bcast:xx.xx.xx.255 Mask:255.255.255.0
inet6 addr: fe80::5054:ff:fe71:b1b6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:354 errors:0 dropped:0 overruns:0 frame:0
TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:53305 (53.3 KB) TX bytes:8199 (8.1 KB)
Being picky...
I was hoping to tune my bridge to use a 1520 byte global MTU for some
specific reasons but when I checked the bridge it said 1500 via the (sudo
ovs-vsctl list interface vbridge0) command but it also shows "down" sooo....
A quick adjustment on my eth0 interface of my guest VM to set MTU to 1520
and then a quick:
foobar@1404Base:~$ tracepath -n 8.8.8.8 <<<when
I had the MTU set at 1500 on the guest eth0 the tracepath worked normally.
1?: [LOCALHOST] pmtu 1520
1: no reply
2: no reply
3: no reply
This confirms (unless I've totally missed the mark) that my OVS bridge is
only set to run at 1500.
I know the vbond0 port by default will run at the smallest mtu of all the
bonded interfaces included in the bond.
In my above interfaces file you'll see I have those ports set to 1520 for
MTU. I also have the system MTU in the cisco switch set to 1520
I confirmed everything in the bond is running at 1520 MTU
So that leaves the OVS bridge. How can I make the bridge adjust MTU size
with an ovs-vsctl command?
I have searched around and cant find syntax to set this.
Finally I had set my lacp to "fast" with my ovs-vsctl command
when running show etherchannel 1 detail..
The Cisco switch says it's negotiating in SA mode. (Slow Active).... So
there's that too... Hmmmmmm.....
Those are my final ramblings on this subject. Thanks all for letting me
burn some of your time.
Chris
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
