Ok, so we've all memorized what interior routing protocols are Link-State and which are distance vector, but what does that mean exactly?
Well, the biggest difference is the view of the network that each router has.
In a Distance Vector protocol, routers only see their neighboring routers, and only see the "distance" or cost passed to it from each "vector" or direction. In other words, a distance vector router sees a list of x routes with a cost on interface 1 and y routes with costs on interface 2.
Link-State protocols on the other hand use a bit more overhead and processing power. With a link state router, the entire (area or domain) topology is known by every router.
Picture it like this, Distance Vector is sitting at an intersection seeing the signs, turn left = 2000 miles to NY, Turn right = 1000 miles to portland, continue straight = 1700 miles to Dallas. All you have are distances and an arrow, you have no idea how straight or round-about the path may lead.
Link state is when you are looking at a map. You can see that turning left does indeed take you toward NY, but can see a slew of different roads and freeways that you can choose from. You make your own decision based on the entire topology of the road system.
The other difference between the two protocols is that link state sends advertisements only when a link changes, so if a router sees a link go up or down, it sends the changes.
Distance Vector sends regular announcements of it's paths and costs at a set time interval.
Wednesday, July 21, 2010
Wednesday, July 14, 2010
STP Topology Change Notifications
Q1. What is the purpose of spanning tree portfast?
A. Well, the noticeable part is from the client's view. Portfast means the port does not move through the listening and learning states (30 seconds) which can mean delayed, slow, and even missed startup scripts.
The (arguably) more important point is the affect on your network. Every time a port comes out of blocking and moves to listening, learning, and forwarding, a topology change has occured. The switch sends a Topology change notification to the root switch and EVERY switch in your STP topology will shorten their cam table aging time to the forward delay time (default 15 seconds). This means every device in your STP network that isn't very chatty will have their mac flushed from the switch and need to be relearned. So moral of the story, use portfast on every client port to prevent a whole lot of spanning tree traffic and cam table flushes.
Q2. So describe this Topology Change Notification Process
A. Ok, a port on a switch changes state (we are assuming it is not in portfast mode), so a link comes up or a forwarding port goes down. The switch immediately sends a Topology Change Notice (TCN) out it's root port. (unless the root port was the link that just went down, then the switch will sit and wait to hear from the root or attempt to make itself root) All switches that receive the TCN forward it toward the root.
Once the root receives the TCN, first it sends an acknowledment to the originating switch, then it creates a packet with the Topology Change Bit Set, to notify all switches that there has been a topology change. This is flooded to all switches in the topology. When each switch sees the packet with the topology change bit set, it will lower it's bridge table aging time to the forward delay timer and pass on the topology change packet down the tree. The cam table flush is because the changing topology can mean mac addresses will be appearing on new interfaces. The switches don't yet know how the topology has changed, just that they need to flush any unused mac addresses to prepare for a change.
Ports will go through their regular STP states to create a new topology if one is required.
Q3. When does a port come out of blocking state?
A. If no BPDU (bridge protocol data units, how switches communicate STP) arrives within the max age time, OR if a port receives a BPDU with a better root "cost".
Remember, If a port is not a root port or a designated port, it will be in blocking.
Q4. How often are BPDUs sent
A. By default, 2 seconds
A. Well, the noticeable part is from the client's view. Portfast means the port does not move through the listening and learning states (30 seconds) which can mean delayed, slow, and even missed startup scripts.
The (arguably) more important point is the affect on your network. Every time a port comes out of blocking and moves to listening, learning, and forwarding, a topology change has occured. The switch sends a Topology change notification to the root switch and EVERY switch in your STP topology will shorten their cam table aging time to the forward delay time (default 15 seconds). This means every device in your STP network that isn't very chatty will have their mac flushed from the switch and need to be relearned. So moral of the story, use portfast on every client port to prevent a whole lot of spanning tree traffic and cam table flushes.
Q2. So describe this Topology Change Notification Process
A. Ok, a port on a switch changes state (we are assuming it is not in portfast mode), so a link comes up or a forwarding port goes down. The switch immediately sends a Topology Change Notice (TCN) out it's root port. (unless the root port was the link that just went down, then the switch will sit and wait to hear from the root or attempt to make itself root) All switches that receive the TCN forward it toward the root.
Once the root receives the TCN, first it sends an acknowledment to the originating switch, then it creates a packet with the Topology Change Bit Set, to notify all switches that there has been a topology change. This is flooded to all switches in the topology. When each switch sees the packet with the topology change bit set, it will lower it's bridge table aging time to the forward delay timer and pass on the topology change packet down the tree. The cam table flush is because the changing topology can mean mac addresses will be appearing on new interfaces. The switches don't yet know how the topology has changed, just that they need to flush any unused mac addresses to prepare for a change.
Ports will go through their regular STP states to create a new topology if one is required.
Q3. When does a port come out of blocking state?
A. If no BPDU (bridge protocol data units, how switches communicate STP) arrives within the max age time, OR if a port receives a BPDU with a better root "cost".
Remember, If a port is not a root port or a designated port, it will be in blocking.
Q4. How often are BPDUs sent
A. By default, 2 seconds
Thursday, July 8, 2010
Follow the Moon Strategy
Learned a new term today: "follow the moon strategy".
The idea is that power consumption is, in many areas, cheaper at night/non-peak-usage times. So, you slide your virtual machines between datacenters every few hours all the way around the world to keep your power usage high only at "night".
To do this you need a good strategy to be able to keep an IP address moving all around the world between datacenters... (and the physical datacenters all around the world, not everyone has that!)
The idea is that power consumption is, in many areas, cheaper at night/non-peak-usage times. So, you slide your virtual machines between datacenters every few hours all the way around the world to keep your power usage high only at "night".
To do this you need a good strategy to be able to keep an IP address moving all around the world between datacenters... (and the physical datacenters all around the world, not everyone has that!)
Local Area Mobility
So networking companies have been trying to sell us ways to extend layer 2 networks for many years now, back in the days with brouters, Shortest Path First Switching, and even new technologies just out in the last few months such as TRILL and OTV. Now I haven't looked into the new technologies enough to give a thumbs up or down, but since everything in the past has had so many problems I am skeptical.
Looking into it a little though I run into an old gem from the mid 90s (the whitepaper talks about how the new windows 95, with a DHCP client installed, can automatically get an IP address!). Local Area Mobility. Now this may not scale well, but for the problem of a few servers needing to be in the same subnet but a different physical location it works great. In fact it is so simple it blew my mind that I had never heard about or thought of such a thing.
The key is simply that routers use the longest prefix to determine a route. Solution - Host routes.
Local Area Mobility, when turned on, will listen and when a computer is turned on with a statically set IP address that doesn't match the interface's subnet, the router injects a host route (/32) into the routing table. It will also proxy arp requests so that clients in the same subnet (but different router) can still communicate. User attempts to connect to the server's IP, router looks up and finds the /32 hostroute preferred over the /24 or whatever and the packet is properly sent to the server.
I don't know why but that is still blowing my mind how simple it is.
http://www.cisco.com/en/US/products/ps6590/products_white_paper09186a00800a3ca5.shtml
Looking into it a little though I run into an old gem from the mid 90s (the whitepaper talks about how the new windows 95, with a DHCP client installed, can automatically get an IP address!). Local Area Mobility. Now this may not scale well, but for the problem of a few servers needing to be in the same subnet but a different physical location it works great. In fact it is so simple it blew my mind that I had never heard about or thought of such a thing.
The key is simply that routers use the longest prefix to determine a route. Solution - Host routes.
Local Area Mobility, when turned on, will listen and when a computer is turned on with a statically set IP address that doesn't match the interface's subnet, the router injects a host route (/32) into the routing table. It will also proxy arp requests so that clients in the same subnet (but different router) can still communicate. User attempts to connect to the server's IP, router looks up and finds the /32 hostroute preferred over the /24 or whatever and the packet is properly sent to the server.
I don't know why but that is still blowing my mind how simple it is.
http://www.cisco.com/en/US/products/ps6590/products_white_paper09186a00800a3ca5.shtml
Wednesday, July 7, 2010
Petition for an educational IOS version
As cisco continues to tighten it's control over who can download what IOS, Etherealmind.com has started a petition to ask cisco for an "educational IOS" for study purposes. The educational IOS could possibly have performance crippling functions that would prevent it from being useful in a production environment, but would work perfect for home and test labs.
Click Here or browse to http://etherealmind.com/petition/ to view and sign the petition.
Click Here or browse to http://etherealmind.com/petition/ to view and sign the petition.
Subscribe to:
Posts (Atom)
