BGP Peering with HSRP Virtual Address

[netservices]

Are there any caveats associated when peering in BGP with an HSRP virtual address?

I have a national ethernet circuit which terminates on a layer 2 switchport. The vlan of this switchport is then trunked to 2 Layer 3 gateway routers running HSRP between them for resiliency.

I want to set up eBGP between the CE on one end of the link and the PE routers at the other end.

Is it possible for the CE to peer with the HSRP virtual address? I'm hoping that whichever PE router is the active router for the standby group will peer with the CE and in the event of a PE router failure, the standby router will take up the responsibility of peering with the CE.

Thoughts anyone?

[royalblues]

You cannot peer with the HSRP virtual address

The TCP packets for BGP peering is allowed to source only from an interface, not from a virtual address.

You may be able to configure the neighbor pointing to the HSRP address but the remote connection will be refused since it will be sending the packet from an invalid IP address.

HTH

Narayan

[Harold Ritter]

Narayan,

It is actually possible to run BGP session to the VIP address. This might require to configure the HSRP routers to passively accept the BGP session (nei x.x.x.x transport connection-mode passive".

Bear in mind that the convergence will be slower than if you had a BGP session between the CE and both PEs since the BGP session will need to reinitialize when a fail over occurs.

Regards,

[AJAZ NAWAZ]

implementing aggressive timers would minimise failover period required for reconvergence.

good shout harold !

[Alexei Monastyrnyi]

HSRP is a LAN technology, a First Hop Redundancy Protocol, and should be used on the LAN side of things IMO. Of course, we can hack things and make them work in a twisted way (some folks treat it as CCIE way :-),  but would we want such a solution in a production environment? One should put together extensive redundancy testing with such implementation and there is still there is a chance for a FFFF-up simply cause the technology in use is not designed for the use-case.