SGT CCIE » 3550 http://www.sgtccie.com/blog A man on a mission Sat, 20 Mar 2010 03:47:00 +0000 en hourly 1 http://wordpress.org/?v=3.0.1 My new CCIE rack http://www.sgtccie.com/blog/2010/02/my-new-ccie-rack/ http://www.sgtccie.com/blog/2010/02/my-new-ccie-rack/#comments Fri, 05 Feb 2010 22:35:09 +0000 Mike http://www.sgtccie.com/blog/?p=481 I’ve ordered all of the components for my CCIE rack. Here is what it will consist of:

  • (4) 3550′s
  • (3) 2611xm’s
  • (3) 3640′s (instead of 1841′s)
  • (1) 2522 (Frame switch)
  • (3) 2501′s (BB routers)
  • (1) 2511 (Terminal server)

If you’re familiar with Internetworkexpert’s topology, you’ll probably notice that you only really “need” two BB routers (the 2501′s). I purchased an extra simply as a backup, so I could expand the topology a little bit and have a wildcard in there if I chose to experiment a little more. All of the gear is going in a 24U rack, and I estimate I’ll have about 20U’s occupied with the gear above (plus PDU’s, and possibly a shelf).

Anyway, can’t wait for it to all arrive. In the meantime I have a lot of cleaning to do, and will be reorganizing my computer desk-area (which is no small feat!). I will post pics as the gear comes in!

]]> http://www.sgtccie.com/blog/2010/02/my-new-ccie-rack/feed/ 4 Command of the week: Switchport protected http://www.sgtccie.com/blog/2009/04/command-of-the-week-switchport-protected/ http://www.sgtccie.com/blog/2009/04/command-of-the-week-switchport-protected/#comments Thu, 23 Apr 2009 00:12:26 +0000 Mike http://www.sgtccie.com/blog/?p=183 I have done my share of work in the networking field, and had never heard of this command. I have also not been exposed to a wide variety of layer 2 technologies, but I must say, that this is a very cool command. Granted, it could be considered old- or not on par with private VLAN’s (which take the same idea of isolating particular ports a little bit further), but I like it’s simplicity. However, it IS available in older catalyst switches that may not support Private VLAN’s, so that is a bonus. Last but not least,  knowing how to configure PVLAN’s and protected ports, you can accomplish- to some degree- the same thing in two different ways- which is always a plus. This article will primarily function as a basic overview of the command, although I will briefly flyby the configuration as it is fairly straightforward. Let’s get to it. First, I’ll present you a scenario that will demonstrate what switchport protected does.

Let’s say you have a Cisco 3550 in a closet somewhere, and for whatever reason want two hosts coming off of that 3550 to have no traffic pass between them. Switchport protected will enable you to do just that. The idea is simple: Any protected port can not talk to any other protected port, but can talk with any unprotected port. The idea here is the same as private VLAN’s somewhat..just a more basic method. There’s a few caveats worth mentioning regarding protected ports:

  • The protection is only local to that switch. If you have User A on SW1, and User B on SW1, both on VLAN 100, configured with switchport protected..they will not talk. However, if you split the two users up on two switches that are trunking, but still within VLAN 100…they WILL talk. The protection does not span multiple switches!
  • The protection is limited to Layer 2. Once the frame becomes a packet at Layer 3, it will allow the two hosts to communicate.
  • To block traffic at Layer 3 also, you would need to look at ACL’s, or Vlan Access-lists, or other methods of access control.

So how do we configure a port to be protected? It’s cake. See below:

Switch(config)# interface fa0/1

Switch(config-if)# switchport protected

That is it! I know, almost a letdown, right? Well, the plus is, there’s more! Commonly when implementing protected ports, you will want to also block unknown unicast/multicast traffic. Why? Think about the basic nature of a switch when it receives an unknown unicast frame..it will flood it out all ports except the one it was received. This could introduce a possible avenue for attack. To mitigate this risk, we can block unknown unicast/multicasts on these ports by using the following configuration.

Switch(config-if)#switchport block {multicast | unicast}

That’s all there really is to it. I hope this short article has at least given you a small insight into small lesser-known features the Cisco IOS has to offer. I look forward to finding the next one to share with all of you!



]]> http://www.sgtccie.com/blog/2009/04/command-of-the-week-switchport-protected/feed/ 0