RE: Frame-Relay, RIP & Split-Horizon

Hi Roy,

Are you saying the RIP response route is suppressed from the 'debug ip rip'
output on R2 because it sees that the next hop (12.12.12.2) is itself?

Cheers,

-Aaron.

From: Roy Khan [mailto:roykhan123_at_hotmail.com]
Sent: Thursday, 14 July 2011 1:04 PM
To: joeastorino1982_at_gmail.com; ariemer_at_amnet.net.au
Cc: ccielab_at_groupstudy.com
Subject: RE: Frame-Relay, RIP & Split-Horizon

this is because of next hop value.

Next Hop identifies a better next-hop address, if one exists, than the
address of the advertising router. That is, it indicates a next-hop address,
on the same subnet, that is metrically closer to the destination than the
advertising router is. If the field is set to all zeros (0.0.0.0), the
address of the advertising router is the best next-hop address.

here r1 is sending back to r2 but look the next hop value 2.2.2.2/32 via
12.12.12.2, metric 2, tag 0

> Date: Wed, 13 Jul 2011 21:22:40 -0400
> Subject: Re: Frame-Relay, RIP & Split-Horizon
> From: joeastorino1982_at_gmail.com
> To: ariemer_at_amnet.net.au
> CC: ccielab_at_groupstudy.com
>
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Thu Jul 14 2011 - 13:48:31 ART