RIP multicast updates are sent with TTL of 2

The “culprit” for today's post is Francois Ropert, who provides a nice summary of Cisco-related blogs in his Planet Cisco web site. Reading the CCIE-related posts, I've stumbled across a post by Ethan Banks wondering whether the RIP updates are really sent with IP TTL set to 2. He concluded that this information cannot be deduced from the debugging outputs (anyone having an idea how you can get this information on the router?) and that he would need a sniffer to figure it out … and I thought: What a nice job for Dynamips.

I took one of my standard lab topologies (three routers in a triangle running OSPF between them, see the figure below) and started it in Dynagen.


When the routers were up and running I've configured RIP on all three of them:

router rip
 version 2
 network 10.0.0.0
Next I've used Dynagen to start the packet capture on the first serial port of the R1 with the capture R1 s1/0 rip.cap PPP command. After a minute, I've stopped the capture with the no capture R1 s1/0 command and opened the rip.cap file with Wireshark. The results are shown below (click to enlarge); RIP multicast updates are actually sent with TTL 2 (at least in IOS release 12.4(15)T).

I've used the same technique to figure out that the RIP unicast updates (configured with the neighbor address router configuration command) are sent with TTL 255.

9 comments:

  1. who said you can't deduce this information from router debugs ?

    c2509(config)#access-list 199 permit udp any any eq 520
    c2509(config)#router rip
    c2509(config-router)#version 2
    c2509(config-router)#network 192.168.1.0
    c2509(config-router)#network 172.16.0.0
    c2509(config-router)#end
    c2509#debug ip pack 199 dump
    IP packet debugging is on (dump) for access list 199
    c2509#term mon
    000079: Sep 27 2007 01:20:40.531 EDT: IP: s=192.168.1.9 (local), d=224.0.0.9 (Ethernet0), len 52, sending broad/multicast
    00E31D40: 45C00034 00000000 E@.4....
    00E31D50: 0211163F C0A80109 E0000009 02080208 ...?@(..`.......
    00E31D60: 0020ABCD 02020000 00020000 AC100000 . +M........,...
    00E31D70: FFFF0000 00000000 00000001 ............ r
    000080: Sep 27 2007 01:20:42.427 EDT: IP: s=172.16.1.9 (local), d=224.0.0.9 (Loopback0), len 52, sending broad/multicast
    00E03730: 45C00034 00000000 02112AD7 AC100109 E@.4......*W,...
    00E03740: E0000009 02080208 0020ABCC 02020000 `........ +L....
    00E03750: 00020000 C0A80100 FFFFFF00 00000000 ....@(..........
    00E03760: 00000001 ....
    000081: Sep 27 2007 01:20:42.451 EDT: IP: s=172.16.1.9 (Loopback0), d=224.0.0.9, len 52, rcvd 2
    00E02150: 45C00034 00000000 01112BD7 AC100109 E@.4......+W,...
    00E02160: E0000009 02080208 0020ABCC 02020000 `........ +L....
    00E02170: 00020000 C0A80100 FFFFFF00 00000000 ....@(..........
    00E02180: 00000001 ....
    c2509#u all
    All possible debugging has been turned off
    c2509#

    now, break your copy of Comer's or Steven's - or Google for "IP header" - need to have the header handy ;)

    4 nibble is IP proto version. 5 is IP header length (20 bytes). C0 is TOS, 0034 is total length. 0000 is IPID, and the next 0000 is flags and fragment offset. next byte, 02, is TTL.

    Problem solved - using the router debugs ;)

    ReplyDelete
  2. Perfect :) This is one of the solutions I've had in mind. There is another one (although not as elegant as this one) ...

    ReplyDelete
  3. Hm. I haven't tried it but if you're running a fairly recent IOS version you could use the "ACL Support for Filtering on TTL Value" on a neigbor router - PERMIT with TTL = 2 and log.

    But it's 12.4T or later - this one works across the board.

    ReplyDelete
  4. Bingo! This is the second method I had in mind. You're really good :))

    ReplyDelete
  5. Thanks :)

    And there is still one more way to do it . . . Wanna give it a shot ? :)

    ReplyDelete
  6. Flexible packet matching, but this is almost equivalent to an access list (although I still have to test whether you can match router-generated outbound packets).

    ReplyDelete
  7. Ivan, you rock :)

    For the record: I don't do a lot of web surfing - I just go to the nytimes.com, slashdot - and here. Love the blog.

    ReplyDelete
  8. Ivan, do you know why TTL is set to 2? Because, as far as I know RIP packets don't go to another links over the router, so TTL=1 would be enough. The same thing with EIGRP. Or am I missing something obvious/basic?

    ReplyDelete
    Replies
    1. I think I figured out the answer a while ago, but can't remember what it was. However, it's a great feature if you have to run a routing protocol across a firewall or a VPN concentrator.

      Delete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.