[j-nsp] VRRP

[Harry Reynolds]

No arguments with your sentiment, Hannes....

This is a bit of a "lab trick", but the idea was prompted when the P1
router became exceedingly slow when peered to both the VRRP routers
directly. Because it got the same route feed from each VRRP router,
it seemed reasonable to let it peer with the VIP to provide
redundancy while not forcing it to carry a full set of duplicate
routes (policy is also used to strip the internet routes from P1 in
yet another attempt to avoid buying some memory).

The fact that it also tests a candidate's knowledge of VRRP and the
accept-data knob was a plus in my mind.





> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net
> [mailto:juniper-nsp-bounces at puck.nether.net]On Behalf Of
> Hannes Gredler
> Sent: Monday, April 07, 2003 2:27 AM
> To: Junoguy
> Cc: 'Michael'; juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] VRRP
>
>
> On Sun, Apr 06, 2003 at 11:11:46PM -0400, Junoguy wrote:
> | I will take a stab at this as well.  The reason for the
> "accept-data"
> | being required is because you are sourcing your BGP
> traffic from the
> | VIP.  So if and when R1 fails and you don't have the command
> | "accept-data" then R2 BGP peering will not come up
> because traffic from
> | the BGP neighbor is being sent to R2's VIP address.
> |
> | Mario
>
> VRRP and the functionality of a VIP is intendend as a
> high-resiliency tool targeted to end hosts and not for
> router 2 router communication ... [we have routing protocols
> doing that job much better ;-)]
>
> /hannes
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp