Friday, May 29, 2009

Routing - Link State Protocols

Link State protocols differ from Distance-Vector protocols in several ways, but in a nutshell a link state protocol uses a different and complex mathematical formula to compute the best route to a given network based on the actual condition of the network (or rather, the "state of the link"). Where distance-vector protocols gather their information by obtaining all possible routes that their neighbours provide, link state protocols discover their neighbours and keep the information from them in a neighbour table. Their neighbours update the condition of the networks they have knowledge of, and each router then uses Dijkstra's "Shortest Path First" algorithm to compute the best route. An example of a link-state protocol is Open Shortest Path First, or OSPF, which is an industry standard protocol that can be used between any vendor's equipment.

LS protocols send out Link State Announcements, or LSA's when they first come on line, this alerts their neighbours that they exist and that there are networks connected to them. Because each router needs to update their own routing table based on the state of their neighbours, this is a very processor-intense operation. The nice thing about LS protocols is that this only happens when there is a change in the topology (contained in the topology table which holds all possible routes to all possible networks). The updates are sent in Link State Updates, or LSU's.
One reason that LS protocols are much faster to converge than Distance Vector protocols is that a link state protocol, when it receives an update of a change in topology via LSU, forwards that info out to all its neighbours even before updating its own topology table. Getting the info out takes precedence, so all routers know the condition of the network before bothering to change their own routing tables.

LS protocols also do not send out regular updates like distance vector protocols do. They only send out changes when they occur, so once the network is converged there is very little network management traffic. Routers only send out small LSA Hello packets to make sure everyone is still alive and well.

To keep routing tables manageable and link state calculation to a reasonable time frame, LS protocols are typically separated into sections, or Areas. These areas are connected to a single area (called a backbone area), and routers in each area only maintain a topology table for other routers in their area. Between these areas, routes are summarized to keep tables manageable.

I'll be looking more in-depth at the actual protocols and perhaps comparing and contrasting them a bit in the upcoming posts.

Thursday, May 28, 2009

Routing loops mitigated - Distance Vector Protocols

To keep your data from floating around in never-ending loops, there are a few methods used by Distance-Vector protocols to avoid looping. They are:

Hop Counts
When a routing protocol sends its routing table to its neighbors, it increases teh hop counts on connected routes by one each time. In the case of a network that is unavailable or looped, this could go on forever (a scenario known as "counting to infinity"). Maximum hop counts are the most basic of the mitigation methods for DV protocols. This way, once a hop count metric reaches the max value, the route is assumed as unavailable.

Maximum hop counts are:

RIP v1 and v2 15
EIGRP 224

Split-horizon
This one, simply stated is to not advertise a route out the same interface in which it came. If I tell you that I am connected to network 192.168.1.0/24, why would I tell you that 192.168.1.0/24 is one router away from me? First, you already know where it is, and because I increment the hop count, you would now think that 192.168.1.0/24 is *two* hops away from me.

Route Poisoning
When a link fails, the router to which it is attached sends out a routing update with a hop count that exceeds the maximum value for that protocol. So, if I have a router connected to 192.168.2.0/24, and the interface connected to that network fails, I send an update to my neighbors incrementing the hop count for that network to 16. Then all my neighbors know it is unavailable. Cool.

Poison Reverse
Poison reverse overrides the split-horizon rule and sends the route update back out the interface on which it came. This provides an acknowledgement that the device received the change to the topology.

Hold-down Timers
Simply stated, hold-down timers store an update for a given amount of time before adding the change to their routing table. The idea is that, should a link start going up and down rapidly (otherwise known as "flapping"), the link will come up before the timer expires and there is no need to change the routing table. If the timer expires and the router doesn't hear of a route with a lower metric, it adds the route to its table.

Triggered Updates
To speed convergence of the network, a triggered update allows a router to send an update in the event of a failed link instead of waiting for the regular update. This allows the network to react more quickly to topology changes.

Invalid/Dead Timers
When a device is removed from the network but doesn't fail, a triggered update isn't sent, so the remaining routers may think the device still exists. To combat this, when a router stops receiving updates from another router, after a certain amount of time the router is considered "dead" and the routes are invalid. The routes are then removed from the table. This method is also used in the case where a router stops receiving updates from a given routing protocol but is no longer. Perhaps we changed our topology and started to use EIGRP instead of RIP, and after that set amount of time the RIP-learned routes are considered invalid and removed.

Tomorrow, more routing protocols! I know you can hardly wait, Bear...

Routing Protocols review - metric

This morning I reviewed routing protocols again, which should be known but I want to make sure I'm absolutely clear on this since it is the foundation of routing.

After being clear on Administrative Distance yesterday, this morning I wanted to make sure I understood what was being described by "Metric," which is something you see in a route table when you execute a "show ip route" command. So for instance, you might get output that looks like:

R 172.17.0.0/16 [120/1] via 192.168.1.10, Serial0/0/0

This is telling us that the network 172.17.0.0/16 was learned using RIP, that its Administrative Distance is 120, the metric is 1, and that it came from 192.168.1.10 (the IP address of our neighbouring router) through the Serial 0/0/0 interface (on our router). Cool enough.

The Administrative Distance is the number that Cisco IOS uses to determine the most reliable route to the network with the lower AD being the more reliable. The *metric* is what the routing protocol uses to determine the best path to that network. So, if we learned about the 172.17.0.0/16 network through another interface, indicating we had multiple paths to that network, and that path was using RIP also, RIP would choose the path with the lowest metric and place that in the routing table. So, if RIP had another entry that looked like:

R 172.17.0.0/16 [120/3] via 192.168.1.129, Serial0/0/1

it would place the route with the lowest metric into the table and use it for any traffic destined for that network. It is then important to know how each routing protocol determines its metric - RIP uses "hop count," or a count of the number of networking devices between the source and the destination networks. Our first entry tells us that there is one router between source and destination, while the second tells us there are 3. Going through one stop theoretically is faster than going through 3, right?

So, that is what the metric is. Administrative Distance is used by IOS to determine the most reliable path based on routing protocol, and metric is used within a routing protocol to determine the most efficient path.

I probably could have just summarized that and saved 15 minutes of typing...

Wednesday, May 27, 2009

Routing - things I should have known

Funny how you go through life thinking that you know an awful lot, only to find out that you don't know nearly as much as you did, making you question everything you actually do know...

Anyhow, I was reading up on static routes for the CCNA tonight. Breezing over things, I saw something that I had never really considered before, though I instantly saw how this was going to help me do my job a little better.

I thought there was not much more to a static route entry than to specify the network you wanted to route to, the netmask and the IP address to send that traffic toward. For instance:

ip route 192.168.1.0 255.255.255.0 10.1.1.1

sends anything destined for the 192.168.1.0/24 network to an interface with IP address 10.1.1.1. Woo-hoo, right? Well, now I've learned about Floating Static Routes. By adding a parameter at the end of the ip route statement, you can set the administrative distance for the route than the default value of 1 for a statically-assigned route. So now our command becomes:

ip route 192.168.1.0 255.255.255.0 10.1.1.2 2

The "2" at the end of that statement makes this route slightly higher in administrative distance, and that route will not be added to the routing table unless the first route goes down. This is useful if you have multiple links to get to the same location, such as two different ISP's (multiple default routes) or multiple paths to your remote offices. So, along with that, let's run down the default administrative distances for ip routes in Cisco IOS:

Route type Administrative distance
==============================================
Connected interface 0
Static route 1
EIGRP summary 5
External BGP 20
Internal EIGRP 90
IGRP 100
OSPF 110
IS-IS 115
RIP (v1 and v2) 120
EGP 140
External EIGRP 170

When a router learns of the same destination through multiple routing protocols, it will choose the path with the lowest administrative distance.

Perhaps more later. I've been solidifying my understanding of the show ip route output today, also, but like I said...I feel like I should know this stuff already. Ah well, it's good to learn and better to know what the heck you're talking about should a client ask "What does that number mean there, after the IP address?"

Good night, all.

Tuesday, May 26, 2009

Studying again

I am preparing to take my CCNA (Cisco Certified Network Associate) in the next few weeks. I've been preparing for this for about 60 days now, and with summer coming up I'm feeling the pinch to do other things besides sitting in front of this computer with emulated routing and switching labs. But this needs to be completed soon, so I'll bear with it.

Right now I'm using a really excellent study tool called GNS3, and this is a real money saver. It's an emulation environment for Cisco IOS that runs actual IOS images as opposed to running simulated IOS. I found that, although some other router sims were quite good, they lacked in flexibility and completeness of the IOS command set. It is good to follow a canned lab, executing the required commands and nothing else. It's a whole other thing to set up a lab yourself and emulate a real-world environment. I have a number of labs created that I'm planning to put the finishing touches on and upload to GNS3-labs, which has been a really great tool for learning how to make GNS3 perform at its highest.

I'm in the final days of cramming, as I"ve already been thorough the majority of the material. I'm hoping to blog here about my topics of study to clarify what I'm learning for myself and perhaps to assist others in their own attempts. I find that there is a lot of material on the web pertaining to the CCIE, but not as much for the entry-level certs. (For that matter, I'd recommend not using Paul Browning's web site, book or racks. His material is lacking depth, his book is full of errors and his racks didn't function well. When I asked for a refund, he became condescending, insulting and childish. I'd be happy to show my correspondence with this unprofessional individual should anyone care to see it).

So, at any rate, on to the books and a little WAN theory tonight.