Re: Frame-Relay, RIP & Split-Horizon

OK I have simplified this whole thing to show the root of the problem.

Now we simply have the easiest thing in the world R1 ----- R2 connected via
ethernet. Split-Horizon is disabled on R1. R1 and R2 have RIP v2 enabled
on the ethernet segment 12.12.12.0/24. R2 advertises in 2.2.2.2.

R2 sends the route...

RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (12.12.12.2)
RIP: build update entries
   2.2.2.2/32 via 0.0.0.0, metric 1, tag 0
   12.12.12.0/24 via 0.0.0.0, metric 1, tag 0

R1 receives it and sends it back to R2...

RIP: received v2 update from 12.12.12.2 on FastEthernet0/0
      2.2.2.2/32 via 0.0.0.0 in 1 hops
      12.12.12.0/24 via 0.0.0.0 in 1 hops
RIP: Update contains 2 routes
R1#
RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (12.12.12.1)
RIP: build update entries
   2.2.2.2/32 via 12.12.12.2, metric 2, tag 0
   12.12.12.0/24 via 0.0.0.0, metric 1, tag 0
 RIP: Update contains 2 routes
 RIP: Update queued
 RIP: Update sent via FastEthernet0/0

R2 receives the update...but alas 2.2.2.2 has disappeared from "debug ip
rip". Am I losing my marbles?

RIP: received v2 update from 12.12.12.1 on FastEthernet0/0
      12.12.12.0/24 via 0.0.0.0 in 1 hops

On Wed, Jul 13, 2011 at 9:03 PM, Joe Astorino <joeastorino1982_at_gmail.com>wrote:

> It's actually driving me a bit mad right now.... I came to the same
> conclusion...hold down timer has nothing to do with it, I had just jumped
> the gun and was confused for a minute.
>
> I am still not sure why on the spoke I don't see the route at least in the
> RIP database or in the debug ip rip output. I keep thinking it must be
> something silly and simple I just can't put my finger on it right now
>
>
> On Wed, Jul 13, 2011 at 8:59 PM, Aaron Riemer <ariemer_at_amnet.net.au>wrote:
>
>> Hi Joe,
>>
>> Wouldn't the routes in question have to be in hold down first?
>>
>> I labbed this up as well. You can definitely see the routes being
>> advertised
>> from the spoke to the hub and back to the spoke again (wireshark). I would
>> say that IOS is silently binning the route has it has a higher metric
>> before
>> the debugging process is invoked.
>>
>> Would be good to know for sure though :)
>>
>> Cheers,
>>
>> -Aaron.
>>
>> -----Original Message-----
>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>> Joe
>> Astorino
>> Sent: Thursday, 14 July 2011 8:24 AM
>> To: Cisco certification
>> Subject: Re: Frame-Relay, RIP & Split-Horizon
>>
>> OK so I think I figured it out. Simple -- RIP hold timer. If a RIP router
>> sees a route with a HIGHER metric hop-count than the one it currently has,
>> the hold timer has to expire first to prevent what I'm trying to do from
>> happening : ) So ...not nearly as dramatic as I had thought and has
>> NOTHING
>> to do with frame-relay and DLCIs, just a general function of RIP
>>
>> I'm pretty sure it is just a hold timer thing.
>>
>> This is what happens when I don't get enough sleep or as Scott would say
>> "not nearly enough caffeine". Still, thanks for reading and I welcome
>> any
>> comments
>>
>>
>> --
>> Regards,
>>
>> Joe Astorino
>> CCIE #24347
>> Blog: http://astorinonetworks.com
>>
>> "He not busy being born is busy dying" - Dylan
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Regards,
>
> Joe Astorino
> CCIE #24347
> Blog: http://astorinonetworks.com
>
> "He not busy being born is busy dying" - Dylan
>
>

-- 
Regards,
Joe Astorino
CCIE #24347
Blog: http://astorinonetworks.com
"He not busy being born is busy dying" - Dylan
Blogs and organic groups at http://www.ccie.net