Ethan Banks Not writing about IT.

NMC DOiT Vol.2 Scenario 6 Day 1 – OSPF On Unnumbered Links + Do RIP Packets Have TTL of 2? Inquiring Minds Want To Know…

N

I got rolling along with NMC scenario 6 tonight, managing to plow through the frame-relay, PPP, Catalyst VLAN, OSPF and RIP. Most of the requested tasks were what I’m starting to think of as “normal” requests. IOW, things I’d NEVER do in real-life, but what you’re supposed to know how to do to demonstrate your competency on the lab. Things like:

  • Configure OSPF on a link without explicit IP addresses assigned. Assuming physically connected interfaces, configure the link as “ip unnumbered xx” where xx represents the interface of your choice. Configure the interface to “ip ospf network point-to-point” if it didn’t default to that. Write network statements using the interfaces you referenced in your “ip unnumbered” to get OSPF rolling. Watch the adjacency form. Smile, knowing that the OSPF adjacency will form, even though the two ends of the link are using IP’s not in the same IP network.
  • Unicast routing updates between RIP routers. Set your interfaces to passive, configure a neighbor statement for whoever you want to unicast to, then write a network statement to commence unicasting.
  • Make sure all RIP routers on a point-to-multipoint frame can exchange routes, but leave split-horizon enabled. Unicast the RIP routes to specific neighbors.
  • Make sure that an OSPF router does not participate in a DR election. On the appropriate interface, set “ip ospf priority 0”. OSPF router interfaces with a priority of 0 are not eligible to become DRs or BDRs.

On a side note, I just did a Google search for “cisco ttl 2 rip updates“, and got back one of my own blog articles on the first page of results. <sigh> That’s just plain weird…it would have been even weirder if the article had the answer. ;-) Anyway, I was trying to find documentation stating that Cisco sets the TTL of RIP packets to 2, but I haven’t been able to spot that yet. NMC states that in their answer key for the RIP section, and it’s sort of an interesting detail to know if you need a frame-relay hub to forward a RIP update to a spoke on behalf of another spoke. I guess I can take NMC’s word for it, but I’m a big fan of taking odd little facts like that and seeing it on cisco.com. The “official” Cisco word on such things usually has context about facts like that, explaining the scenarios where it would matter, etc. Depending on who wrote the Cisco doc on the topic of interest, you can sometimes even understand what they’re talking about!

<Ethan scrambles madly at the router console with a flash of inspiration…5 minutes goes by…tick tock…>

Well, bummer. I just tried a debug ip packet on the router to see if it would tell me what the TTL was on a RIP packet. No such luck…good info, just not detailed enough. I could break out a packet sniffer at work I guess, but that’s a lot of trouble to prove something I think I can believe without swallowing too hard.

R5(config)#ip access-l extended 150
R5(config-ext-nacl)#permit udp any any rip
R5(config-ext-nacl)#exi
R5(config)#exi
R5#debug ip packet 150 detail
IP packet debugging is on (detailed) for access list 150
R5#debug ip rip
RIP protocol debugging is on
R5#

*Apr 21 17:55:36.582: RIP: sending v2 update to 172.16.35.3 via Serial1/1 (172.16.35.5)
*Apr 21 17:55:36.582: RIP: build update entries
*Apr 21 17:55:36.582: 5.0.0.0/8 via 0.0.0.0, metric 1, tag 0
*Apr 21 17:55:36.582: 172.16.50.0/24 via 0.0.0.0, metric 1, tag 0
*Apr 21 17:55:36.582: 172.16.102.1/32 via 0.0.0.0, metric 1, tag 0
*Apr 21 17:55:36.582: 172.16.105.0/24 via 0.0.0.0, metric 1, tag 0
*Apr 21 17:55:36.582: IP: s=172.16.35.5 (local), d=172.16.35.3 (Serial1/1), len 112, sending
*Apr 21 17:55:36.582: UDP src=520, dst=520

3 comments

  • About the OSPF on the unnumbered link. The way the AK does it is to write network statements covering the interfaces you referenced in your unnumbered. This has the unfortunate side effect of activating OSPF on those interfaces when you might not want it.

    I find the much better way to deal with unnumbered links is to use ip ospf 100 area 0 on the unnumbered interface itself. This activates the OSPF on the interface and allows it to form neighbor adjacencies without touching the interfaces supplying the IP address. I do it that way as a matter of course for unnumbered interfaces.

    In fact, now that you can activate IPv4 OSPF on an interface-by-interface basis, just like in IPv6, I was thinking about abandoning the network statement altogether. What do you think?

  • On the TTL of 2. I heard recently (maybe from Russ White at Networkers in Barcelona, but maybe not), that RIP has a TTL of 2 because some non-Cisco implementations decrement the TTL before deciding whether to discard the packet. So the packet has to have a TTL of 2 to start with.

    About static neighbors, there is a lab experiment I want to do some time: for each of the three protocols (RIP, EIGRP, OSPF):

    1. Does configuring a static neighbor automatically stop the multicast? In EIGRP it does, in RIP it doesn’t, I think. Not sure about OSPF.

    2. Does a static neighbor penetrate a passive-interface? In EIGRP is does not, in RIP it does, I think. Not sure about OSPF.

    You can do great things with Ethereal on an old laptop connected to a SPAN port.

By Ethan Banks
Ethan Banks Not writing about IT.

You probably know Ethan Banks because he writes & podcasts about IT. This site is his, but covers other stuff.

Get the details on his about page.