Monthly Archives: November 2010

CCNP ROUTE (Part 10 EIGRP Over NBMA)

Posted on by
4

In what I think will be the last post on EIGRP (I will save redistribution between routing protocols for another time), I want to look at what is needed to insure EIGRP runs smoothly over NBMA (non broadcast multi access) networks such as Frame Relay.

As I have covered before EIGRP relies on multicast hello messages to form its neighbour relationships, but NBMA network by default do not forward any broadcast or multicast traffic. So this is the first issue with getting it up and running.

To achieve this you have two choices. First you could if you wished manually set up the neighbours. Going under the EIGRP AS process you can issues the command

router#(config-router)#neighbor <IP ADDRESS>  <INT ID>

This need to be done on both ends of the link, and will change the interface from sending out multicast hello messages to directed broadcasts, so you need to enter addition neighbour statements for each neighbour you want to connect to.

For some NBMA networks (such as frame relay) CISCO has added in a command to allow the router to forward the broadcasts over the link. It does this by sending a copy of the multicast/broadcast packet to each neighbouring router. This is needed for multipoint networks

#router(config-inf)#frame-relay  map IP <neighbour IP>  <Local DLCI>  broadcast

Now rather than using the neighbour command the router will forward any EIGRP hello’s across the to any routers configured with the broadcast command in there mapping.

Either of these two methods will allow the formation across the NBMA.

However there’s is now the issue of split horizon. Imagen you have a central router connected to two remote routers, each with there own routing tables. Split horizon says that a route update received on an interface will not be sent back out that same interface.  This means that if one of the remote routers sends an update to the central router, it will not then be relayed over to the second remote router.. To allow this to happen you must manually disable split horizon (it is disabled by default on a physical interface but enabled on sub interfaces). The command is as follows

router(config-inf)#no ip split-horizon eigrp <AS>

So recapping there is two parts to this, first allowing the hello messages across the NBMA, and then insuring the updates get copied to all routers.

These problems mainly occur when using the multipoint method, using point to point (although requiring more IP addresses and subnetting) avoids both the split horizon issue and the non broadcast issues, and is generally the recommended option.

DevilWAH

Download article as PDF

Simulating PC’s in GNS3

Posted on by
Reply

One of my main issues with GNS3 for studying that there are no end devices (PC’s) by default. Ok you can set up loopback interfaces, or add in an extra router and just configure one interface with an IP to act an an end device. But loopbacks don’t really show well when looking at the topology on screen, and adding a whole router (or creating a Qemu host) seems to be a bit much when all you need is a device that can reply to and send pings and/or run trace routes.

However the other day I came across VPCS! There is actuly a down load for this at the bottom of the GNS3 site (here), and it is so simple and easy to get up and running that I suggest any one who uses GNS3 has a look.

Simple unpack the zip file to a folder and then run the VPCS.exe file. this will by default create 3 PC’s with various IP addresses. However it is simple to configure it to create up to 9 separate simulated PC’s with either static or DHCP assigned addresses. These can then be easily added to GNS3 topologies by adding a cloud (see later in the post for how to make them look pretty), and configuring a NIO_UDP port. Really it takes all of 10 seconds to get it up and running. Then you have a simple CLI interface to the “virtual PC’s” where you can run Pings and Traceroutes.

There is only one thing to be careful of. You may find the cygwin1.dll file is a different version in GNS3 as to the version that comes with VPCS and this can casue issues. I find the simple way around this is to delete the cygwin1.dll file from the VPCS folder, and then copy the one form the GNS3 program folder in. (even better copy it to a system path such as c:\window\system32, and then delete it from both folders, and just keep a single copy they both can use).

The following is a link to a blog post on www.firstdigest.com with a video tutorial of how to set it up. (GNS3 and VPCS Video)

Now your GNS3 topology’s can actuly look and run like proper topologies and with our the overheads of emulating entire routers of operating systems. OK if you really need more complex hosts then there are other ways to do that, but for simple end devices that can ping and be pinged it is GREAT!!

DevilWAH

Download article as PDF

Why No Route Posts

Posted on by
1

I know I have been a bit lapse on Route posts lately. New job, sleepless baby and some other things on, have meant that I haven’t had much time to study. Much less write up posts and write new flash cards.

But hopefully over the next week things will settle down and I can start posting again 🙂

DevilWAH

Download article as PDF

Spanning Tree enhancements (Uplink fast)

Posted on by
1

In my last job, I jumped straight in to configuring Rapid spanning Tree, I mean what is the point of running Standard STP with its 50second fail over times, when you can enable Rapid-STP and gain sub second fail over??

Well if you want to pass your CCNP SWITCH you need to know it, and you need to know how to configure the enhancements. Actually having read through them and labed them up. They do help in understanding how STP works and how the original protocol was improved in a number of way, before CISCO took all the enhancements and came up with Rapid-STP.

Over the next few post I will be covering all of the basic enhancements, including uplinkfast, backbone fast, portfast, loopguard etc..

Uplinkfast.

This is normaly configured on access switchs that have two links back to the root, in these cases after the initial STP algrothem has run, one of the ports (lowest priority back to the root bridge) will be designated as the root port, while the other will be blocked. See digram below.

Now with standard STP, if the active link fails, the switch sees the root port link has fail and as it is receiving root BPDU’s on the backup blocked port it starts to bring this up. However with out uplink fast enabled this requires the port to go through the listening and learning stages. By default this is 30 seconds of outage, and even with best STP tuning it still results in a 14 second outage.

However with uplink fast configured the switch keeps track of the blocked ports that point back to bridge and forms them in to an “uplink group”. Now if the primary link goes down the switch can pick the next best root port and immediately places it in the forwarding mode as this will not be creating a loop. This creates an almost instant fail over of the primary link. However switch CAM tables will now be out of sync, which could result in frames being sent down the wrong links. To sort this out, the switch creates dummy frames with source address from its CAM table, and destination of multicast address. this updates the other switches on the network.

Now when the link comes back up, the switch waits twice the forward delay + 5 seconds before it switches back over. This allows the core switch at the other end of the link to have time to run through STP and start forwarding on the port.

And that’s Uplink fast. Providing a method to allow instant fail over of directly redundant links towards the root.

Configuration is very simple and is carried out in global config mode.

Switch(config)Spanning-tree uplinkfast

DevilWAH

Download article as PDF