... would be nice if someone could add a systemd-networkd section to Documentation/networking/bonding.txt
Looks like all methods but systemd-networkd are covered.
Regards,
Brian
On Tue, Oct 13, 2020 at 4:06 PM Brian Hutchinson <b.hutchman@xxxxxxxxx> wrote:
On Tue, Oct 13, 2020 at 10:06 AM Brian Hutchinson <b.hutchman@xxxxxxxxx> wrote:On Tue, Oct 13, 2020 at 9:16 AM Kevin P. Fleming <kevin@xxxxxxx> wrote:While I can't comment on the specifics of configuring systemd-networkd
to use ports through DSA (although the linked GitHub issue shows that
it can be done), I really doubt you are going to be able to
successfully bond any group of such ports, because they all have the
same MAC address. In your proposed configuration, you have a NIC
connected to a switch (internal to your system), which would then have
multiple ports connected to *another* switch. Unless the switches
involved support STP or some other loop-avoidance mechanism, you will
get a switching loop in this configuration.
Connecting multiple ports between two switches requires cooperation in
the switches (STP, or LACP, or something else).ds,So a primer on DSA:You can make the switch ports act as individual network interfaces (called single port in that web link) that won't create switch loops.The pre-cursor to DSA that the OpenWRT guys use does the same thing. It can bust a switch up into individual ports ... then you can do whatever you want with them.Regards,BrianKevin,I believe some of your concerns can also be handled by bonding:This is from kernel Documentation directory ... but a link to same https://www.kernel.org/doc/Documentation/networking/bonding.txt3.7 Configuring LACP for 802.3ad mode in a more secure way ---------------------------------------------------------- When using 802.3ad bonding mode, the Actor (host) and Partner (switch) exchange LACPDUs. These LACPDUs cannot be sniffed, because they are destined to link local mac addresses (which switches/bridges are not supposed to forward). However, most of the values are easily predictable or are simply the machine's MAC address (which is trivially known to all other hosts in the same L2). This implies that other machines in the L2 domain can spoof LACPDU packets from other hosts to the switch and potentially cause mayhem by joining (from the point of view of the switch) another machine's aggregate, thus receiving a portion of that hosts incoming traffic and / or spoofing traffic from that machine themselves (potentially even successfully terminating some portion of flows). Though this is not a likely scenario, one could avoid this possibility by simply configuring few bonding parameters: (a) ad_actor_system : You can set a random mac-address that can be used for these LACPDU exchanges. The value can not be either NULL or Multicast. Also it's preferable to set the local-admin bit. Following shell code generates a random mac-address as described above. # sys_mac_addr=$(printf '%02x:%02x:%02x:%02x:%02x:%02x' \ $(( (RANDOM & 0xFE) | 0x02 )) \ $(( RANDOM & 0xFF )) \ $(( RANDOM & 0xFF )) \ $(( RANDOM & 0xFF )) \ $(( RANDOM & 0xFF )) \ $(( RANDOM & 0xFF ))) # echo $sys_mac_addr > /sys/class/net/bond0/bonding/ad_actor_system (b) ad_actor_sys_prio : Randomize the system priority. The default value is 65535, but system can take the value from 1 - 65535. Following shell code generates random priority and sets it. # sys_prio=$(( 1 + RANDOM + RANDOM )) # echo $sys_prio > /sys/class/net/bond0/bonding/ad_actor_sys_prio (c) ad_user_port_key : Use the user portion of the port-key. The default keeps this empty. These are the upper 10 bits of the port-key and value ranges from 0 - 1023. Following shell code generates these 10 bits and sets it. # usr_port_key=$(( RANDOM & 0x3FF )) # echo $usr_port_key > /sys/class/net/bond0/bonding/ad_user_port_key
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
