Checksum Verification

Occasionally I have to install software that is no longer available for download via the official channels. This is due to us having pretty strict standards on which IOS versions are stable and suitable for use via a bug scrub process that Cisco are party to.

I could speak to our Cisco SE and ask for the image to be provided, but it’s simpler and quicker to find a similar piece of kit on the network and FTP/SCP the image across.

I did this today, and then realised that I couldn’t rely on CCO to give me the MD5 sum for the image. A quick google tells me that I can perform a checksum on the switch using this command:

verify /md5 <file-location>:<file-name>

Location choices are:

bs: File to be verified
cns: File to be verified
flash: File to be verified
ftp: File to be verified
http: File to be verified
https: File to be verified
null: File to be verified
nvram: File to be verified
rcp: File to be verified
scp: File to be verified
system: File to be verified
tar: File to be verified
tftp: File to be verified
tmpsys: File to be verified
xmodem: File to be verified
ymodem: File to be verified

Example: verify /md5 flash:c3560e-ipbasek9-mz.122-53.SE2.bin

This yields a checksum which can be compared to the file copied across using the following command if you’re on a UNIX based system:

md5 <filename> | grep <expected-checksum>

 

Layer 2 ASA And OSPF

So recently I had to configure an OSPF adjacency between two routers.

I thought simply permitting multicast traffic to the All Routers and All DR/BDR Routers would permit OSPF Hellos across the link and allow OSPF adjacencies to form. In fact what I saw was routers entering the EXSTART state and the neighbourship failing. I checked the manual, for an OSPF adjacency to form, the following conditions need to be satisfied:

– Area IDs need to match

– Neighbours need to be on the same subnet

– MTUs need to match

– Hello/Dead timers need to match

– Authentication (if any is configured)

So, what I saw was the routers entering the EXSTART state and the neighbourship dropping. Bear in mind, at this point, the only thing permitted through the firewall both ways was multicast traffic to 224.0.0.5 (the AllSPF Routers multicast address) using the OSPF protocol (IP protocol 89). So for some reason the DBD exchange was not taking place.

My initial reaction was to check MTU size. I’d seen a similar issue before where an MTU mismatch (jumbo frames on one side, 1500 bytes on the other side) meant while the non-backbone area’s routes made it into the backbone ABR router the backbone area’s routes did not. This turned out to be a red herring, but not a bad idea to check this. Incidentally, I suspected the BVI on the ASA maybe causing problems, or perhaps even the VLAN tagging between inside and outside interfaces, as even though the two connected interfaces across the link were in the same subnet they were being tagged with different VLAN IDs. Seems OSPF doesn’t care what you tag it as because the bridging in the ASA takes care of that issue. For all intents and purposes, the two interfaces are in the same L2 domain.

Further investigation of the problem made me realise that once the initial Hello exchange was complete the DBD exchange took place using unicast transmission. Therefore, I amended the firewall rule to permit OSPF traffic between the unicast subnets relevant to the routers and all was well. A bit of a head scratcher. Seems I’ve forgotten some of my routing from my CCNP revision.

Thanks to this website for a very handy troubleshooting guide:

http://cisco.iphelp.ru/faq/5/ch09lev1sec6.html