RE: [VRRP] Query on Load sharing using VRRP

Thanks Don and Radia
Now I got the concept that VR MAC address to be used only in case of VRRP
packets, and other IP packets can be sent with either VMAC or physical Mac
address.

But does this cause any issues if we use the L2 switch/Bridge in the LAN
side of the Virtual Router, that learning of 2 diff Mac address for same
port/Router, Here I suppose this will cause only additional entires in the
Switch but no harm, am I correct.

I feel its not mentioned in the Spec , is there a way to include such
modifications also

Best Regards
Gunaseelan V

-----Original Message-----
From: Don Provan [mailto:dprovan@bivio.net]
Sent: Thursday, 20 November 2003 1:38 AM
To: 'Radia Perlman'; gunav@future.futsoft.com
Cc: vrrp@ietf.org
Subject: RE: [VRRP] Query on Load sharing using VRRP

As far as I can tell, the answer is that "the spec
doesn't say". I interpret this to mean that the spec
considers the question outside it's domain, so the
router should forward the traffic just as it does
without VRRP, which is using it's physical MAC
address as the source. I also claim that this is
the correct answer because the source MAC address
should unambiguously identify the local transmitter.

But I agree that the spec really should spell this
out. The question's come up a few times, and I also
remember spending quite a while puzzling out the
answer myself when I started. Now I consider it
obvious that only VRRP packets should use the
VR MAC address as the source, but I forget that the
spec never actually says that.
-don

> -----Original Message-----
> From: vrrp-admin@ietf.org [mailto:vrrp-admin@ietf.org]On
> Behalf Of Radia
> Perlman
> Sent: Wednesday, November 19, 2003 11:20 AM
> To: gunav@future.futsoft.com
> Cc: vrrp@ietf.org
> Subject: Re: [VRRP] Query on Load sharing using VRRP
>
>
> Re: Gunaseelan V's msg
>
> I think you've raised more than one issue.
>
> I think one thing you were asking is if you
> have two VRs, A and B, and host H1 is using A
> and host H2 is using B, then obviously off-LAN
> traffic from H1 goes through router A and
> off-LAN traffic from H2 goes through router B.
> I think you're asking about traffic from the
> WAN to the LAN. In that case it's irrelevant
> which VRID the endnode is configured with.
> Whichever router receives the packet from the WAN
> will forward it directly to the endnode.
>
> So now:
>
> issue 1: What MAC address should A use when
> forwarding a data packet from off-LAN to on-LAN.
> I think
>    a) it doesn't matter, so for instance it could
>       use its own physical MAC address. I think
>       it doesn't matter because endnodes don't
>       do reverse learning (refresh their ARP
>       cache based on seeing the source layer 2
>       address in received data packets)
>    b) the spec doesn't say
> If I'm right about b), then the spec ought to
> say something about it. If I'm right about a) then
> it can pick anything (its own MAC address or the
> VMAC address). If I'm wrong, and it matters, then
> the spec should say whatever works.
>
> As for what you said here:
> > Are there any way of classifying Hosts' IP address of to VRIDs ,
> > Need some
> > help in this reg
> >
> > Also pl hint me what type of support is needed from IP like
> Aliasing,
> > multinetting etc
>
> I can't quite parse it, so I'll let someone
> else comment.
>
> Radia
>
>
>
> _______________________________________________
> vrrp mailing list
> vrrp@ietf.org
> https://www1.ietf.org/mailman/listinfo/vrrp

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp