From: Ravi Singh (way2ccie@googlemail.com)
Date: Sun Mar 22 2009 - 06:28:34 ART
Hi Tharak,
You can find that from your debug outputs. The reason it says
unroutable means a packet destined for 224.0.0.10 cannot be sent over
the interface which in turn means that EIGRP is not enabled on that
particular interface. or in simpler words the interface is not enabled
to send multicast packets for that particular group.
Ravi
On Sun, Mar 22, 2009 at 7:09 AM, Tharak Abraham <tharakabraham@gmail.com> wrote:
> (Well am so sorry guys this is a mistake from my side, after looking into it
> thoroughly, got to know i advertised the wrong subnet in R1 under eigrp)
>
> Here are the configs from the two routers pls...
> But still i have posted the config with a question?
> ***In such a case how would i ever know what went wrong while debugging?***
>
>
> R1#sh ip int br
> Interface IP-Address OK? Method Status
> Protocol
> FastEthernet0/0 1.0.0.1 YES NVRAM administratively down
> down
> Serial1/0 155.1.0.1 YES NVRAM up
> up
> Serial1/1 unassigned YES NVRAM administratively down
> down
> Serial1/2 unassigned YES NVRAM administratively down
> down
> Serial1/3 unassigned YES NVRAM administratively down
> down
> Serial3/0 155.1.45.1 YES NVRAM up
> up
> R3(config)#do sh ip int brief
> Interface IP-Address OK? Method Status
> Protocol
> FastEthernet0/0 3.0.0.1 YES NVRAM administratively down
> down
> Serial1/0 155.1.0.3 YES NVRAM up
> up
> Serial1/1 unassigned YES NVRAM administratively down
> down
> Serial1/2 unassigned YES NVRAM administratively down
> down
> Serial1/3 unassigned YES NVRAM administratively down
> down
> Serial2/0 23.0.0.3 YES NVRAM administratively down
> down
> Serial2/1 unassigned YES NVRAM administratively down
> down
> Serial2/2 unassigned YES NVRAM administratively down
> down
> Serial2/3 unassigned YES NVRAM administratively down
> down
> Serial3/0 155.1.45.3 YES NVRAM up
> up
>
> ==============================================================
>
> R3#sh ip eigrp neigh
> IP-EIGRP neighbors for process 100
> H Address Interface Hold Uptime SRTT RTO Q Seq
> (sec) (ms) Cnt Num
> 0 155.1.45.1 Se3/0 12 00:07:02 232 1392 0 5
>
> R1#sh ip eigrp topo
> IP-EIGRP Topology Table for AS(100)/ID(150.1.1.1)
> Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
> r - reply Status, s - sia Status
> P 150.1.3.0/24, 1 successors, FD is 2297856
> via 155.1.45.3 (2297856/128256), Serial3/0
> P 150.1.1.0/24, 1 successors, FD is 128256
> via Connected, Loopback0
> P 155.1.0.0/24, 0 successors, FD is Inaccessible *# watch out???*
> via 155.1.45.3 (2681856/2169856), Serial3/0
> P 155.1.45.0/24, 1 successors, FD is 2169856
> via Connected, Serial3/0
>
> R1#ping 155.1.0.3 # *ping to R3's directly connected serial*
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 155.1.0.3, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 16/89/188 ms
> R1#ping 155.1.45.3 *# PIng to router R3 via frame relay*
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 155.1.45.3, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 28/84/176 ms
>
>
>
>
>
>
> On Sun, Mar 22, 2009 at 3:59 AM, Scott M Vermillion <
> scott_ccie_list@it-ag.com> wrote:
>
>> Can't say for sure whether or not your specific problem is related to one
>> bug ID or another, but the behavior is incorrect. I just slapped together
>> R1 and R3 with both serial and Ethernet connectivity. Here's the view from
>> R3:
>>
>> R3#sh ip eig neigh
>> IP-EIGRP neighbors for process 100
>> H Address Interface Hold Uptime SRTT RTO Q
>> Seq
>> (sec) (ms) Cnt Num
>> 1 150.1.13.1 Se1/2 11 00:00:07 33 200 0 6
>> 0 150.1.31.1 Fa0/0 12 00:00:07 34 204 0 5
>>
>> R3#debug ip packe det
>> IP packet debugging is on (detailed)
>> R3#
>> *Mar 1 00:03:40.731: IP: s=150.1.13.1 (Serial1/2), d=224.0.0.10, len 60,
>> rcvd 2, proto=88
>> *Mar 1 00:03:41.115: IP: s=150.1.31.1 (FastEthernet0/0), d=224.0.0.10, len
>> 60, rcvd 2, proto=88
>> R3#
>> *Mar 1 00:03:41.815: IP: s=150.1.31.3 (local), d=224.0.0.10
>> (FastEthernet0/0), len 60, sending broad/multicast, proto=88
>> *Mar 1 00:03:44.999: IP: s=150.1.13.3 (local), d=224.0.0.10 (Serial1/2),
>> len 60, sending broad/multicast, proto=88
>>
>>
>>
>> On Mar 21, 2009, at 5:06 , Tharak Abraham wrote:
>>
>> Hi,
>>>
>>> R1 is connected to R3 via frame relay and serial link.(redundant) and
>>> networks advertised via eigrp.
>>> If right, i am supposed to get both my interfaces as eigrp neighbours
>>> under
>>> the command "sh ip eigrp neigh"
>>> But am getting only one and that particular interface which forms the
>>> adjacency first(first advertised)
>>>
>>> when i did a debug ip packet the result showed as follows and saw the
>>> serial
>>> interfaces being unroutable
>>>
>>> R3#
>>> *Mar 1 01:32:48.947: IP: s=155.1.45.1 (Serial3/0), d=224.0.0.10, len 60,
>>> unroutable
>>> *Mar 1 01:32:52.015: IP: s=150.1.3.3 (local), d=224.0.0.10 (Loopback0),
>>> len
>>> 60, sending b
>>> road/multicast
>>> *Mar 1 01:32:52.023: IP: s=150.1.3.3 (Loopback0), d=224.0.0.10, len 60,
>>> rcvd 2
>>> *Mar 1 01:32:53.567: IP: s=155.1.45.1 (Serial3/0), d=224.0.0.10, len 60,
>>> unroutable
>>> *Mar 1 01:32:56.639: IP: s=150.1.3.3 (local), d=224.0.0.10 (Loopback0),
>>> len
>>> 60, sending b
>>> road/multicast
>>> *Mar 1 01:32:56.647: IP: s=150.1.3.3 (Loopback0), d=224.0.0.10, len 60,
>>> rcvd 2
>>> *Mar 1 01:32:58.247: IP: s=155.1.45.1 (Serial3/0), d=224.0.0.10, len 60,
>>> unroutable
>>>
>>> I tried the other way round by advertising the serial 3/0 first and
>>> resulted
>>> in frame relay interface throwing the unroutable messages
>>>
>>> R1#
>>> *Mar 1 01:40:03.911: IP: s=155.1.45.3 (Serial3/0), d=224.0.0.10, len 60,
>>> rcvd 2
>>> *Mar 1 01:40:04.679: IP: s=12.0.0.2 (Serial1/0), d=224.0.0.10, len 60,
>>> unroutable
>>> *Mar 1 01:40:04.807: IP: s=155.1.45.1 (local), d=224.0.0.10 (Serial3/0),
>>> len 60, sending
>>> broad/multicast
>>> R1#
>>> *Mar 1 01:40:05.579: IP: s=12.0.0.2 (Serial1/0), d=224.0.0.10, len 60,
>>> unroutable
>>> *Mar 1 01:40:05.611: IP: s=150.1.1.1 (local), d=224.0.0.10 (Loopback0),
>>> len
>>> 60, sending b
>>> road/multicast
>>> *Mar 1 01:40:05.619: IP: s=150.1.1.1 (Loopback0), d=224.0.0.10, len 60,
>>> rcvd 2
>>> *Mar 1 01:40:06.467: IP: s=12.0.0.2 (Serial1/0), d=224.0.0.10, len 60,
>>> unroutable
>>>
>>> I dont know whether someone has faced this problem, but it looks similar
>>> to
>>> a bug in this link towards the end,
>>>
>>> http://www.cisco.com/en/US/products/hw/routers/ps167/products_tech_note09186a0080094320.shtml
>>>
>>> But i am not getting any drops as such specified in the doc and its
>>> happening with both the routers and with different interfaces !
>>>
>>> please let me know whether its the same?
>>>
>>> Best Regards,
>>> Tharak Abraham.
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Mon Apr 06 2009 - 06:44:06 ART