Re: kernel 4.2 : "bridge vlan" command return empty result (works with kernel 4.1.3)
>>he problem went away on my box with the following patch. I >>will submit an official patch in a bit. Hi, I confirm that your patch fix the problem for me too. Regards, Alexandre - Mail original - De: "roopa" À: "aderumier" Cc: "netdev" , "Scott Feldman" Envoyé: Mardi 15 Septembre 2015 21:02:34 Objet: Re: kernel 4.2 : "bridge vlan" command return empty result (works with kernel 4.1.3) On 9/15/15, 10:39 AM, Alexandre DERUMIER wrote: > Hi, > > since kernel 4.2, "bridge vlan" command return empty result. > > > kernel 4.1.3 > > # bridge vlan > port vlan ids > eth0 1 PVID Egress Untagged > 90 > 91 > 92 > 93 > 94 > 95 > 96 > 97 > 98 > 99 > 100 > > vmbr0 1 PVID Egress Untagged > 94 > > > > kernel 4.2 > > # bridge vlan > port vlan ids > > > > Note that vlans are correctly working,it seem that is just the display. > > tcpdump -e -i vmbr0 > > 19:38:08.005055 00:08:7c:bd:ae:40 (oui Unknown) > 00:18:8b:7c:c8:37 (oui > Unknown), ethertype 802.1Q (0x8100), length 64: vlan 94, p 0, ethertype IPv4, > 172.20.0.17.52299 > kvmtest2.odiso.net.ssh: Flags [.], ack 339613, win 5523, > length 0 > 19:38:08.007730 00:08:7c:bd:ae:40 (oui Unknown) > 00:18:8b:7c:c8:37 (oui > Unknown), ethertype 802.1Q (0x8100), length 64: vlan 94, p 0, ethertype IPv4, > 172.20.0.17.52299 > kvmtest2.odiso.net.ssh: Flags [.], ack 342145, win 5568, > length 0 > 19:38:08.010977 00:08:7c:bd:ae:40 (oui Unknown) > 00:18:8b:7c:c8:37 (oui > Unknown), ethertype 802.1Q (0x8100), length 64: vlan 94, p 0, ethertype IPv4, > 172.20.0.17.52299 > kvmtest2.odiso.net.ssh: Flags [.], ack 344677, win 5614, > length 0 > 19:3 I was able to reproduce this when there is a bond in the system. Looks like this was due to 85fdb956726ff2a ("switchdev: cut over to new switchdev_port_bridge_getlink"). When CONFIG_SWITCHDEV is off, nodes that use switchdev api for ndo_bridge_getlink (example, bonds, teams, rocker) can return -EOPNOTSUPP. The problem went away on my box with the following patch. I will submit an official patch in a bit. Do you have a bond in your system ?. diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c index 01ced4a..bdb3842 100644 --- a/net/core/rtnetlink.c +++ b/net/core/rtnetlink.c @@ -3013,6 +3013,7 @@ static int rtnl_bridge_getlink(struct sk_buff *skb, struct u32 portid = NETLINK_CB(cb->skb).portid; u32 seq = cb->nlh->nlmsg_seq; u32 filter_mask = 0; + int err; if (nlmsg_len(cb->nlh) > sizeof(struct ifinfomsg)) { struct nlattr *extfilt; @@ -3033,20 +3034,25 @@ static int rtnl_bridge_getlink(struct sk_buff *skb, stru struct net_device *br_dev = netdev_master_upper_dev_get(dev); if (br_dev && br_dev->netdev_ops->ndo_bridge_getlink) { - if (idx >= cb->args[0] && - br_dev->netdev_ops->ndo_bridge_getlink( - skb, portid, seq, dev, filter_mask, - NLM_F_MULTI) < 0) - break; + if (idx >= cb->args[0]) { + err = br_dev->netdev_ops->ndo_bridge_getlink( + skb, portid, seq, dev, + filter_mask, NLM_F_MULTI); + if ( err < 0 && err != -EOPNOTSUPP) + break; + } idx++; } if (ops->ndo_bridge_getlink) { - if (idx >= cb->args[0] && - ops->ndo_bridge_getlink(skb, portid, seq, dev, - filter_mask, - NLM_F_MULTI) < 0) - break; + if (idx >= cb->args[0]) { + err = ops->ndo_bridge_getlink(skb, portid, + seq, dev, + filter_mask, + NLM_F_MULTI); + if ( err < 0 && err != -EOPNOTSUPP) + break; + } idx++; } } -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel 4.2 : "bridge vlan" command return empty result (works with kernel 4.1.3)
>>Do you have a bond in your system ?. Yes, Indeed. Removing the bond fix the problem. I'll try your patch today. Thanks ! Alexandre - Mail original - De: "roopa" À: "aderumier" Cc: "netdev" , "Scott Feldman" Envoyé: Mardi 15 Septembre 2015 21:02:34 Objet: Re: kernel 4.2 : "bridge vlan" command return empty result (works with kernel 4.1.3) On 9/15/15, 10:39 AM, Alexandre DERUMIER wrote: > Hi, > > since kernel 4.2, "bridge vlan" command return empty result. > > > kernel 4.1.3 > > # bridge vlan > port vlan ids > eth0 1 PVID Egress Untagged > 90 > 91 > 92 > 93 > 94 > 95 > 96 > 97 > 98 > 99 > 100 > > vmbr0 1 PVID Egress Untagged > 94 > > > > kernel 4.2 > > # bridge vlan > port vlan ids > > > > Note that vlans are correctly working,it seem that is just the display. > > tcpdump -e -i vmbr0 > > 19:38:08.005055 00:08:7c:bd:ae:40 (oui Unknown) > 00:18:8b:7c:c8:37 (oui > Unknown), ethertype 802.1Q (0x8100), length 64: vlan 94, p 0, ethertype IPv4, > 172.20.0.17.52299 > kvmtest2.odiso.net.ssh: Flags [.], ack 339613, win 5523, > length 0 > 19:38:08.007730 00:08:7c:bd:ae:40 (oui Unknown) > 00:18:8b:7c:c8:37 (oui > Unknown), ethertype 802.1Q (0x8100), length 64: vlan 94, p 0, ethertype IPv4, > 172.20.0.17.52299 > kvmtest2.odiso.net.ssh: Flags [.], ack 342145, win 5568, > length 0 > 19:38:08.010977 00:08:7c:bd:ae:40 (oui Unknown) > 00:18:8b:7c:c8:37 (oui > Unknown), ethertype 802.1Q (0x8100), length 64: vlan 94, p 0, ethertype IPv4, > 172.20.0.17.52299 > kvmtest2.odiso.net.ssh: Flags [.], ack 344677, win 5614, > length 0 > 19:3 I was able to reproduce this when there is a bond in the system. Looks like this was due to 85fdb956726ff2a ("switchdev: cut over to new switchdev_port_bridge_getlink"). When CONFIG_SWITCHDEV is off, nodes that use switchdev api for ndo_bridge_getlink (example, bonds, teams, rocker) can return -EOPNOTSUPP. The problem went away on my box with the following patch. I will submit an official patch in a bit. Do you have a bond in your system ?. diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c index 01ced4a..bdb3842 100644 --- a/net/core/rtnetlink.c +++ b/net/core/rtnetlink.c @@ -3013,6 +3013,7 @@ static int rtnl_bridge_getlink(struct sk_buff *skb, struct u32 portid = NETLINK_CB(cb->skb).portid; u32 seq = cb->nlh->nlmsg_seq; u32 filter_mask = 0; + int err; if (nlmsg_len(cb->nlh) > sizeof(struct ifinfomsg)) { struct nlattr *extfilt; @@ -3033,20 +3034,25 @@ static int rtnl_bridge_getlink(struct sk_buff *skb, stru struct net_device *br_dev = netdev_master_upper_dev_get(dev); if (br_dev && br_dev->netdev_ops->ndo_bridge_getlink) { - if (idx >= cb->args[0] && - br_dev->netdev_ops->ndo_bridge_getlink( - skb, portid, seq, dev, filter_mask, - NLM_F_MULTI) < 0) - break; + if (idx >= cb->args[0]) { + err = br_dev->netdev_ops->ndo_bridge_getlink( + skb, portid, seq, dev, + filter_mask, NLM_F_MULTI); + if ( err < 0 && err != -EOPNOTSUPP) + break; + } idx++; } if (ops->ndo_bridge_getlink) { - if (idx >= cb->args[0] && - ops->ndo_bridge_getlink(skb, portid, seq, dev, - filter_mask, - NLM_F_MULTI) < 0) - break; + if (idx >= cb->args[0]) { + err = ops->ndo_bridge_getlink(skb, portid, + seq, dev, + filter_mask, + NLM_F_MULTI); + if ( err < 0 && err != -EOPNOTSUPP) + break; + } idx++; } } -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
kernel 4.2 : "bridge vlan" command return empty result (works with kernel 4.1.3)
Hi, since kernel 4.2, "bridge vlan" command return empty result. kernel 4.1.3 # bridge vlan portvlan ids eth0 1 PVID Egress Untagged 90 91 92 93 94 95 96 97 98 99 100 vmbr01 PVID Egress Untagged 94 kernel 4.2 # bridge vlan portvlan ids Note that vlans are correctly working,it seem that is just the display. tcpdump -e -i vmbr0 19:38:08.005055 00:08:7c:bd:ae:40 (oui Unknown) > 00:18:8b:7c:c8:37 (oui Unknown), ethertype 802.1Q (0x8100), length 64: vlan 94, p 0, ethertype IPv4, 172.20.0.17.52299 > kvmtest2.odiso.net.ssh: Flags [.], ack 339613, win 5523, length 0 19:38:08.007730 00:08:7c:bd:ae:40 (oui Unknown) > 00:18:8b:7c:c8:37 (oui Unknown), ethertype 802.1Q (0x8100), length 64: vlan 94, p 0, ethertype IPv4, 172.20.0.17.52299 > kvmtest2.odiso.net.ssh: Flags [.], ack 342145, win 5568, length 0 19:38:08.010977 00:08:7c:bd:ae:40 (oui Unknown) > 00:18:8b:7c:c8:37 (oui Unknown), ethertype 802.1Q (0x8100), length 64: vlan 94, p 0, ethertype IPv4, 172.20.0.17.52299 > kvmtest2.odiso.net.ssh: Flags [.], ack 344677, win 5614, length 0 19:3 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [pve-devel] bridge vlan range, kernel 4.1 : "message truncated" warning when too much vlans defined
Hi, This still not fixed in iproute 4.2. Is they any plan to increase the rtnl_dump_filter buffer size soon ? Regards, Alexandre Derumier - Mail original - De: "aderumier" À: "Arad, Ronen" Cc: "netdev" , "pve-devel" Envoyé: Jeudi 30 Juillet 2015 07:31:44 Objet: Re: [pve-devel] bridge vlan range, kernel 4.1 : "message truncated" warning when too much vlans defined Thanks Ronen, I have tested - char buf[16384]; + char buf[3*16384]; and It's working fine to handle 4096 vlans numbers. (The problem was really the number of vlans ids defined, could be 1 interface with 2-4095vlans, or 100 interfaces with same 2-4095vlans). With this buffer size it's working fine Thanks for the fast reply. Regards, Alexadre - Mail original - De: "Arad, Ronen" À: "aderumier" , "netdev" Cc: "pve-devel" Envoyé: Jeudi 30 Juillet 2015 04:03:06 Objet: RE: bridge vlan range, kernel 4.1 : "message truncated" warning when too much vlans defined The easiest fix is in iproute2. Increasing the buffer size used in rtnl_dump_filter_l 3x empirically resolves the issue. The root-cause is due to the buffer size calculation of dump request in the kernel. It is based on the total number of VLANs and does not account for compressed vlan requests. The flag argument is not propagated to get size functions. Fixing the size calculation in the kernel would work most of the time but would Fail when the number of ranges (and/or non-contiguous VLANs) exceeds ~1800. Therefore, fixing the size calculation in the kernel does not worth the Effort. Fixing iproute2 seems the easy way to overcome the issue. diff --git a/lib/libnetlink.c b/lib/libnetlink.c index 901236e..25c1c02 100644 --- a/lib/libnetlink.c +++ b/lib/libnetlink.c @@ -198,7 +198,7 @@ int rtnl_dump_filter_l(struct rtnl_handle *rth, .msg_iov = &iov, .msg_iovlen = 1, }; - char buf[16384]; + char buf[3*16384]; int dump_intr = 0; iov.iov_base = buf; Ronen >-Original Message- >From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On >Behalf Of Alexandre DERUMIER >Sent: Wednesday, July 29, 2015 11:25 AM >To: netdev >Cc: pve-devel >Subject: bridge vlan range, kernel 4.1 : "message truncated" warning when too >much vlans defined > >Hi, > >I'm currently testing vlan range on bridge filtering with kernel 4.1. > > >If I defined too much vlans, or too big vlan range, >I have a warning "message truncated", even if I'm using "-c" > > ># bridge -c vlan >Message truncated >port vlan ids >eth2 1 PVID Egress Untagged > >bond0 1 PVID Egress Untagged >2-1850 > >vmbr0 1 PVID Egress Untagged >94 > > >or ># bridge -c vlan >Message truncated >port vlan ids >eth2 1 PVID Egress Untagged >2-900 >bond0 1 PVID Egress Untagged >2-900 > >vmbr0 1 PVID Egress Untagged >94 > > > >Also, more important, this is also impact "ip", and truncate the output > >#ip link > >Message truncated >1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode >DEFAULT group default >link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >2: eth2: mtu 9000 qdisc pfifo_fast master >vmbr1 state DOWN mode DEFAULT group default qlen 1000 >link/ether 00:15:17:80:29:e6 brd ff:ff:ff:ff:ff:ff >3: eth3: mtu 1500 qdisc noop state DOWN mode DEFAULT >group default qlen 1000 >link/ether 00:15:17:80:29:e7 brd ff:ff:ff:ff:ff:ff >4: eth0: mtu 1500 qdisc mq master >bond0 state UP mode DEFAULT group default qlen 1000 >link/ether 00:1a:a0:3c:98:c5 brd ff:ff:ff:ff:ff:ff >5: eth5: mtu 9000 qdisc pfifo_fast master >ovs-system state UP mode DEFAULT group default qlen 1000 >link/ether 68:05:ca:09:c3:7c brd ff:ff:ff:ff:ff:ff >6: eth4: mtu 9000 qdisc pfifo_fast master >ovs-system state UP mode DEFAULT group default qlen 1000 >link/ether 68:05:ca:09:c3:7d brd ff:ff:ff:ff:ff:ff >7: eth1: mtu 1500 qdisc mq master >bond0 state UP mode DEFAULT group default qlen 1000 >link/ether 00:1a:a0:3c:98:c5 brd ff:ff:ff:ff:ff:ff >8: ovs-system@NONE: mtu 1500 qdisc noop state DOWN mode >DEFAULT group default >link/ether 7e:dd:5d:ea:ef:26 brd ff:ff:ff:ff:ff:ff >9: vmbr10@NONE: mtu 9000 qdisc noqueue state >UNKNOWN mode DEFAULT group default >link/ether 68:05:ca:09:c3:7d brd ff:ff:ff:ff:ff:ff >10: bond1@NONE: mtu 9000 qdisc noqueue state >UNKNOWN mode DEFAULT group default >link/ether 8a:c3:da:b0:9d:87 brd ff:ff:ff:ff:ff:ff >11: bond0@NONE: mtu 1500 qdisc >noqueue master vmbr0 state UP mode DEFAULT group default >link/ether 00:1a:a0:3c:98:c5 brd ff:ff:ff:ff:ff:ff >12: vmbr0@NONE: mtu 150
Re: bridge vlan range, kernel 4.1 : "message truncated" warning when too much vlans defined
Thanks Ronen, I have tested - char buf[16384]; + char buf[3*16384]; and It's working fine to handle 4096 vlans numbers. (The problem was really the number of vlans ids defined, could be 1 interface with 2-4095vlans, or 100 interfaces with same 2-4095vlans). With this buffer size it's working fine Thanks for the fast reply. Regards, Alexadre - Mail original - De: "Arad, Ronen" À: "aderumier" , "netdev" Cc: "pve-devel" Envoyé: Jeudi 30 Juillet 2015 04:03:06 Objet: RE: bridge vlan range, kernel 4.1 : "message truncated" warning when too much vlans defined The easiest fix is in iproute2. Increasing the buffer size used in rtnl_dump_filter_l 3x empirically resolves the issue. The root-cause is due to the buffer size calculation of dump request in the kernel. It is based on the total number of VLANs and does not account for compressed vlan requests. The flag argument is not propagated to get size functions. Fixing the size calculation in the kernel would work most of the time but would Fail when the number of ranges (and/or non-contiguous VLANs) exceeds ~1800. Therefore, fixing the size calculation in the kernel does not worth the Effort. Fixing iproute2 seems the easy way to overcome the issue. diff --git a/lib/libnetlink.c b/lib/libnetlink.c index 901236e..25c1c02 100644 --- a/lib/libnetlink.c +++ b/lib/libnetlink.c @@ -198,7 +198,7 @@ int rtnl_dump_filter_l(struct rtnl_handle *rth, .msg_iov = &iov, .msg_iovlen = 1, }; - char buf[16384]; + char buf[3*16384]; int dump_intr = 0; iov.iov_base = buf; Ronen >-Original Message- >From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On >Behalf Of Alexandre DERUMIER >Sent: Wednesday, July 29, 2015 11:25 AM >To: netdev >Cc: pve-devel >Subject: bridge vlan range, kernel 4.1 : "message truncated" warning when too >much vlans defined > >Hi, > >I'm currently testing vlan range on bridge filtering with kernel 4.1. > > >If I defined too much vlans, or too big vlan range, >I have a warning "message truncated", even if I'm using "-c" > > ># bridge -c vlan >Message truncated >port vlan ids >eth2 1 PVID Egress Untagged > >bond0 1 PVID Egress Untagged >2-1850 > >vmbr0 1 PVID Egress Untagged >94 > > >or ># bridge -c vlan >Message truncated >port vlan ids >eth2 1 PVID Egress Untagged >2-900 >bond0 1 PVID Egress Untagged >2-900 > >vmbr0 1 PVID Egress Untagged >94 > > > >Also, more important, this is also impact "ip", and truncate the output > >#ip link > >Message truncated >1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode >DEFAULT group default >link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >2: eth2: mtu 9000 qdisc pfifo_fast master >vmbr1 state DOWN mode DEFAULT group default qlen 1000 >link/ether 00:15:17:80:29:e6 brd ff:ff:ff:ff:ff:ff >3: eth3: mtu 1500 qdisc noop state DOWN mode DEFAULT >group default qlen 1000 >link/ether 00:15:17:80:29:e7 brd ff:ff:ff:ff:ff:ff >4: eth0: mtu 1500 qdisc mq master >bond0 state UP mode DEFAULT group default qlen 1000 >link/ether 00:1a:a0:3c:98:c5 brd ff:ff:ff:ff:ff:ff >5: eth5: mtu 9000 qdisc pfifo_fast master >ovs-system state UP mode DEFAULT group default qlen 1000 >link/ether 68:05:ca:09:c3:7c brd ff:ff:ff:ff:ff:ff >6: eth4: mtu 9000 qdisc pfifo_fast master >ovs-system state UP mode DEFAULT group default qlen 1000 >link/ether 68:05:ca:09:c3:7d brd ff:ff:ff:ff:ff:ff >7: eth1: mtu 1500 qdisc mq master >bond0 state UP mode DEFAULT group default qlen 1000 >link/ether 00:1a:a0:3c:98:c5 brd ff:ff:ff:ff:ff:ff >8: ovs-system@NONE: mtu 1500 qdisc noop state DOWN mode >DEFAULT group default >link/ether 7e:dd:5d:ea:ef:26 brd ff:ff:ff:ff:ff:ff >9: vmbr10@NONE: mtu 9000 qdisc noqueue state >UNKNOWN mode DEFAULT group default >link/ether 68:05:ca:09:c3:7d brd ff:ff:ff:ff:ff:ff >10: bond1@NONE: mtu 9000 qdisc noqueue state >UNKNOWN mode DEFAULT group default >link/ether 8a:c3:da:b0:9d:87 brd ff:ff:ff:ff:ff:ff >11: bond0@NONE: mtu 1500 qdisc >noqueue master vmbr0 state UP mode DEFAULT group default >link/ether 00:1a:a0:3c:98:c5 brd ff:ff:ff:ff:ff:ff >12: vmbr0@NONE: mtu 1500 qdisc noqueue state >UP mode DEFAULT group default >link/ether 00:1a:a0:3c:98:c5 brd ff:ff:ff:ff:ff:ff >13: vmbr0.94@vmbr0: mtu 1500 qdisc noqueue >state UP mode DEFAULT group default >link/ether 00:1a:a0:3c:98:c5 brd ff:ff:ff:ff:ff:ff > >>should have more interfaces here > > >Is it a known bug ? > > > >Regards, > >Alexandre Derumier > >-- >To unsubscribe from this list: send the line "unsubscribe netdev" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
bridge vlan range, kernel 4.1 : "message truncated" warning when too much vlans defined
Hi, I'm currently testing vlan range on bridge filtering with kernel 4.1. If I defined too much vlans, or too big vlan range, I have a warning "message truncated", even if I'm using "-c" # bridge -c vlan Message truncated port vlan ids eth2 1 PVID Egress Untagged bond0 1 PVID Egress Untagged 2-1850 vmbr0 1 PVID Egress Untagged 94 or # bridge -c vlan Message truncated port vlan ids eth2 1 PVID Egress Untagged 2-900 bond0 1 PVID Egress Untagged 2-900 vmbr0 1 PVID Egress Untagged 94 Also, more important, this is also impact "ip", and truncate the output #ip link Message truncated 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth2: mtu 9000 qdisc pfifo_fast master vmbr1 state DOWN mode DEFAULT group default qlen 1000 link/ether 00:15:17:80:29:e6 brd ff:ff:ff:ff:ff:ff 3: eth3: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:15:17:80:29:e7 brd ff:ff:ff:ff:ff:ff 4: eth0: mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000 link/ether 00:1a:a0:3c:98:c5 brd ff:ff:ff:ff:ff:ff 5: eth5: mtu 9000 qdisc pfifo_fast master ovs-system state UP mode DEFAULT group default qlen 1000 link/ether 68:05:ca:09:c3:7c brd ff:ff:ff:ff:ff:ff 6: eth4: mtu 9000 qdisc pfifo_fast master ovs-system state UP mode DEFAULT group default qlen 1000 link/ether 68:05:ca:09:c3:7d brd ff:ff:ff:ff:ff:ff 7: eth1: mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000 link/ether 00:1a:a0:3c:98:c5 brd ff:ff:ff:ff:ff:ff 8: ovs-system@NONE: mtu 1500 qdisc noop state DOWN mode DEFAULT group default link/ether 7e:dd:5d:ea:ef:26 brd ff:ff:ff:ff:ff:ff 9: vmbr10@NONE: mtu 9000 qdisc noqueue state UNKNOWN mode DEFAULT group default link/ether 68:05:ca:09:c3:7d brd ff:ff:ff:ff:ff:ff 10: bond1@NONE: mtu 9000 qdisc noqueue state UNKNOWN mode DEFAULT group default link/ether 8a:c3:da:b0:9d:87 brd ff:ff:ff:ff:ff:ff 11: bond0@NONE: mtu 1500 qdisc noqueue master vmbr0 state UP mode DEFAULT group default link/ether 00:1a:a0:3c:98:c5 brd ff:ff:ff:ff:ff:ff 12: vmbr0@NONE: mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether 00:1a:a0:3c:98:c5 brd ff:ff:ff:ff:ff:ff 13: vmbr0.94@vmbr0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether 00:1a:a0:3c:98:c5 brd ff:ff:ff:ff:ff:ff >should have more interfaces here Is it a known bug ? Regards, Alexandre Derumier -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html