We are working on getting notifications for ports that go into a BPDU state when a loop happens. And once again the newer EX-2300 switches are causing issues. (I really hate how inconsistent these switches are.)
So we have a trap receiver set up and we are sending BPDU traps to it. What we can NOT find is how to tell an EX-2300 to send a trap when a port comes out of a BPDU state and is back up and running correctly.
So to further clarify. On a EX-2200 or EX-3300 you need to tell the switch to send a trap based on:
set event-options policy snmptrap events ESWD_BPDU_BLOCK_ERROR_DISABLEDset event-options policy snmptrap events ESWD_BPDU_BLOCK_ERROR_ENABLEDset event-options policy snmptrap then raise-trap
(There is more to the config than the above but in general those are the settings needed for the trap.)
So the "DISABLED" is a port going into a blocked state and the "ENABLED" is it coming out (and yes, it still can go right back into a blocked state if the loop still exists). All of this works as it should and has an expected outcome. We get the traps correctly sent to the trap server.
Our problem comes in with an EX-2300. So to monitor a port getting blocked by a loop:
set event-options policy snmptrap events "L2CPD_RECEIVE_BPDU_BLOCK_ENABLED: BPDU_PROTECT"
The above works sending the trap for a port going into a blocking state. What we can't find is the correct event-options policy to send a trap when it comes out of a blocking state.
From what we've read the documentation all points to the same web pages for doing this for either type of EX switch... none seem to show an ELS level switch and sending an SMMP trap message for it coming out of a blocked state.
From the messages logs you get:
Oct 21 08:25:59 cl2ntt18 l2cpd: L2CPD_RECEIVE_BPDU_BLOCK_ENABLED: BPDU_PROTECT: Interface ge-0/0/35 is DOWN: BPDU error detectedOct 21 08:25:59 cl2ntt18 l2cpd: L2CPD_RECEIVE_BPDU_BLOCK_ENABLED: BPDU_PROTECT: Interface ge-0/0/34 is DOWN: BPDU error detectedOct 21 08:26:59 cl2ntt18 l2cpd: BPDU_PROTECT: Interface ge-0/0/35 is UP: BPDU error ClearedOct 21 08:26:59 cl2ntt18 l2cpd: BPDU_PROTECT: Interface ge-0/0/34 is UP: BPDU error Cleared
But trying (we've tried a bunch of variations of the above in the policy - none have worked):
set event-options policy snmptrap events BPDU_PROTECT
Is NOT enough to have the trap sent to the trap receiver.
Any idea how to get an EX-2300 to send a trap message when a port comes out of a BPDU blocking state?
Just as an idea, try this one
You will need to correlate the even with UP event.
I also found this one is very helpful
Interesting... I'll have to look at these a bit more closely. But I'm not sure you can correlate it with an UP event(?). There's no guarantee that port(s) you are looking for will come back up to an active link state. I originally was thinking of looking for a link on the port with no corresponding BPDU down message to follow... but that logic fails if the loop is simply removed.
(Or I need to read the referenced web pages much more closely. Which I do plan to do.)
We did end up opening a TAC case for this although that is going rather slowly and still don't have a solution yet. It really feels to me that it is something that was missed and needs to be put back in place....(?) Hopefully the TAC case sheds some light on this.
We also have found the same behavior on a EX 3400 switch. It sends the trap for port down but nothing when it comes backup.
Thanks for the reply.
I see the point.
You can also look on this one:
You need to have sort of "BPDU related event" will it be UP or clear - so you need to trigger based on the match.
For sure there is a different direction
so you can think to convert all this into an OP script +/or event script.
Using Nonstandard System Log Messages to Trigger an Event Policy
Looks promising. I'll have to try that since I do know what the log message looks like. I should be able to get that to work.
But I still question why the Trap doesn't seem to be there in the first place... similar to the 2200 and 3300: ESWD_BPDU_BLOCK_ERROR_DISABLED
It feels like the 2300 and 3400 should also have something similar. I guess we'll see what TAC says.
Or at least an explanation as to why it's not there.