headers
vrrp-admin | 13 Aug 2002 22:30
Picon
Favicon

Welcome To "vrrp"!

Welcome to the vrrp <at> ietf.org mailing list!

********** Note Well

All statements related to the activities of the IETF and addressed to
the IETF are subject to all provisions of Section 10 of RFC 2026,
which grants to the IETF and its participants certain licenses and
rights in such statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which
are addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other
function, that are clearly not intended to be input to an IETF
activity, group or function, are not subject to these provisions.

*********

Welcome to the new mailing list for the IETF Virtual Router Redundancy
Protocol (VRRP) Working Group.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Hinden | 13 Aug 2002 23:13
Picon

New VRRP Mailing List

Do to some recent problems, the VRRP working group mailing list has been 
moved to ietf.org.  The new mailing list is:

   vrrp <at> ietf.org

All current subscribers have been subscribed to the new list (and 
unsubscribed from the old list).  You will not have to re-subscribe.  You 
should have received a welcome message earlier today confirming your 
subscription to the new list.

Information on the new list can be found at:

   https://www1.ietf.org/mailman/listinfo/vrrp

Please contact me with questions and problems.

Thanks,
Bob

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |
headers
Bob Hinden | 13 Aug 2002 23:22
Picon

VRRP Working Group Minutes

Virtual Router Redundancy Protocol W.G.

Yokohama IETF Meeting
July 16, 2002

Minutes taken by Eric Gray.

Chair: Bob Hinden / Nokia

Agenda:
    Introduction and Review Agenda
    Announcements
    Current Drafts
      VRRP (for IPv4)
        <draft-ietf-vrrp-spec-v2-06.txt>
      VRRP for IPv6
        <draft-ietf-vrrp-ipv6-spec-02.txt>
    Updated Milestones for working group charter
    What to do with AH Security issues for VRRPv4 and VRRPv6?

Minutes:

Bob announced that he is planning to step down as chair for the WG. They 
are now looking for somebody to step into the role.  Contact ADs or Bob - 
who will continue in the role until replaced.

Bob talked about the (2) current drafts and asked if there were people who 
have implemented VRRPv6.  NEC and Hitachi have done an implementation and 
some interoperability testing.  Bob asked the implemented to feedback 
anything they've learned in the implementations.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alex Zinin | 15 Aug 2002 23:30

Re: VRRP Working Group Minutes

Tuesday, August 13, 2002, 2:22:28 PM, Bob Hinden wrote:
...
> Bob announced that he is planning to step down as chair for the WG. They
> are now looking for somebody to step into the role.  Contact ADs or Bob - 
> who will continue in the role until replaced.

Folks interested in running for the WG chair position, please
drop myself and Bill a message--we're starting the interview
process.

Thanks.
Alex

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |
headers
Phil Roberts | 27 Aug 2002 20:44

Nomcom call for volunteers


The members of the IESG and IAB and the IETF chair are selected
by a nominations committee made up of volunteers from the
IETF community.  The nominations committee is now in the process
of being formed and volunteers are being accepted until Sep 6.
Please see (http://www.ietf.org/nomcom/msg19765.html)
for information if you are interested in volunteering 
to be on the nominations committee.
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |
headers
jamal | 28 Aug 2002 03:53
Picon
Picon

conflicting MAC addresses


This might have been discussed in the past although scanning
the list since 1998 doesnt seem to provide an answer.

Has anyone thought about the effect of having two pairs of routers VRRPing
for different IPs with an end result of the same VMAC address being used
by two routers on the same broadcast domain? Actually not concerned
about VRRP perse; rather say VRRP and HSRP.

Is there a simple way to work around this via dynamic discovery (sure easy
to do via static configs)?

cheers,
jamal

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 4 comments |
headers
danny mitzel | 28 Aug 2002 04:42
Picon
Favicon

Re: conflicting MAC addresses


--- jamal <hadi <at> cyberus.ca> wrote:
>> Has anyone thought about the effect of having two
pairs 
>> of routers VRRPing for different IPs with an end
result 
>> of the same VMAC address being used by two routers
on the 
>> same broadcast domain?

the vrrp protocol receive processing (rfc2338 section
7.1)
specifies:
>      - MAY verify that the IP address(es) associated
with 
>	the VRID are valid
>   If the above check fails, the receiver SHOULD log
the event 
>   and MAY indicate via network management that a
misconfiguration 
>   was detected.  If the packet was not generated by
the address 
>   owner (Priority does not equal 255 (decimal)), the
receiver MUST 
>   drop the packet, otherwise continue processing.
if the implementation you're using follows this
recommendation
and encounters two vrrp virtual routers using same
vrid with
different addresses then you should at least get some
(Continue reading)

Permalink | Reply | 3 comments |
headers
jamal | 28 Aug 2002 04:59
Picon
Picon

Re: conflicting MAC addresses


On Tue, 27 Aug 2002, danny mitzel wrote:

>
> --- jamal <hadi <at> cyberus.ca> wrote:
> >> Has anyone thought about the effect of having two
> pairs
> >> of routers VRRPing for different IPs with an end
> result
> >> of the same VMAC address being used by two routers
> on the
> >> same broadcast domain?
>
> the vrrp protocol receive processing (rfc2338 section
> 7.1)
> specifies:

[..]

>
> >> Actually not concerned about VRRP perse; rather say
> VRRP
> >> and HSRP.
>
> vrrp calculates its vmac using a range of mac
> addresses
> assigned from official ietf OUI.  I can't remember the
>
> hsrp algorithm from memory but I can say it doesn't
> use
(Continue reading)

Permalink | Reply | 2 comments |
headers
danny mitzel | 28 Aug 2002 05:34
Picon
Favicon

Re: conflicting MAC addresses


--- jamal <hadi <at> cyberus.ca> wrote:

> A CISCO running HSRP on the same network is
> 00-00-5E-00-01-1F;

the original rfc submitted to document hsrp
(rfc2281) states the hsrp mac is from the cisco 
oui (00:00:0c:07:ac:{hsrp group number}).  from
the latest ios 12.2 docs online this still seems
unchanged.  my only guess would be that someone
has used a 'value add' ios feature 
[e.g. standby mac-address <mac-address>] to 
utilize non-standard hsrp group mac address.  
not a very smart idea IMO.

later,danny

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 1 comment |
headers
jamal | 28 Aug 2002 14:28
Picon
Picon

Re: conflicting MAC addresses


Danny,
I agree with your point view in general;
Apart from the "value-adding" crowd, this could be a result of a
misconfiguration; the problem is clearly avoided when the OUIs are
known to be owned by vendors who take a lot of care ensuring they dont
get rotated in decade time-frames. How do you do the same for a
MAC address which is reusable like the VRRP ones are? The dangers of
conflict are pretty high as we have seen.

cheers,
jamal

On Tue, 27 Aug 2002, danny mitzel wrote:

>
> --- jamal <hadi <at> cyberus.ca> wrote:
>
> > A CISCO running HSRP on the same network is
> > 00-00-5E-00-01-1F;
>
> the original rfc submitted to document hsrp
> (rfc2281) states the hsrp mac is from the cisco
> oui (00:00:0c:07:ac:{hsrp group number}).  from
> the latest ios 12.2 docs online this still seems
> unchanged.  my only guess would be that someone
> has used a 'value add' ios feature
> [e.g. standby mac-address <mac-address>] to
> utilize non-standard hsrp group mac address.
> not a very smart idea IMO.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane