Category Archives: Cisco tech

Layer 2 Tech labs/VTP Version propagation

Posted by on September 17, 2011 No comments

On page 96/156 of INE Vol I labs. Flying through them so far. I am moving through them fast because I’ve worked hands on with a lot of the topics so far. If I don’t understand something, though- I take the time to stop and understand it before moving on. Here’s an interesting tidbit on VTP I learned.

-If you have a network (for simplicity, we’ll say two switches, directly connected by one link) running VTP, with a client-server model (versus transparent mode), the mode of the server will be sent in VTP messages, and the receiving client will change their respective mode (IF the version is 1 OR 2; 3 does not do this)

Of course, I have to prove this:

Here’s our root SW, standard config pretty much.

SW1#show vtp status
VTP Version capable                 : 1 to 3
VTP version running                 : 1
VTP Domain Name                     : CISCO
VTP Operating Mode                  : Server
Maximum VLANs supported locally     : 1005
Number of existing VLANs            : 13
Configuration Revision              : 26

Then we have our SW2 (Transparent mode). This is just to show the current version:

SW2#sh vtp status
VTP Version capable               : 1 to 3
VTP version running               : 2
VTP Domain Name                   : CISCO
VTP Operating Mode                : Transparent
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 13
Configuration Revision            : 0

Now, I’ll change SW2 to a client with a “vtp mode client” – and here is the output from SW2 proving that it is now following suit with the VTP server, and using the version it is using (VTP ver 1 now):

SW2#sh vtp status
VTP Version capable               : 1 to 3
VTP version running               : 1
VTP Domain Name                   : CISCO
VTP Operating Mode                : Client
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 13
Configuration Revision            : 26

 

There we go! Pretty nifty.

HSRP Version 1 vs Version 2

Posted by on September 3, 2011 No comments

So, call me stupid, but I always thought HSRP version 2 was the default. Apparently, according to Cisco- Version 1 is the default. What’s the difference? According to Cisco:

  • Version 1 multicasts hello’s to 224.0.0.2, Version 2 multicasts hello’s to 224.0.0.102 to allow CGMP to function properly- the new addresses allows CGMP leave processing to function without interference. 

Additionally Version 2 addresses the shortfalls of Version 1, such as:

-HSRP version 2 advertises and learns millisecond timer values (version 1 does not)

-Group numbers are restricted to the range from 0 to 255. HSRP version 2 expands the group number range from 0 to 4095.

-With HSRP version 1, there is no method to identify from HSRP active hello messages which physical router sent the message because the source MAC address is the HSRP virtual MAC address. The HSRP version 2 packet format includes a 6-byte identifier field that is used to uniquely identify the sender of the message. Typically, this field is populated with the interface MAC address.

If you want to change to HSRP version 2, it’s cake:

RouterA(config-if)#standby version 2

That’s it!

STP: Port ID’s..making sense of it all.

Posted by on March 1, 2010 2 comments

I won’t lie, when I understood the STP tiebreaker process, it was one of those “ohhhhhh” moments. And by understand, I mean, actually proved and saw it work firsthand. Here’s the deal, and I’ll explain any highlights of little things that I found may be confusing for others. First, some key notes about STP and root port selection:


STP Root port selection (and tiebreaker) process notes:

  • There’s 2 ports per segment..a designated port (closest to the root switch), and a root port. The designated port sends out BPDU’s on the segment as it receives them (in 802.1D)..the root port does not send out any BPDU’s with the exception of TCN BPDU’s..another time, another place.

When a switch is trying to decide between two ports in regards to root port selection, it has a few tiebreakers it tries:

  • Lowest Root BID (should be the same)
  • Lowest Root Path cost (remember, this is root PATH cost..not just the local configured cost)
  • Lowest sending BID (BID = Priority + MAC address, so even if the priorities are the default 32,768, the lowest MAC will win)
  • Lowest Port ID..NOT just lowest port number. Port ID is a 16 bit field composed of two subfields, Port priority, and Port number. By default, Port ID would be something such as 0×8001 for Port 1/1. 0×80 in hex = 128 (default port priority). 01 equals 1, which is the last section of the interface number. So, by default, with dual links to the same switch, lowest PORT NUMBER wins, but that’s only a part of the Port ID. The other part is priority, which if configured, will cause a sway in the decision process.

So a general rule of thumb could be developed:

-When two separate paths exist to separate bridges, with the same root path cost..the lowest MAC wins by default. Configuring a lower priority on the non-designated switch (the “loser”) would change this, and cause it to become the designated bridge. If multiple redundant links are in place, this will break down further and not only choose a designated SW with the lowest MAC, it will use the interface with the lowest port number.

-When dual links exist to the same bridge, lowest port number wins. Best way to influence this (IMO) is simply adjust STP port cost on a per-interface basis.

Key point to take away: It’s so important to remember that BPDU’s are sent out the designated port as they are received. Knowing this, you know that a downstream (away from the root) switch is making it’s decisions based on RECEIVED information, with some minor exceptions such as cost (assuming that the locally configured cost affects the root path cost enough to make a difference).

 

 

Cisco puts out iPhone security app

Posted by on November 24, 2009 No comments

Article by Austin Modine from San Francisco.

Cisco has pushed out a new iPhone app that helps IT managers respond to newly-detected security threats by the seat (pocket) of their pants.

The Cisco SIO To Go iPhone application beams in data from the company’s Security Intelligence Operations (SIO) to show a customizable menagerie of security information that could potentially help defend a business network.

At hand are real-time alerts and threat mitigation solutions which come from sources that include more than 700,000 Cisco security devices, the company’s historical threat database, 3,300 IPS signatures, and over 600 third-party threat-intelligence sources, Cisco said.

The app also has the ability to check a site or server’s “reputation” powered by IronPort — which shows if it’s been attacked by a virus over the past 24 hours.

It also includes links to Cisco’s security blog, press releases, and Twitter feeds if that’s your bag.

While the iPhone isn’t known for its enterprise-ready prowess, clearly folks are hooking into businesses with their fancy App shwag anyway. Cisco playing along with an iPhone app is a pretty good indication how common it is inside corporations.

The Cisco app is available now. At the iTunes store, naturally. ®

(Article has been reposted from theregister.co.uk. You can view the original article here)

_____________________________________________________

This is great! As a former blackberry lover turned iphone fanatic- this is awesome news. It shows that the iPhone is surely taking a foothold in the corporate IT sector. The only problem now, is how do we secure a device used to secure other devices?

Changes to CCIE R&S exam, Ver 4.0!

Posted by on May 6, 2009 No comments

Alright folks, Cisco has finally announced the changes to the CCIE R&S track. Among those are a new 2 hour troubleshooting section at the beginning of the lab, plus the addition of MPLS and VPN technologies. For more information, see https://cisco.hosted.jivesoftware.com/docs/DOC-4605