search for: enslavement

What is the maximum number of devices that can be enslaved in a bridge interface? I have tried enslaving 512 devices. Although the brctl tool did not complain while adding them, when I use brctl show command it only shows 255. Thanks

I have a bridge br0, it enslaves two NICs: eth0 and eth1. By using "cat /proc/net/dev ", i can see the Rx/Tx packets and bytes through each interface. just like this: [* time tick 1 *] Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed

...s it seems to be to enslave the VF driver >> > > netdev under a persistent anchor netdev. >> > > And it's indeed desired to allow (but not enforce) PV netdev and VF >> > > netdev to work in conjunction. >> > > And it's indeed desired that this enslavement logic work out-of-the box. >> > > But in case of PV+VF some configurable policies must be in place (and >> > > they'd better be generic rather than differ per PV technology). >> > > For example - based on which characteristics should the PV+VF coupling >&g...

...s it seems to be to enslave the VF driver >> > > netdev under a persistent anchor netdev. >> > > And it's indeed desired to allow (but not enforce) PV netdev and VF >> > > netdev to work in conjunction. >> > > And it's indeed desired that this enslavement logic work out-of-the box. >> > > But in case of PV+VF some configurable policies must be in place (and >> > > they'd better be generic rather than differ per PV technology). >> > > For example - based on which characteristics should the PV+VF coupling >&g...

Ahoy, I've encountered some confusing semantics with using PACKET(7) sockets on bridge-enslaved interfaces. Specifically, if my socket accepts all types of frame (bind() to ETH_P_ALL) then it gets all packets; but if it accepts any specific type (e.g. ETH_P_IP), then it receives no packets at all. That is how it's coded in net/core/dev.c's netif_receive_skb(). First ETH_P_ALL

...nd with modprobe, ifconfig, ifenslave, etc., a solution was stumbled upon: enslave the eth1 device before eth0, and all is good. Why this should matter is a puzzle - I could not find anything in bonding.txt or on the web about it. I had to change ifup-eth to fix the problem. Any ideas on why the enslavement order matters, or a better solution to work around it? The rest of this post is details. To fix this, I had to patch /etc/sysconfig/network-scripts/ifup-eth to reverse the order when it is updating the sysfs slaves list. A 1-line change, from: for device in $(LANG=C egrep -l "^[[:space:]]...

Hi all Assume that you have a linux bridge with two interfaces eth0 and eth1 enslaved to this bridge What is the difference between sniffing the bridge and sniffing its interfaces? tcpdump -i br0 vs tcpdump -i eth0 Thanks MiniME -------------- next part -------------- An HTML attachment was scrubbed... URL:

...s was suggested by Lennart since udev is only doing naming policy > because kernel names were not repeatable. > > This makes the VF show up as "ethN_vf" on Hyper-V which is user friendly. > > Patch is pending. While it's good to show VF with specific naming to indicate enslavement, I wonder wouldn't it be better to hide this netdev at all from the user space? IMHO this extra device is useless when being enslaved and we may delegate controls (e.g. ethtool) over to the para-virtual device instead? That way it's possible to eliminate the possibility of additional udev s...

...s was suggested by Lennart since udev is only doing naming policy > because kernel names were not repeatable. > > This makes the VF show up as "ethN_vf" on Hyper-V which is user friendly. > > Patch is pending. While it's good to show VF with specific naming to indicate enslavement, I wonder wouldn't it be better to hide this netdev at all from the user space? IMHO this extra device is useless when being enslaved and we may delegate controls (e.g. ethtool) over to the para-virtual device instead? That way it's possible to eliminate the possibility of additional udev s...

I can think of several potential differences. ?You may miss any bridge specific traffic (STP, LLDP) using the interfaces generated by the bridge itself. If you have vlan tagged sub interfaces you might also miss that traffic if you were snooping a particular interface. Obviously you will miss any on-wire broadcast traffic specific to the layer1 connection a particular interface was connected to

...ace that userspace > (udev) may fail to rename the slave if the kernel (net_failover) > opens the slave earlier than when the userspace rename happens. > Unlike bond or team, the primary slave of failover can't be renamed by > userspace ahead of time, since the kernel initiated auto-enslavement is > unable to, or rather, is never meant to be synchronized with the rename > request from userspace. > > As the failover slave interfaces are not designed to be operated > directly by userspace apps: IP configuration, filter rules with > regard to network traffic passing and et...

...ace that userspace > (udev) may fail to rename the slave if the kernel (net_failover) > opens the slave earlier than when the userspace rename happens. > Unlike bond or team, the primary slave of failover can't be renamed by > userspace ahead of time, since the kernel initiated auto-enslavement is > unable to, or rather, is never meant to be synchronized with the rename > request from userspace. > > As the failover slave interfaces are not designed to be operated > directly by userspace apps: IP configuration, filter rules with > regard to network traffic passing and et...

Hello, I am working on Network-Simulation (VNUML). Our simulator uses linux bridgi= ng to connect the UMLs. So there is one problem: The example is the following: There are two hosts simulating one big net. The two hosts have connection over the external nets Net3 and Net6 (see htt= p://www.uni-koblenz.de/~timbub/verteilteSim3.GIF), but in fact there is onl= y one physical connection between the

...ace that userspace > (udev) may fail to rename the slave if the kernel (net_failover) > opens the slave earlier than when the userspace rename happens. > Unlike bond or team, the primary slave of failover can't be renamed by > userspace ahead of time, since the kernel initiated auto-enslavement is > unable to, or rather, is never meant to be synchronized with the rename > request from userspace. > > As the failover slave interfaces are not designed to be operated > directly by userspace apps: IP configuration, filter rules with > regard to network traffic passing and et...

...ace that userspace > (udev) may fail to rename the slave if the kernel (net_failover) > opens the slave earlier than when the userspace rename happens. > Unlike bond or team, the primary slave of failover can't be renamed by > userspace ahead of time, since the kernel initiated auto-enslavement is > unable to, or rather, is never meant to be synchronized with the rename > request from userspace. > > As the failover slave interfaces are not designed to be operated > directly by userspace apps: IP configuration, filter rules with > regard to network traffic passing and et...

...river >> >> > > netdev under a persistent anchor netdev. >> >> > > And it's indeed desired to allow (but not enforce) PV netdev and VF >> >> > > netdev to work in conjunction. >> >> > > And it's indeed desired that this enslavement logic work out-of-the box. >> >> > > But in case of PV+VF some configurable policies must be in place (and >> >> > > they'd better be generic rather than differ per PV technology). >> >> > > For example - based on which characteristics shoul...

...river >> >> > > netdev under a persistent anchor netdev. >> >> > > And it's indeed desired to allow (but not enforce) PV netdev and VF >> >> > > netdev to work in conjunction. >> >> > > And it's indeed desired that this enslavement logic work out-of-the box. >> >> > > But in case of PV+VF some configurable policies must be in place (and >> >> > > they'd better be generic rather than differ per PV technology). >> >> > > For example - based on which characteristics shoul...

...: >> Indeed the best way to address it seems to be to enslave the VF driver >> netdev under a persistent anchor netdev. >> And it's indeed desired to allow (but not enforce) PV netdev and VF >> netdev to work in conjunction. >> And it's indeed desired that this enslavement logic work out-of-the box. >> But in case of PV+VF some configurable policies must be in place (and >> they'd better be generic rather than differ per PV technology). >> For example - based on which characteristics should the PV+VF coupling >> be done? netvsc uses MAC ad...

...: >> Indeed the best way to address it seems to be to enslave the VF driver >> netdev under a persistent anchor netdev. >> And it's indeed desired to allow (but not enforce) PV netdev and VF >> netdev to work in conjunction. >> And it's indeed desired that this enslavement logic work out-of-the box. >> But in case of PV+VF some configurable policies must be in place (and >> they'd better be generic rather than differ per PV technology). >> For example - based on which characteristics should the PV+VF coupling >> be done? netvsc uses MAC ad...

...ly upon pre-copy phase start. Re. problem #2: Indeed the best way to address it seems to be to enslave the VF driver netdev under a persistent anchor netdev. And it's indeed desired to allow (but not enforce) PV netdev and VF netdev to work in conjunction. And it's indeed desired that this enslavement logic work out-of-the box. But in case of PV+VF some configurable policies must be in place (and they'd better be generic rather than differ per PV technology). For example - based on which characteristics should the PV+VF coupling be done? netvsc uses MAC address, but that might not always be...