Mailing List Archive

Michael,
"accept data" enables the VRRP router to respond to pings to the Virtual
IP address. By default, in accordance with the RFC, the VRRP router is
not supposed to respond to pings unless the actual interface address
matches the VIP (if I remember correctly). However, HSRP routers WILL
respond to pings directed at the VIP. This knob allows you to mimic
that behavior. It will work fine without it. Hope this helps.

Todd

-----Original Message-----
From: Michael [mailto:wsf@vodatelsys.com]
Sent: Sunday, April 06, 2003 7:39 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] VRRP


Hi,

in vrrp configuration.is it also necessary to put "accept data".
does it work without "accept data"?
--
Michael <wsf@vodatelsys.com>

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

Hi Michael,

It will work without it. But without it you can not test the VIP
address via ping packets. Based on the VRRP standards, a router can
respond to traffic destined to the VIP only if it is the group master
AND the VIP is actually assigned to an interface on the router. The
only exception is ARPs which the group master router is allowed to
respond to. So if the VIP is not assigned to any of the router
interface's and you want the router to respond to traffic destined to
the VIP then you need this command.


Mario

-----Original Message-----
From: juniper-nsp-bounces@puck.nether.net
[mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of Michael
Sent: Sunday, April 06, 2003 10:39 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] VRRP

Hi,

in vrrp configuration.is it also necessary to put "accept data".
does it work without "accept data"?
--
Michael <wsf@vodatelsys.com>

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

Hi Todd,

Thanks. could you pls check with the book of JNCIP-M on page 493
abt. P1 EBGP Peering. after reading, culd you pls confirm me if
both R1 and R2 need to "accept data", after R1 fail, will R2 become
master and has BGP peer with P1 without "accept data"?

--
Michael <wsf@vodatelsys.com>

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

-----Original Message-----
From: juniper-nsp-bounces@puck.nether.net
[mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of Michael
Sent: Sunday, April 06, 2003 10:59 PM
To: Todd Regonini
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] VRRP

Hi Todd,

Thanks. could you pls check with the book of JNCIP-M on page 493
abt. P1 EBGP Peering. after reading, culd you pls confirm me if
both R1 and R2 need to "accept data", after R1 fail, will R2 become
master and has BGP peer with P1 without "accept data"?

--
Michael <wsf@vodatelsys.com>

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Michael,

I don't have a copy of the book, but if I read your question right, you're
suggesting that a router has a peering session with two boxes, which happen
to have VRRP configured. Whatever happens, I wouldn't peer with the VRRP
address. I'd peer with the interface address (for eBGP) or the loopback
(for iBGP). Therefore, the VRRP address is irrelevant to any BGP session.

VRRP is really only there to give some resilience to devices, which don't
support IP routing and only support a default gateway.

Regards,

Guy

> -----Original Message-----
> From: Michael [mailto:wsf@vodatelsys.com]
> Sent: Monday, April 07, 2003 3:59 AM
> To: Todd Regonini
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] VRRP
>
>
> Hi Todd,
>
> Thanks. could you pls check with the book of JNCIP-M on page 493
> abt. P1 EBGP Peering. after reading, culd you pls confirm me if
> both R1 and R2 need to "accept data", after R1 fail, will R2 become
> master and has BGP peer with P1 without "accept data"?
>
> --
> Michael <wsf@vodatelsys.com>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPpEy2o3dwu/Ss2PCEQK7zACgpNbbxM78a+20d/XesFvPucxxraEAoPjH
dlHuuvffvOqD15J0l6V4UfKP
=IPFB
-----END PGP SIGNATURE-----

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

From the book :
"The P1 router is configured with a single neighbor statement.
You must configure r1 and r2 to peer with P1 while ensuring that
the failure of either r1 or R2 does not result in chronic loss
of the routes advertised by P1".

No doubt it's just another lab trick you'll never use
in the "real life".

Nicolas.

# Hi Michael,
#
# I don't have a copy of the book, but if I read your question
# right, you're
# suggesting that a router has a peering session with two
# boxes, which happen
# to have VRRP configured. Whatever happens, I wouldn't peer
# with the VRRP
# address. I'd peer with the interface address (for eBGP) or
# the loopback
# (for iBGP). Therefore, the VRRP address is irrelevant to any
# BGP session.
#
# VRRP is really only there to give some resilience to devices,
# which don't
# support IP routing and only support a default gateway.
#
# Regards,
#
# Guy
#
# > -----Original Message-----
# > From: Michael [mailto:wsf@vodatelsys.com]
# > Sent: Monday, April 07, 2003 3:59 AM
# > To: Todd Regonini
# > Cc: juniper-nsp@puck.nether.net
# > Subject: Re: [j-nsp] VRRP
# >
# >
# > Hi Todd,
# >
# > Thanks. could you pls check with the book of JNCIP-M on page 493
# > abt. P1 EBGP Peering. after reading, culd you pls confirm me if
# > both R1 and R2 need to "accept data", after R1 fail, will R2 become
# > master and has BGP peer with P1 without "accept data"?
# >
# > --
# > Michael <wsf@vodatelsys.com>
# >
# > _______________________________________________
# > juniper-nsp mailing list juniper-nsp@puck.nether.net
# > http://puck.nether.net/mailman/listinfo/juniper-nsp
# >
#
# -----BEGIN PGP SIGNATURE-----
# Version: PGP 8.0
#
# iQA/AwUBPpEy2o3dwu/Ss2PCEQK7zACgpNbbxM78a+20d/XesFvPucxxraEAoPjH
# dlHuuvffvOqD15J0l6V4UfKP
# =IPFB
# -----END PGP SIGNATURE-----
# _______________________________________________
# juniper-nsp mailing list juniper-nsp@puck.nether.net
# http://puck.nether.net/mailman/listinfo/juniper-nsp
#

Ping, telnet, or BGP, you need accept-data if you expect the VIP to
reply to anything except ARP.

Thanks


> -----Original Message-----
> From: juniper-nsp-bounces@puck.nether.net
> [mailto:juniper-nsp-bounces@puck.nether.net]On Behalf Of Michael
> Sent: Sunday, April 06, 2003 7:59 PM
> To: Todd Regonini
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] VRRP
>
>
> Hi Todd,
>
> Thanks. could you pls check with the book of JNCIP-M on page 493
> abt. P1 EBGP Peering. after reading, culd you pls confirm me if
> both R1 and R2 need to "accept data", after R1 fail, will R2 become
> master and has BGP peer with P1 without "accept data"?
>
> --
> Michael <wsf@vodatelsys.com>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp

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@puck.nether.net
> [mailto:juniper-nsp-bounces@puck.nether.net]On Behalf Of
> Hannes Gredler
> Sent: Monday, April 07, 2003 2:27 AM
> To: Junoguy
> Cc: 'Michael'; juniper-nsp@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@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp

At 11:27 AM 4/7/2003 +0200, Hannes Gredler wrote:

>VRRP and the functionality of a VIP is intended 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 ;-)]

That assumes you run the whole network; I can think of half-a-dozen places
where VRRP (etc) is used because the (sub)organizations running two
networks that touch don't trust each other enough to even run RIP.

Of course, in such a situation they're not running BGP either. :-)

===
Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov