I always name my IOS static routes as a best practise. However I hit a syntax issue last week when I tried to combine the named static with a tag, then redistributing that tagged static route into OSPF. If you have issues redistributing a ‘named and tagged static’ then this may be the post for you.
The simplified config snippet below is configured on SW1 (cisco 3750X). This config will match all static routes tagged with ‘200’ and redistribute them into OSPF. I could have avoided this whole issue if I used a prefix list to match the routes, but I think tag-and-match is a more efficient and less-error prone approach.
I’m experimenting with a new quiz engine and thought I’d write an OSPF Quiz. It’s only 8 questions and covers some of the weird and wonderful OSPF topics I have covered in the past. You’ll find them pretty easy if you’re a regular reader, or just don’t get out that much (like me!).
I’d love it if you could have a go and give me some feedback.
MTU mismatches are the primary reason an OSPF adjacency becomes stuck in the EXSTART state. After hellos are exchanged and the routers become neighbors, each OSPF speaker advertises the IP MTU of it’s local interface in a Data Base Description (DBD) LSA. If there is a mismatch you’ll probably just adjust the configuration to be identical on both ends of the link and be done. However, when you try to peer two OSPF routers with different network operating systems, things start to fall apart fairly quickly.
OSPF Sequence Numbers
Image: Numbers by eye/see – some rights reserved
When an OSPF router originates an LSA for the first time, it will choose the sequence number 0x80000001. The 0x prefix means it’s a hexadecimal number, where each hex character represents a four bit binary word. This post discusses why the OSPF sequence number begins with 0x8, and some quirks when counting with signed numbers.
Unicast Hello packets
I was debugging an issue recently and ran across something unusual. I had thought that all OSPF hellos on BCAST and P2P intefaces were sent as multicasts. However as you can see from the wireshark capture below, packet 10 is clearly sent as a unicast.
# Time Source Dest Proto Info
04 15.503997 192.168.12.2 188.8.131.52 OSPF Hello Packet
09 23.507483 192.168.12.1 184.108.40.206 OSPF Hello Packet
10 23.518430 192.168.12.2 192.168.12.1 OSPF Hello Packet
14 25.400245 192.168.12.2 220.127.116.11 OSPF Hello Packet
When a single-homed router is isolated by link failure, the LSAs it had previously originated can live for up to 60 minutes in the OSPF LSDB of the surviving routers. This may not be what you were expecting, and can cause a lot of confusion when troubleshooting OSPF. In this post we’ll look at why LSAs from an isolated router linger and how OSPF still knows how to ‘do the right thing’.