[c-nsp] HSRP and RIPv2

[Brian Johnson]

What you are trying to do sounds reasonable in a mixed equipment environment
where you can not guarantee any specific routing protocol (except static).

I would say to modify the metric on the secondary making it less preferred.
Leave the HSRP in place for anything that doesn't play nice with RIP (yuck!
:P)

Redistribution from EIGRP... Can't help you there.

- Brian J.

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Crist Clark
> Sent: Thursday, September 15, 2005 11:47 AM
> To: bep at whack.org
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] HSRP and RIPv2
> 
> Bruce Pinsky wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Crist Clark wrote:
> > 
> >>We have a network with some devices that only speak RIPv2. 
> On the Cisco
> >>routers connected to the network, we are redistributing 
> routes from EIGRP
> >>into RIP. Two routers are in an HSRP group. What we see happening is
> >>each of the routers is announcing the networks using RIP, 
> but each is
> >>sending the updates with a source address of their 
> interface on the network
> >>and all zeros for the next hop. Therefore the other RIP 
> listeners use
> >>the source on the announcement as the next hop. What we want is the
> >>other RIP listeners to have the HSRP address as the next hop.
> >>
> >>I am not aware of a way to get the routers to use the HSRP 
> address as
> >>the source on their route announcements. That does not mean there is
> >>not one. Is there? Another option is to use "set next-hop" 
> to force the
> >>next hop in the RIP advertisements to be the HSRP address, but that
> >>becomes a slight administrative hassle since this configuration is
> >>repeated at multiple sites and we want to keep the site-specific
> >>configuration to a minimum. It would be nice to just be 
> able to tell the
> >>router to use the HSRP address as the next hop and not 
> specify the IP
> >>address explicitly. Finally, another option might be to 
> simply shut up
> >>the router that is in stand-by, but how do we tell it to 
> automatically
> >>start talking RIP again when it comes on line?
> >>
> >>This would seem to be something many have had to deal with 
> before, HSRP
> >>routers advertising their "real" IPs rather than the HSRP 
> address into
> >>RIP. Any suggestions?
> > 
> > 
> > You're using a routing protocol.  The RIPv2 listeners hear 
> both of the
> > adverts.  What is the problem?   Even if one of the 
> advertising routers
> > dies, the other will be sending updates.
> 
> Both routers advertise the same metric for the routes in RIP. 
> The routers
> could chose either router. However, we'd actually prefer the 
> HSRP primary
> to be the one used when both are up. So, should we play with 
> the next hop?
> Or play with metrics? Both seem pretty ugly with possible 
> hidden problems.
> 
> > HSRP doesn't seem like it should enter the equation here.  
> It's designed
> > for the situation where a device can be configured with 
> only one, static
> > default gateway.  That isn't the case here since you have 
> devices that can
> > accept dynamic routing updates.
> 
> There are other devices on the network that don't speak any routing
> protocols. The HSRP is mostly for them.
> 
> > What am I missing?
> 
> Hopefully, _I'm_ missing something. We may very well be doing 
> something
> blindingly dumb that's keeping us from seeing the easy way to do it...
> Like now I have to go back and remember why we forced the metrics in
> RIP in the manner we did when redistributing from EIGRP... Forcing the
> backup to a higher metric would seem to do the trick, but I could
> swear we had a problem with that.
> 
> Thanks for the responses.
> -- 
> Crist J. Clark                               
> crist.clark at globalstar.com
> Globalstar Communications                                
> (408) 933-4387
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>