Error pinging redistributed route

I am working with IEWB Vol2 lab2 and I have redistributed a route from eigrp running on R3 & R5 to ospf.  Redistribution points were R2 & R3 but R3 routes were preferred due to a lower metric. This ospf process is running on R1,R2,R3.

The route is installed in R1 quite alright but I don’t know why I cannot ping this route from R1.

As shown below, I have no problem pinging this route on R3 even though the route came from R5 but both R3 & R5 are eigrp neighbors.

See the info below

R1
RSRack1R1#sh ip ro 192.10.1.5
Routing entry for 192.10.1.0/24
Known via “ospf 1”, distance 110, metric 20, type extern 2, forward metric 64
Last update from 132.1.0.2 on Serial1/0, 00:08:41 ago
Routing Descriptor Blocks:
* 132.1.0.2, from 150.1.2.2, 00:08:41 ago, via Serial1/0
Route metric is 20, traffic share count is 1

RSRack1R1#ping 192.10.1.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.10.1.5, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

Pinging work on this route from R3:
Rack1R3#sh ip ro 192.10.1.5
Routing entry for 192.10.1.0/24
Known via “eigrp 10”, distance 170, metric 2195456, type external
Redistributing via eigrp 10, ospf 1
Advertised by ospf 1 metric 30 subnets
Last update from 132.1.35.5 on Serial1/1.1, 00:26:33 ago
Routing Descriptor Blocks:
* 132.1.35.5, from 132.1.35.5, 00:26:33 ago, via Serial1/1.1
Route metric is 2195456, traffic share count is 1
Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Rack1R3#ping 192.10.1.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.10.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/44/56 ms

Also traceroute always get to R3 serial intf. and stops

Rack1R3#traceroute 192.10.1.5

Type escape sequence to abort
Tracing the route to 192.10.1.5

1 132.1.0.2 24 msec 52 msec 44 msec
2 132.1.23.3 64 msec 92 msec 68 msec
3 * * *
4 * * *
5 * * *

The Solution:

AFter wasting some good minutes on this wondering why ? I had to start “thinking” as a router to figure out what was wrong here……

First I narrowed the problem down to communication down to R3 as shown by traceroute, the routes hits R3 serial intf. so why is R3 not routing it towards R5 or routing the icmp backk to R1.

Finally I found out that I FORGOT to redistribute ospf into eigrp on R3, hence R5 does not really have the ip address of R1 in its routing table, hence when it receives packets from R1, it drops it!!

This is probably one of those kinds of silly mistakes that everyone talks about.

Free CCIE Scholarship from InternetworkExpert

IE guys have decided to offer 2 CCIE scholarships to any CCIEs to be.

This scholarship gives you every resources at their disposal free of charge to pass CCIE lab.

Application for this will close by June 13, 2008 (new deadline now is June 20) and winner will be annouced sometimes in July.

To learn more, please follow this link.. IE Scholarship

IP RIPv2 Basics

While labbing section 4 in IPExpert books which is devoted to testing RIP protocol.

I came accross some of these basic features that worth mentioning……

1.  It is always a good idea to disable auto-summary since rip summarizes across classful network by default.

2.  Summary address is created per outgoing interface using “ip summary-address rip” command

3.  Since RIPv2 send updates to multicast address 224.0.0.9, if a task requires rip updates not to use unicast or multicast, then the rip process will have to use broadcast (just like RIPv1). This can be accomplished with “ip rip v2-broadcast” on rip interface mode.

4.  On the other hand, if a task requires RIPv2 updates to be sent as unicast packets ONLY to rip neigbors, then you need to use neigbor command under rip process to specify the neighbor. But HERE is a catch, with neighbor command, RIPv2 still sends multcast packets ANYWAY, hence the neighbor command must be combined with “passive-interface <intf_name>” Passive-interface command disables all RIP updates being sent on that interface but neighbor still send unicast to rip neighbor.

  • router rip
  • neighbor 150.50.24.68
  • passive-interface fa0/0

5.  RIPv2 supports both md5 & clear text authentication. This is configured by first creating key chain and then applying the key chain to a rip interface.

  • key chain r2r4
  • key 1
  • key-string sesano
  • int fa0/0
  • ip rip authentication mode md5
  • ip rip authentication key-chain r2r4

6.  Routes metrics (hop counts) can be modified with off-set list with acl matching the selected routes.

7.  Route filtering in RIP is commonly done with distribute-list and this can be combined with acl or prefix-list .

8.  If a secondary ip address is configured on interface, please note that RIP only advertises updates sourced from primary address.  To allow updates from secondary interface to be sent out on primary interface, disable split horizon on that interface or use “no validate update-source” on neighbor interface.

9.  RIPv2 supports 4 timers (update, holddown, invalid, flush) and out of these timers, holddown timer is not specified in the RFC (It is cisco specific).