I took the time tonight to figure this out because it had been bugging me. I've found as long as I separate the management vlan from a ports native vlan everything works as expected. It's when both are on the same vlan that port security will still allow management access to the switch during Restrict and Protect violation modes. I used routing on a stick to facilitate and test the inter-vlan routing. I'm sure the same thing could be achieved via Layer 3 switching but I didn't test it.

Yeah I suspected it had to do with having everything on VLAN 1.

_________________
Regards,

Steven King
San Diego Cisco User Group - http://www.sdcug.com
"The only time something is impossible is when you think it is." - Kevin Corbin, CCIE #11577

Probably one of the reason Cisco recommends never to use VLAN1.

I've tested this scenario too using 2950s, but on VLAN192 - the switch's management interface is Vlan192 and the switch interface my offending NIC was connected to was in VLAN #192. Thus, it's not solely VLAN 1.

Yeah, as long as you separate the management vlan from a connecting switchports native access vlan all will be fine. It's when both the switchport and the management interface share the same native vlan that you effectively negate any Restrict and Protect port-security for devices physical connected to the switch.

I think it's cool, I love little unexpected results like this!

just keep in mind, real world results do not necessarily coincide with the correct answers on the exam.

I've skimmed the thread so apologies if I've missed the answer to this question but does the port security restriction affect management traffic passing through the switch? I'd sort of expect it to allow traffic heading to the switch control plane but I'd be a little puzzled if allowed traffic on a management VLAN to pass through the switch.

No need to apologize, I hate reading 5-6 pages just to get caught up!

As I tested it, this is the case: If the offending switchport is configured as Protect or Restrict and is on the same native (access) vlan as the management interface, once connected to the switch (ssh or telnet) offending device can pass traffic through the switch as if port security was not configured. The security violations counters will increment, but no port restrictions will actually be applied. I haven't tested this thoroughly, but from what I've seen I had no problems telneting into any other devices on my network or reaching my default gateway, name server, or using ICMP on outside ip addresses.

I think that answers your question, If I'm missing the point just hit me on the head..

Scott you realize you're testing a CCNP-level topic right? Kudos sir.

_________________
Regards,

Steven King
San Diego Cisco User Group - http://www.sdcug.com
"The only time something is impossible is when you think it is." - Kevin Corbin, CCIE #11577

Well, it didn't exactly start out that way. I was just trying to figure out why port-security wasn't functioning as expected..

I'm sorry but how is port-security restrict/protect/shutdown behavior CCNP-level? It's covered in ICND1?

It comes down to the level of testing done. Steven King was just commenting that Scott was taking it farther than CCNA is meant to. (perhaps the wording should be needs to)
For example Spanning Tree, I would think its covered in CCENT. Its also part of the CCIE. Does that make it a CCENT level if you need to test/troubleshoot STP in the CCIE test/lab?

You raise a good point, for some reason I've been trying to learn everything I absolutely can about a given topic. For instance, I'm currently learning spanning tree protocol at the moment and I've gone to the extent of reading the IEEE specifications so I can get a firm grasp on how it works. I guess my approach is over the top.

Well it all comes down to what your goal is.
I always prefer learning as much as I can about a subject.

But for certification purposes, lets say ccent or ccna in this case. Reading the IEE specifications, RFC's or whitepapers are outside the scope of the exam.

From a learning perspective only yourself can answer as to on what level you want to be.
Having a good grasp of something from the beginning can help you later on if you are thinking of studying more. Or if you get a job within networking.

I'm looking forward to testing this once I start putting my routing/switching lab together in the new year.

Yeah, I'm the same way (prefer to learn as much as I can about a subject). I currently work within networking and have found that by knowing how something works, rather than simply knowing how to configure/troubleshoot according to procedures, often works better.

I will be doing the same thing Halo. I just got so much stuff to do right now that I dont want to half @#$ my studies.

Jeez, I didn't mean it as some serious comment, more like a "more power to ya" for Scott for digging in depth into the concepts.

_________________
Regards,

Steven King
San Diego Cisco User Group - http://www.sdcug.com
"The only time something is impossible is when you think it is." - Kevin Corbin, CCIE #11577

Yes, I apologize, my post was possibly a little harsh.

Apology accepted.

/marks Joshua off the list of people to kill and puts on some lipstick

POP QUIZ! What movie is that from!?

_________________
Regards,

Steven King
San Diego Cisco User Group - http://www.sdcug.com
"The only time something is impossible is when you think it is." - Kevin Corbin, CCIE #11577