Subject: RE: Why Virtual MACs....?

From: "Casey S. Ajalat" <[email-masked]>
Date: Tue, 15 May 2001 06:32:03 -0400

Yet another way of looking at this is:

Scenario 1: Virtual IP but Unique MAC (Badri's suggestion)

- Master Router fails
- Secondary now has IP (IP aliasing for example)
- Secondary issues Grat ARP
- Switch DB is not changed (at L2) but ALL hosts now update their ARP-Cache 
Tables to reflect new MAC for the same IP

Scenario 2: Virtual IP/MAC (RFC 2238)

- Master router fails
- Secondary now owns BOTH Virtual IP/MAC
- Secondary issues Grat ARP
- Switch DB is updated (at L2), all hosts see Grat ARP but their ARP-Cache 
is unchanged

In the first example, the burden is on the host to make sure they reference 
the VRRP IP via the proper MAC address.  In the second (and VRRP Standard), 
the burden is on the switches to reflect the new location of the virtual 
MAC.  The latter is of course preferred.  In a Data Center environment 
where you potentially can have dozens of hosts using the same default 
router (or hundreds in the case of RFC 3069) it quickly becomes clear why 
the current implementation of VRRP makes sense.  i.e. it is significantly 
quicker and more reliable for a couple of switches to update the new 
location of a host/port (i.e. vMAC) in the switch MAC tables than it is for 
hundreds of hosts to update their ARP-Cache tables.

Casey

At 10:49 AM 4/5/2001, Fernandes, Flavio wrote:

>Another way of "looking" at what VRRP tries to address via Virtual Macs:
>
>As VRRP was defined, a concern existed (and still exists) in moving IP
>address
>ownership around.
>
>That is so because management stations normally use IPs as indexes for
>tables in
>their monitoring scheme. It is a bad trouble to have stations confused about
>"who" the
>IP owner really is for the purposes of walking SNMP tables, ping, telnet,
>etc...
>
>Thus, moving the ownership of Mac addresses was the solution found (virtual
>Macs to be
>more exact. :)).
>
>-- flavio
>
>
>-----Original Message-----
>From: Vikram [mailto:[email-masked]]
>Sent: Thursday, April 05, 2001 10:19 AM
>To: Badri Srinivasan S; VRRP
>Subject: Re: Why Virtual MACs....?
>
>
>The moot purpose of the virtual mac is to allow the learning bridges to
>know which lan segment the virtual router is in other than letting the
>failover to be transparent(and fast) to endhosts.
>
>If I missed anything please fill me in.
>
>tks,
>
>vikram
>
>--- Badri Srinivasan S <[email-masked]> wrote:
> > Hi:
> >
> > another doubt down the line...
> >
> > 1. Why is it necessary that the source MAC addr of the VRRP
> > Advertisements
> > must me set to the Virtual MAC addr...i really dont understand the
> > real
> > purpose of virtual MACs...
> >
> > Can we solve the prob without using vMACs but only virtual IPs in the
> > following way..
> >
> > -->Whenever a VRRP router becomes a master, add the virtual IP
> > address
> > to the master's ethernet by doing a IP aliasing..
> > -->Then let the Master do a gratutious ARP for the virtual IP addr
> > ----
> > real MAC combination so that the hosts update their ARP cache with
> > this.
> >
> > -->so when the host wants to send a pckt to the virtual IP, its wiil
> > look into its ARP cache & get the real MAC of the Master..
> > or else , it can make  an ARP req  for the Virtual IP addr , and the
> > Master replies with its real MAC addr & not any vMAC..
> >
> > so the pckts ultimately reach the Master...
> > When the Master goes to the backup state it removes the virtual IP
> > alias..
> > The new Master performs the same steps whenit starts just as above..
> > i.e --> Do an IP alias for the virtual IP
> >     --> do a gratutious ARP with virtual IP --- the new Masters real
> > MAC...
> >
> >
> > if it can be implemented like this , what is the purpose of Virtual
> > MAC..
> >
> > please reply..
> >
> > thanks & Regards,
> > Badri
> >
>
>
>=====
>----
>NO sense being pessimistic. It wouldnt work anyway
>
>__________________________________________________
>Do You Yahoo!?
>Get email at your own domain with Yahoo! Mail.
>http://personal.mail.yahoo.com/

---

From: Jerome Etienne <[email-masked]>
Date: Tue, 15 May 2001 06:59:51 -0400

> hundreds of hosts to update their ARP-Cache tables.

can you elaborate on explaining why it is more reliable or faster ?

---

From: "Casey S. Ajalat" <[email-masked]>
Date: Tue, 15 May 2001 07:23:33 -0400

Reliable:

 From experience primarily.  We're a hosting provider (thousands of 
hosts).  We've seen from time to time misbehaved ARP cache problems with 
hosts than we have with Switches (Switch/Routers).  Granted they are far 
and few in between but when they do happen they're usually a bit more time 
consuming to troubleshoot and isolate especially when you have to deal with 
potentially hundreds of hosts in a large hosting center--the reliability 
becomes important.

Faster:

Sorry for the confusion, I meant quicker to diagnose problems in a large 
hosted environment.  When a VIP/vMAC moves from one port to another on a 
Switch then looking for that information in switch MAC tables is 
significantly less time consuming than looking for MAC/IP (arp cache) 
entries on hundreds of hosts.

Casey

---

From: Jerome Etienne <[email-masked]>
Date: Tue, 15 May 2001 07:31:28 -0400

> potentially hundreds of hosts in a large hosting center--the reliability 

which OS has a misbehaved cache ?
 
> entries on hundreds of hosts.

I considere that the time consumed is negligible in both cases 
because to update a ARP cache is cheap and because the rate of state 
transition is likely low.

---

From: "Casey S. Ajalat" <[email-masked]>
Date: Tue, 15 May 2001 11:47:26 -0400

>which OS has a misbehaved cache ?

Various...see www.securityfocus.com, specifically Bugtaq.

>transition is likely low.

I would agree if the size of the network and the number of hosts are small 
but in large hosting centers this may not be the case.  When assuming 
properly functioning hosts then we generally don't diagnose problems if 
things are running ok.  It is when they DON'T run ok that you need to 
diagnose problems and when you are faced with potentially dozens of hosts 
then it becomes more apparent.

Casey