Just to be clear - is this true also when protocol-mode differs from none on that bridge?
I haven’t tried it yet, we do not use bridges in any of the xSTP modes (at the edge APs, where we use bridges, there’s really no need to include them in the spanning tree topology). However, both protocols (xSTP and LLDP) are independent and thus the protocol setting (none/stp/rstp/mstp) at the bridge level should not change whether LLDP BPDUs are forwarded or not (yes, I know that in Linux kernel forwarding of both these protocols is controlled by the same bitmap setting group_fwd_mask, so there may be common point of both). Also, the behavior can be different in different modes of bridge operation (full software bridging, fast path, switchchip aka hardware acceleration), so there are many scenarios to check the behavior in all possible situations.
To be precise, the reasons why a when (not) forward STP and LLDP are also different:
- LLDP - intended to exist only between physical ports, so the bridge/switch should not forward LLDP BPDUs in any case
- STP - if the bridge/switch does not perform spanning tree operations, it should forward (=flood) STP BPDUs so it does not break function of spanning tree in the surrounding network (from spanning tree perspective such passive switch acts like a cable); otherwise, if the bridge/switch is active part of spanning tree topology, STP BPDUs need to be processed on reception and not forwarded
Ondrej
And indeed it is. I did a quick test on RB750GL (switchip Atheros 8327) and the results are:
- bridge in full software and fast path modes with protocol-mode=none forwards LLDP frames
- bridge in full software and fast path modes with protocol-mode=rstp does not forward LLDP frames
- bridge in hardware accelerated mode always forwards LLDP frames
Also, in hardware accelerated mode, when the switch ports have configured VLANs, LLDP frame forwarded from access port to trunk port gets appropriate 802.1Q encapsulation, that is completely wrong, but this is expectable generic behavior of switch chip that doesn’t know anything about LLDP.
Ondrej
After upgrading to FW 6.48.1, my 3 CCR1009-8G-1S routers (PPPoE servers) disconnect from PPPoE client every minute. What could be wrong? Upgrading to FW 6.46.8 fixes this issue.
upgraded hAP ac routeos and routerboard firmware (routerboot) as well from 6.47.4 directly to 6.48.1. - ethernet port started flopping, pretty much ‘stock’ config. dunno why 
downgrading to 6.47.8 solved the issue.
RB450Gx4, been running on this version since release. No flapping, no errors, no crashes or any noticeable issue.
aronw95, did you check the log after the first attempt?
Please help after upgrade to v6.48.1. MT is not booting.
hex rb750
Seams like my HEX (RouterBOARD 750G r3) crashes after about 30-40 Uptime days and what I just noticed now, winboard dosn’t find it anymore, is that because i turned lldp off? I mean that winboard dosn’t find the board?
When it crashes it dosn’t reboot, i just notice that all my AP are down…then I have to poweroff the Hex..this happended now twice since version 6.48
It seems that MNDP (neighbour discovery) runs on top of LLDP. However, you should still be able to connect to your router using winbox if entering its IP address (or MAC address), you just have to do it manually. If router is alive enough that is.
I may have misunderstood what you mean by “on top”. If it means “in addition to”, then that’s correct - three protocols in total are used in parallel unless you disable some of them - MNDP (which is a UDP broadcast one), LLDP (which uses a range of multicast MAC addresses intended not to be forwarded by bridges) and CDP (which uses another range of multicast MAC addresses not forwarded by Cisco switches but forwarded by other vendors’ ones).
If you had in mind that MNDP uses LLDP as its transport protocol, then this is incorrect.
Plus I know that RouterOS itself understands received PDUs of any of the three protocols, but I’m not sure whether Winbox understands CDP and/or LLDP; as a minimum, Winbox does understand MNDP, so disabling of LLDP alone on the hEX should not prevent Winbox from detecting the hEX.
MNDP is a UDP broadcast and will not work when IP is not configured. But Winbox can still detect devices in that state, it will list them without IP address.
So apparently Winbox does not use or does not rely on MNDP, but uses at least one of the LLDP or CDP protocols.
Nope. MNDP is sent even if no IPv4 is configured on the interface, from 0.0.0.0 to 255.255.255.255.
As for LLDP, it seems the bridge on Hyper-V doesn’t pass it from the CHR to the Windows, so I can’t say whether Winbox would use it for neighor discovery, but it seems unlikely to me as it would have to bind very low to the network stack to ever see an LLDP frame even if the Windows would get it. If I disable MNDP and allow LLDP and CDP in the /ip neighbor discovery-settings, Winbox stops showing the 6.48.1 CHR among neighbors.
[quote=iceman18ice post_id=849126 time=1616104375 user_id=104761]
i have error and when startup 4 minutes for boot
error while running customized default configuration script: std failure: timeout (13)
[/quote]
That and a few other reports here sound suspiciously similar to what
-->
I don’t know if it was introduced by this version or not, but I have a hEX S router and if I open “System —> Health” from left menu it shows nothing at all, if I click at “Configure” there are no options to do.
But if I open a new terminal, and ask by manual command for this ( /system health print ) I have Voltage and Temperature as reply, with both values.
As I say I have latest stable version, Winbox is v3.27 (MKPS)
Tks!
Gerardo
Makes one wonder if these releases are tested… I’ve just updated a hEX PoE to this ‘stable’ release and so far:
In Webfig and Winbox: No /system/heath output at all
In Webfig: /Interfaces/VLAN/Add-New does not work at all - nothing happens when the button is pressed (in three browsers on 2 boxes)
You upgraded the routerboard as well to 6.48.1 as well and rebooted?
System->Routerboard->Upgrade
I can confirm. I have an hEX Gr3, with 6.48.1. Upgraded firmware as well.
Webfig doesn’t show health.
Winbox doesn’t show health.
SSH works.
Yes, firmware and ROS updated. I did spot other errors in Webfig yesterday (things that just don’t work, but do in Winbox) but can’t remember what now. I just needed to get it working so cracked on in a console session.
You can turn off this logging under /system logging. Just create a rule (or disable one).