[ovirt-users] R: vlan-tagging on non-tagged network

--_000_06wqhiuiyku9vk7vukt2dtor1439845594308emailandroidcom_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sorry for jumping into the discussion, but I'm currently experiencing exac= tly the opposite behaviour. DHCP offer is reached until the host bridge interface, but it is not propa= gated to the vnet device. I'm using VLAN tagging. Packets incoming are correctly managed until vnet d= evice and seems to have impact only into DHCP packets. Static IP assigned to the vm =E5eave VM active and reachable. Just my cent to a topic that I suppose could be related to mine issue. Roberto -------- Messaggio originale -------- Da: Felix Pepinghege <pepinghege(a)ira.uka.deData: 17/08/2015 13:36 (GMT+01:00) A: Users(a)ovirt.org Oggetto: Re: [ovirt-users] vlan-tagging on non-tagged network Hi Ido, hi everybody, sorry that I kept you waiting for two months, I only just found the time to go back to this problem. You were completely right with your guess. The ethernet frames do appear on the vnet-interface, but not on the bridge. The dropped-counter seems to be independent from these losses, though. However, while this tells me *where* the problem is, I still don't know *what* the problem is. I've done some research, but couldn't find anything particularly helpful. An interesting point may be that this problem is mono-directional. That is, the bridge happily passes vlan-tagged frames from the ethernet device to the vnet, but not the other way around. Untagged ethernet frames make their way through the brigde, no matter where they come from. The vlan module is loaded, as to the versioning questions: # cat /etc/centos-release ; uname -s -v -r CentOS Linux release 7.1.1503 (Core) Linux 3.10.0-229.7.2.el7.x86_64 #1 SMP Tue Jun 23 22:06:11 UTC 2015 The guest OS is an up-to-date Debian Jessie, which should not matter, though, as the frames get lost on the doorstep of the bridge on the host. Again, any suggestions are much appreciated! Regards, Felix Am 16.06.2015 um 08:27 schrieb Ido Barkan: ge on the tap device? est's MAC g he bridge. people e by running: t. _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users ________________________________ Questo messaggio e' indirizzato esclusivamente al destinatario indicato e p= otrebbe contenere informazioni confidenziali, riservate o proprietarie. Qua= lora la presente venisse ricevuta per errore, si prega di segnalarlo immedi= atamente al mittente, cancellando l'originale e ogni sua copia e distruggen= do eventuali copie cartacee. Ogni altro uso e' strettamente proibito e potr= ebbe essere fonte di violazione di legge. This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise private information. If you have received it i= n error, please notify the sender immediately, deleting the original and al= l copies and destroying any hard copies. Any other use is strictly prohibit= ed and may be unlawful. --_000_06wqhiuiyku9vk7vukt2dtor1439845594308emailandroidcom_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable <html<head<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 2"<meta name=3D"Generator" content=3D"Microsoft Exchange Server"<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; pad= ding-left: 4pt; border-left: #800000 2px solid; } --></style</head<bodySorry for jumping into the discussion, &nbsp;but I'm currently experiencing= exactly the opposite behaviour. <div>DHCP offer is reached &nbsp;until the host bridge interface, but it is= not propagated to the vnet device.</div<div>I'm using VLAN tagging. Packets incoming are correctly managed until v= net device and seems to have impact only into DHCP packets.</div<div><br</div<div>Static IP assigned to the vm =E5eave VM active and reachable.</div<div><br</div<div>Just my cent to a topic that I suppose could be related to mine issue.= </div<div><br</div<div>Roberto</div<br<br-------- Messaggio originale --------<brDa: Felix Pepinghege &amp;lt;pepinghege(a)ira.uka.de&amp;gt; <brData: 17/08/2015 13:36 (GMT&#43;01:00) <brA: Users(a)ovirt.org <brOggetto: Re: [ovirt-users] vlan-tagging on non-tagged network <br<br<font size=3D"2"<div class=3D"PlainText">Hi Ido, hi everybody,<br<brsorry that I kept you waiting for two months, I only just found the time <b= rto go back to this problem.<br<brYou were completely right with your guess. The ethernet frames do appear <b= ron the vnet-interface, but not on the bridge. The dropped-counter seems <br= to be independent from these losses, though.<br<brHowever, while this tells me *where* the problem is, I still don't know <br= *what* the problem is. I've done some research, but couldn't find <branything particularly helpful.<brAn interesting point may be that this problem is mono-directional. That <br= is, the bridge happily passes vlan-tagged frames from the ethernet <brdevice to the vnet, but not the other way around. Untagged ethernet <brframes make their way through the brigde, no matter where they come from.<b= r<brThe vlan module is loaded, as to the versioning questions:<br# cat /etc/centos-release ; uname -s -v -r<brCentOS Linux release 7.1.1503 (Core)<brLinux 3.10.0-229.7.2.el7.x86_64 #1 SMP Tue Jun 23 22:06:11 UTC 2015<br<brThe guest OS is an up-to-date Debian Jessie, which should not matter, <brthough, as the frames get lost on the doorstep of the bridge on the host.<b= r<brAgain, any suggestions are much appreciated!<br<brRegards,<brFelix<br<br<brAm 16.06.2015 um 08:27 schrieb Ido Barkan:<br&gt; Hey Felix.<br&gt;<br&gt; IIUC your frames are dropped by the bridge. Ovirt uses Linux Bridges<b= r&gt; To connect virtual machines to 'networks'. The guest connects to the b= ridge<br&gt; using a tap device which usually is called 'vnet&lt;number&gt;'.<br&gt;<br&gt; So, just to verify, can you please tcpdump both on the bridge device a= nd on the tap device?<br&gt; The bridge can be quite noisy so I suggest filtering traffic using the= guest's MAC<br&gt; address. So I am not sure what protocol you use for tunneling but appl= ying<br&gt; a filter similar to this one should do the job:<br&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tcpdump -n= -i vnet0 -vvv -s 1500 'udp[38:4]=3D0x001a4aaeec8e'<br&gt;<br&gt; My guess is that you will observe traffic on the tap device, but not o= n the bridge.<br&gt; You didn't specify which centOS version you use but I do remember seei= ng people<br&gt; complaining about Linux bridges discarding their tagged frames.<br&gt; You can -maybe- also observe the 'dropped' counter increases on the br= idge by running:<br&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'ip -s lin= k show dev trunk'<br&gt;<br&gt; There were a few bugs on rhel6/7 about this, specifically I remember<b= r&gt; <a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1174291"&... s://bugzilla.redhat.com/show_bug.cgi?id=3D1174291</a><br&gt; and<br&gt; <a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1200275#c20&qu... https://bugzilla.redhat.com/show_bug.cgi?id=3D1200275#c20</a><br&gt;<br&gt; Also, is the vlan module loaded on your host?<br&gt; 'lsmod |grep 8021q'<br&gt;<br&gt; Thanks,<br&gt; Ido<br&gt;<br&gt; ----- Original Message -----<br&gt; From: &quot;Felix Pepinghege&quot; &amp;lt;pepinghege(a)ira.uka.de&amp;gt;&lt;br&gt; To: Users(a)ovirt.org&lt;br&gt; Sent: Monday, June 15, 2015 11:33:39 AM<br&gt; Subject: [ovirt-users] vlan-tagging on non-tagged network<br&gt;<br&gt; Hi everybody!<br&gt;<br&gt; I am experiencing a behaviour of ovirt, of which I don't know whether = it<br&gt; is expected or not. My setup is as follows:<br&gt; A virtual machine has a logical network attached to it, which is<br&gt; configured without vlan-tagging and listens to the name 'trunk'.<br&gt; The VM is running an openvpn server. It is a patched openvpn version,<= br&gt; including vlan-tagging. That is, openvpn clients get a vlan tag. This<= br&gt; should not really be an issue but should satisfy the &quot;why do you = want to<br&gt; do it in the first place&quot;-questions.<br&gt; Anyhow, effectively, the VM simply puts vlan-tagged ethernet-frames on= <br&gt; the virtual network. These frames, however, never make it to the host'= s<br&gt; network bridge, which represents the logical network.<br&gt; My observations are: According to tcpdump, the vlan-tagged packages<br= &gt; arrive at the &quot;eth1&quot;-interface inside the VM (which *is* the= correct<br&gt; interface). Again, according to tcpdump, these packages never arrive a= t<br&gt; the corresponding network-bridge (i.e., the interface 'trunk') on the = host.<br&gt; I know that the setup itself is feasible with KVM---I have it working = on<br&gt; a proxmox-machine. Therefore, my conclusion is, that ovirt doesn't lik= e<br&gt; vlan-tagged ethernet-frames on non-tagged logical networks, and someho= w<br&gt; filters them out, though I don't really see on what &quot;level&quot; = that would<br&gt; happen (Handling the ethernet frames should be a concern of<br&gt; KVM/QEMU/Linux only, once ovirt has started the VM).<br&gt; So this problem could be a CentOS issue, but I really don't see why<br= &gt; CentOS should act differently than debian does (proxmox is debian-base= d).<br&gt; Is this a known/wanted/expected behaviour of ovirt, and can I somehow<= br&gt; prevent or elude it?<br&gt;<br&gt; Any help is much appreciated! Of course I am happy to provide more<br&gt; information if that helps helping me :)<br&gt;<br&gt; Regards,<br&gt; Felix<br&gt; _______________________________________________<br&gt; Users mailing list<br&gt; Users(a)ovirt.org&lt;br&gt; <a href=3D"http://lists.ovirt.org/mailman/listinfo/users">http:... .ovirt.org/mailman/listinfo/users</a><br&gt;<br<br_______________________________________________<brUsers mailing list<brUsers(a)ovirt.org&lt;br<a href=3D"http://lists.ovirt.org/mailman/listinfo/users">http:... t.org/mailman/listinfo/users</a><br</div</font><br<hr<font face=3D"Courier New" color=3D"Black" size=3D"2">Questo messaggio e' i= ndirizzato esclusivamente al destinatario indicato e potrebbe contenere inf= ormazioni confidenziali, riservate o proprietarie. Qualora la presente veni= sse ricevuta per errore, si prega di segnalarlo immediatamente al mittente, cancellando l'originale e ogni sua copia e dis= truggendo eventuali copie cartacee. Ogni altro uso e' strettamente proibito= e potrebbe essere fonte di violazione di legge.<br<brThis message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise private information. If you have received it i= n error, please notify the sender immediately, deleting the original and al= l copies and destroying any hard copies. Any other use is strictly prohibited and may be unlawful.<br</font</body</html --_000_06wqhiuiyku9vk7vukt2dtor1439845594308emailandroidcom_--