Jump to content

Odd behavior from systemd-networkd and lldp


Shoka

Recommended Posts

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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

 

 

Link to comment
Share on other sites

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
 

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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


 

 

 

Link to comment
Share on other sites

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 :)

 

 

 

1839705470_Screenshotfrom2020-02-2314-40-13.thumb.png.585599dc71688231cc2205f3d0e74dcc.png

 

Harry

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines