Monthly Archives: February 2012

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!

Advertisements

Building it twice

“It’s what you learn after you know it all that counts.” – D. K. H. Zokaites

I’ve been studying for the CCNP SWITCH test for going on 10 months now.

It feels like an eternity, even when figuring in a couple of major interruptions. Despite all this time, I’m not ready, and my practice test scores show it. Such a low feeling, to read all the materials (3 books), go through the labs (21 of them), watch hours of video, and STILL do poorly on the practice tests. No doubt this kind of struggle has affected many of us. I’m not alone in this dogged pursuit.

So far, here’s the study territory I’ve covered:

A lot of material.

After passing ROUTE nearly a year ago, Layer 2 feels nebulous and hazy. Routing is grounded in Layer 3; discreet subnets, integer based thinking, definite boundaries. Either you’ve got an IP destination or you don’t! Even multicast and broadcast are delivered to a single IP address.

But Layer 2? What is it? Packet headers and timers, priority numbers and countdowns. I can only really see it with Wireshark. And the names! Everything in STP ends with fast or guard. PortFast, UplinkFast, BackboneFast, LoopGuard, RootGuard, BPDUGuard. Seriously? They must have forgotten FastGuard.I just had a mental block to all this bewilderment, and this resistance slowed down my studies.

Along the way, I decided I NEEDED a better chair at work. To help my back of course. Which is bad. I NEED this chair. This ‘need’ seemed a good justification to escape from all the Layer 2 concepts swirling in my head. It was just an excuse. After 2 months (!), I emerged with a half-way OK chair, and an important lesson.

You can find the chair here: http://cleverchair.wordpress.com/

The lesson is this: to truly learn something, do it twice (at least).

By the time the chair was done, I’d actually built it three times, and some pieces even more than that. SWITCH is no different. The first time through it was a morass of never-ending protocols, jamming my bandwidth with sticky, androgynous concepts.

This time I’ll use a different study strategy which will focus on my weak areas first and also heavily use daily/weekly reviews of material. Packet Pushers has laid out a good learning method, and I’ll follow that closely.

But now? Once more unto the breach, my friends, once more. ‘Tis only a fight with ideas, a fight inside my mind, no more. Hopefully, soon I too will join the happy few, we happy few, we band of (certified) brothers.

Cisco ASA OS real-time logging bug – FIXED

For a few months now, my ASA’s ASDM real-time log debugger has been giving fits. More specifically, it’s been displaying exactly NOTHING. Look at the ASDM real-time log viewer, and … nada. It was running OS version 8.2.1 with ASDM 6.2.3. This combo was not the default – I upgraded them from OS 7.x and ASDM 5.x.

A few intensive Google searches pointed to an 8.2.x OS bug. Not much to be done about it, except  maybe open a TAC case a hope for the best. Oh yeah, you could always open the ASDM log-buffer viewer and hit F5 a lot.

Well, we ended up ordering a new ASA 5510, and it came from Cisco with OS 8.2.3 and ASDM 6.2.1. Guess what? ASDM real-time log viewer works with this combo! Looks like it was an ASDM issue rather than an OS issue.

FIX: Changed ASDM on old ASA to 6.2.1. Whew. A LOT easier than upgrading the OS.

Grepping ASA syslogs for AnyConnect client logon/logoff activity

Ran across a Quick Question the other day: “Hey, can you quick tell me when so-and-so has been on the vpn in the last week?” Everybody knows a quick question is anything but. This was no exception.

The quick answer is “Sure, just let me look in the syslogs. Hang on.” To my genuine surprise, the syslogs we very large. 2+ Gbs for each day – way too large just to search in Notepad++ (Notepad and Wordpad actually refused to open the file). So, I quick learned to use GNU32 Grep for Windows.

Once I figured that out, the next trick was to figure out what to grep for. Of course, if you’re syslogging the right classes, this helps tremendously (wink wink). In addition to the default syslog classes, I  had added the following:

logging class auth trap informational
logging class vpdn trap informational
logging class vpn trap informational
logging class vpnc trap informational
logging class webvpn trap informational

Turns out that class vpnc (VPNCLIENT) is not what you think. I’m was thinking this is for the remote access client activity, like AnyConnect activity. Wrong. It’s most for EZVPN setups. For remote access activity, class webvpn is what you want. Specifically, message 716001 is for logon events, and 716002 is for logoff events.

We’re using ASA software version 8.2.1, and Cisco syslog message documentation explains these messages like this:

716001
Error Message %ASA-6-716001: Group group User user IP ip WebVPN session started.
Explanation: The WebVPN session has started for the user in this group at the specified IP address. When the user logs in via the WebVPN login page, the WebVPN session starts.

716002
Error Message %ASA-6-716002: Group GroupPolicy User username IP ip WebVPN session
terminated: User requested.
Explanation: The WebVPN session has been terminated by a user request.

In Part 2, I’ll go into detail on how to search multiple syslogs files for these events with one command.

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.