Interesting idea.... but I don't like the idea of people being able to access the management plane either if I've implemented Port Security.

_________________
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

Now this is taking from cisco and its for the command switchport protected.(I know its not the same) Its a similar behavior.
A protected port does not forward any traffic (unicast, multicast, or broadcast) to any other port that is also a protected port. Data traffic cannot be forwarded between protected ports at Layer 2; only control traffic, such as PIM packets, is forwarded because these packets are processed by the CPU and forwarded in software. All data traffic passing between protected ports must be forwarded through a Layer 3 device.



I agree, makes you think a bit more about securing your control pane. But you should already have ACL's in place for the vty's.
But with that said I don't use vlan 1 and I use dedicated VLANs for management. So It shouldn't become an issue unless I inherit an existing network. (which does happen)

Wouldn't using any Vlan as your management interface cause the same issue? Not just Vlan1? Are you saying the only real way to protect the management interface of a switch is to apply an ACL on the interfaces? I'm not following. This "plane" talk is over my skill set.. I'm only on the ICND1

not to confuse things, it's never so easy, as you advance you'll understand, alot of the way things really work is very simplified for the beginner.

as a side note: The router/switch is typically segmented into three planes, each with a clearly identified objective. The dataplane allows the ability to forward packets; the control plane allows the ability to route data correctly; and the management plane allows the ability to manage network elements.

So... what? How does someone prevent a directly connected device from reaching a switches management interface? Change the default vlan1 management interface to a different vlan like 99? I'm strait up lost in what you guys are talking about..

Yes, from what I've been reading in my CCNP studies, best practices would be to have a separate VLAN for data, voice, management, and native.

I think it's an inherent problem with the port security command itself.

From what I know, once enabled (and in protect or restrict mode NOT shutdown) it acts like a poorly written ACL - kinda like access-group 101 out attached to the VLAN interface itself. It will drop all traffic destined for any other IP address outside of the port it's connected to. But because the port is a part of the VLAN AND the VLAN has a management IP, it will be able to talk only to the VLAN's management IP.

I've heard from places that not even Cisco recommends using protect or restrict.

huh?

_________________
http://blog.alwaysthenetwork.com

sorry vito... I read through the first could of pages when you guys were specifically talking about the port-security command. I was only responding to the first couple of pages of the discussion.

I get what you were talking about. The "huh?" still stands.

I'm not sure what you're saying.

_________________
http://blog.alwaysthenetwork.com

huh from me too

port security has nothing to do with IP addresses

_________________
www.mellowd.co.uk/ccie/

Check this out:

http://www.cisco.com/en/US/docs/switche ... t_sec.html

Pay close attention to how they define the different violation modes.

You're talking about IPs and management SVIs. That's my "huh". Basically, all port security does it drop frames from MACs that aren't authorized on the port. When it's configured to shutdown, it doesn't just drop, it puts the port into err-disable.

_________________
http://blog.alwaysthenetwork.com

I don't disagree with what's written. I'm studying for my CCNA Security right now in fact so I understand what protect and restrict are supposed to do.

I was only trying to logically explain what could be happening behind the scene's within the IOS pertaining to what scottsee is explaining.

From Cisco :



so in essence, the frame with an invalid source MAC should be dropped once it hits the port no questions asked, but scottsee is saying that protect and restrict are only working if he tries a destination other than the management IP of the VLAN associated to the port...



so what I trying to do was create an analogy based on his findings:



...which should produce the same results as what he's explaining.

I could be wrong, I'm not contesting that. But it just made sense to me

What scott is seeing is wrong.

And I think I'm still confused about your analogy. A deny all ACL applied to an SVI (on and L3 switch - important distinction) in the outbound will block all traffic OUT to hosts in the respective VLAN. I'm not sure how you're making the connection between that and this.

_________________
http://blog.alwaysthenetwork.com

What you want to do is put management interface in a VLAN other than the one that is used by regular users.
So for example put regular user traffic on VLAN 10 and management SVI on VLAN 999. Going further if its a L2 switch it doesn't need a SVI for VLAN 10 so there is no way regular users can interact with the switch. If its a L3 switch that your using as a default gateway for VLAN 10 you can then put a ACL incoming on SVI VLAN 10 to block access to VLAN 999 subnet.
Then in a production environment you would also put ACL's on the VTY lines and on snmp polls. If supported you can also enable ssh and disable telnet. Same with https and http if your using it.
This related to the management plane. cisco link

Then there is the control plane. Here you can create ACL's and service policy to rate limit traffic and/or block certain ports for the host (router) forwarding etc.
cisco link2

Also the point about not using VLAN 1 is that the only place you want there to be untagged L2 traffic is on the access ports. Its best practice to disable it and use other VLAN's.
The interface command for native VLAN comes into play if you have a trunk, and want to put any untagged traffic into a VLAN. For example have a trunk towards an IP phone which is then connected to a PC. Traffic from the IP phone should come tagged, but traffic from the PC will probably come in untagged. So the native vlan command will put the PC traffic in the correct PC VLAN.

@Scott: I guess we kinda got a little sidetracked from your OP, but since we(I) you got confused I thought I'd try to clear it up for you.

Ok, so I tested this on my 2950T.. not so sure I really need to test this on my other switches.

Here's my lab at home:


Now, when I did as Scott did, I got the very same thing.

I secured the port that 10.1.1.200 was on with a MAC address of 2222.2222.2222. Then:
1. Ping from 10.1.1.200 to 10.1.1.103; succeeded; saw psecure violations
2. Ping from 10.1.1.200 to 10.1.1.101; unsuccessful; saw psecure violations
3. Telnet from 10.1.1.200 to 10.1.1.103; successful; saw psecure violations
4. Once inside that terminal session, I could successfully telnet into 10.1.1.101 (Core Switch) even though I was still seeing psecure violations! I kind of suspected this though since I'm originating the new telnet session technically from 10.1.1.103.

That's pretty scary. Guess that's why you should use an ACL.

I also learned a bug. If you're configuring port security, you may get an error when entering a MAC address (In my case, 1111.2222.3333), saying that an internal error occured. Turns out if you use 2222.2222.2222 or something more like a real MAC address it's fine. Just a bug with using 1111.2222.3333

_________________
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

and?

_________________
http://blog.alwaysthenetwork.com

Sorry was testing the picture out, I added the rest afterward

_________________
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

hmm

_________________
http://blog.alwaysthenetwork.com

I'm trying to test out using another VLAN as the native rather than VLAN 1... but I'm running into some trouble with my limited experience... I'll let you know what I find out once I can get this set up correctly.

_________________
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