Consistently Inconsistent Cisco

http://www.cisco.com/en/US/tech/tk828/technologies_q_and_a_item09186a00800a43f5.shtml

Address Resolution Protocol - ARP

Often I have seen CCNA Candidates struggling with understanding ARP & Proxy ARP. So I always recommend such guys two things :

1. Read through the following document:

http://www.cisco.com/en/US/docs/ios/ipaddr/configuration/guide/iad_cfg_arp_ps6350_TSD_Products_Configuration_Guide_Chapter.html

2. Lab up ARP and Inverse ARP on real equipments and verify the operation using debugs.


HTH...
Deepak Arora
Evil CCIE

EIGRP Variance & Unequal Cost Load Balancing Demystified - With Little GNS Bug

It's been a month since I posted my EIGRP challenge lab:


http://deepakarora1984.blogspot.com/2010/10/eigrp-challenge-lab-1.html


So today it's time to show you how to do it. I won't be spending much time today in explaining theory behind all this as so many people have already written about it but of-course that doesn't mean they covered it from all aspects.


But still I'll provide some reference links in the end of this post to make sure you don't have any gaps regarding concepts.


So lets load the initial configurations which I provided in original post and lets get started :


Note: Click Images To Enlarge

so far we can see the route is in routing table of R4, but we don't see redundant path as yet because of it's higher cost.


Lets calculate variance to install redundant route in routing table:


For those who don't understand variance yet here is the link:


http://www.networkworld.com/community/node/29966


Lets first examine the difference between two metrics that belong to both links for same route:

Now to calculate the required variance use the equation: Higher FD / Lower FD, and result will be:

As variance can't be fractional, so we need to take higher value, which will be 4


Lets's use variance value 4 and take a look at routing table:

Looks like both routes now have made it to routing table. So first objective is achieved. Now lets take a look at Traffic Share Count for both links for same route:

so as you can see that current traffic share count is 21:80. Traffic share count is inversely proportional to metric difference between both links.


So next step is to somehow make it as 1:1 :-)


As you might be thinking that Mr. Garcia (Creator Of EIGRP) should be around :-)

so lets take a look at first how much difference is there between both metrics:

Now lets subtract the lower metric from higher metric: By Metric I mean FD AKA RD:

So the difference comes as - 30000128


Now in next step lets add this metric to link with lower metric using "offset-list".

Here offset List calling ACL "0" means matching all routes... just for your sake :-)


Lets check again different EIGRP tables and see if it works:

Duhhh....looks like GNS is creating pain in butt again.... tired of GNS bugs :-(

Actually to over come this issue I had to jump to real equipments with same configuration and here are the results:

Though IOS ver "15.x" was not liking somehow idea of offset-list 0, so I had to create a specific ACL for this route:

So all functional and we have traffic share count of 1:1 between both links though they have different bandwidth.


Some more interesting reads on EIGRP or I should say "Must" read documents on EIGRP Load Balancing:


http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094823.shtml

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094820.shtml

http://www.cisco.com/en/US/tech/tk827/tk831/technologies_white_paper09186a00800a62d9.shtml

http://www.cisco.com/en/US/products/hw/modules/ps2033/prod_technical_reference09186a00800afeb7.html/

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009437d.shtml

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c2d96.shtml

HTH...
Deepak Arora

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

so again not much of information to help us with.

Lets check debugs and see if we can find something interesting in there.

Never mind...Here is the information you need to look upon to fix this issue.

http://deepakarora1984.blogspot.com/2009/01/does-ripv2-support-cidrsupernet.html


http://deepakarora1984.blogspot.com/2009/01/does-ripv2-support-cidrsupernet_25.html

http://deepakarora1984.blogspot.com/2009/01/reply-from-brian-mcghan-internetowk.html

So after reading all this, we know now that all we need is to perform following steps to fix this issue.

HTH...

Deepak Arora

Mastering DOC CD for CCIE R&S - Video Tutorial From INE

http://classroom.internetworkexpert.com/doc-cd