RE: Frame-Relay, RIP & Split-Horizon

Yes but i am not 100 percent sure about it it could be one of the possible
reason..
> From: ariemer_at_amnet.net.au
> To: roykhan123_at_hotmail.com; joeastorino1982_at_gmail.com
> CC: ccielab_at_groupstudy.com
> Subject: RE: Frame-Relay, RIP & Split-Horizon
> Date: Thu, 14 Jul 2011 13:48:31 +0800
>
> 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
> > >>
> > >>
Received on Thu Jul 14 2011 - 12:04:55 ART