Potential Port Security bug in 3.3(5)

Here is an update on this issue: Apparently there is no bug and this is normal behavior for port-security. I would think that once you clear the violation, it should no longer show under “show port-security violations vsan xx”. However, it does. So how do you know what is currently in violation and what is not? You have to manually reconcile against the FLOGI database. This is no good. If you don’t see something FLOGI that you think should be in there, then you bounce the port and see if the “Repeat count” of “show port-security violations vsan xx” increments. To me, this is a pain. I wish I could just do a show command that will show me what is in violation. If I fix it, then this should no longer show. At the very least there should be a command to clear this table, which there is not!

I think I may be on to finding another bug in 3.3(5).  Here is the summary:

First we enable port security

port-security enable
port-security distribute
port-security database vsan 20
swwn 20:00:00:0d:ec:0e:b2:40 interface fc1/7
swwn 20:00:00:0d:ec:0e:b2:40 interface port-channel 1
swwn 20:00:00:0d:ec:10:05:40 interface port-channel 128
swwn 20:00:00:0d:ec:0f:8c:80 fwwn 20:07:00:0d:ec:0e:b2:40
swwn 20:00:00:0d:ec:0f:8c:80 fwwn 24:01:00:0d:ec:0e:b2:40
swwn 20:00:00:0d:ec:10:05:40 fwwn 20:0e:00:0d:ec:0e:b2:40
swwn 20:00:00:0d:ec:10:05:40 fwwn 24:02:00:0d:ec:0e:b2:40
swwn 20:00:00:0d:ec:0e:b2:40 fwwn 24:02:00:0d:ec:10:05:40
swwn 20:00:00:0d:ec:0e:b2:40 fwwn 20:03:00:0d:ec:10:05:40
swwn 20:00:00:0d:ec:0f:8c:80 fwwn 24:80:00:0d:ec:10:05:40
pwwn 21:00:00:04:cf:9c:d4:c3 fwwn 20:04:00:0d:ec:10:05:40
!      [J3A1]
pwwn 21:00:00:04:cf:9c:d5:6b fwwn 20:04:00:0d:ec:10:05:40
!      [J3A2]
pwwn 21:00:00:04:cf:9c:d5:74 fwwn 20:04:00:0d:ec:10:05:40
!      [J3A3]
pwwn 21:00:00:04:cf:9c:d4:e3 fwwn 20:04:00:0d:ec:10:05:40
!      [J3A4]
pwwn 21:00:00:04:cf:9c:d4:db fwwn 20:04:00:0d:ec:10:05:40
!      [J3A5]
pwwn 21:00:00:04:cf:9c:d5:6a fwwn 20:04:00:0d:ec:10:05:40
!      [J3A6]
pwwn 21:00:00:04:cf:83:d2:6c fwwn 20:05:00:0d:ec:10:05:40
!      [J4A1]
pwwn 21:00:00:20:37:fc:1f:42 fwwn 20:05:00:0d:ec:10:05:40
!      [J4A2]
pwwn 21:00:00:04:cf:4c:f9:aa fwwn 20:05:00:0d:ec:10:05:40
!      [J4A3]
pwwn 21:00:00:04:cf:7f:aa:15 fwwn 20:05:00:0d:ec:10:05:40
!      [J4A4]
pwwn 21:00:00:04:cf:22:80:3e fwwn 20:05:00:0d:ec:10:05:40
!      [J4A5]
pwwn 21:00:00:04:cf:96:a5:e3 fwwn 20:05:00:0d:ec:10:05:40
!      [J4A6]
port-security activate vsan 20 force
no port-security auto-learn vsan 20
port-security commit vsan 20

Two PWWN’s are not listed above, so they become in violation

MDS2# show port-security violations
——————————————————————————-
VSAN Interface        Logging-in Entity             Last-Time    [Repeat count]
——————————————————————————-
20   fc1/2            21:01:00:e0:8b:28:e5:af(pwwn) Jun 20 16:30:45 2010 [2]
20:00:00:e0:8b:08:e5:af(nwwn)
20   fc1/3            21:00:00:e0:8b:03:52:23(pwwn) Jun 20 16:30:54 2010 [1]
20:01:00:e0:8b:23:52:23(nwwn)
[Total 2 entries]

Ok, so no problem, we add these to the database

MDS2(config)# port-security database vsan 20
MDS2(config-port-security)# pwwn 21:01:00:e0:8b:28:e5:af interface fc1/2
MDS2(config-port-security)# pwwn 21:00:00:e0:8b:03:52:23 interface fc1/3
MDS2(config-port-security)# exit
MDS2(config)# port-security activate vsan 20 force no-auto-learn
MDS2(config)# port-security commit vsan 20

We “no shut” the interfaces as per the documentation

MDS2(config)# int fc1/2
MDS2(config-if)# no shut
MDS2(config-if)# int fc1/3
MDS2(config-if)# no shut
MDS2(config-if)# exit
MDS2(config)# exit

Port still shows in violation!!!!


MDS2# show port-security violations
——————————————————————————-
VSAN Interface        Logging-in Entity             Last-Time    [Repeat count]
——————————————————————————-
20   fc1/2            21:01:00:e0:8b:28:e5:af(pwwn) Jun 20 16:30:45 2010 [2]
20:00:00:e0:8b:08:e5:af(nwwn)
20   fc1/3            21:00:00:e0:8b:03:52:23(pwwn) Jun 20 16:30:54 2010 [1]
20:01:00:e0:8b:23:52:23(nwwn)
[Total 2 entries]
MDS2# show flogi data vsan 20
No flogi sessions found.

Active database clearly shows the port is in the database, so should not be blocked

MDS2# show port-security database active vsan 20
——————————————————————————–
VSAN Logging-in Entity             Logging-in Point       (Interface)     Learnt
——————————————————————————–
20   21:01:00:e0:8b:28:e5:af(pwwn) 20:02:00:0d:ec:0f:8c:80(fc1/2)*
20   21:00:00:e0:8b:03:52:23(pwwn) 20:03:00:0d:ec:0f:8c:80(fc1/3)*
20   20:00:00:0d:ec:0e:b2:40(swwn) 20:07:00:0d:ec:0f:8c:80(fc1/7)*
20   20:00:00:0d:ec:0e:b2:40(swwn) 24:01:00:0d:ec:0f:8c:80(port-channel 1)*
20   20:00:00:0d:ec:10:05:40(swwn) 24:80:00:0d:ec:0f:8c:80(port-channel 128)*
20   20:00:00:0d:ec:0f:8c:80(swwn) 20:07:00:0d:ec:0e:b2:40*
20   20:00:00:0d:ec:0f:8c:80(swwn) 24:01:00:0d:ec:0e:b2:40*
20   20:00:00:0d:ec:10:05:40(swwn) 20:0e:00:0d:ec:0e:b2:40*
20   20:00:00:0d:ec:10:05:40(swwn) 24:02:00:0d:ec:0e:b2:40*
20   20:00:00:0d:ec:0e:b2:40(swwn) 24:02:00:0d:ec:10:05:40*
20   20:00:00:0d:ec:0e:b2:40(swwn) 20:03:00:0d:ec:10:05:40*
20   20:00:00:0d:ec:0f:8c:80(swwn) 24:80:00:0d:ec:10:05:40*
20   21:00:00:04:cf:9c:d4:c3(pwwn) 20:04:00:0d:ec:10:05:40*
20   21:00:00:04:cf:9c:d5:6b(pwwn) 20:04:00:0d:ec:10:05:40*
20   21:00:00:04:cf:9c:d5:74(pwwn) 20:04:00:0d:ec:10:05:40*
20   21:00:00:04:cf:9c:d4:e3(pwwn) 20:04:00:0d:ec:10:05:40*
20   21:00:00:04:cf:9c:d4:db(pwwn) 20:04:00:0d:ec:10:05:40*
20   21:00:00:04:cf:9c:d5:6a(pwwn) 20:04:00:0d:ec:10:05:40*
20   21:00:00:04:cf:83:d2:6c(pwwn) 20:05:00:0d:ec:10:05:40*
20   21:00:00:20:37:fc:1f:42(pwwn) 20:05:00:0d:ec:10:05:40*
20   21:00:00:04:cf:4c:f9:aa(pwwn) 20:05:00:0d:ec:10:05:40*
20   21:00:00:04:cf:7f:aa:15(pwwn) 20:05:00:0d:ec:10:05:40*
20   21:00:00:04:cf:22:80:3e(pwwn) 20:05:00:0d:ec:10:05:40*
20   21:00:00:04:cf:96:a5:e3(pwwn) 20:05:00:0d:ec:10:05:40*
[Total 24 entries]

So it looks like a bug to me.  Once I have the info for sure I will post the bug ID or resolution.  Really not liking some of these issues I am running into with 3.3(5).

This entry was posted in CCIE Storage, Port Security and tagged , , , . Bookmark the permalink.

4 Responses to Potential Port Security bug in 3.3(5)

Leave a Reply