Any implication of having slpp-guard on NNI port (from auto-sense)

[MaxHibbin]

Currently our ZTP+ just applies auto-sense to all ports, however we want to deploy slpp-guard to all ports during ZTP+ onboarding as well. Thinking about NNI links, we have up to now enjoyed the flexibility that an auto-sense port can be used as an NNI link without any further configuration, but I did see in best practice guide not to put slpp-guard on NNI links, so in our case would we have to manually config NNI links? What are the implications of having slpp-guard on an NNI links, I presume the link disable itself if slpp packet is received, how likely is that if every access port also has slpp-guard on it? Seeing in another post the slpp packets "sent in the C-VLAN and encapsulated in the B-VLAN", so does this insulate the NNI from actually "receiving" slpp packet?

[RobertD1]

The best practices do say not to use slpp-guard on NNI links. It is not possible to enable it on a port with slpp packet-rx on it also. I believe the slpp packets get generated from the cores and slpp-guard is used at the edge to detect the loop and disable as close to the loop as possible and not to take down any important inter-switch links that would impact a lot more. That can still happen of course and sometimes both sides can go down at once as well. Not seen it used on NNI links myself.

https://extreme-networks.my.site.com/ExtrArticleDetail?an=000083496

[gfriedl]

As you already mentioned: SLPP frames across NNI links are encapsulated and could not reach the CPU to react on them; at least unless you are not going to add other than the BVLANs to NNI ports (which is impossible per default boot flag setting).