LLDPD on Bonded/LAG Ports

[NickBurns]

Hello All.

RT-AC5300
RT-AX86U
RP-AC1900

I have my ASUS routers under LAN -> Switch Control set for link aggregation. The resulting interface is br0.

The default LLDPD call appears to be below which omits br0. The line below is from my RP-AC1900 which also incorrectly identifies the product as "RT-AC68U" but that's an Asus code issue for that model I would think.

RP-AC1900
lldpd -L /usr/sbin/lldpcli -I vlan1,eth1,eth2,vlan2,wl0.1,wl1.1,dpsta,wds0.*,wds1.* -s RT-AC68U

RT-AX86U / RT-AC5300
lldpd -L /usr/sbin/lldpcli -I vlan1,eth1,eth2,eth3,wds0.*,wds1.*,wds2.* -s RT-AC5300
lldpd -L /usr/sbin/lldpcli -I eth2,eth1,eth5,eth6,eth7,wl1.2,wds0.*.*,wds1.*.* -s RT-AX86U


Anyone know if the system can be modified to add in br0 on startup or is it hardcoded? Or a way to say kill the default process and run it automatically with the new cmdline on startup? If kill and manually restart this process with br0 appended all is good.

Also would this be something that can be fixed/changed in the AsusWRT codebase that if LAG is enabled it includes br0?

Thank you.

 

[ColinTaylor]

I have my ASUS routers under LAN -> Switch Control set for link aggregation. The resulting interface is br0.

br0 is not the link aggregation interface, it is the LAN bridge interface that's present on all Asus routers in all configurations.

I have no idea what interface link aggregation creates on your routers. I'd guess it would be something like bond0 or bond1.

EDIT: Reading more about this it appears that this is working correctly. Apparently lldpd should only be used on physical interfaces and not bonded/aggregated/bridged interfaces.

 

[Ripshod]

@NickBurns are you sure you don't mean LACP, which is active by default when LANs are bonded on asus routers?

 

[NickBurns]

@NickBurns are you sure you don't mean LACP, which is active by default when LANs are bonded on asus routers?

Not in this case. Definitely LLDP. I support products that draw network maps based on LLDP data advertised by devices to switches/routers that support LLDP and SNMP.

 

[NickBurns]

br0 is not the link aggregation interface, it is the LAN bridge interface that's present on all Asus routers in all configurations.

I have no idea what interface link aggregation creates on your routers. I'd guess it would be something like bond0 or bond1.

EDIT: Reading more about this it appears that this is working correctly. Apparently lldpd should only be used on physical interfaces and not bonded/aggregated/bridged interfaces.

So my mistake - yes this is bond0 vs br0.

The moment I enable bond0 I get the LLDP advertisements to my connected switch.

Where are you reading that LLDP should not be advertised by bonded/LAG interfaces?

 

[ColinTaylor]

Where are you reading that LLDP should not be advertised by bonded/LAG interfaces?

I was just looking at various google results for "lldpd bond0". It returned results such as this flapping problem and this discussion. This seems to make sense to me given that LLDP is working at the physical layer.

 

[NickBurns]

So I've made some headway on this.

The default LLDPD running is

lldpd -L /usr/sbin/lldpcli -I eth2,eth1,eth5,eth6,eth7,wl1.2,wds0.*.*,wds1.*.* -s RT-AX86U

... and thinking now bond0/br0 are no no's (thank you btw) why the order above is/was selected considering I have two ports in LAG.

Guess which two ports are in LAG?

cat /proc/net/bonding/bond0
eth3/eth4

So I changed lldp to advertise on eth3,eth4 and voila - my problem is solved. I now see advertisements on both interfaces at my switch... my switch has determined they are in a LAG and my mapping now shows the two ports in a LAG.

The question I now have then is the default lldpd call above appears to omit (purposely??) the two ports I have in LAG. Is that a / the bug?


I also had to make the following configuration changes via lldpcli

configure system bond-slave-src-mac-type real
configure lldp portidsubtype ifname

... as it would advertise the same MAC address (because ifconfig shows the same MAC address for each port) to ifname.


At this point I'm trying to figure out how I can make this change permanent...

 

[ColinTaylor]

The question I now have then is the default lldpd call above appears to omit (purposely??) the two ports I have in LAG. Is that a / the bug?

It sounds like a bug to me. Here is the output from my non-bonded RT-AX86U.

 1673 admin     3420 S    lldpd -L /usr/sbin/lldpcli -I eth4,eth3,eth2,eth1,eth5,eth6,eth7,wl0.2,wds0.*.*,wds1.*.* -s RT-AX86U
 1677 nobody    3420 S    lldpd -L /usr/sbin/lldpcli -I eth4,eth3,eth2,eth1,eth5,eth6,eth7,wl0.2,wds0.*.*,wds1.*.* -s RT-AX86U

# nvram get lan_ifnames
eth4 eth3 eth2 eth1 eth5 eth6 eth7 wl0.2

Looking at the source code it is deliberately excluding the bonded physical interfaces. I couldn't guess what the reasoning behind that is though.

 

[NickBurns]

I suppose I'd like some help to learn how to manipulate the system here.

I can see the executables make a call to a run_lldpd.sh script, if present. In the /tmp sub-directory on each of my routers/repeaters there is one. It does not have the +x bit set. Doing so I can run it (and I can edit it to do what I want it to do)...

.. but I'm not clear if it survives a restart and right now I can't bring down my home network to play in those waters.

Does this /tmp sub-dir survive a restart or does it get automatically overwritten / refreshed on reboot?

/tmp# cat run_lldpd.sh
#!/bin/sh
lldpd -L /usr/sbin/lldpcli -I vlan1,eth1,eth2,vlan2,wl0.1,wl1.1,dpsta,wds0.*,wds1.* -s RT-AC68U
sleep 2
lldpcli configure lldp tx-interval 10
lldpcli configure lldp tx-hold 2
lldpcli resume
nvram set amascli_dbg=1
amas-utils-cli set cost -v 0
nvram set amascli_dbg=0


I'm still interested in why my LAG ports by default don't show in the list on my AX86 router.

 

[ColinTaylor]

I'm still interested in why my LAG ports by default don't show in the list on my AX86 router.

The router's lldpd is a subset of the AiMesh code (the clue is in all the references to "amas"). My suspicion is that it isn't intended to be used by the end user, but rather it's just a tool used by AiMesh. As such I wouldn't rely it being implemented in a "normal" way.

The run_lldpd.sh script is automatically generated each time the router boots up or the amas_lldpd service is started.

 

[NickBurns]

I guess I'll have to accept that... that the lldpd service, while present, was not intended for use as I would like to you use - for network mapping purposes - since it's freely advertising itself on the local network.

For now I've written a script task to ssh into my four routers/repeaters and periodically kill and restart the LLDP service for my needs.


Thank you.