Discussion:
Problem with syslog in bridge(?) with ethernet broadcast packets with QinQ
(too old to reply)
Andrés Pozo Muñoz
2017-09-18 15:21:11 UTC
Permalink
Hi all,

I'm facing some problem with ethernet multicast traffic and QinQ
(802.3q in both tags) in -apparently- a bridge in Ubuntu 16.04
(4.12.0-041200-generic).

My set up is the following:
+-----------+
| VM |
+-----+-----+
|
| tag 55
+---------+------------+
| OVS |
+-----------+----------+
| veth3.9
veth3 + |
+--+
| veth2
+-------+----------+
| BRIDGE |
+-------+----------+
|
|
+-------+----------+
| ens11f1 |
+------------------+


I am setting the inner tag with OVS and the outer tag with a vlan type veth.
The problem I have is that every packet sent from the VM to Ethernet
broadcast addresses (33:33:xx:xx:xx:xx) generates a "IPv6 header not
found" entry in syslog.

If I generate a 'ens11f1.9' interface and remove the BRIDGE, the log
entry dissapears.

Some questions:
* Is there any problem with these packets (ethernet multicast with
QinQ) in bridges?
* Is there any configuration I should change for the problem to dissapear?

Thanks in advance for your help! Any hint about what could be
generating those logs is appreciated.

Regards,
Andrés Pozo
Stephen Hemminger
2017-10-12 14:58:34 UTC
Permalink
On Mon, 18 Sep 2017 17:21:11 +0200
Post by Andrés Pozo Muñoz
Hi all,
I'm facing some problem with ethernet multicast traffic and QinQ
(802.3q in both tags) in -apparently- a bridge in Ubuntu 16.04
(4.12.0-041200-generic).
+-----------+
| VM |
+-----+-----+
|
| tag 55
+---------+------------+
| OVS |
+-----------+----------+
| veth3.9
veth3 + |
+--+
| veth2
+-------+----------+
| BRIDGE |
+-------+----------+
|
|
+-------+----------+
| ens11f1 |
+------------------+
I am setting the inner tag with OVS and the outer tag with a vlan type veth.
The problem I have is that every packet sent from the VM to Ethernet
broadcast addresses (33:33:xx:xx:xx:xx) generates a "IPv6 header not
found" entry in syslog.
If I generate a 'ens11f1.9' interface and remove the BRIDGE, the log
entry dissapears.
* Is there any problem with these packets (ethernet multicast with
QinQ) in bridges?
* Is there any configuration I should change for the problem to dissapear?
Thanks in advance for your help! Any hint about what could be
generating those logs is appreciated.
Regards,
Andrés Pozo
Where is the log message coming from? Could you change the printk into
a WARN_ON_ONCE and get backtrace? My guess is the firewall code doesn't
understand the additional tag.
Andrés Pozo Muñoz
2017-10-16 10:39:21 UTC
Permalink
Hi Stephen,

thanks for your response.

I managed to move forward removing the bridge from my schema. I think
the problem has to deal with multicast IPv6 addresses with QinQ in a
bridge.

If I remove that bridge and put the traffic through a vlan type
subinterface in the physical interface, everything seems to work fine
(and the syslog entry, no longer appears...).

I'll try to follow your suggestion and get that trace....

Thanks!
Regards,
Andres


On Thu, Oct 12, 2017 at 4:58 PM, Stephen Hemminger
Post by Stephen Hemminger
On Mon, 18 Sep 2017 17:21:11 +0200
Post by Andrés Pozo Muñoz
Hi all,
I'm facing some problem with ethernet multicast traffic and QinQ
(802.3q in both tags) in -apparently- a bridge in Ubuntu 16.04
(4.12.0-041200-generic).
+-----------+
| VM |
+-----+-----+
|
| tag 55
+---------+------------+
| OVS |
+-----------+----------+
| veth3.9
veth3 + |
+--+
| veth2
+-------+----------+
| BRIDGE |
+-------+----------+
|
|
+-------+----------+
| ens11f1 |
+------------------+
I am setting the inner tag with OVS and the outer tag with a vlan type veth.
The problem I have is that every packet sent from the VM to Ethernet
broadcast addresses (33:33:xx:xx:xx:xx) generates a "IPv6 header not
found" entry in syslog.
If I generate a 'ens11f1.9' interface and remove the BRIDGE, the log
entry dissapears.
* Is there any problem with these packets (ethernet multicast with
QinQ) in bridges?
* Is there any configuration I should change for the problem to dissapear?
Thanks in advance for your help! Any hint about what could be
generating those logs is appreciated.
Regards,
Andrés Pozo
Where is the log message coming from? Could you change the printk into
a WARN_ON_ONCE and get backtrace? My guess is the firewall code doesn't
understand the additional tag.
Continue reading on narkive:
Loading...