Best practice: lldp, spanning-tree bpdu-protection/admin-edge-port, rate-limits?

[Garacesh]

'ello everybody.

 

We've had a review from our support folks regarding our switch configurations, mostly aimed at bringing our old procurve-style devices in line with our newer cisco-style ones, but I'm in the mud a little regarding some of the advice.

Sometimes it's a little inconsistent or not really quantified very well, and whilst I could go back and ask them about it (which I plan to do) I'd rather get my head around it a little more so I know I'm phrasing my questions properly (and also I like to understand the changes I'm making, as that makes me more likely to remember them.. Plus, y'know, who doesn't like actually knowing what they're doing..?)

 

LLDP - What devices should or shouldn't have it on their ports?

We've been advised to change lldp admin-status from disable to rxonly, but I notice that there's no real rhyme or reason for which ports are or aren't specified.

On some switches, it's everything but the uplinks, on some it's almost everything but the uplinks but not quite, on others there's no real structure as to which ports are or aren't.

Does the old setting of disabled mean that it's off on those ports, rxonly sets it as receive only, and then any unspecified ports are defaulted to send-receive?

 

STP (bpdu-protection and admin-edge-port) - Where should it or should it not be applied?

Most of our switches have spanning tree ## admin-edge-port and spanning tree ## bpdu-protection enabled, but as with LLDP there's no real criteria obvious for it.

Some switches have it not at all, with just spanning-tree and nothing further, some switches have it only set on the ports connected to access points, some have it set on everything except uplinks, and some on a random assortment of ports.

Also some switches also have an additional loop-protect setting applied. What's the difference? I thought spanning tree was loop protection (plus other stuff)?

 

Rate limits

Practically every port has rate-limit icmp ip-all percent 1 set on every port, which we have been advised to remove from printer ports.

However, as with lldp and stp, there's a bunch of other devices with settings. The settings are usually consistent (rate-limit bcast in percent 10, rate-limit mcast in percent 10, and occasionally rate-limit unknown-unicast in percent 10 (or occasionally 20), but again there's no real pattern here. Some workstations do, some don't, some AP's do, some don't. Some switches have no rate limits applied on any ports.

 

I know a lot this will likely just be holdovers from the way a switch/port used to be configured, where bits of it have been changed but other bits have been left alone, but I'll hold my hand up and admit it's not something I'm intimately familiar with.

Edited July 27, 2023 by Garacesh

[psydii]

Just checking, they audited your network not mine? TBH looking forward to the responses so I can clean things up here too.

[dmj]

Sounds like you've inherited a hand managed system!

Your #1 takehome from this should be that you need to track changes and manage these centrally. At the very least so you have documentation of how the network is supposed to be configured!

 

As for the specific configs, I'm a bit too far removed from network administration these days, but what your network consultants are saying make sense to me.

I don't believe LLDP and STP are mutually exclusive, or even related. I would certainly set a STP default priority on all switches, and lower it on core switches. I think loop-protection is more for ports that connect clients and unmanaged switches that can't use STP. I'm not clear on this though. The important think is to set it the same on all devices, unless you have a reason not to. It sounds like it's a bit arbitrary at the moment.

[psydii]

The word used was Procurve. That's a brand that hasn't existing for 12 years. Most people using that brand did/do not have access to network switch management tools. They are/were notoriously finickity and capabilities and bugs varied wildly between models. Hand management was the norm by necessity. The only 'properly' centrally managed procurve network I have seen was an absolute disaster, that was only fixable through "hand management" as you put it. And with kit that old, I doubt any modern management platform will have much luck standardizing configs.

 

FWIW I do have change management on ours - but with the variety and ages of the kit we alter configs by hand and use the NMS to track changes, monitor for problems and offer roll-back. Its a mess (but reliable). Could it be better, yes but we'd need to employ a network engineer with a procurve background to get there, and if we had an audit that made recommendations around config changes that seems to have very little rhyme or reason, I'd want to bounce them off others who might have more of a clue too.

[Chris_Cook]

With LLDP its a matter of balancing easy of discovering the network structure vs not giving out to much info to people who shouldn't know it. Its quite low bandwidth (1 or 2 packets per minute, and only goes to the next device).

 

If you're not familiar, you can use an LLDP utility, network switch, or Wireshark with the 'LLDP' filter to see the port number, hostname and IP address of the switch you are connected to. Quite handy if you are not familiar with your network, or if you need to look up which switch port to configure a VLan on etc. You can also see which IP phones are plugged in where, and use things like LLDP-med for auto config etc.

 

Provided your switches have been setup securely, then its probably not too much of a risk.

 

If you where worried, then limiting it to uplink/sfp ports, or rx-only would be beneficial.

 

I'm not sure what the default settings are on procurve. Most of the switches I've come across, its just completely disabled across the board by default.

[dmj]

The word used was Procurve. That's a brand that hasn't existing for 12 years. Most people using that brand did/do not have access to network switch management tools. They are/were notoriously finickity and capabilities and bugs varied wildly between models. Hand management was the norm by necessity. The only 'properly' centrally managed procurve network I have seen was an absolute disaster, that was only fixable through "hand management" as you put it. And with kit that old, I doubt any modern management platform will have much luck standardizing configs.

 

FWIW I do have change management on ours - but with the variety and ages of the kit we alter configs by hand and use the NMS to track changes, monitor for problems and offer roll-back. Its a mess (but reliable). Could it be better, yes but we'd need to employ a network engineer with a procurve background to get there, and if we had an audit that made recommendations around config changes that seems to have very little rhyme or reason, I'd want to bounce them off others who might have more of a clue too.

 

Appreciate they are old, but we are talking centralised management, not software defined networking so it doesn't need an api - plain old ssh and a tftp server will do it.

Have you thought about simply centralising the config files, per switch and just templating those config files and deploying with ansible. All the tools are free.

[psydii]

Yes I’ve thought about it.

[CrootUK]

LLDP enabled across all the Edge

 

RSTP enabled globally

 

BPDU guard on all access ports

 

If your switch supports it Loop Guard on switch uplinks.

 

Make sure your core switch has lowest root priority set

Edited July 27, 2023 by CrootUK

[psydii]

If you've got RSTP why loop guard on switch uplinks? I thought it more suitable for edge ports where there is a very real risk that an end user in a random office might create a loop. (as previously alluded, I am not a network engineer, so my understanding is almost certainly weak/wrong it at least some areas)

[dmj]

I was also unclear on this point. There's a really good explanation here: https://community.cisco.com/t5/switching/where-to-apply-loop-guard/m-p/1969256/highlight/true#M220492

[Garacesh]

Sounds like you've inherited a hand managed system!

Your #1 takehome from this should be that you need to track changes and manage these centrally. At the very least so you have documentation of how the network is supposed to be configured!

Yep, I've already documented the Cisco-style switches we've got, trying to do the same for the older ones.

 

I don't believe LLDP and STP are mutually exclusive, or even related

No, I don't expect they are. To clarify, the 3 settings I've asked about, I've asked about because there is no consistency about how they're set on each switch, not because they're related somehow.

 

The word used was Procurve. That's a brand that hasn't existing for 12 years.

The switches aren't actually procurve switches, they're mostly various flavours of the HP 2530 series switches. I just thought the two command structures were referred to as procurve-style (tagged/untagged) and cisco-style (access/trunk)

[psydii]

Ok, now I'm off reading the docs. I'm sure I was supposed to be doing something else this morning....

 

So it seems that tn HP Procurve /HPE Aruba Provision universe, loop protect and loop guard are different things. Use Loop protect for edge ports, and Loop Guard for ports that are involved in Spanning Tree. (at least on the 16.x software)

https://techhub.hpe.com/eginfolib/Aruba/16.06/5200-4826a/index.html#s_Loop_protection.html

https://techhub.hpe.com/eginfolib/Aruba/16.06/5200-4826a/index.html#s_STP_loop_guard.html

 

 

On older stuff, one reading of the docs implies that loop protect is only for ports where bpdu protection is enabled (likely ports connected to end user devices, that should never be (but may accidentally become) connected to other switch ports)

https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=c02563813 (search for loop protect).

The inference that they are referring to edge ports only comes from in the examples they give ports 1-10 for loop protect, but for examples of configuring spanning tree they use ports like A1 (typically module ports or stacking ports).

[psydii]

The rate limiting setting remains a bit of a puzzle. I know when we had procuve experts in over a decade ago they set it on some but not all of our switches/ports; it seemed to depend on the specific model. When we had a bit of work done by an HP partner a few years ago, they agreed with how it had been done, but didn't suggest that setting on our new kit they were adding to the mix.