Generating traffic from a router

I was looking how to do this to test a monitoring system using GNS 3, and came across this little gem

http://etherealmind.com/the-poor-mans-ios-traffic-generator/

nothing fancy just enabling the small TCP servers (#service tcp-small-servers), but a nice simple way to push some data across a link between two routers. The article also mentions some other methods so will be looking in to them as well.

Always nice to be able to test some things with out having to fire up servers or other hard/soft ware 🙂

CCNP ROUTE (Part 3 Route Protocol Types)

Although there are various routing protocols around such as RIP, OSPF, IS-IS, EIGRP and BGP. They all fall in to one of two groups, either the call of routing protocols labelled Link-state, or those labelled Distant-Vector.

The fundamental difference is that a Link-State route builds up a complete topology map of all the routers in its network segment, and how they are all linked together.  This map is built up be each router sending its own topology to every other router in its segment. This is achieved by each router sending its topology to its connected neighbour, these then check if it is newer than the current stored, and if so add it to there own topology and then forward it out to there neighbours, this way every router in the segment will receive the update. The routers then combines all the received individual topologies to create an over all map of the network. An algorithm is then run on this map by each router to determine the best paths to all the destination  networks advertised and these are added to the routing table that will be used to forward traffic. If an update is received that causes a change to the map topology then the algorithm has to be re-run to update the tables. If two routers in the segment send conflicting information about a link (eg Router A reports a link to route B but Router B does not report this link. Then when Router C receive the topology’s from A and B it will not add this possible link to its topology).

Distant-Vector protocols work in a different way. Rather than know the entire topology of the network segment. Routers only advertise if they can reach a network and the cost to reach it. Generally this cost will be higher for links that are slow and have multiply hops. and low for higher bandwidth links with less hops. Each router will updates its neighbours with the list of networks it can reach and how much it cost to reach each one. The receiving router will  place all this information, from all its neighbours in to a table and pick out (by default) the route with the best cost to each destination network to add to the routing table.

So which is best then?

Well they both have there strengths and weaknesses.

Re-convergence speed after a topology change would generally go to Link-state, most distant-vector protocols don’t remember the back up links so have to relearn them becfore they can forward data again. A link-state know the entire topology, so when a link fails it can re-run the algorithm to find a new best path.

However resources wise Link-state are very costly, to keep the topology map in memory and to run the algorithm across it means high CPU and memory usage. This means they don’t scale well to very large network, CISCO recommend a maximum of 90-100 routers and 200 subnets in a single OSPF area. More than this and the size of the topology map and time need to run the algorithm could slow the routers to a crawl. On the other hand Distant-vector do scale much better, routers only communicate with there direct neighbour and only need to know the destination network address, next-hop and cost. This is why you will find Distant-vector used for the internet backbone routers that need to deal with large routing tables and constant topology changes, while you find the link-state protocols inside company networks.

One more advantage link-state has over distant-vector is that due to the fact it has a complete topology there is little danger of loops. While for distant-vector this is a very real problem and one that needs checks to be introduce to insure against.

So the chose of what one to to use really does very much depend on the situation. In every day networks there are 5 well known protocols in use

Distant-vector = RIP, EIGRP, BGP

Link-state = OSPF, IS-IS

Of these EIGRP, OSPF and BGP are the most common. BGP is an external protocol (realy the only main stream one) used between the core internet service providers, so as I mentions most of the internet is run using distant-vector. EIGRP is highly optimised distant-vector protocols and has many of the benifits of link-state with out the huge CPU and memory cost, however its main issue is that is it CISCO proprietary so unless you have 100% CISCO devices it is ruled out. Leaving OSPF as the remaining protocol to run in internal networks. For many people in small to medium size networks the benefits gained from running OSPF or EIGRP are small and often come down to personal choice. The consistency and reliability of Link-state or the simplicity and low resources of Distant-vector?

Further Reading

Distance Vector Routing Protocols

Link State Routing Protocols

Well thats the review stuff out of the way, next time we can get in to the workings of EIGRP.

DevilWAH

CCNP ROUTE (Part 2, General Routing)

OK so what is this routing thing all about?

Well it seems to me there are two parts to routing, the actual physical routing of data across networks, and the methods in which the network devices keep track of where these route are (the routing protocols). Although there are several different routing protocols in use, they all have the same basic function, to allow routers to share the information of possible paths through the network between each other. Which in turn allows the indivual routers to build up routing tables which they can then use to look up the destination IP address in a packet and determine the next router (hop) to which the packet must be sent.

So what about this routing table? what does it look like and what does it contain?

router# <strong>show ip route</strong>

171.68.0.0/24 is subnetted, 3 subnets
S       171.68.1.0 [1/0] via 171.68.192.201
S       171.68.16.0 [1/0] via 172.16.191.254
C       171.68.192.0 is directly connected, FastEthernet0/0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
S       172.16.88.0/24 [1/0] via 172.16.191.254
C       172.16.191.252/30 is directly connected, Serial2/0
D    192.168.80.0/24 [90/156160] via 171.68.192.201, 00:00:07, FastEthernet0/0
D    192.168.90.0/24 [90/156160] via 171.68.192.201, 00:00:08, FastEthernet0/0
S   0.0.0.0/0 [1/0] via 10.1.1.3

From this output we can see how the routing table functions. Each network/subnet that the router has learnt about there is an entry telling the router where to send a packet that is destined to that network. This destination can be either the IP address of the next router in the path, or the outgoing interface ID. There is also a priority given to each entry for deciding entry to use if a route is added twice due to multiply paths to the same destination network.

The three methods that can add entries to the routing table are , Connected networks (added automatically), statically added routes, and routes learnt through routing protocols. In terms of default priority’s, Connected bet Static which in turn bet those learnt through protocols (where in general from highest to lowest we have BGP, EIGRP, OSPF, IS-IS and RIP). The last entry in the table above is a special case static entry, often know as the “default route” this route of “0.0.0.0 0.0.0.0” will catch any packet that does not match any other entry in to the routing table and forward it to a next hop address. This is commonly used to route packets destined to the internet, so rather than you company router needing to learn the router to every address on the internet, it only knows about internal company address. Anything else is caught with by the default route and passed to the ISP to deal with. This drastically cuts down the size of routing tables and is what allows the internet to function.

However once added the function is the same, as packets enter the router the destination address will be read and checked against the routing table to determine the next step, and then forward the packet out the destination interface. Now although some routers do build up a “map” of the network segment they are part of, once a router has passed on a packet to an upstream router is has no influence on what then happens to that packet. So it is important that all routers in the path have valid routes, and that failers in the network can be notified to downstream routers, so they can route packets around network issues. This is where the routing protocols come in to the picture!

In an ideal world we would not have to add any static routes, we would simple configure IP address on interfaces, enable routing protocols and the routers would teach each other how to reach all the networks. And in fact in many cases this is how it works. Once the interface are set up, a routing protocol is enabled and you simple have to configure what networks you wish to advertise using this protocol and to what neighbouring routers you wish to send the adverts to. This configuration and exact method may change between the different routing protocols, but fundamentals are the same, what do you want to advertise and who do you want to advertise this to. Of course there is far more to it than simply this, and we cover it in more depth later in course. But for now we just want to get a fundamental picture of the why’s and the how’s of routing.

I know once again this is really a bit of revision from CCNA material, but I think it is good to once in a while return to the basics, if you make sure you are clear in your head about them, then later on they can be built on to form the more complex topics. But no matter how complex things get, these fundamentals of what routing is and why we use routing protocols will always hold true.

In the next episode of CCNP ROUTE we shall be looking in more detail at the two main types of routing protocols (link state and Distance vector), and why we may chose one over the other.

Mean while you may want to take a look at CISCO Routing Basic. As well as this one document I would recommend you add a book mark to the handbook as a whole, there is lots of useful info there.

Off to do a bit more study now. 🙂

DevilWAH

Setting up HSRP (or how not to..)

OK need time out from reading about wireless networks, its all a bit of a repeat to be honest and I’m getting brain ache. I have update my ANKI flashcard pack though with some of it.

But I thought a few words on HSRP would help clear my mind.

HSRP (hot spare routing protocol), its a wonderful idea of CISCO’s. Two or more Routers on a subnet, sharing one IP address. You assign you client PC’s this IP as there default gate way, and in the event of one of the routers failing another takes over and keeps connectivity for you clients! And so simply to set up (both cisco routers and switches with the advanced IP feature set have this).

On the Primary router enter the config mode followed by the interface you wish to configure this on, and enter the following commands

(config-if)#ip address 192.168.14.200 255.255.255.0
(config-if)#standby 1 preempt
(config-if)#standby 1 ip 192.168.14.254
(config-if)#standby 1 priority 100

Then on the secondary router enter the following.

(config-if)#ip address 192.168.14.100 255.255.255.0
(config-if)#standby 1 preempt
(config-if)#standby 1 ip 192.168.14.254
(config-if)#standby 1 priority 95

And there we have it, now the first router will respond to any ARP requests for the 192.168.14.254 address which can be used as the DFGW for you clients. What is even better is that the routers will share the same MAC address for this IP. So in the event of the primary router failing with in 3 seconds (default timers) the secondry router takes over and all currently active clients will be able to carry on where they left off.

As always that is far from all you can do with HSRP, one of the main limitation you may notice is only one gateway is active at any one time, and although you can play with HSRP to achieve load balancing (See here), there is a much better way by using GLBP (Gateway Load Balancing Protocol). You can also have HSRP track interfaces and IP SLA counters to increase and decrease a routers priority to insure the router in the best position is running as the active, this cisco document covers the settings in far more detail than there is space for here.

Now for the how not to do it part 😉

By default the timers on HSRP are set to send a hello every 1 second and the standby router becomes active if it fails to hear a hello from the active route for more than 3 seconds. you don’t have to enter this of couse but the command would like like this to set it up

(config-if)#standby 1 timers 1 3

But 3 seconds ????!!!!!!!!!!!! three second network outage I cried! Hitting the question mark after typing (config-if)#standby 1 timers ?… what’s this I see msec. Yay I cried and after checking the documentation so see this really did reduce timers to the msec range, I proceeded to configure a hello timer of 50msec and a hold timer of 150msec ( you can actual configure it as low as 10msec). A quick test and yes almost instance fail over, not even a packet dropped, and I went home a happy lad.

However I configured that in the evening with little traffic on the network, next day just before lunch however…. Oh this is not so good, no one can get out of site? Things start to move then crash to a stop again. Well better log on to the core switches I suppose and see what the logs are saying….. Umm nope they wont let me on just hanging. Finally after switching off the secondary switch the primary one magically let me log in again and after checking its logs I could see what was happening. With such short hello timers packets where getting dropped, the switches started flapping between active and standby and in doing so just made the issue worse. And they could not settle on who was in charge.

From this I learnt two important things, First the don’t go below 200msec hello timers and 700msec hold timers (come on still less than a second fail over), and only do this is the routers/switches are directly attached. Secondly add in a preempt delay statement

(config-if)#standby 1 preempt delay 10

This will stop the flapping between active and standby. Once a device has change state away from being the active router, with the configuration above it must wait at least 10 seconds before it can take over again.

And finally just because you can do some thing does not mean you should or need to. The time out in the TCP stack in XP (and most other systems) is at least 9 seconds. In the case of VoIP and Video a few seconds delay may make a call hicup, but it will normally stay up. And people will not mine or take much notice of a slight hicup as long as it only happens once ever 6 months.

There are cases when you need better fail times, in which case you need the correct equipment. HSRP is a great technology but as I found back a few years ago when I did this. You can push a good thing to far.

For those of you with out CISCO devices, the industry standard version is VRRP (Virtual Router Redundancy Protocol), and some information on that can be found in this document.

Well I hope some of you will learn from my mistake, thankfully because I had played around with HSRP a lot on a test network, I was in a good position to trouble shoot and had it back up and working quickly. But still it is one of the times few times I have had to hold up my hands to management. Thank fully these times are rare and so far non-critical and short lived…

Well back to work tomorrow. Night all have a good one.