[c-nsp] HSRP and BGP

[Dima Dorfman]

Skeeve Stevens <skeeve at skeeve.org> wrote:
> 	But, it just wouldn't work.  In the /29, lets say the upstream was
> .1 and the virtual IP was .2 with router-A being .3 and router-B being .4.
> 
> 	Router-A just would not connect as it seemed in debugging to be
> announcing itself as .3, not .2, even though I forced the Router-ID as .2.

Router-ID doesn't influence the source IP address. You can try
update-source instead, but it's still not a good idea (see below).

> 	Is this not a valid way to do HSRP to an upstream? Is there
> something wrong with this methodology? Is there some configuration in the

Several problems come to mind. If you have a failover event and the
other router takes over, the BGP session will drop and it will take
some time to get reestablished. Additionally, depending on your HSRP
configuration, when the "primary" router comes back up, it may try to
retake the virtual IP, flapping your session again. I don't see any
reason to play this kind of head game with your BGP peer.

> HSRP or BGP that I have missed? And if this wont work for some reason, what
> is another way of doing this? Should I just have 2 BGP peers with router-B
> pre-pending itself?

This is a much better solution. It uses the routing protocol the way
it was intended instead of hacking around it. Use MEDs instead of
prepending. As a customer, your upstream Should(tm) accept MEDs from
you. The problem with prepending is that a failure will trigger
UPDATEs all over the network. If you're doing this on the Internet,
that means networks all over the place will recalculate the best path
to you, possibly not using that upstream any more. If you're having
internal problems, the last thing you need is to cause instability for
your prefixes on everyone else's network.

Hope this helps.

--
Dima Dorfman
Trit Networks