While reading through my Cisco Press CCIE lab workbook, I came upon a section of the configs that kind of threw me off. The lab asked you to configure RIP to unicast updates without using the neighbor/passive-interface command. For those of you unfamiliar with the “neighbor” way of doing things, here’s how it goes. You configure “neighbor x.x.x.x” as the neighbors address (obviously). This will unicast updates, however, it will also broadcast (for RIPv1) or multicast (for RIPv2) updates regardless. See below.

The following shows

Apr  9 17:29:42.815: RIP: sending v2 update to 224.0.0.9 via Serial1/0 (10.25.1.1)

R1(config-router)#neighbor 10.25.1.2 (added the neighbors IP here)

*Apr  9 17:31:04.575: RIP: sending v2 update to 224.0.0.9 via Serial1/0 (10.25.1.1)
*Apr  9 17:31:04.583: RIP: sending v2 update to 10.25.1.2 via Serial1/0 (10.25.1.1)

As you can see,  unicast RIP updates are being sent, but the multicast updates are still going out. How do we stop them? Using the passive-interface command.

R1(config-router)#passive-interface s1/0

*Apr  9 17:34:50.887: RIP: sending v2 update to 10.25.1.2 via Serial1/0 (10.25.1.1)

As you can see, RIP updates are no longer being multicasted now, however the unicast ones are still exiting the interface..success! That’s fine and dandy, but let’s see another tricky way to pull this off. What happens if the lab says you cannot use the neighbor statement?…

Enter NAT.  I won’t lie, NAT is one of my least favorite subjects due to the unfamiliarity, but I’m sure after reading the following text, you’ll be impressed. I found this to be a sneaky way of unicasting RIP updates. Here’s the idea, since the neighbor statement is out of the question, we’ll use NAT to translate any outgoing traffic on UDP port 520 (RIP updates) to multicast address 224.0.0.9 into our neighbors interface address..in this case 10.25.1.2. Here is the configuration.

R1(config)#int s1/0

R1(config-if)#ip nat outside

Above, we simply identified our s1/0 as the outside interface for NAT purposes. Next, we’ll create our NAT statement which will do the magic.

R1(config)#ip nat outside source static udp 10.25.1.2 520 224.0.0.9 520

Here’s the catch. If we look at R1′s debug ip packet detail output:

*Apr  9 17:49:04.739: IP: s=10.25.1.2 (Serial1/0), d=224.0.0.9, len 52, rcvd 2
*Apr  9 17:49:04.743:     UDP src=520, dst=520

My first impression was: “damn, not working”. Then I checked R2′s debug ip packet detail output..low and behold..

*Apr  9 17:51:13.915: IP: s=10.25.1.1 (Serial1/0), d=10.25.1.2 (Serial1/0), len52, rcvd 3
*Apr  9 17:51:13.915:     UDP src=520, dst=520

Ah ha! The RIP updates sourced from R1 (10.25.1.1) are being sent to 10.25.1.2..or unicasted. We can verify this is unicast only, because without the NAT configuration, you will see the destination as the RIP multicast address, or 224.0.0.9. Pretty sneaky! Now, why can’t we see this NAT solution in R1 through debug ip rip, or debug ip packet det? It all comes down to the NAT order of operation. When performing NAT inside-to-outside translation, routing is done before NAT (with good reason)..therefore your RIP output shows that it is addressed to the 224.0.0.9 address, but by looking at debug ip nat detail on R1, we could see the NAT translation taking place.

*Apr  9 17:56:45.843: NAT: i: udp (10.25.1.1, 520) -> (224.0.0.9, 520) [0]

*Apr  9 17:56:17.815: NAT: s=10.25.1.1, d=224.0.0.9->10.25.1.2 [0]

There you have it! The lesson learned here is to 1) use 100% of the debug commands available, and 2) sometimes debugging from a neighboring router will help troubleshoot the node with an issue.

Edit:  Although I used RIPv2 in the example above, you can do the same with RIPv1, but instead of putting the RIPv2 multicast address in the NAT statement, use the broadcast address. It is key to note that you have to specify UDP port 520, or else you will translate all broadcast traffic that leaves the router instead of just RIP updates!