From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

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

589 Words. Plan about 4 minute(s) to read this.

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