Usual disclaimer: this post links to code you'd better don't use if you don't understand it. It has been tested in exos virtual to the best of my and Claude Code's abilities.
I've been delivering a training to customer deploying a Spine and Leaf MLAG based architecture. one of the topics we discuss is preventing accidental loops in the network. Obviously we discuss ELRP, SLPP-guard and BPDU-guard.
I was surprised not to find a ELRP-guard configuration so the blocking action always falls down to the ELRP - emitter.
So I roughly summarized to my attendees that the aim of these techniques is to create a hard demarcation between access where chaos reigns, and you must protect yourself from any connection, and the core of the network where they have absolute control of what, how and when something is connected there.
One of them replied why we don't just block any switch connection at the access? Well, to some degree that's what bpdu-guard does. but bpdu guard needs an active stp, proper assignement of ports to stp config, edge port configured, it is not a on/off switch like SLPP-guard.
We had discussed ACLs a minute ago, and he said why not use an ACL?, and I had to shut it down, it's not that simple. Doable: a meter shutting down the port, a log and then a script linked to the log, but in the end you're better off with bpdu-guard...
I went home thinking about it, with the weird feeling that I was missing something. Indeed, I was. ACL was a bunch of work initially, but then, all ports could be enabled at will with a single line.
Not just that, you could tweak the ACL to detect a switch not just using STP, actually, you could use any protocol you could identify, e.g. trigger it by any proprietary crap that Cisco throws at you.
Taking it a bit longer, I wanted to see if we can create something like an 'package' that can be devalop and built for EXOS, you just move your files to the switch, execute a load script install.xsf and then enable the feature on the port you need with a load script edge_guard port 1-24.
That is how the edge_guard was born.
So everything seems to work, just copy the files pol, xsf and py to a switch and execute install.xsf to create all required configs, after that just load script edge_guard.py enable port <list> and anything that can be a risk like a elrp packet coming through an unexpected port or a bpu, vtp or pvstp+ will trigger a port shutdown.
Nothing is secret, just reading the manual and claude code performing all the coding/testing in virtual exos (that is why there are two versions of the ACL policy, one acl verb was accepted but it had no effect in virtual and I don't have hw available to verify). If you feel like commenting, please let me know your thoughts.
https://github.com/salva-ferrer/ExtremeNetworks/tree/main/edge-guard-exos
regards
salva
PD: Of course, there might be better ways of achieving what I describe above, but the point was testing a concept: how far can we stretch an EXOS config when the limit is not "that's too hard to code in the CLI, ramifications are endless", instead we have unlimited test cpu with GNS3 and unlimited testing time because Claude Code has no sense of how long this is going to take to write and test.
