Somewhat undocumented OSPF behavior

Ping 224.0.0.5 to get a list of ospf routers that are broadcasting and ping 224.0.0.6 to get a reply showing the DR and BDR (although you can't tell which one is the backup).

Rtr1#ping 224.0.0.5

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.0.0.5, timeout is 2 seconds:

Reply to request 0 from 172.123.1.42, 12 ms
Reply to request 0 from 172.21.1.1, 44 ms
Reply to request 0 from 172.16.1.2, 44 ms
Reply to request 0 from 172.123.1.17, 12 ms
Rtr1#ping 224.0.0.6

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.0.0.6, timeout is 2 seconds:

Reply to request 0 from 172.123.1.42, 12 ms
Reply to request 0 from 172.123.1.17, 12 ms
Rtr1#

Addresses returned are the interface IPs, not the OSPF IDs

Of course commands like show ip ospf neighbor give better info, but the exercise does help show which boxes respond to the 2 broadcast addresses.

EDIT: This doesn't work on all IOS versions, so not as cool a post as I thought it would be

Find more posts tagged with

Comments

onesaint

Nice trick, but whats the caveat with IOS version? Some don't Tx or reply?

Chris_

It is a nice trick. It could be more useful than sho ip OSPF neighbors as any router running OSPF will respond, regardless of if it has formed an adjacency or not i.e. misconfigured routers.
Haven't tested that, just an assumption.

down77

I'm not so sure I would call this an undocumented behavior. If you read up on how multicast works (great basic explanation is in the SWITCH FLG) this would be the anticipated result. You sent an ICMP echo request to a specified multicast group and they responded accordingly. It would make sense that the interface IP would respond since that IP is a member of the multicast group in question rather than the RID.

You can ping a number of the well known multicast addresses and see similar responses. Try pinging 224.0.0.1 for example on your home network. I wouldn't try this at work since it *may* trip an IPS sensor.

ITdude

down77 wrote: »

I wouldn't try this at work since it *may* trip an IPS sensor.

Yea, but wouldn't it be fun?

srikanth.ccna2010

What is IPS sensor?

Forsaken_GA

Netwurk wrote: »

Addresses returned are the interface IPs, not the OSPF IDs

That's to be expected, given the nature of routers and the nature of multicast. Responding to an ICMP echo is not part of the OSPF process, it's part of the interface bound to and listening on that multicast address, while the ospf router ID is purely part of the OSPF process

Of course commands like show ip ospf neighbor give better info, but the exercise does help show which boxes respond to the 2 broadcast addresses.

Ah, ah, careful of your terminology there