A Network Artist : RIP Challenge 1

Friday, August 13, 2010

RIP Challenge 1 - Solution

So welcome back everybody and lets talk about the solution of RIP challenge 1.

So back to the results first - if someone solved entire puzzle correctly ? And the big answer is "NO".

Some were actually closer and solved the first half of the puzzle but some how no one was able to solve the second half.

Anyways Did I tell you that there were actually two challenging tasks to handle in this puzzle? :-)

Although it looks like only one challenge but actually there were two of them. And If I am recalling it correctly thats what some Mock Lab vendors called as "Spot The ISSUEs" part of real/mock lab.

Yes...actually there was also a configuration twist between R2 & R3. Which I guess no body got correctly :-)

Without saying further lets get back to command line and solve the first requirement of the puzzle.

Lets start with taking a look if initial configuration are in place to begin with:

***Basic Configuration & Verification***

Now lets configure the basic RIPv2 on each router & verify our configuration:

So far everything looks good with basic configuration now.

Now lets talk about solution of first task which says - ***The RIP Updates from R1 over network 12.12.12.0/24 should not be send as "Multicast" or "Broadcast" packets.***

Hmmm. so speaking about RIPv2 we all know that it sends it's update packets out every interface it's configured on in every 30 second (+ - a jitter timer value in case you care about that :-) ). The destination address it uses is a well known multicast address of "224.0.0.9" ( Which belongs to Permanent Multicast Group range out of full range of Multicast addresses) and the port it uses is "UDP" port "520". So basically it relies on UDP for transport and does not have it's own protocol number.

just to add a little more info - A RIP update packet can carry at max 25 destinations information inside a single update packet.

Ok...So the task say we need to send updates to R2 but we shouldn't be sending it as "Multicast" or "Broadcast". Which pretty much leaves us with option of sending "Unicast" updates. By the way we can change RIPv2's "Multicast" update behavior into "Broadcast" with command "ip rip v2-broadcast" at interface level.

Now lets talk about UNICAST. To send RIPv2 updates as "UNICAST" lets see what options do we have apart from configuring "neighbor command" which essentially allow RIPv2 router to send it's updates as "UNICAST" but keep this in mind that you have to configure an extra command "passive interface {default}" in conjunction to make it work properly because without this second command although RIPv2 will send UNICAST updates to configured neighbors but will also keep sending MULTICAST updates too . But we are not allowed to use these commands here :-(

Now Lets navigate DOC CD to IOS 12.4 RIP command reference guide and see what information we can find there in this regard.

http://www.cisco.com/en/US/docs/ios/iproute_rip/command/reference/irr_rip.html

Hmmm...That's ugly...at-least in my opinion because even if we navigate to the command reference guide then press "ctrl+f" to find keyword "unicast" we can't find anything.

Okay...now DOC CD can't help us more then that. So basically if we are in lab then we can pretty much say that our Best Friend DOC CD has rejected to help us :-(
Worst nightmare during lab...

Now lets think little outside the box and think what we can do to make RIP sending "UNICAST" updates but without configuring "NEIGHBOR" command ?

How about "NAT" ?... Hmm...Good Idea

Because with help of NAT we can translate One Address into Another and the other side don't know about this translation of Addresses at our side....simply Unaware.

Lets put the Static NAT configuration and see if it's working for us.

So all we are doing here is translating an "inbound" Multicast packet to a "Unicast".
So what actually happening here is that when incoming RIPv2 update destined for address 224.0.0.9 hits R1 sent by R2, R1 translates it the 224.0.0.9 into 12.12.12.2

Now because STATIC NAT is bidirectional in nature, So after the first packet comes "IN", the next outbound packet will check the translation table and build off that.

Lets verify if everything we just configured is working correctly and as expected.

So looks like everything is working fine and we are done with Task 1 completely fine.

Now before moving to second "GOTCHA" lets verify the routing tables of all 3 routers.

so routing between R1 & R2 seems to be working fine. But somehow R2 and R3 can't exchange routing information. Any guesses ?

Lets verify even if RIP has been enabled properly on R3.

Everything looks OK here. Hmmm... lets check RIB aka Routing Information Base for RIPv2 which is configured here in our case here.

By the way there is a majority of people who thinks "RIB" and Router's "Routing Table" is one/same thing. But actually it's NOT.

Lets take a look at RIP's RIB