[c-nsp] HSRP and RIPv2

[Joseph Jackson]

I am leaning towards increasing the metric of the backup device.  This isn't
the fault of HSRP I think it was envisioned that the backup route would have
a higher metric in a design like you have.

 -----Original Message-----
From: 	Crist Clark [mailto:crist.clark at globalstar.com]
Sent:	Thu Sep 15 09:52:10 2005
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/