Somewhat undocumented OSPF behavior

NetwurkNetwurk Member Posts: 1,155 ■■■■■□□□□□
in CCNP
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

:)
· Share on FacebookShare on Twitter

Comments

  • onesaintonesaint Member Posts: 801
    Nice trick, but whats the caveat with IOS version? Some don't Tx or reply?
    Work in progress: picking up Postgres, elastisearch, redis, Cloudera, & AWS.
    Next up: eventually the RHCE and to start blogging again.

    Control Protocol; my blog of exam notes and IT randomness
    · Share on FacebookShare on Twitter
  • Chris_Chris_ Member Posts: 326
    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.
    Going all out for Voice. Don't worry Data; I'll never forget you
    :study: CVoice [X] CIPT 1 [ ] CIPT 2 [ ] CAPPS [ ] TVOICE [ ]
    · Share on FacebookShare on Twitter
  • down77down77 Member Posts: 1,009
    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.
    CCIE Sec: Starting Nov 11
    · Share on FacebookShare on Twitter
  • ITdudeITdude Member Posts: 1,181 ■■■□□□□□□□
    down77 wrote: »
    I wouldn't try this at work since it *may* trip an IPS sensor.

    Yea, but wouldn't it be fun?icon_lol.gif
    I usually hang out on 224.0.0.10 (FF02::A) and 224.0.0.5 (FF02::5) when I'm in a non-proprietary mood.

    __________________________________________
    Simplicity is the ultimate sophistication.
    (Leonardo da Vinci)
    · Share on FacebookShare on Twitter
  • srikanth.ccna2010srikanth.ccna2010 Member Posts: 11 ■□□□□□□□□□
    What is IPS sensor?
    · Share on FacebookShare on Twitter
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    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 ;)
    · Share on FacebookShare on Twitter
Sign In or Register to comment.