Hi,
Is VRRP operation across subnets valid?
RFC3768 does not discuss anything related to this. Kindly respond with any known references in this regard.
Thanks
Venki..
_______________________________________________ vrrp mailing list vrrp <at> ietf.org https://www1.ietf.org/mailman/listinfo/vrrp
-----Original Message-----
From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf Of venki
Sent: Sunday, January 08, 2006 10:40 PM
To: vrrp <at> ietf.org
Subject: [VRRP] VRRP Operation across subnets
Hi,
Is VRRP operation across subnets valid?
RFC3768 does not discuss anything related to this. Kindly respond with any known references in this regard.
Thanks
Venki..
_______________________________________________ vrrp mailing list vrrp <at> ietf.org https://www1.ietf.org/mailman/listinfo/vrrp
Extactly this is what I expected.. It clarifies my query..
Thanks JD..
- Venki.
On Tue, 10 Jan 2006 Davis,Jesse M wrote :
>Hi Venki,
>
> Since VRRP is designed as a Unicast first-hop gateway mechanism, I don't
>see how it could function successfully across subnets. VRRP allows a client
>to store a shared MAC address handled by one or more virtual routers. Since
>a MAC address is only available locally on the same data-link network,
>receiving and storing a DMAC for a VRRP router on a different subnet would
>not make communication using said DMAC possible. In practice I have never
>seen any situation where a VRRP advertisement is learned across subnets.
>
>
>Hope this helps,
>JD
>
>-----Original Message-----
> From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf Of
>venki
>Sent: Sunday, January 08, 2006 10:40 PM
>To: vrrp <at> ietf.org
>Subject: [VRRP] VRRP Operation across subnets
>
>
>
>
>Hi,
>
> Is VRRP operation across subnets valid?
>
> RFC3768 does not discuss anything related to this. Kindly respond with any
>known references in this regard.
>
>Thanks
>Venki..
>
>
>
>
><http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.com/signa
>ture-home.htm/1507191490 <at> Middle5?PARTNER=3>
>
_______________________________________________ vrrp mailing list vrrp <at> ietf.org https://www1.ietf.org/mailman/listinfo/vrrp
All,
This is just a reminder that the draft for providing sub-second timers for VRRP for IPv4 was posted. I would appreciate any comments that you might have on this draft.
Abstract: The router survivability capability provided by the Virtual Router Redundancy Protocol for IPv4 (VRRPv4) satisfies the requirements for many LAN environments. There are, however, LAN environments that have sub-second failover requirements and thus a need for finer granularity of the VRRP timers. This draft proposes extensions to VRRPv4 [RFC 3768] for specifying sub-second Advertisement Intervals. A new message type is introduced which permits the timer granularity for the Advertisement Interval to be specified. In addition, a new field is introduced permitting the specification of the number of missed ADVERTISEMENTs before a Virtual Router Master is declared down.
Bob Hott
Robert (Bob) W. Hott
NSWC-DD
Code B35, Bldg. 1500A/122A
17320 Dahlgren Road
Dahlgren, VA 22448-5100
540-653-1497 (W)
540-653-8673 (FAX)
robert.hott <at> navy.mil (E-mail)
_______________________________________________ vrrp mailing list vrrp <at> ietf.org https://www1.ietf.org/mailman/listinfo/vrrp
Few comments on the draft
If the VR_Mode = 1, then:
o Send an ADVERTISEMENT
o Set the Adver_Timer to Advertisement_Interval
else:
o Send a FAST ADVERTISEMENT
o Set the Adver_2_Timer to Advertisement_Interval
For initialization, when VR_Mode = 1, then why are Fast Advts. not sent.
VR_Mode = 1 indicates that both types of VRRP implementations are
present. Then, to satisfy the backup routers with newer implementation,
Fast Advts. are needed. If not, they will declare Master Down and will
try to become Master causing more than one Masters to be active.
- If the Adver_2_Timer fires, then:
If the VR_Mode is 1
or
if the VR_Type is 2, then:
o Send a FAST ADVERTISEMENT
o Reset the Adver_2_Timer to VR_Adver_Interval
When Adver_2_Timer fires, and VR_Type configured on the local router is
2, then local router should send a Fast Advt. Why do we need a check for
VR_Mode == 1 at all ? In my opinion, the only check for sending Fast
Advt should be VR_Type == 2. Please clarify.
I would like to suggest removal of parameter 'VR_Mode'. If there is a
situation of new implementation inter operating with older one, we can
live with ignore and log. Although 'VR_Mode' takes care of this issue,
but implementation would be relatively simpler if we don't consider the
heterogeneous environment. This is just my opinion, if this topic is
still open for discussion.
--
Sonum
________________________________
From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On
Behalf Of Hott, Robert W CIV B35-Branch
Sent: Thursday, January 19, 2006 6:56 AM
To: vrrp <at> ietf.org
Subject: [VRRP] Reminder of posting of
draft-ietf-vrrp-ipv4-timers-01.txt
All,
This is just a reminder that the draft for providing
sub-second timers for VRRP for IPv4 was posted. I would appreciate any
comments that you might have on this draft.
Abstract: The router survivability capability provided by the
Virtual Router Redundancy Protocol for IPv4 (VRRPv4) satisfies the
requirements for many LAN environments. There are, however, LAN
environments that have sub-second failover requirements and thus a need
for finer granularity of the VRRP timers. This draft proposes extensions
to VRRPv4 [RFC 3768] for specifying sub-second Advertisement Intervals.
A new message type is introduced which permits the timer granularity for
the Advertisement Interval to be specified. In addition, a new field is
introduced permitting the specification of the number of missed
ADVERTISEMENTs before a Virtual Router Master is declared down.
Bob Hott
Robert (Bob) W. Hott
NSWC-DD
Code B35, Bldg. 1500A/122A
17320 Dahlgren Road
Dahlgren, VA 22448-5100
540-653-1497 (W)
540-653-8673 (FAX)
robert.hott <at> navy.mil (E-mail)
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Sonum,
Thank you for your comments on the draft. I have included my response to your comments in-line.
Bob Hott
-----Original Message-----
From: Mathur Sonum-CSM109 [mailto:sonum <at> motorola.com]
Sent: Tuesday, January 24, 2006 19:44
To: Hott, Robert W CIV B35-Branch; vrrp <at> ietf.org
Subject: RE: [VRRP] Reminder of posting of
draft-ietf-vrrp-ipv4-timers-01.txt
Few comments on the draft
If the VR_Mode = 1, then:
o Send an ADVERTISEMENT
o Set the Adver_Timer to Advertisement_Interval
else:
o Send a FAST ADVERTISEMENT
o Set the Adver_2_Timer to Advertisement_Interval
For initialization, when VR_Mode = 1, then why are Fast Advts. not sent.
VR_Mode = 1 indicates that both types of VRRP implementations are
present. Then, to satisfy the backup routers with newer implementation,
Fast Advts. are needed. If not, they will declare Master Down and will
try to become Master causing more than one Masters to be active.
<Bob Hott> This is a good observation. You caught an error in the draft. The "VR_Mode" in the IF statement,
above and on page 8 in the draft, should have been "VR_Type"! During initialization, the VRRP router, when
it is the Master, should send out the type of advertisement that it is configured to send. Thank you for
catching this error.
- If the Adver_2_Timer fires, then:
If the VR_Mode is 1
or
if the VR_Type is 2, then:
o Send a FAST ADVERTISEMENT
o Reset the Adver_2_Timer to VR_Adver_Interval
When Adver_2_Timer fires, and VR_Type configured on the local router is
2, then local router should send a Fast Advt. Why do we need a check for
VR_Mode == 1 at all ? In my opinion, the only check for sending Fast
Advt should be VR_Type == 2. Please clarify.
<Bob Hott> For the above comment, this test is on pages 12 and 13 of the draft. I believe that we should have
both tests following the firing of the Adver_2_Timer. It is possible that the VRRP router, although
running this new implementation, would be configured to run as an older version (possibly to use
authentication). Thus it should check to see if the VR_Mode is 1 (heterogeneous).
I would like to suggest removal of parameter 'VR_Mode'. If there is a
situation of new implementation inter operating with older one, we can
live with ignore and log. Although 'VR_Mode' takes care of this issue,
but implementation would be relatively simpler if we don't consider the
heterogeneous environment. This is just my opinion, if this topic is
still open for discussion.
<Bob Hott> If you are in an environment in which a new implementation is interoperating with an older
implementation, if the new implementation only logs and ignores the older implementation, then you run
the risk of having two masters. If the new implementation is supposed to be the Master, it must force the
older implementation to transition to a backup state. The older implementation will ignore the new FAST
ADVERTISEMENTS, thus it will want to transition to Master, unless it sees an ADVERTISEMENT from the new
implementation Master. For this reason, I don't think you want to ONLY ignore and log.
--
Sonum
________________________________
From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On
Behalf Of Hott, Robert W CIV B35-Branch
Sent: Thursday, January 19, 2006 6:56 AM
To: vrrp <at> ietf.org
Subject: [VRRP] Reminder of posting of
draft-ietf-vrrp-ipv4-timers-01.txt
All,
This is just a reminder that the draft for providing
sub-second timers for VRRP for IPv4 was posted. I would appreciate any
comments that you might have on this draft.
Abstract: The router survivability capability provided by the
Virtual Router Redundancy Protocol for IPv4 (VRRPv4) satisfies the
requirements for many LAN environments. There are, however, LAN
environments that have sub-second failover requirements and thus a need
for finer granularity of the VRRP timers. This draft proposes extensions
to VRRPv4 [RFC 3768] for specifying sub-second Advertisement Intervals.
A new message type is introduced which permits the timer granularity for
the Advertisement Interval to be specified. In addition, a new field is
introduced permitting the specification of the number of missed
ADVERTISEMENTs before a Virtual Router Master is declared down.
Bob Hott
Robert (Bob) W. Hott
NSWC-DD
Code B35, Bldg. 1500A/122A
17320 Dahlgren Road
Dahlgren, VA 22448-5100
540-653-1497 (W)
540-653-8673 (FAX)
robert.hott <at> navy.mil (E-mail)
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Comments inline > - If the Adver_2_Timer fires, then: > If the VR_Mode is 1 > or > if the VR_Type is 2, then: > o Send a FAST ADVERTISEMENT > o Reset the Adver_2_Timer to VR_Adver_Interval > > When Adver_2_Timer fires, and VR_Type configured on the local > router is 2, then local router should send a Fast Advt. Why > do we need a check for VR_Mode == 1 at all ? In my opinion, > the only check for sending Fast Advt should be VR_Type == 2. > Please clarify. > > <Bob Hott> For the above comment, this test is on pages 12 > and 13 of the draft. I believe that we should have both tests > following the firing of the Adver_2_Timer. It is possible > that the VRRP router, although running this new > implementation, would be configured to run as an older > version (possibly to use authentication). Thus it should > check to see if the VR_Mode is 1 (heterogeneous). The 'or' condition is ok for Adver_Timer and is not needed for Adver_2_Timer. We need to send regular Advt. when we are configured as old version (VR_Type = 1) or when environment is heterogeneous (VR_Mode = 1). For Fast Advt., we need to send it only when we are configured as new version (VR_Type = 2). The truth table can look something like this Type Mode 1 0 Advt only 1 1 Advt only 2 0 Fast Advt only 2 1 Advt & Fast Advt If a router (with new implementation) is configured to run as older version (VR_Type = 1), then why do we want to send Fast Advt. at all from this router ? We should never have the case of 'Adver_2_Timer' firing at all when VR_Type = 1. Once you make the correction of changing VR_Mode to VR_Type on Page 8 for initialization, if VR_Type = 1, then we will set only Adver_Timer and won't touch Adver_2_Timer. Correct me if I am not understanding this right and correct the table accordingly. Also, in initialization, if VR_Mode == 1 and VR_Type == 2, then we want to send and trigger timers for both - Advt. and Fast Advt. So we will need a check for VR_Mode in initialization also. To avoid confusion, it might be a good idea to rename 'VR_Mode' or 'VR_Type' (or both). They can be renamed to something like VR_Conf (for type) and VR_Envt (for mode) - just a suggestion. > <Bob Hott> If you are in an environment in which a new > implementation is interoperating with an older > implementation, if the new implementation only logs and > ignores the older implementation, then you run the risk of > having two masters. If the new implementation is supposed to > be the Master, it must force the older implementation to > transition to a backup state. The older implementation will > ignore the new FAST ADVERTISEMENTS, thus it will want to > transition to Master, unless it sees an ADVERTISEMENT from > the new implementation Master. For this reason, I don't think > you want to ONLY ignore and log. Agreed. We will need this if we want to make it backward compatible. -- Sonum > -----Original Message----- > From: Hott, Robert W CIV B35-Branch [mailto:robert.hott <at> navy.mil] > Sent: Thursday, January 26, 2006 5:30 AM > To: Mathur Sonum-CSM109; vrrp <at> ietf.org > Subject: RE: [VRRP] Reminder of posting of > draft-ietf-vrrp-ipv4-timers-01.txt > > Sonum, > Thank you for your comments on the draft. I have > included my response to your comments in-line. > > Bob Hott > > -----Original Message----- > From: Mathur Sonum-CSM109 [mailto:sonum <at> motorola.com] > Sent: Tuesday, January 24, 2006 19:44 > To: Hott, Robert W CIV B35-Branch; vrrp <at> ietf.org > Subject: RE: [VRRP] Reminder of posting of > draft-ietf-vrrp-ipv4-timers-01.txt > > > > Few comments on the draft > > If the VR_Mode = 1, then: > o Send an ADVERTISEMENT > o Set the Adver_Timer to Advertisement_Interval > else: > o Send a FAST ADVERTISEMENT > o Set the Adver_2_Timer to Advertisement_Interval > > For initialization, when VR_Mode = 1, then why are Fast > Advts. not sent. > VR_Mode = 1 indicates that both types of VRRP implementations > are present. Then, to satisfy the backup routers with newer > implementation, Fast Advts. are needed. If not, they will > declare Master Down and will try to become Master causing > more than one Masters to be active. > > <Bob Hott> This is a good observation. You caught an error in > the draft. The "VR_Mode" in the IF statement, above and on > page 8 in the draft, should have been "VR_Type"! During > initialization, the VRRP router, when it is the Master, > should send out the type of advertisement that it is > configured to send. Thank you for catching this error. > > > > - If the Adver_2_Timer fires, then: > If the VR_Mode is 1 > or > if the VR_Type is 2, then: > o Send a FAST ADVERTISEMENT > o Reset the Adver_2_Timer to VR_Adver_Interval > > When Adver_2_Timer fires, and VR_Type configured on the local > router is 2, then local router should send a Fast Advt. Why > do we need a check for VR_Mode == 1 at all ? In my opinion, > the only check for sending Fast Advt should be VR_Type == 2. > Please clarify. > > <Bob Hott> For the above comment, this test is on pages 12 > and 13 of the draft. I believe that we should have both tests > following the firing of the Adver_2_Timer. It is possible > that the VRRP router, although running this new > implementation, would be configured to run as an older > version (possibly to use authentication). Thus it should > check to see if the VR_Mode is 1 (heterogeneous). > > > I would like to suggest removal of parameter 'VR_Mode'. If > there is a situation of new implementation inter operating > with older one, we can live with ignore and log. Although > 'VR_Mode' takes care of this issue, but implementation would > be relatively simpler if we don't consider the heterogeneous > environment. This is just my opinion, if this topic is still > open for discussion. > > <Bob Hott> If you are in an environment in which a new > implementation is interoperating with an older > implementation, if the new implementation only logs and > ignores the older implementation, then you run the risk of > having two masters. If the new implementation is supposed to > be the Master, it must force the older implementation to > transition to a backup state. The older implementation will > ignore the new FAST ADVERTISEMENTS, thus it will want to > transition to Master, unless it sees an ADVERTISEMENT from > the new implementation Master. For this reason, I don't think > you want to ONLY ignore and log. > > -- > Sonum > > > ________________________________ > > From: vrrp-bounces <at> ietf.org > [mailto:vrrp-bounces <at> ietf.org] On Behalf Of Hott, Robert W > CIV B35-Branch > Sent: Thursday, January 19, 2006 6:56 AM > To: vrrp <at> ietf.org > Subject: [VRRP] Reminder of posting of > draft-ietf-vrrp-ipv4-timers-01.txt > > > > All, > This is just a reminder that the draft for > providing sub-second timers for VRRP for IPv4 was posted. I > would appreciate any comments that you might have on this draft. > > Abstract: The router survivability capability provided > by the Virtual Router Redundancy Protocol for IPv4 (VRRPv4) > satisfies the requirements for many LAN environments. There > are, however, LAN environments that have sub-second failover > requirements and thus a need for finer granularity of the > VRRP timers. This draft proposes extensions to VRRPv4 [RFC > 3768] for specifying sub-second Advertisement Intervals. > A new message type is introduced which permits the timer > granularity for the Advertisement Interval to be specified. > In addition, a new field is introduced permitting the > specification of the number of missed ADVERTISEMENTs before a > Virtual Router Master is declared down. > > Bob Hott > > Robert (Bob) W. Hott > NSWC-DD > Code B35, Bldg. 1500A/122A > 17320 Dahlgren Road > Dahlgren, VA 22448-5100 > 540-653-1497 (W) > 540-653-8673 (FAX) > robert.hott <at> navy.mil (E-mail) > _______________________________________________ vrrp mailing list vrrp <at> ietf.org https://www1.ietf.org/mailman/listinfo/vrrp
RSS Feed1 | |
|---|---|
2 | |
1 | |
4 | |
19 | |
1 | |
5 | |
2 | |
7 | |
2 | |
3 | |
3 | |
1 | |
1 | |
5 | |
9 | |
1 | |
4 | |
8 | |
1 | |
4 | |
4 | |
1 | |
7 | |
4 | |
1 | |
9 | |
2 | |
3 | |
5 | |
5 | |
20 | |
25 | |
5 | |
6 | |
2 | |
1 | |
3 | |
45 | |
18 | |
3 | |
10 | |
12 | |
6 | |
4 | |
7 | |
23 | |
4 | |
6 | |
14 | |
3 | |
15 | |
10 | |
5 | |
3 | |
30 | |
23 | |
11 | |
5 | |
1 | |
10 | |
10 | |
8 | |
6 | |
4 | |
2 | |
12 | |
5 | |
7 | |
11 | |
13 | |
4 | |
1 | |
10 | |
4 | |
10 | |
13 | |
10 | |
31 | |
12 | |
2 | |
6 | |
8 | |
1 | |
8 | |
12 | |
14 | |
11 | |
1 | |
13 | |
1 | |
5 | |
35 | |
20 | |
42 | |
38 | |
22 | |
9 | |
28 | |
4 | |
17 | |
15 | |
7 | |
35 | |
30 | |
19 | |
12 | |
10 | |
4 | |
5 | |
1 |
