Shoka Posted February 22, 2020 Posted February 22, 2020 Using systemd-networkd for network management on a small cluster of orangepi r1's and an orangepi zero. All are connected to a single TP-Link 8 port gigabit switch. Version of systemd-networkd is what is shipping in the current armbian buster image networkctl --version systemd 241 (241) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid All four devices are configured to emit lldp and to monitor lldp. All devices are emitting lldp, seen here from one of the four devices. netadmin@probe1:~$ tshark ether proto 0x88cc Capturing on 'eth0' 1 0.000000000 02:42:63:e3:6a:8f → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe2 2 13.009395698 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 3 13.999563625 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 4 15.953929402 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor 5 30.255577659 02:42:63:e3:6a:8f → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe2 6 43.011986058 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 7 44.249476615 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 8 45.954353503 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor 9 60.259316364 02:42:63:e3:6a:8f → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe2 10 73.014544815 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 11 74.249343777 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 12 75.955214745 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor ^C12 packets captured netadmin@probe1:~$ However networkctl only ever shows two neighbors at the orangepi R1s and only one at the Orangepi zero (ups-monitor) netadmin@probe1:~$ networkctl lldp -a LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe3 .......a... eth0 \"probe3 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: o - Other; p - Repeater; b - Bridge; w - WLAN Access Point; r - Router; t - Telephone; d - DOCSIS cable device; a - Station; c - Customer VLAN s - Service VLAN; m - Two-port MAC Relay (TPMR) 2 neighbors listed. netadmin@probe1:~$ From an r1: netadmin@probe1:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe2 .......a... eth0 \"probe2 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. netadmin@probe1:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe3 .......a... eth0 \"probe3 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. netadmin@probe1:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe3 .......a... eth0 \"probe3 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. netadmin@probe1:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe3 .......a... eth0 \"probe3 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. netadmin@probe1:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe2 .......a... eth0 \"probe2 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. From the zero: netadmin@ups-monitor:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe1 .......a... eth0 \"probe1 uplink… Capability Flags: a - Station 1 neighbors listed. netadmin@ups-monitor:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe2 .......a... eth0 \"probe2 uplink… Capability Flags: a - Station 1 neighbors listed. netadmin@ups-monitor:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe2 .......a... eth0 \"probe2 uplink… Capability Flags: a - Station 1 neighbors listed. netadmin@ups-monitor:~$ tshark ether proto 0x88cc Capturing on 'eth0' 1 0.000000000 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 2 1.440290330 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 3 4.231811986 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor 4 19.653023845 02:42:63:e3:6a:8f → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe2 5 30.282432096 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 6 31.720208055 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 7 34.481361824 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor 8 49.931488643 02:42:63:e3:6a:8f → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe2 9 60.550552316 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 10 61.986085939 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 ^C 11 64.480995938 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor 11 packets captured netadmin@ups-monitor:~$ It's as the neighbor table has one, and only one "neighbor" slot for each interface. Which seems crazy, but i'm not familiar enough with the code to check... Harry
Shoka Posted February 22, 2020 Author Posted February 22, 2020 For information, if you want to see the lldp burble in detail: netadmin@ups-monitor:~$ tshark -V ether proto 0x88cc Capturing on 'eth0' Frame 1: 93 bytes on wire (744 bits), 93 bytes captured (744 bits) on interface 0 Interface id: 0 (eth0) Interface name: eth0 Encapsulation type: Ethernet (1) Arrival Time: Feb 22, 2020 14:12:01.997293541 GMT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1582380721.997293541 seconds [Time delta from previous captured frame: 0.000000000 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 0.000000000 seconds] Frame Number: 1 Frame Length: 93 bytes (744 bits) Capture Length: 93 bytes (744 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:lldp] Ethernet II, Src: 02:42:1c:e9:eb:be (02:42:1c:e9:eb:be), Dst: LLDP_Multicast (01:80:c2:00:00:0e) Destination: LLDP_Multicast (01:80:c2:00:00:0e) Address: LLDP_Multicast (01:80:c2:00:00:0e) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: 02:42:1c:e9:eb:be (02:42:1c:e9:eb:be) Address: 02:42:1c:e9:eb:be (02:42:1c:e9:eb:be) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: 802.1 Link Layer Discovery Protocol (LLDP) (0x88cc) Link Layer Discovery Protocol Chassis Subtype = Locally assigned, Id: 6c44cc9224724968bd3c53bef6a26a11 0000 001. .... .... = TLV Type: Chassis Id (1) .... ...0 0010 0001 = TLV Length: 33 Chassis Id Subtype: Locally assigned (7) Chassis Id: 366334346363393232343732343936386264336335336265... Port Subtype = Interface name, Id: eth0 0000 010. .... .... = TLV Type: Port Id (2) .... ...0 0000 0101 = TLV Length: 5 Port Id Subtype: Interface name (5) Port Id: eth0 Time To Live = 120 sec 0000 011. .... .... = TLV Type: Time to Live (3) .... ...0 0000 0010 = TLV Length: 2 Seconds: 120 Port Description = "probe1 uplink" 0000 100. .... .... = TLV Type: Port Description (4) .... ...0 0000 1111 = TLV Length: 15 Port Description: "probe1 uplink" System Name = probe1 0000 101. .... .... = TLV Type: System Name (5) .... ...0 0000 0110 = TLV Length: 6 System Name: probe1 Capabilities 0000 111. .... .... = TLV Type: System Capabilities (7) .... ...0 0000 0100 = TLV Length: 4 Capabilities: 0x0094 .... .... .... ...0 = Other: Not capable .... .... .... ..0. = Repeater: Not capable .... .... .... .1.. = Bridge: Capable .... .... .... 0... = WLAN access point: Not capable .... .... ...1 .... = Router: Capable .... .... ..0. .... = Telephone: Not capable .... .... .0.. .... = DOCSIS cable device: Not capable .... .... 1... .... = Station only: Capable Enabled Capabilities: 0x0080 .... .... .... ...0 = Other: Not capable .... .... .... ..0. = Repeater: Not capable .... .... .... .0.. = Bridge: Not capable .... .... .... 0... = WLAN access point: Not capable .... .... ...0 .... = Router: Not capable .... .... ..0. .... = Telephone: Not capable .... .... .0.. .... = DOCSIS cable device: Not capable .... .... 1... .... = Station only: Capable End of LLDPDU 0000 000. .... .... = TLV Type: End of LLDPDU (0) .... ...0 0000 0000 = TLV Length: 0
lanefu Posted February 22, 2020 Posted February 22, 2020 Is there a switch-side setting that has to be enabled?
Shoka Posted February 22, 2020 Author Posted February 22, 2020 If you mean for lldp to be generated/read by the switch my routers do that, but this test set up is simply four Orangepi boards attached to a dumb TP-Link gigabit unit, no config possible. However all the lldp traffic is reaching the four Orange pi's, that is what the tshark network traces are about. If you keep watching the networkctl lldp output, all the peers do appear, but only two at a time for the pi r1's and only one at a time for the pi zero. Harry
Shoka Posted February 22, 2020 Author Posted February 22, 2020 Some more info; looking through the networkctl code for anything related to lldp I came across this. static int open_lldp_neighbors(int ifindex, FILE **ret) { _cleanup_free_ char *p = NULL; FILE *f; if (asprintf(&p, "/run/systemd/netif/lldp/%i", ifindex) < 0) return -ENOMEM; f = fopen(p, "re"); if (!f) return -errno; *ret = f; return 0; } So looking at the /run file referenced, on the orangepi zero netadmin@ups-monitor:/run/systemd/netif/lldp$ ls 3 netadmin@ups-monitor:/run/systemd/netif/lldp$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe1 .......a... eth0 \"probe1 uplink… Capability Flags: a - Station 1 neighbors listed. netadmin@ups-monitor:/run/systemd/netif/lldp$ xxd 3 00000000: 5d00 0000 0000 0000 0180 c200 000e 0242 ]..............B 00000010: 1ce9 ebbe 88cc 0221 0736 6334 3463 6339 .......!.6c44cc9 00000020: 3232 3437 3234 3936 3862 6433 6335 3362 224724968bd3c53b 00000030: 6566 3661 3236 6131 3104 0505 6574 6830 ef6a26a11...eth0 00000040: 0602 0078 080f 2270 726f 6265 3120 7570 ...x.."probe1 up 00000050: 6c69 6e6b 220a 0670 726f 6265 310e 0400 link"..probe1... 00000060: 9400 8000 00 ..... netadmin@ups-monitor:/run/systemd/netif/lldp$ and on one of the orangepi r1's netadmin@probe2:/run/systemd/netif/lldp$ ls 3 netadmin@probe2:/run/systemd/netif/lldp$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe1 .......a... eth0 \"probe1 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. netadmin@probe2:/run/systemd/netif/lldp$ xxd 3 00000000: 5d00 0000 0000 0000 0180 c200 000e 0242 ]..............B 00000010: 1ce9 ebbe 88cc 0221 0736 6334 3463 6339 .......!.6c44cc9 00000020: 3232 3437 3234 3936 3862 6433 6335 3362 224724968bd3c53b 00000030: 6566 3661 3236 6131 3104 0505 6574 6830 ef6a26a11...eth0 00000040: 0602 0078 080f 2270 726f 6265 3120 7570 ...x.."probe1 up 00000050: 6c69 6e6b 220a 0670 726f 6265 310e 0400 link"..probe1... 00000060: 9400 8000 0067 0000 0000 0000 0001 80c2 .....g.......... 00000070: 0000 0e02 428e 4109 de88 cc02 2107 3865 ....B.A.....!.8e 00000080: 6266 3935 6566 6266 6463 3431 6335 6266 bf95efbfdc41c5bf 00000090: 6339 3865 6264 6461 6634 3962 3638 0405 c98ebddaf49b68.. 000000a0: 0565 7468 3006 0200 7808 1422 7570 732d .eth0...x.."ups- 000000b0: 6d6f 6e69 746f 7220 7570 6c69 6e6b 220a monitor uplink". 000000c0: 0b75 7073 2d6d 6f6e 6974 6f72 0e04 0094 .ups-monitor.... 000000d0: 0080 0000 .... netadmin@probe2:/run/systemd/netif/lldp$ So it looks like networkctl is correctly reporting all the information available to it. So why does systemd-networkd only acquire those one or two results. ???? Harry
Shoka Posted February 22, 2020 Author Posted February 22, 2020 Stranger and stranger.... I have an nanopi R1 on another segment of my network, lots of devices, including buster based raspberry pi's, an antique pi running Jessie, and a MikroTik router. That behaves pretty much as expected... netadmin@nanopi:~$ cd /run/systemd/netif/lldp netadmin@nanopi:/run/systemd/netif/lldp$ ls 3 netadmin@nanopi:/run/systemd/netif/lldp$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 4c:5e:0c:54:93:d7 core-MikroTik ..b.r...... Local devices/et… n/a eth0 b8:27:eb:30:ff:62 namepi .......a... b8:27:eb:30:ff:62 eth0 eth0 b8:27:eb:3e:6a:ab watchpi.local.s… .......a... b8:27:eb:3e:6a:ab eth0 eth0 edc39c88bf9d4103… namepi .......a... eth0 \"timepi uplink… eth0 fe1d4a4d0ac7441e… routerpi .......a... eth0 routepi uplink Capability Flags: b - Bridge; r - Router; a - Station 5 neighbors listed. netadmin@nanopi:/run/systemd/netif/lldp$ xxd 3 00000000: 9200 0000 0000 0000 0180 c200 000e 4c5e ..............L^ 00000010: 0c54 93d7 88cc 0207 044c 5e0c 5493 d704 .T.......L^.T... 00000020: 2205 4c6f 6361 6c20 6465 7669 6365 732f ".Local devices/ 00000030: 6574 6865 7231 3020 6d67 6d74 2073 7769 ether10 mgmt swi 00000040: 7463 6806 0200 780a 0d63 6f72 652d 4d69 tch...x..core-Mi 00000050: 6b72 6f54 696b 0c2c 4d69 6b72 6f54 696b kroTik.,MikroTik 00000060: 2052 6f75 7465 724f 5320 362e 3436 2e33 RouterOS 6.46.3 00000070: 2028 7374 6162 6c65 2920 5242 3230 3131 (stable) RB2011 00000080: 5569 4153 100c 0501 ac19 1901 0200 0000 UiAS............ 00000090: 0b00 0e04 0014 0014 0000 be00 0000 0000 ................ 000000a0: 0000 0180 c200 000e b827 eb30 ff62 88cc .........'.0.b.. 000000b0: 0207 04b8 27eb 30ff 6204 0703 b827 eb30 ....'.0.b....'.0 000000c0: ff62 0602 0078 0a06 6e61 6d65 7069 0c5e .b...x..namepi.^ 000000d0: 5261 7370 6269 616e 2047 4e55 2f4c 696e Raspbian GNU/Lin 000000e0: 7578 2039 2028 7374 7265 7463 6829 204c ux 9 (stretch) L 000000f0: 696e 7578 2034 2e31 392e 3636 2d76 372b inux 4.19.66-v7+ 00000100: 2023 3132 3533 2053 4d50 2054 6875 2041 #1253 SMP Thu A 00000110: 7567 2031 3520 3131 3a34 393a 3436 2042 ug 15 11:49:46 B 00000120: 5354 2032 3031 3920 6172 6d76 376c 0e04 ST 2019 armv7l.. 00000130: 009c 0080 100c 0501 c0a8 3701 0200 0000 ..........7..... 00000140: 0300 0804 6574 6830 fe09 0012 0f03 0100 ....eth0........ 00000150: 0000 00fe 0900 120f 0103 ecc0 0010 0000 ................ 00000160: cd00 0000 0000 0000 0180 c200 000e b827 ...............' 00000170: eb3e 6aab 88cc 0207 04b8 27eb 3e6a ab04 .>j.......'.>j.. 00000180: 0703 b827 eb3e 6aab 0602 0078 0a17 7761 ...'.>j....x..wa 00000190: 7463 6870 692e 6c6f 6361 6c2e 7368 6f6b tchpi.local.shok 000001a0: 612e 6e65 740c 5c52 6173 7062 6961 6e20 a.net.\Raspbian 000001b0: 474e 552f 4c69 6e75 7820 3820 286a 6573 GNU/Linux 8 (jes 000001c0: 7369 6529 204c 696e 7578 2034 2e39 2e33 sie) Linux 4.9.3 000001d0: 352d 7637 2b20 2331 3031 3420 534d 5020 5-v7+ #1014 SMP 000001e0: 4672 6920 4a75 6e20 3330 2031 343a 3437 Fri Jun 30 14:47 000001f0: 3a34 3320 4253 5420 3230 3137 2061 726d :43 BST 2017 arm 00000200: 7637 6c0e 0400 9c00 8010 0c05 01ac 1919 v7l............. 00000210: 9502 0000 0002 0008 0465 7468 30fe 0900 .........eth0... 00000220: 120f 0301 0000 0000 fe09 0012 0f01 036c ...............l 00000230: c000 1000 005d 0000 0000 0000 0001 80c2 .....].......... 00000240: 0000 0eb8 27eb 30ff 6288 cc02 2107 6564 ....'.0.b...!.ed 00000250: 6333 3963 3838 6266 3964 3431 3033 6162 c39c88bf9d4103ab 00000260: 3863 6339 6262 3436 3130 3136 3762 0405 8cc9bb4610167b.. 00000270: 0565 7468 3006 0200 7808 0f22 7469 6d65 .eth0...x.."time 00000280: 7069 2075 706c 696e 6b22 0a06 6e61 6d65 pi uplink"..name 00000290: 7069 0e04 0094 0080 0000 5e00 0000 0000 pi........^..... 000002a0: 0000 0180 c200 000e b827 ebf9 db38 88cc .........'...8.. 000002b0: 0221 0766 6531 6434 6134 6430 6163 3734 .!.fe1d4a4d0ac74 000002c0: 3431 6538 3137 6430 3131 6537 3064 6132 41e817d011e70da2 000002d0: 3437 3104 0505 6574 6830 0602 0078 080e 471...eth0...x.. 000002e0: 726f 7574 6570 6920 7570 6c69 6e6b 0a08 routepi uplink.. 000002f0: 726f 7574 6572 7069 0e04 0094 0080 0000 routerpi........ All the armbian systems are notionally running buster and the same release of systemd-networkd. netadmin@ups-monitor:/run/systemd/netif/lldp$ networkctl --version systemd 241 (241) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid netadmin@probe2:/run/systemd/netif/lldp$ networkctl --version systemd 241 (241) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid netadmin@nanopi:/run/systemd/netif/lldp$ networkctl --version systemd 241 (241) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid netadmin@nanopi:/run/systemd/netif/lldp$ This has to be some difference between the armbian builds for the Orangepi r1 and the nanopi r1. This has to constitute a bug, inside armbian. I'll raise a bug and point to this thread. Harry
lanefu Posted February 23, 2020 Posted February 23, 2020 Please Switch to alternate ethernet ports on the nano pi r1 and opi r1 and see if results change
Shoka Posted February 23, 2020 Author Posted February 23, 2020 More info, it's not a bug. I moved the nanopi to the test network and it demonstrated the same symptoms. Digging into the lldp traffic as captured by tshark. chassis subtype: device: Chassis ID: 8ebf95efbfdc41c5bfc98ebddaf49b68 ups_monitor 386562663935656662666463343163356266633938656264... 6c44cc9224724968bd3c53bef6a26a11 probe1 366334346363393232343732343936386264336335336265... 6c44cc9224724968bd3c53bef6a26a11 probe2 366334346363393232343732343936386264336335336265... 6c44cc9224724968bd3c53bef6a26a11 probe3 366334346363393232343732343936386264336335336265... 6c44cc9224724968bd3c53bef6a26a11 nanopir1 366334346363393232343732343936386264336335336265... All the orangepi r1's and (possibly the nanopir1 were cloned from the same sd card. It looks like systemd-networkd is seeing all the r1's and the nanopi as the same device, despite the differing MAC addresses, and thus the difference between the orangepi zero, which sees only one unique device, and the ri's and the nano, which see two unique devices. It's just an unhappy coincidence that the number of unique devices seen matches the number of interfaces on the device. lldpd allows per system configuration of chassis subtype and chassis ID. Off to find out if the same is possible with systemd-networkd Suggestion to switch ports is a good one, but I'm not sure if systemd-networkd would consider them different devices, with the those properties matching, so going down fixing that mistake first. I can probably persuade systemd-networkd to use the mac address in it's lldp broadcasts, but if anyone knows where those chassis type and chassis ID strings are stored, generated from etc, I'd love to find out. Thanks for the help and suggestions so far. Harry 1
Shoka Posted February 23, 2020 Author Posted February 23, 2020 Fixed There is a file /etc/machine-id that controls (among other things) the machine id broadcast by systemd-networkd. It's set during first boot, by systemd-machine-id-setup. Another thing to fix on a cloned system In principal simply deleting this file and running systemd-machine-id-setup should generate a new random machine-id file. Unfortunately systemd-machine-id-setup takes its preferred id from another file /var/lib/dbus/machine-id I think, so you get straight back to the original, duplicated file. Answer 2 (29) here gives a sequence that recreates a random /etc/machine-id file compatible with dbus/machine-id, and replaces the dbus/machine-id with the new /etc/machine-id. Notes elsewhere suggest that "bad things will happen" if you replace dbus machine-id on a running system, but as noted in that solution, a boot fixes any bad things that occur. sequence here in case that link disintegrates... # Messing with machine-id at al sudo rm -f /etc/machine-id sudo dbus-uuidgen --ensure=/etc/machine-id sudo rm /var/lib/dbus/machine-id sudo dbus-uuidgen --ensure # immediate reboot. Done and rebooted all five machines in my test setup. netadmin@ups-monitor:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 2ddb2dd5c7ab115e… probe3 .......a... eth0 \"probe3 uplink… eth0 6c44cc9224724968… probe2 .......a... eth0 \"probe2 uplink… eth0 a304dbe115289f1c… nanopi .......a... eth0 \"nanopir1 upli… eth0 abe4d225ff47687e… probe2 .......a... eth0 \"probe2 uplink… eth0 eaf8d1906e1149a0… probe1 .......a... eth0 \"probe1 uplink… Capability Flags: a - Station 5 neighbors listed. Yay Harry 1
lanefu Posted February 23, 2020 Posted February 23, 2020 Solid forensic works. So... what are you using lldp for?
Shoka Posted February 23, 2020 Author Posted February 23, 2020 Nothing special. Its a very convenient way to keep track of whats running. The pi's show as neighbor's to the MikroTik routers I use. I'm a retired network engineer, like to keep my hand in Harry
![m][sko](https://forum.armbian.com/uploads/n2a/n2a-180904eb9612afa23a4c3358385bd86f384613e3.avatars_letters_gd.png){kind=avatar}
Recommended Posts