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 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?