Re: [systemd-devel] Systemd setting up two Microchip switch ports as individual network interfaces and then bonding them
... 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 wrote: > > > On Tue, Oct 13, 2020 at 10:06 AM Brian Hutchinson > wrote: > >> >> On Tue, Oct 13, 2020 at 9:16 AM Kevin P. Fleming 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: >> >> https://docs.phyglos.org/kernel/networking/dsa/configuration.html >> >> 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, >> >> Brian >> > > Kevin, > > 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.txt > > 3.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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd setting up two Microchip switch ports as individual network interfaces and then bonding them
On Tue, Oct 13, 2020 at 10:06 AM Brian Hutchinson wrote: > > On Tue, Oct 13, 2020 at 9:16 AM Kevin P. Fleming 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: > > https://docs.phyglos.org/kernel/networking/dsa/configuration.html > > 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, > > Brian > Kevin, 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.txt 3.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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Crond session, pam_access and pam_systemd
On Tue, 13 Oct 2020 at 13:09:43 +0200, Thomas HUMMEL wrote: > Ok, so for instance, on my debian, when I see: > > > user@1000.service > │ │ ├─gvfs-goa-volume-monitor.service > │ │ │ └─1480 /usr/lib/gvfs/gvfs-goa-volume-monitor > │ │ ├─gvfs-daemon.service > │ │ │ ├─1323 /usr/lib/gvfs/gvfsd > │ │ │ ├─1328 /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes > │ │ │ └─1488 /usr/lib/gvfs/gvfsd-trash --spawner :1.19 > /org/gtk/gvfs/exec_spaw > │ │ ├─gvfs-udisks2-volume-monitor.service > │ │ │ └─1453 /usr/lib/gvfs/gvfs-udisks2-volume-monitor > │ │ ├─xfce4-notifyd.service > │ │ │ └─1355 /usr/lib/x86_64-linux-gnu/xfce4/notifyd/xfce4-notifyd > > those services jobs are started by the systemd --user in this user init > scope, correct ? Yes. In many cases they're started on-demand (for example because something talks to them over D-Bus) rather than being started "eagerly". > My understanding now after your explanation is that crond, in the case of a > user crontab and pam_systemd in the crond stack, will create a session and > thus instanciate a systemd --user if not already present (like in the > lingered case) Yes. If uid 1000 is already logged in or is flagged for lingering, and a cron job for uid 1000 starts, the cron job will reuse their pre-existing systemd --user. If uid 1000 does not already have a systemd --user, crond's PAM stack will result in a systemd --user being started before the cron job, and stopped after the cron job. > Do you confirm that, in the case of crond this systemd --user is useless ? It might be useful, it might be useless. It depends what's in your cron jobs. For example, if you have a cron job that uses GLib to act on SMB shares or trashed files or anything like that, then it will need gvfs-daemon.service (just like the fragment of a process tree you quoted above) to be able to access smb:// or trash:// locations. smcv ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd setting up two Microchip switch ports as individual network interfaces and then bonding them
On Tue, Oct 13, 2020 at 10:06 AM Brian Hutchinson wrote: > > On Tue, Oct 13, 2020 at 9:16 AM Kevin P. Fleming 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: > > https://docs.phyglos.org/kernel/networking/dsa/configuration.html > > 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, > > Brian > .. the reason I mentioned my switch going crazy is I could immediately tell the /etc/systemd/network scripts were not setting up my switch DSA driver to make lan1 and lan2 single ports (individual NIC's). If I set up DSA with the ip command line options in the original post, I don't get that behavior (no crazy blinking switch lights) and the DSA part works. So it's kind of two parts, how to get systemd to setup DSA interfaces as single ports and then part two is making the bond. I kind of have a feeling the systemd bond examples in the links in OP would work if the DSA ports were setup in single port mode correctly. Regards, Brian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd setting up two Microchip switch ports as individual network interfaces and then bonding them
On Tue, Oct 13, 2020 at 9:16 AM Kevin P. Fleming 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: https://docs.phyglos.org/kernel/networking/dsa/configuration.html 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, Brian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd setting up two Microchip switch ports as individual network interfaces and then bonding them
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). On Tue, Oct 13, 2020 at 8:56 AM Brian Hutchinson wrote: > > Hi, > > I have my device tree exposing two Microchip KSZ9567 switch ports. I need to > use them as individual NIC's. > > I've tested the DSA driver as individual nics and they work fine. I do this > with: > > ip addr add 192.168.0.4/24 dev lan1 > ip addr add 192.168.2.4/24 dev lan2 > > ip link set eth0 up > ip link set lan1 up > ip link set lan2 up > > ... but I have no clue how to do this with /etc/systemd/network scripts > > The above was just testing/verifying my device tree and DSA driver and a step > toward real goal. Once I get two of the switch ports (the only two the > hardware brings out) to act as individual NIC's my next goal is to bond them > for redundancy. > > I really have no clue how to do that and have struggled to even uncover > relevant information. The closest thing I've found is: > > A discussion of DSA issues > https://github.com/systemd/systemd/issues/7478 > > Bonding but doesn't look like my DSA case. > https://kerlilow.me/blog/setting-up-systemd-networkd-with-bonding/#setting-up-the-bond > > I tried the above link and it looked like all I did was create a switch loop > as the LED's on my switch went crazy when I connected both of my ethernet > ports. > > Anyone have experience with systemd and DSA and bonding? > > Regards, > > Brian > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd setting up two Microchip switch ports as individual network interfaces and then bonding them
Hi, I have my device tree exposing two Microchip KSZ9567 switch ports. I need to use them as individual NIC's. I've tested the DSA driver as individual nics and they work fine. I do this with: ip addr add 192.168.0.4/24 dev lan1 ip addr add 192.168.2.4/24 dev lan2 ip link set eth0 up ip link set lan1 up ip link set lan2 up ... but I have no clue how to do this with /etc/systemd/network scripts The above was just testing/verifying my device tree and DSA driver and a step toward real goal. Once I get two of the switch ports (the only two the hardware brings out) to act as individual NIC's my next goal is to bond them for redundancy. I really have no clue how to do that and have struggled to even uncover relevant information. The closest thing I've found is: A discussion of DSA issues https://github.com/systemd/systemd/issues/7478 Bonding but doesn't look like my DSA case. https://kerlilow.me/blog/setting-up-systemd-networkd-with-bonding/#setting-up-the-bond I tried the above link and it looked like all I did was create a switch loop as the LED's on my switch went crazy when I connected both of my ethernet ports. Anyone have experience with systemd and DSA and bonding? Regards, Brian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Crond session, pam_access and pam_systemd
Hello, thanks again for your answer (and for your patience ;-)) On 12/10/2020 19:48, Mantas Mikulėnas wrote: Yes, but it is *not* a top level for *all* of the user's processes – just for those that are managed through systemctl --user. Ok, so for instance, on my debian, when I see: user@1000.service │ │ ├─gvfs-goa-volume-monitor.service │ │ │ └─1480 /usr/lib/gvfs/gvfs-goa-volume-monitor │ │ ├─gvfs-daemon.service │ │ │ ├─1323 /usr/lib/gvfs/gvfsd │ │ │ ├─1328 /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes │ │ │ └─1488 /usr/lib/gvfs/gvfsd-trash --spawner :1.19 /org/gtk/gvfs/exec_spaw │ │ ├─gvfs-udisks2-volume-monitor.service │ │ │ └─1453 /usr/lib/gvfs/gvfs-udisks2-volume-monitor │ │ ├─xfce4-notifyd.service │ │ │ └─1355 /usr/lib/x86_64-linux-gnu/xfce4/notifyd/xfce4-notifyd those services jobs are started by the systemd --user in this user init scope, correct ? So you mean that any service in this placeholder can and do use the sd-pam helper to call pam_open_session() and pam_close_session instead of doing it themselves, passing it the relevant PAMName ? No, I'm talking about system (global) services. user@.service, itself, is a system service. Ok it is a system service but why would other system services use the sd-pam helper in the init scope inside of a user service ? I'm not sure I understood in which cases this PAM service name is used It's used in only one case: when starting the "user@.service" unit. But in a regular ssh session, this service gets started without the need for the user to have (in access.conf) access to systemd-user pam service. My understanding now after your explanation is that crond, in the case of a user crontab and pam_systemd in the crond stack, will create a session and thus instanciate a systemd --user if not already present (like in the lingered case) Do you confirm that, in the case of crond this systemd --user is useless ? It is just created because it is the generic way a session (and side user@.service) is created ? It correct, I still don't get why the user would need to be explcitly (in access.conf) allowed to access systemd-user pam service while it's not needed if it had ssh'd Yes, they're completely separate PAM instances. Ok but again, the crond pam session has nothing to do with sd-pam or does it ? Ok so it's this service (systemd --user) which uses the systemd-user PAM service name ? Passed to the generic sd-pam worker ? Correct ? Yes. You said above that it was only at the creation of this service ? Thanks for your help -- Thomas HUMMEL ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
