Category Archives: EIGRP

Debugging a single EIGRP neighbor

Debugging router neighbors can get tricky, especially when debugging on a headend router that has  a log of neighbors. However, you can debug traffic coming from just one neighbor.

First, enable debugging on all eigrp packets with this cmd:

debug eigrp packets

Second, narrow down your debug to just one neighbor:

debug ip eigrp neighbor a.b.c.d

The trick here is to combine the “debug eigrp” wth “debug ip eigrp”.  And IOS will let you know if you do it wrong too. In 12.4, If you put the second cmd in first, it’ll throw this back at you:

First enable IP-EIGRP Route Events or EIGRP packet debug

However, in 15.0, you’ll get no such complaints. Either  way, once you’re done with this, just “term mon” and you’re done!

Redistributing static routes on EIGRP stub routers

Ran into this little enigma while working with remote routers and distribution routers using EIGRP. At least, it’s always an enigma when you don’t know how it works, right?

The setup was fairly straightforward: two distribution routers talk to a remote router (configured as a stub in EIGRP), and the remote router has a static route to the subnet in question, 172.x.x.x/24 (see diagram below). How do you redistribute the 172 subnet back the core, through the distribution router?

Originally, I played with static routes. Static routes on Remote (to get a path through the firewall), and static routes on Dist 1 and a static route on the Core. Fine, it worked, but only provisionally. I could reach 172.x.x.x, but if Dist 1 failed, there was no automatic failover of the route. It had to be redistributed into EIGRP.

OK, that’s relatively simple – one one routing protocol, don’t have to work about weighting the metrics, no prob. Just to be sure I was only redistributing the route in question, and nothing else, I created a route map:

ip route 172.x.x.x 255.255.255.0 192.168.x.x (The original static route)

access-list 10 permit 172.x.x.x 0.0.0.255 (ACL identifying the 172.x.x.x subnet)

route-map 172.x.x.x_net permit 10 match ip address 10 (Route Map calling ACL 10)

So far so, good. Now, to redistribute the route into the EIRGP process:

router eigrp 1

redistribute static route-map 172.x.x.x_net

I looked at the eigrp topology table, and? Yes, 172.x.x.x does appear in the topology table:

P 172.19.39.0/25, 1 successors, FD is 28160 via Rstatic (28160/0)

All is well on the Remote router. Now, does the route appear in the Distribution Routers? I take a look at the EIGRP topology table there and? Nothing. Wait, what? Look again. Nothing.

Damn.

The route is making it into the EIGRP process on the remote, but isn’t being advertised to its peers. Why?

After some Googling, I run across this article:

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/eigrpstb.html#wp1035883

It explains that in order to advertise redistributed static routes, you have to modify the stub configuration to allow the sending of redistributed static routes, thusly:

router eigrp 1

eigrp stub static

Now, when I check the Distribution Routers, there is the route, pretty as a sunrise on a morning in May.

Note to self: when redistributing static routes on EIGRP stub routers, redistribute first into EIGRP, and then be sure to modify the eigrp stub statement to allow advertisement of the route to EIGRP peers.


HSRP and EIGRP: Part 2

So, back to HSRP and EIGRP. From Part 1, connectivity in the lab setup was working fine during my tests until I disconnected the Data Centers HSRP interfaces. Then we lost ping completey to our remote site. It took a while to figure out, but here’s what was happening.

On the EIGRP/VPN side, we had two VPN tunnels setup on the Remote Router – one tunnel to each of our Corporate Routers. All three routers are running EIGRP, which gave the Remote Router two routes to the Corporate network. When I disconnected the HSRP interface on Data Center Router 1 (1.1.1.2), the primary VPN tunnel went down, as well as the primary EIGRP route, and the Remote Router switched over to the secondary VPN tunnel, and EIGRP route number two. So far, so good.

However, back in the Data Center, our PC Host is still trying to reach the Remote Router through the primary VPN tunnel, and Corporate Router 1 is still forwarding traffic through EIGRP route number one, having no knowledge of EIGRP route number two (on Corporate Router 2). Packets from the PC Host are forwarded to the Remote Router on the primary VPN Tunnel (which is down), but the only available return path from the Remote Router is the secondary VPN Tunnel.  This is a problem. But what is the solution?

Like usual in Cisco-land, there are multiple solutions. After having a lengthy chat with my good buddy Google, I choose this one: use IP SLA to track the availability of both the internal and external interfaces of the Data Center Routers. Then, make the HSRP failover on our Corporate Routers occur whenever any of those interfaces went down. This way, whenever the Data Center HSRP failover occurs, our HSRP failover would also occur, thus insuring our Hosts and Remote Routers would always be communicating over the same VPN Tunnels, and the same routes.

Below is a sample config snippet for the statements to make this happen on our Corporate Router 1.

NOTE:  this IOS version is 15.0, but for the HSRP, IP SLA and tracking cmds, it’s functionally the same as 12.4.

!
!
track 1 ip sla 1 reachability
### Establishes the object tracking of IP SLA 1, which will be used by HSRP###
!
track 2 ip sla 2 reachability
### Establishes the object tracking of IP SLA 2, which will be used by HSRP###
!
!
<<<Output Omitted>>>
!
!
interface GigabitEthernet0/0
ip address 172.150.1.10 255.255.255.128
duplex auto
speed auto
standby version 2
standby 1 ip 172.150.1.1
standby 1 priority 110
standby 1 preempt
standby 1 track 1 decrement 20
###Tracks reachability of 1.1.1.2, and decreases HSRP router priority by 20 points if 1.1.1.2 goes down, triggering an HSRP failover###
standby 1 track 2 decrement 20
###Tracks reachability of 2.2.2.2, and decreases HSRP router priority by 20 points if 1.1.1.2 goes down, triggering an HSRP failover###
!
!
<<<Output Omitted>>>
!
!
ip sla 1
icmp-echo 1.1.1.2 source-ip 1.1.1.10
frequency 5
ip sla schedule 1 life forever start-time now
###Sets up the pings every 5 seconds to 1.1.1.2, using the local routers external IP as the source-ip###
ip sla 2
icmp-echo 2.2.2.2 source-ip 1.1.1.10
frequency 5
ip sla schedule 2 life forever start-time now
###Sets up the pings every 5 seconds to 2.2.2.2, using the local routers external IP as the source-ip###
!
!
No doubt this wasn’t the solution running through your mind, or you’ve a more efficient config. Either way, I’d love to hear your solutions. After all, I’m just a CCNA thrashing around in a CCNP world. However, if this is new to you like it is to me, here’s some pointers to what Cisco has say about HSRP, IP SLA and object tracking.

HSRP and EIGRP: Part 1

Been tasked with a new project: design and setup a fully redundant network for a new data-center. The old data center just doesn’t have enough uptime. It wasn’t designed right, and we suffered a major production outage a couple of months ago due a car crash. A couple cars lost control, and one of them hit the telephone pole that carries electricity to our facility. Bingo-Bongo, power outage for 12 hours. Finally (!) the powers that be agreed to move the servers to a REAL facility (thank you thank you thank you).

The Systems Administrator is working on the fully redundant systems pieces (VMware ESX 4, a SAN, tape backups and autoloader and all that goes with it), so fortunately I don’t have to sweat any of that. However, this new center will be one of the hubs in for our dual-hub, hub-and-spoke network. We’ve got something like 35 remote sites that will need two VPN tunnels to this location, and will be running EIGRP over each tunnel.

This will give the remote sites the redundancy they need should one of our data center routers go down.  Of course, we have dual routers and dual switches, and will run HSRP on our routers LAN interface. Additionally, the Data Center will run HSRP on their routers LAN interface, to protect us against a circuit/equipment failure on their side. So far, so good (in theory).

So I set about to create a simulation of this whole setup (since the routers and switches came in early), and test the failure scenarios to make sure the redundancy operated like we expected it to (lab network diagram below). And boy, how it did NOT work!

In the setup (see diagram below), I had one host (a PC) connected to a pair of switches, which in turn are connected to a pair of routers running HSRP on their LAN interface. These routers are connected to the dual handoff from the Data Center switches, which of course are connected to dual Data Center routers. The lead to the internet, and ultimately, our remote router. The remote router has a 2 VPNs, one to each of our pair of routers.

The failure test itself is pretty simple: establish the VPNs, start a continuous ping, and start disconnecting interfaces. Theoretically, we should have a few drops pings with every disconnect (and reconnect), but no more. And at no point should we lose ping altogether.

It all worked fine, till I disconnected the interfaces on the Data Center HSRP interfaces. Then we lost ping altogether, even though the Data Center routers successfully failed over. Took me a while to figure it out, but in the end, it was pretty simple.

Any guesses? I’ll post what I found and the resolution in Part 2. No doubt some of you have found better solutions than me!