From VRRP-owner@drcoffsite.com Tue May 2 17:56:34 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09435 for ; Tue, 2 May 2000 17:56:32 -0400 (EDT) Received: from fw1.tbb.com.tw [210.61.159.253] by drcoffsite.com (SMTPD32-5.05) id AD978C402F8; Tue, 02 May 2000 17:50:15 -0400 Received: from 210.61.159.253 by fw1.tbb.com.tw (SMI-8.6/SMI-SVR4) id FAA26797; Wed, 3 May 2000 05:28:21 +0800 From: Search-Magic@imove.fsnet.co.uk Message-Id: <200005022128.FAA26797@ fw1.tbb.com.tw> Date: Wed, 03 May 00 14:41:10 EST To: Search-Magic@imove.fsnet.co.uk Subject: Search Engine Secrets Discovered Precedence: bulk Sender: VRRP-owner@drcoffsite.com "Amazing Search Engine Secrets Discovered By A Computer Illiterate Man in Massachusetts Can Practically Hand You the Top Search Engine Positions...And Add 1,550 Hits a Day to Web Site Overnight!" Dear Friend, Remember the first time you built a web site. You stayed up until the early morning working it out so that it would be just perfect. Then, you were finally done and you sat back and thought, "The World is Good." After that, you've dreamed of all the visitors your site would have, how they would all see your ad and buy your product. Then it hit you, like a ton of bricks....How was anyone going to find your web site? You thought about it for a while and eventually thought you had the answer....submit your site to the search engines. But after you submitted your site you checked it out and couldn't find it. So you waited a few days.....and still nothing You couldn't even find your site if you looked up your own name!!! Then, you got discouraged....after all that hard work NOTHING?!?!? And this is where most people give up..... BUT You Don't Have To... You can achieve top 20 positioning for your web site...and the tens of thousands of hits which come with it...if you have the "Right" information available to you. For Example, did you know: * Infoseek, Alta Vista, and HotBot ban web sites which break their rules (many of the 'insider' techniques most experts recommend will get you banned faster than you could imagine). * Many search engines limit the number of pages you can submit from your domain (some only allow you to submit one page for best results), although we can show you a technique we use to get hundreds of our pages listed. * Yahoo only lists about 1% of the web in their actual directory. To even get your page listed, you may have to use the "backdoor". * Using a so-called search engine submission software that submits your site to 1,000 or more search engines could actually get your page deleted from the major search engines. * 95% of Internet traffic originates at one of the 10 major search engines...If you're not listed, you might as well not even have a web site! * Choosing the most effective 'keywords' is one of the major keys to a successful web site submission...Pick the right ones and your web site will look like Grand Central Station during rush hour! It has taken us over 2 years to learn how to consistently and without fail place any type of web site in the top 20 of the major search engines. Normally, we charge $500 per keyword that you want a top ranking on (plus a monthly fee of $150 for keeping that rank), but we have found we just don't have enough time for all of the clients that desperately need our services... So, we have produced a "Search Engine Magic" interactive CD-ROM that will show you step by step how to create pages which storm the search engines and lay hold to the precious Top 20 positions that millions of people are trying to reach. The Search Engine Magic CD-ROM consists of 21 interactive video and audio lessons that will run on any IBM compatible computer showing you the exact step-by-step process we use to traffic thousands of visitors to our web sites every single day. You will learn: * Three Different Methods We Use to Pick the Best Traffic Producing Keywords for any web site...and how you can have a list of hundreds of popular keywords in only a few minutes. * How Quick and Easy it is to Create 'Doorway' and 'Hallway' pages for the search engines so that you could possibly have thousands of different pages on your domain all pulling in visitors for your site 24 hours a day 7 days a week. * The Secret Weapon that gives you an "Unfair Advantage" over your competition...and virtually assures you will reach the top positions (don't let your competitors hear about this one first or you will be in trouble). * How to Submit Your Pages to the Search Engines and assure that every single one of them gets listed. (if you listen to one of those amateurs tell you how to list your site, you may just get banned for life). * How to Use Pay-Per-Click search engines to receive over 10,000 visitors for only $100 * The Infamous Yahoo backdoor...You can get listed and we will show you the quickest and easiest method for doing so! * And much, much more... Even Better, You'll Get the Same Results For A Fraction of What Everyone Else Had to Pay! Listen: A lot of people all over the world are gonna be furious with me for sharing these "Insider Secrets" with you...especially since you won't be paying even part of what they had to shell out for one top positioning page! That's just too bad. It's been a secret for too long. So, let me tell you what the deal is.... Contact us today using the below Risk-Free Response Form and you can have all of our secrets for only $139.00. This price wouldn't even buy you 10 minutes of our time at our regular submission fees, but you can own the top search engine positions for less than the cost of a few classified ads! You will be learning everything we know about top positioning! That, my friend, is the bargain of a lifetime for a serious Internet marketer like yourself. What’s more, the money is actually irrelevant, because... You Also Get a 90 Day No-Risk 100% Money-Back Guarantee! Here's how it works. Order your personal copy of this CD-ROM, and use it like you own it. If...For any reason or no reason at all, you aren't completely satisfied after 90 days (by which I had over 47 Top 20 positions for my own web site), just send the CD-ROM back in any condition, and I personally guarantee you to get a complete refund of your purchase price. No questions asked. No problems or forms to fill out. No problems at all. PLUS, You Will Also Receive What is Considered to be by most experts as the "Ultimate Bonus!" For the first 50 people who fill out the below response form and send it in, you will also receive UNLIMITED REPRINT AND REPRODUCTION RIGHTS to this CD-ROM for LIFE! I am not going to allow this CD-ROM to become like many of those over-advertised products you see out there, so only the first 50 will receive these rights. This means that you will be able to use this exact same sales letter, copy the CD-ROM yourself, and sell it For $139.00 a copy, one sell will have breaking even. Sell two copies and you will be in profit.This isn't even counting what the CD-ROM package will do for you! Since only 50 people are going to have these rights... you must take action today! Yours in Success, Michael Burgess To rush order this "Search Engine Magic CD-ROM" simply fill out the order form below and fax it to our 24 hour order line at: FAX ORDER LINE: 1 (212) 504-8032 Regular Mail to: Financial Systems P.O. Box 301 Orange, Ma 01364 ORDER FORM ID#SP502 -------------------------------------------------------- Please send to: Your Name: _____________________________________________ Your Address: __________________________________________ Your City: _____________________________________________ State / Zip: ___________________________________________ Your Country: __________________________________________ Phone #: _______________________________________________ (For problems with your order only. No salesmen will call.) Email Address: ___________________________________________ We Accept Checks or Money Orders along with all Major Credit Cards including Visa, MasterCard, American Express and Discover. (NOTE - We only ship to the address listed on the credit card) (Please Fill Out Below Section and Make sure that the above name and address are listed as it appears on the card) for $144 ($139 + 5.00 Shipping) Credit Card Number:________________________________ Expiration Date:___________________________ Signature:_________________________ Date:____________________ * Please check one of the following payment options: [ ] I am faxing a check (Do not send original, we will make a draft from the faxed check) [ ] I am faxing or mailing my credit card number. (Note your card will be charged for $144.00 and we only ship to the address on the card) [ ] I am enclosing a check or money order for $144.00! Note - If ordering outside continental US, please add $5 to S&H P.S. If you send in your order and you are not one of the first 50 to receive the Reprint and Reproduction Rights, I will notify you immediately and give you the opportunity to cancel your order. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ If you have received this message in error and would like to be removed from future mailings, please reply with the word remove in the subject. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From VRRP-owner@drcoffsite.com Thu May 11 08:42:22 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26114 for ; Thu, 11 May 2000 08:42:21 -0400 (EDT) Received: from naucalpan [132.248.90.200] by drcoffsite.com (SMTPD32-5.05) id A8A6EB31012A; Thu, 11 May 2000 08:33:42 -0400 Received: from 132.248.90.200 by naucalpan (SMI-8.6/SMI-SVR4) id HAA04696; Thu, 11 May 2000 07:14:52 -0500 From: HomeLoans@vwwv.fsnet.co.uk Message-Id: <200005111214.HAA04696@naucalpan> Date: Fri, 12 May 00 00:32:36 EST To: HomeLoans@vwwv.fsnet.co.uk Subject: Home Loans & Refinancing Available Precedence: bulk Sender: VRRP-owner@drcoffsite.com Hit reply to be removed. Homeowners, let the power of the internet work for you. Fill in our quick loan request form and you will get competitive mortgage quotes from 3 of over 150 lenders signed up for our service. When lenders compete you win. Cash back refinances No Equity 2nd Trust Deeds Debt Consolidation No Income Verification The most competitive interest rates! Lenders are standing by, ready to approve your loan today! They will contact you, often minutes after filling in the form or when it's best for you. Visit this site: http://3518593971/bin/redirector.cgi?http://3498852644/?SP0508 (If web site doesn't come right up, please try back later) -Save Time -Save Money -Save Aggravation There is NEVER any fee to consumers for using this service. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Copyright © 1999, 2000 eWorld Marketing, Inc. 1-888-418-2575. This is not a solicitation or offer to lend money. eWorld Marketing is not a lender, broker or other financial intermediary. We provide marketing services to the mortgage industry. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From VRRP-owner@drcoffsite.com Fri May 12 10:37:10 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02883 for ; Fri, 12 May 2000 10:37:09 -0400 (EDT) Received: from dialin156.ottawa.globalserve.net [205.205.36.207] by drcoffsite.com (SMTPD32-5.05) id A4A53850486; Fri, 12 May 2000 10:26:45 -0400 Received: (qmail 706 invoked by uid 1000); 12 May 2000 14:24:26 -0000 Date: Fri, 12 May 2000 10:24:26 -0400 From: Jerome Etienne To: vrrp@drcoffsite.com Subject: why gratuitous arp ? Message-ID: <20000512102426.A674@long-haul.net> Reply-To: jetienne@arobas.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0i Precedence: bulk Sender: VRRP-owner@drcoffsite.com in the rfc2338, each time a router becomes master (rfc2338.6.2.1 and 6.2.2), it must "Broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address associated with the virtual router". but in the text, i don't find an explaination for these ARP requests. my interpretation follows, please comment: - It isn't for update the ARP cache of others computers because each master send the exact same ARP packet. so there is no update to do. - Is it to detect there is multiple master at the same time ? i don't think so because if it happen it is very temporary. - is it to update the spanning tree of the switches we are connected to ? - others ? From VRRP-owner@drcoffsite.com Fri May 12 10:53:12 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03135 for ; Fri, 12 May 2000 10:53:11 -0400 (EDT) Received: from shrimp.baynetworks.com [192.32.253.7] by drcoffsite.com with ESMTP (SMTPD32-5.05) id A8033CA049C; Fri, 12 May 2000 10:41:07 -0400 Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by shrimp.baynetworks.com (8.9.1/8.9.1) with ESMTP id KAA05282; Fri, 12 May 2000 10:36:28 -0400 (EDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id KAA07038; Fri, 12 May 2000 10:46:26 -0400 (EDT) Received: from skibum.engeast (skibum [192.32.138.69]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id KAA18425; Fri, 12 May 2000 10:41:35 -0400 for Received: from localhost by skibum.engeast (SMI-8.6/SMI-SVR4) id KAA20956; Fri, 12 May 2000 10:41:35 -0400 Date: Fri, 12 May 2000 10:41:35 -0400 (EDT) From: Hamayon Mujeeb X-Sender: hmujeeb@skibum To: Jerome Etienne cc: vrrp@drcoffsite.com Subject: Re: why gratuitous arp ? In-Reply-To: <20000512102426.A674@long-haul.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Sender: VRRP-owner@drcoffsite.com On Fri, 12 May 2000, Jerome Etienne wrote: > in the rfc2338, each time a router becomes master (rfc2338.6.2.1 > and 6.2.2), it must "Broadcast a gratuitous ARP request containing > the virtual router MAC address for each IP address associated with the > virtual router". but in the text, i don't find an explaination for > these ARP requests. > > my interpretation follows, please comment: > - It isn't for update the ARP cache of others computers because each > master send the exact same ARP packet. so there is no update to do. It is. Consider the following scenario. Two router in a network, one with address 1.1.1.1 and the other with 1.1.1.2. All hosts have physical MAC of 1.1.1.1 in their cache. Now the network Manager configures a VR on the second router, with IP address 1.1.1.1. The router with physical 1.1.1.1 meanwhile is struck by lightning and dies. The second router comes up in Backup state, waits for timeout and comes up in Master state. Don't you think the hosts deserve a grat. ARP to update for IP 1.1.1.1 ? What I am saying is that for cases where owner VRRP router either dies or never comes up as Master, we need this grat. ARP from any router that changes state from Backup to Master. > - Is it to detect there is multiple master at the same time ? i don't > think so because if it happen it is very temporary. We have Advertisements to cover THAT. I hope it helps ... Then again, what do I know, I just work here ... :-) Hamayon From VRRP-owner@drcoffsite.com Fri May 12 11:10:23 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03732 for ; Fri, 12 May 2000 11:10:22 -0400 (EDT) Received: from dialin156.ottawa.globalserve.net [205.205.36.207] by drcoffsite.com (SMTPD32-5.05) id ABDB19920414; Fri, 12 May 2000 10:57:31 -0400 Received: (qmail 761 invoked by uid 1000); 12 May 2000 14:55:12 -0000 Date: Fri, 12 May 2000 10:55:12 -0400 From: Jerome Etienne To: vrrp@drcoffsite.com Subject: possible clarification on draft-05 Message-ID: <20000512105512.A727@long-haul.net> Reply-To: jetienne@arobas.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0i Precedence: bulk Sender: VRRP-owner@drcoffsite.com it is tiny comment on draft-ietf-vrrp-spec-v2-05.txt. in 6.4.1 and 6.4.2, the same sequence of operations are done when a router enters in the MASTER state. " o Send an ADVERTISEMENT o Broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address associated with the virtual router. o Set the Adver_Timer to Advertisement_Interval o Transition to the {Master} state" I think it would be more clear to replace these duplicates in section 6.4.1 and 6.4.2 by " o Transition to the {Master} state" and to add in section 6.4.3, a sentence like "When a router enters in MASTER state, it must: o Send an ADVERTISEMENT o Broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address associated with the virtual router o Set the Adver_Timer to Advertisement_Interval " From VRRP-owner@drcoffsite.com Fri May 12 11:34:16 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04433 for ; Fri, 12 May 2000 11:34:13 -0400 (EDT) Received: from dialin156.ottawa.globalserve.net [205.205.36.207] by drcoffsite.com (SMTPD32-5.05) id A16912810476; Fri, 12 May 2000 11:21:13 -0400 Received: (qmail 815 invoked by uid 1000); 12 May 2000 15:18:54 -0000 Date: Fri, 12 May 2000 11:18:54 -0400 From: Jerome Etienne To: Hamayon Mujeeb Cc: vrrp@drcoffsite.com Subject: Re: why gratuitous arp ? Message-ID: <20000512111854.A774@long-haul.net> Reply-To: jetienne@arobas.net References: <20000512102426.A674@long-haul.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0i In-Reply-To: ; from hmujeeb@nortelnetworks.com on Fri, May 12, 2000 at 10:41:35AM -0400 Precedence: bulk Sender: VRRP-owner@drcoffsite.com understood, thanks On Fri, May 12, 2000 at 10:41:35AM -0400, Hamayon Mujeeb wrote: > > - It isn't for update the ARP cache of others computers because each > > master send the exact same ARP packet. so there is no update to do. > > It is. > Consider the following scenario. Two router in a network, one with > address 1.1.1.1 and the other with 1.1.1.2. All hosts have physical MAC > of 1.1.1.1 in their cache. Now the network Manager configures a VR > on the second router, with IP address 1.1.1.1. The router with > physical 1.1.1.1 meanwhile is struck by lightning and dies. The second > router comes up in Backup state, waits for timeout and comes up > in Master state. Don't you think the hosts deserve a grat. ARP to > update for IP 1.1.1.1 ? > > What I am saying is that for cases where owner VRRP router either > dies or never comes up as Master, we need this grat. ARP from any > router that changes state from Backup to Master. From VRRP-owner@drcoffsite.com Fri May 12 12:17:13 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05847 for ; Fri, 12 May 2000 12:17:10 -0400 (EDT) Received: from castillo.torrentnet.com [4.18.161.34] by drcoffsite.com with ESMTP (SMTPD32-5.05) id ACE91510660; Fri, 12 May 2000 12:10:17 -0400 Received: from tecate.torrentnet.com (tecate.torrentnet.com [4.18.161.103]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id MAA22890; Fri, 12 May 2000 12:11:18 -0400 (EDT) Received: from torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by tecate.torrentnet.com (8.8.5/8.8.5) with ESMTP id MAA13083; Fri, 12 May 2000 12:11:17 -0400 (EDT) X-Sender: tsjou@torrentnet.com Message-ID: <391C2D25.E6601FF8@torrentnet.com> Date: Fri, 12 May 2000 12:11:17 -0400 From: Tyan-Shu Jou Organization: Ericsson IP Infrastructure X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 2.2.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jetienne@arobas.net CC: Hamayon Mujeeb , vrrp@drcoffsite.com Subject: Re: why gratuitous arp ? References: <20000512102426.A674@long-haul.net> <20000512111854.A774@long-haul.net> Content-Type: multipart/mixed; boundary="------------55308508C5DF2F6AE2D075FD" Precedence: bulk Sender: VRRP-owner@drcoffsite.com This is a multi-part message in MIME format. --------------55308508C5DF2F6AE2D075FD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Well, there used to an (expired) internet draft discussing this issue in general. Due to my laziness it has expired, hence it is no longer carried in ietf repository. I would like to have it revised when I got time.... I am attaching the text file below for whoever is interested. Comments are welcome, of course. -- Tyan-Shu Jou tsjou@torrentnet.com Ericsson IP Infrastructure 919-472-9915 ================= Jerome Etienne wrote: > understood, thanks > > On Fri, May 12, 2000 at 10:41:35AM -0400, Hamayon Mujeeb wrote: > > > - It isn't for update the ARP cache of others computers because each > > > master send the exact same ARP packet. so there is no update to do. > > > > It is. > > Consider the following scenario. Two router in a network, one with > > address 1.1.1.1 and the other with 1.1.1.2. All hosts have physical MAC > > of 1.1.1.1 in their cache. Now the network Manager configures a VR > > on the second router, with IP address 1.1.1.1. The router with > > physical 1.1.1.1 meanwhile is struck by lightning and dies. The second > > router comes up in Backup state, waits for timeout and comes up > > in Master state. Don't you think the hosts deserve a grat. ARP to > > update for IP 1.1.1.1 ? > > > > What I am saying is that for cases where owner VRRP router either > > dies or never comes up as Master, we need this grat. ARP from any > > router that changes state from Backup to Master. ---------------- --------------55308508C5DF2F6AE2D075FD Content-Type: text/plain; charset=us-ascii; name="dupip.txt" Content-Disposition: inline; filename="dupip.txt" Content-Transfer-Encoding: 7bit Network Working Group T.-S. Jou INTERNET-DRAFT IBM Corporation Updates: RFC 826 February, 1999 Duplicate IP Address Detection Based on Gratuitous ARP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract The Address Resolution Protocol specifies the scheme to resolve the hardware address of a host by using its IP address. The hardware addresses are normally unique for each hardware module because they were assigned by manufacturers; but there is much less control on the uniqueness of IP addresses on a LAN. With the booming network popularity, the possibility of the same IP address being used on different hosts is increasing. The duplication may come from users' or network administrators' mistakes, or configuration errors on host addresses assigning programs such as BOOTP or DHCP servers. This document is to define an extension to the original ARP protocol to prevent a newly configured host from making much damage to a host that has been the owner of the same IP address. The solution is based on the de-facto gratuitous ARP packets with modification on a host's behavior when an address duplication is detected. Jou [Page 1] INTERNET_DRAFT Duplicate IP Address Detection February, 1999 Acknowledgments This document was first prepared while the author was an IBM employee. The initial idea was confirmed and tested with help from Lori Napoli and Sajay Khanna in IBM. Thanks also go to Mike Patton in MAP Network Engineering, Inc., for pointing out the security concerns. 1. Introduction The Address Resolution Protocol, defined in RFC 826 [1], is used to determine a host's hardware address based on its network address. To adapt to the possible changes of the association between a hardware address and an IP address, two mechanisms are specified in the RFC: (1) When a host receives an ARP packet and the sender IP address exists in its ARP table, the host should update the cached ARP entry with the sender hardware address in the packet. (2) Each host ages away old ARP entries to allow changes on the network. There are increasing number of hosts that are connected to networks and have IP addresses assigned, some of them dynamically, hence there are increasing number of possibilities that the same IP address is assigned to multiple hosts on a LAN. RFC 826 oversees this problem. Later in this document we can see the above mechanisms even causes catastrophic problems. If address duplication ever occurs, neither of the two hosts sharing the same address can be reliably reached by others because the unpredictable hardware address resolution on the shared IP address. This is especially a serious threat to a server that many clients depend on. The problem can be avoided gracefully if following three conditions are achieved: (a) The host that attempts to use a duplicate IP address can detect this address is being used by another host, and stop using this address immediately, possibly via turning down its interface. (b) The host that originally owns the IP address notifies the the attempting host for the duplication, and then keep operating. (c) The confusion caused by the second host's attempt can be reduced to minimum for all other hosts on the network. A host running one of many latest TCP/IP implementations can generate a gratuitous ARP packet when any of its interfaces is configured, usually at booting time. The gratuitous ARP packet is an ARP request with both sender and the target IP address fields containing the configured IP address. This de-facto behavior can be deployed to detect IP address duplication. After seeing the gratuitous packets, a Jou [Page 2] INTERNET_DRAFT Duplicate IP Address Detection February, 1999 host following RFC 826 will send an ARP reply if the address is being configured on one of its interfaces. Due to the lack of standards, once the gratuitous ARP sender receives the unexpected ARP reply, the response varies. Most implementations can display warning messages on their consoles or to create error logs. Some implementation allows both hosts to keep using this IP address until the problem is corrected manually. Some other implementations disable the networking capability on both hosts and require both hosts to be reconfigured and possibly be rebooted. The latter implementation makes the hosts very vulnerable to configuration errors. The correct behavior should be that the host originally owns this IP address keeps operating, while error messages are reported to draw network administrator's attention. The host that attempts to use a duplicate IP address should stop operating on this address. The problem cannot be fully solved without addressing Condition (c). Since a gratuitous ARP request is a link-layer broadcast packet, all hosts on the network will receive it. According to RFC 826, all hosts that have this IP address cached in their ARP tables will update the entry with the sender hardware address. This behavior originally is designed to allow a host that has just changed its hardware address (such as interface card is replaced) to be able to update others. However, this design results in these hosts not being able to reach the original IP address owner until their ARP entry expires, even if the gratuitous ARP sender stops using the address immediately. Since the gratuitous ARP packet just updated every host's ARP entry, the entry will be valid for the full ARP entry lifetime, normally 20 minutes. As specified by RFC 826, the ARP reply from the original IP address owner is a unicast packet, hence the hosts with the ARP entry cached will not be aware of the occurrence of duplication. To correct the problem, this document specifies the reply of the gratuitous ARP to be a link-layer broadcast packet, hence Condition (c) can be achieved because all other hosts will be able to receive the ARP reply and change their cached entries back to destine to the original address owner. Even thought there is still a window of time that the cached entries are destined to the gratuitous ARP sender, the time period is much shorter than the ARP entry lifetime. 2. Discussion of an Alternative to Broadcast Reply An alternative to replying with a broadcast ARP reply packet is to let the original address owner to send a gratuitous ARP packet again, which can correct other hosts' cached entries as well. However, if for whatever reason the host attempting to use the duplicate IP address chooses to continue operating, that host will reply with an ARP packet. Once the original address owner receives the reply, it becomes a protocol dilemma whether to send another gratuitous ARP, which potentially can cause an infinite looping of ARP packets between the two hosts, or, to hand over the IP address to the new host, which violates Condition (b) we would like to achieve. Jou [Page 3] INTERNET_DRAFT Duplicate IP Address Detection February, 1999 On the other hand, if the link-layer broadcast ARP reply is sent by the original address owner but for some reason the host attempting to use the duplicate IP address is still operating, those hosts that have the ARP entry cached will be able to keep communicating with the original address owner until their ARP entries expire. Since these entries are updated by the broadcast reply, they will remain valid for approximately the full entry lifetime. But those hosts that have to resolve this IP address will see undetermined results. However, if the duplication problem can be fixed in time, perhaps manually by the users or the network administrator, the proposed scheme still causes lesser damage to all hosts on the network. 3. The Solution The implementation details of the solution is described in this section. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. (1) A gratuitous ARP request packet MUST be generated in two situations: (i) when an IP address is being assigned to a working interface, and (ii) when an interface that has IP address assigned is being turned up from down. A gratuitous ARP packet on an Ethernet is defined as 48.bit Destination Address = 0xffffffffffff (broadcast) 48.bit Source Address = Hardware address of interface 16.bit Frame type = 0x806 (ARP) ---------------------- 16.bit Hardware type = 0x1 (Ethernet) 16.bit Protocol Type = 0x800 (IP) 8.bit Hardware Address size = 6 8.bit Protocol Address size = 4 16.bit Opcode = 1 (Request) 48.bit Sender Ethernet Address = Hardware address of interface 32.bit Sender IP Address = Configured IP address 48.bit Target Ethernet Address = Don't care 32.bit Target IP Address = Configured IP Address (2) If a host receives an ARP request packet in which the target IP address and the sender IP address fields are the same and it matches the address of the receiving interface, it implies IP address duplication happens. The host MUST send a link-layer broadcast ARP reply as defined below. The host SHOULD report, log, and/or display warning messages to indicate the detection of IP address duplication. Jou [Page 4] INTERNET_DRAFT Duplicate IP Address Detection February, 1999 48.bit Destination Address = 0xffffffffffff (broadcast) 48.bit Source Address = Hardware address of interface 16.bit Frame type = 0x806 (ARP) ---------------------- 16.bit Hardware type = 0x1 (Ethernet) 16.bit Protocol Type = 0x800 (IP) 8.bit Hardware Address size = 6 8.bit Protocol Address size = 4 16.bit Opcode = 2 (Reply) 48.bit Sender Ethernet Address = Hardware address of interface 32.bit Sender IP Address = Local IP address 48.bit Target Ethernet Address = Sender Addr in Request packet 32.bit Target IP Address = Local IP Address (3) Within a small time period after a host sends a gratuitous ARP packet, if the host receives an ARP reply with both sender IP address and the target IP address fields match the address of the receiving interface, it MUST stop using this address. If this is the only address of the interface, the interface MUST be turned down. If there are multiple IP addresses assigned to the interface, the implementation can choose to only remove the affected address and keep the interface operating with other assigned addresses. The host SHOULD report, log, and/or display messages to indicate the error. If such a reply packet is received outside the time period, the host SHOULD only report, log, and/or display messages, but keep operating with the address. 4. Backwards Compatibility The hosts with this solution implemented can coexist with other hosts that do not have it implemented. The implementation is trivial and the overhead is very limited. Since one of the primary functions to fully solve the problem is that the second host stops using the duplicate IP address, the problem addressed here cannot be completely avoided unless all hosts on the network follow this document. However, because many existing TCP/IP implementations generate gratuitous ARP packet, as well as error reporting when duplication occurs, running hosts with this solution implemented can increase the chance of catching the error at earlier stage and reduce the possible damage made by an error. 5. Security Considerations The proposed solution can decrease the impact when a user, either fraudulently or simply by mistake, configures a host with an existing IP address on the LAN. Nevertheless, the proposed solution is mainly designed to prevent configuration errors, not for malicious attacks. If a hacker can fabricate and transmit ARP packets on a LAN, these packets can easily confuse all hosts on the LAN and to sabotage any Jou [Page 5] INTERNET_DRAFT Duplicate IP Address Detection February, 1999 network operations. Preventing malicious attacks within a LAN is sophisticated, and is out of the scope of this document. A new security concern introduced by the proposed scheme is by having a requirement to disable an interface when a suitable ARP reply is seen. To limit the vulnerability from attacks and network errors, as described in Step (3) of the solution, this disabling SHOULD only happen if the reply is received within some time period of sending out a gratuitous ARP request. A RECOMMENDED default period is 3 seconds, which is long enough to cover normal operations. 6. Reference [1] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, MIT, November 1982. 7. Author's Address Tyan-Shu Jou Torrent Networking Technologies Corporation 3000 Aerial Center Parkway Suite 140 Morrisville, NC 27560 U.S.A. Phone: (919) 468-8466 x233 Email: tsjou@torrentnet.com 8. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Jou [Page 6] INTERNET_DRAFT Duplicate IP Address Detection February, 1999 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Jou [Page 7] --------------55308508C5DF2F6AE2D075FD-- From VRRP-owner@drcoffsite.com Fri May 12 13:52:27 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08459 for ; Fri, 12 May 2000 13:52:25 -0400 (EDT) Received: from theoracle.netiverse.net [209.172.107.51] by drcoffsite.com with ESMTP (SMTPD32-5.05) id A39AC60698; Fri, 12 May 2000 13:47:06 -0400 Received: by THEORACLE with Internet Mail Service (5.5.2650.21) id ; Fri, 12 May 2000 10:48:07 -0700 Message-ID: <578952FF2F92D311A712009027D4DDFC069ADE@THEORACLE> From: Sumandra Majee To: "'Hamayon Mujeeb'" , Jerome Etienne Cc: vrrp@drcoffsite.com Subject: RE: why gratuitous arp ? Date: Fri, 12 May 2000 10:47:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBC3A.34E59750" Precedence: bulk Sender: VRRP-owner@drcoffsite.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFBC3A.34E59750 Content-Type: text/plain; charset="iso-8859-1" VRRP keeps the same IP<->mac binding. So in essence the end host doesn't need to know any new binding. However I think the switches(or other L2 device) do learn from this request and update their table, apart from finding any duplication of ip address. -----Original Message----- On Fri, 12 May 2000, Jerome Etienne wrote: > in the rfc2338, each time a router becomes master (rfc2338.6.2.1 > and 6.2.2), it must "Broadcast a gratuitous ARP request containing > the virtual router MAC address for each IP address associated with the > virtual router". but in the text, i don't find an explaination for > these ARP requests. > > my interpretation follows, please comment: > - It isn't for update the ARP cache of others computers because each > master send the exact same ARP packet. so there is no update to do. It is. Consider the following scenario. Two router in a network, one with address 1.1.1.1 and the other with 1.1.1.2. All hosts have physical MAC of 1.1.1.1 in their cache. Now the network Manager configures a VR on the second router, with IP address 1.1.1.1. The router with physical 1.1.1.1 meanwhile is struck by lightning and dies. The second router comes up in Backup state, waits for timeout and comes up in Master state. Don't you think the hosts deserve a grat. ARP to update for IP 1.1.1.1 ? What I am saying is that for cases where owner VRRP router either dies or never comes up as Master, we need this grat. ARP from any router that changes state from Backup to Master. > - Is it to detect there is multiple master at the same time ? i don't > think so because if it happen it is very temporary. We have Advertisements to cover THAT. I hope it helps ... Then again, what do I know, I just work here ... :-) Hamayon ------_=_NextPart_001_01BFBC3A.34E59750 Content-Type: text/html; charset="iso-8859-1" RE: why gratuitous arp ?

VRRP keeps the same IP<->mac binding. So in essence the end host doesn't need to know
any new binding. However I think the switches(or other L2 device) do learn from this
request and update their table, apart from finding any duplication of ip address.

-----Original Message-----
On Fri, 12 May 2000, Jerome Etienne wrote:

> in the rfc2338, each time a router becomes master (rfc2338.6.2.1
> and 6.2.2), it must "Broadcast a gratuitous ARP request containing
> the virtual router MAC address for each IP address associated with the
> virtual router". but in the text, i don't find an explaination for
> these ARP requests.
>
> my interpretation follows, please comment:
> - It isn't for update the ARP cache of others computers because each
>   master send the exact same ARP packet. so there is no update to do.

It is.
Consider the following scenario. Two router in a network, one with
address 1.1.1.1 and the other with 1.1.1.2. All hosts have physical MAC
of 1.1.1.1 in their cache. Now the network Manager configures a VR
on the second router, with IP address 1.1.1.1. The router with
physical 1.1.1.1 meanwhile is struck by lightning and dies. The second
router comes up in Backup state, waits for timeout and comes up
in Master state. Don't you think the hosts deserve a grat. ARP to
update for IP 1.1.1.1 ?

What I am saying is that for cases where owner VRRP router either
dies or never comes up as Master, we need this grat. ARP from any
router that changes state from Backup to Master.

> - Is it to detect there is multiple master at the same time ? i don't
>   think so because if it happen it is very temporary.

We have Advertisements to cover THAT.

I hope it helps ...
Then again, what do I know, I just work here ... :-)

Hamayon

------_=_NextPart_001_01BFBC3A.34E59750-- From VRRP-owner@drcoffsite.com Fri May 12 14:07:19 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08806 for ; Fri, 12 May 2000 14:07:18 -0400 (EDT) Received: from dialin156.ottawa.globalserve.net [205.205.36.207] by drcoffsite.com (SMTPD32-5.05) id A74DF40590; Fri, 12 May 2000 14:02:53 -0400 Received: (qmail 1336 invoked by uid 1000); 12 May 2000 18:00:22 -0000 Date: Fri, 12 May 2000 14:00:22 -0400 From: Jerome Etienne To: Sumandra Majee Cc: "'Hamayon Mujeeb'" , vrrp@drcoffsite.com Subject: Re: why gratuitous arp ? Message-ID: <20000512140022.B1295@long-haul.net> Reply-To: jetienne@arobas.net References: <578952FF2F92D311A712009027D4DDFC069ADE@THEORACLE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0i In-Reply-To: <578952FF2F92D311A712009027D4DDFC069ADE@THEORACLE>; from smajee@netiverse.net on Fri, May 12, 2000 at 10:47:56AM -0700 Precedence: bulk Sender: VRRP-owner@drcoffsite.com On Fri, May 12, 2000 at 10:47:56AM -0700, Sumandra Majee wrote: > VRRP keeps the same IP<->mac binding. So in essence the end host doesn't > need to know any new binding. as i understood what Hamayon Mujeeb said, it is needed. i will try to rephrase it and hope it will help. before the virtual router start, the ARP cache of the hosts on the network may contain the 'IP address owner' associated with its real MAC address (i.e. not the VRRP one). So when the virtual router start and send gratuitous ARP request for the virtual router address (which happen to be the same), so the hosts updates their cache. If no gratuitous ARP is sent, the hosts won't be able to communicate until the old entry timeout. > However I think the switches(or other L2 device) do learn > from this > request and update their table, apart from finding any duplication of ip > address. From VRRP-owner@drcoffsite.com Fri May 12 14:46:11 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09656 for ; Fri, 12 May 2000 14:46:09 -0400 (EDT) Received: from yarilo.pluris.com [208.227.9.12] by drcoffsite.com with ESMTP (SMTPD32-5.05) id AF52206D04E8; Fri, 12 May 2000 14:37:06 -0400 Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA20657; Fri, 12 May 2000 11:38:03 -0700 (PDT) Received: by monterey-40.pluris.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 May 2000 11:38:03 -0700 Message-ID: From: Vivek Menezes To: "'jetienne@arobas.net'" , Sumandra Majee Cc: "'Hamayon Mujeeb'" , vrrp@drcoffsite.com Subject: RE: why gratuitous arp ? Date: Fri, 12 May 2000 11:37:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: VRRP-owner@drcoffsite.com Another thing to note is that the gratuitous arp can get lost. The protocol has no means of recovery from this. However since the arp entries on the hosts would timeout they would get the correct mapping at some point of time. Implementations might wanna consider this. Vivek. -----Original Message----- From: Jerome Etienne [mailto:jetienne@arobas.net] Sent: Friday, May 12, 2000 11:00 AM To: Sumandra Majee Cc: 'Hamayon Mujeeb'; vrrp@drcoffsite.com Subject: Re: why gratuitous arp ? On Fri, May 12, 2000 at 10:47:56AM -0700, Sumandra Majee wrote: > VRRP keeps the same IP<->mac binding. So in essence the end host doesn't > need to know any new binding. as i understood what Hamayon Mujeeb said, it is needed. i will try to rephrase it and hope it will help. before the virtual router start, the ARP cache of the hosts on the network may contain the 'IP address owner' associated with its real MAC address (i.e. not the VRRP one). So when the virtual router start and send gratuitous ARP request for the virtual router address (which happen to be the same), so the hosts updates their cache. If no gratuitous ARP is sent, the hosts won't be able to communicate until the old entry timeout. > However I think the switches(or other L2 device) do learn > from this > request and update their table, apart from finding any duplication of ip > address. From VRRP-owner@drcoffsite.com Fri May 12 15:02:31 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09980 for ; Fri, 12 May 2000 15:02:30 -0400 (EDT) Received: from dialin156.ottawa.globalserve.net [205.205.36.207] by drcoffsite.com (SMTPD32-5.05) id A302213B04E8; Fri, 12 May 2000 14:52:50 -0400 Received: (qmail 1399 invoked by uid 1000); 12 May 2000 18:50:30 -0000 Date: Fri, 12 May 2000 14:50:30 -0400 From: Jerome Etienne To: Vivek Menezes Cc: "'jetienne@arobas.net'" , Sumandra Majee , "'Hamayon Mujeeb'" , vrrp@drcoffsite.com Subject: Re: why gratuitous arp ? Message-ID: <20000512145030.A1386@long-haul.net> Reply-To: jetienne@arobas.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0i In-Reply-To: ; from vivek@pluris.com on Fri, May 12, 2000 at 11:37:59AM -0700 Precedence: bulk Sender: VRRP-owner@drcoffsite.com On Fri, May 12, 2000 at 11:37:59AM -0700, Vivek Menezes wrote: > Another thing to note is that the gratuitous arp can get lost. The protocol > has no means of > recovery from this. However since the arp entries on the hosts would timeout > they would get the correct mapping at some point of time. > > Implementations might wanna consider this. It may be a good idea to advice in the draft to send 3 requests to reduce this effect. From VRRP-owner@drcoffsite.com Fri May 12 15:35:19 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11090 for ; Fri, 12 May 2000 15:35:16 -0400 (EDT) Received: from theoracle.netiverse.net [209.172.107.51] by drcoffsite.com with ESMTP (SMTPD32-5.05) id AB0A59804A0; Fri, 12 May 2000 15:27:06 -0400 Received: by THEORACLE with Internet Mail Service (5.5.2650.21) id ; Fri, 12 May 2000 12:28:08 -0700 Message-ID: <578952FF2F92D311A712009027D4DDFC069AE1@THEORACLE> From: Sumandra Majee To: Sumandra Majee , "'Hamayon Mujeeb'" Cc: "'vrrp@drcoffsite.com'" Subject: RE: why gratuitous arp ? Date: Fri, 12 May 2000 12:27:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBC48.15687E20" Precedence: bulk Sender: VRRP-owner@drcoffsite.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFBC48.15687E20 Content-Type: text/plain; charset="iso-8859-1" On Fri, 12 May 2000, Sumandra Majee wrote: > VRRP keeps the same IP<->mac binding. So in essence the end host doesn't > need to know Host do need the new binding ... when you configure VRRP dynamically with Virtual IP address that is also present as a real address. As I said (below) the hosts would have the physical MAC to IP binding in their caches and that needs to be changed once VRRP routers come up. So you do need a grat. ARP from Master to update those cache entries. You have to cover this "initial condition" in order for the protocol to work. Hamayon -------------------------------------------------------------------- Let me see. When a host wants to send a packet to an IP address the host would ARP for that IP address and get the MAC address if it doesn't have the address in ARP cache. Once it is in the host keeps it for a fairly long time (20min~housrs in many hosts). As long as this binding remains same nothing has changed form the perspective of the host. What you describe above(as I understood) is duplicate address detection. Lets say router R1 and R2 have a virtual IP address of IP(v)[MAC(v)]. They are not yet configured and assuming there is another device in the same subnet with same IP(v) and MAC1, hosts C would keep sending packets to MAC1 and not MAC(v). A gratuitous ARP would show the duplicate if it is not lost(Vivek). This is really a small case. Certainly this is one use. If the failover solution could have been built based on gratuitous then it would have been[RFC 826]. In fact there is a paper which uses this to allow the backup file server to take over the primary. The feature is when a host rcvs. a ARP req. for which it already has cache entry then it will overwrite it with the hardware address. Unfortunately not all host implementation supports that. For that matter, there are implementations which do not even support gratuitous ARP. Consider the other side effect of the ARP req. when there are L2 devices(most likely) between routers and hosts. The gratuitous arp actually helps this devises to "learn" this new MAC-port binding. The backup router is plugged to different port and certainly there is port change. I could see this as one benefit(side effect) of grat. (tired of typing) ARP. /Sumandra > any new binding. However I think the switches(or other L2 device) do learn > from this > request and update their table, apart from finding any duplication of ip > address. > > -----Original Message----- > On Fri, 12 May 2000, Jerome Etienne wrote: > > > in the rfc2338, each time a router becomes master (rfc2338.6.2.1 > > and 6.2.2), it must "Broadcast a gratuitous ARP request containing > > the virtual router MAC address for each IP address associated with the > > virtual router". but in the text, i don't find an explaination for > > these ARP requests. > > > > my interpretation follows, please comment: > > - It isn't for update the ARP cache of others computers because each > > master send the exact same ARP packet. so there is no update to do. > > It is. > Consider the following scenario. Two router in a network, one with > address 1.1.1.1 and the other with 1.1.1.2. All hosts have physical MAC > of 1.1.1.1 in their cache. Now the network Manager configures a VR > on the second router, with IP address 1.1.1.1. The router with > physical 1.1.1.1 meanwhile is struck by lightning and dies. The second > router comes up in Backup state, waits for timeout and comes up > in Master state. Don't you think the hosts deserve a grat. ARP to > update for IP 1.1.1.1 ? > > What I am saying is that for cases where owner VRRP router either > dies or never comes up as Master, we need this grat. ARP from any > router that changes state from Backup to Master. > > > - Is it to detect there is multiple master at the same time ? i don't > > think so because if it happen it is very temporary. > > We have Advertisements to cover THAT. > > I hope it helps ... > Then again, what do I know, I just work here ... :-) > > Hamayon > ------_=_NextPart_001_01BFBC48.15687E20 Content-Type: text/html; charset="iso-8859-1" RE: why gratuitous arp ?

On Fri, 12 May 2000, Sumandra Majee wrote:

> VRRP keeps the same IP<->mac binding. So in essence the end host doesn't
> need to know

Host do need the new binding ... when you configure VRRP dynamically
with Virtual IP address that is also present as a real address. As I said
(below) the hosts would have the physical MAC to IP binding in their
caches and that needs to be changed once VRRP routers come up. So you
do need a grat. ARP from Master to update those cache entries. You have
to cover this "initial condition" in order for the protocol to work.

Hamayon
--------------------------------------------------------------------
Let me see. When a host wants to send a packet to an IP address the host would ARP for that
IP address and get the MAC address if it doesn't have the address in ARP cache. Once it is
in the host keeps it for a fairly long time (20min~housrs in many hosts). As long as this binding remains
same nothing has changed form the perspective of the host.

What you describe above(as I understood) is duplicate address detection. Lets say router R1
and R2 have a virtual IP address of IP(v)[MAC(v)]. They are not yet configured and assuming there
is another device in the same subnet with same IP(v) and MAC1, hosts C would keep sending packets to
MAC1 and not MAC(v). A gratuitous ARP would show the duplicate if it is not lost(Vivek). This
is really a small case. Certainly this is one use.
If the failover solution could have been built based on gratuitous then it would
have been[RFC 826]. In fact there is a paper which uses this to allow the backup file server to
take over the primary. The feature is when a host rcvs. a ARP req. for which it already has cache
entry then it will overwrite it with the hardware address. Unfortunately not all host implementation
supports that. For that matter, there are implementations which do not even support gratuitous ARP.

Consider the other side effect of the ARP req. when there are L2 devices(most likely) between routers and
hosts. The gratuitous arp actually helps this devises to "learn" this new MAC-port binding. The backup
router is plugged to different port and certainly there is port change. I could see this as one
benefit(side effect) of grat. (tired of typing) ARP.

/Sumandra


> any new binding. However I think the switches(or other L2 device) do learn
> from this
> request and update their table, apart from finding any duplication of ip
> address.
>
> -----Original Message-----
> On Fri, 12 May 2000, Jerome Etienne wrote:
>
> > in the rfc2338, each time a router becomes master (rfc2338.6.2.1
> > and 6.2.2), it must "Broadcast a gratuitous ARP request containing
> > the virtual router MAC address for each IP address associated with the
> > virtual router". but in the text, i don't find an explaination for
> > these ARP requests.
> >
> > my interpretation follows, please comment:
> > - It isn't for update the ARP cache of others computers because each
> >   master send the exact same ARP packet. so there is no update to do.
>
> It is.
> Consider the following scenario. Two router in a network, one with
> address 1.1.1.1 and the other with 1.1.1.2. All hosts have physical MAC
> of 1.1.1.1 in their cache. Now the network Manager configures a VR
> on the second router, with IP address 1.1.1.1. The router with
> physical 1.1.1.1 meanwhile is struck by lightning and dies. The second
> router comes up in Backup state, waits for timeout and comes up
> in Master state. Don't you think the hosts deserve a grat. ARP to
> update for IP 1.1.1.1 ?
>
> What I am saying is that for cases where owner VRRP router either
> dies or never comes up as Master, we need this grat. ARP from any
> router that changes state from Backup to Master.
>
> > - Is it to detect there is multiple master at the same time ? i don't
> >   think so because if it happen it is very temporary.
>
> We have Advertisements to cover THAT.
>
> I hope it helps ...
> Then again, what do I know, I just work here ... :-)
>
> Hamayon
>

------_=_NextPart_001_01BFBC48.15687E20-- From VRRP-owner@drcoffsite.com Sat May 13 03:03:23 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06165 for ; Sat, 13 May 2000 03:03:23 -0400 (EDT) Received: from web1104.mail.yahoo.com [128.11.23.124] by drcoffsite.com (SMTPD32-5.05) id AB24241D0528; Sat, 13 May 2000 02:50:12 -0400 Received: (qmail 17289 invoked by uid 60001); 13 May 2000 06:51:13 -0000 Message-ID: <20000513065113.17288.qmail@web1104.mail.yahoo.com> Received: from [24.5.224.44] by web1104.mail.yahoo.com; Fri, 12 May 2000 23:51:13 PDT Date: Fri, 12 May 2000 23:51:13 -0700 (PDT) From: Erick Reply-To: erickbe@yahoo.com Subject: Re: why gratuitous arp ? To: Hamayon Mujeeb , Jerome Etienne Cc: vrrp@drcoffsite.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Sender: VRRP-owner@drcoffsite.com > Consider the following scenario. Two router in a > network, one with address 1.1.1.1 and the other with > 1.1.1.2. All hosts have physical MAC of 1.1.1.1 in > their cache. Now the network Manager configures a VR > on the second router, with IP address 1.1.1.1. The > router with physical 1.1.1.1 meanwhile is struck by > lightning and dies. The second router comes up in > Backup state, waits for timeout and comes up in > Master state. Don't you think the hosts deserve a > grat. ARP to update for IP 1.1.1.1 ? Let me take a shot. I see a need for grat. ARPs because let's say when the primary router dies, for some reason the host(s) lose their ARP entry for 1.1.1.1. When the backup comes online the grat. ARP will be sent and the host(s) will know about 1.1.1.1 again. Also could be used to reset aging timer for ARP entries in devices that age out entries after a certain timeframe. Just my 2 cents. ===== - Erick B. | erickbe(a)yahoo.com | http://berk.dhs.org __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ From VRRP-owner@drcoffsite.com Sat May 13 09:10:31 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08561 for ; Sat, 13 May 2000 09:10:30 -0400 (EDT) Received: from cc.archtek.com.tw [203.67.59.20] by drcoffsite.com (SMTPD32-5.05) id A32F45D055C; Sat, 13 May 2000 09:05:51 -0400 Received: from asdhjdjk (cranston-ip-1-165.dynamic.ziplink.net [209.206.4.165]) by cc.archtek.com.tw (8.6.12/8.6.9) with ESMTP id VAA18600; Sat, 13 May 2000 21:07:08 +0800 Message-Id: <200005131307.VAA18600@cc.archtek.com.tw> From: "Ross Brook" <22ptm@safe-mail.net> Subject: You Can Win To: lot989i@cc.archtek.com.tw X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Sat, 13 May 2000 06:44:25 -0500 Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: VRRP-owner@drcoffsite.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA08561 Are you interested in increasing your odds in winning a lottery? To find out how, reply to: mailto:perr89@populus.net?subject=How_to_win We will only respond if all of the information below is completed. Thanks for your time. Name: _________________________________________ Email Address: __________________________________ Address __________________________________________ City ________________________ ST _____ ZIP __________ Phone (_______) ______________________Best time to call. ***************************************************************** This message is sent in compliance of the new email bill section 301. PerSection 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email may be stopped at no cost to you. This message is not intended for residents in the State of WA, CA & VA Screening of addresses has been done to the best of our technical ability. If you are a Washington, Virginia, or California resident please remove yourself. ================================================================= If you wish to be removed from future mailings, please Reply to:mailto:bbtt32@netscape.net?subject=remove From VRRP-owner@drcoffsite.com Wed May 17 12:47:55 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08463 for ; Wed, 17 May 2000 12:47:54 -0400 (EDT) Received: from opera [38.31.49.236] by drcoffsite.com (SMTPD32-5.05) id AB84234E04A8; Wed, 17 May 2000 12:40:36 -0400 From: Opera9@flash.net Subject: Best New Trade Show Display by Opera Portables, Inc. adv Date: Wed, 17 May 2000 12:37:03 -0500 X-Sender: Opera9@flash.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: <200005171240359.SM00589@opera > Precedence: bulk Sender: VRRP-owner@drcoffsite.com Opera Portables, Inc. is offering "by invitation" visits to our web site. Packed full of exciting projects and news, Opera is leading the industry with displays that are as much eye-popping as they are eye catching. Winner of numerous industry awards, including Ernst & Young's Crescendo Award, Exhibitor Magazine's Best New Product, Forty Under 40 and Emerging 30, Opera Portables is a progressive young company with imagination and vision. If you use displays, you really owe it to yourself to check out our stuff! Go to http://3637331613/ Opera Portables, Inc. All removes honored at http://3637331613/removes.htm From VRRP-owner@drcoffsite.com Thu May 18 13:29:00 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10842 for ; Thu, 18 May 2000 13:28:55 -0400 (EDT) Received: from server1.skystream.com [63.89.190.5] by drcoffsite.com with ESMTP (SMTPD32-5.05) id A5BD26A0292; Thu, 18 May 2000 13:17:49 -0400 Received: by SERVER1 with Internet Mail Service (5.5.2650.21) id ; Thu, 18 May 2000 10:18:47 -0700 Message-ID: From: Subodh Nijsure To: "'vrrp@drcoffsite.com'" Subject: VRRP implementations... Date: Thu, 18 May 2000 10:18:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: VRRP-owner@drcoffsite.com Hello Bob, Is their "survey" out there that lists commercial vendors that have currently implemented VRRP? /Subodh Nijsure SkyStream Networks. From VRRP-owner@drcoffsite.com Mon May 22 23:35:20 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15053 for ; Mon, 22 May 2000 23:35:18 -0400 (EDT) Received: from mail.marshill.com [12.5.209.6] by drcoffsite.com (SMTPD32-5.05) id AA8BD5D02A6; Mon, 22 May 2000 23:27:07 -0400 Received: from sdn-ar-003njnbrup242.dialsprint.net (sdn-ar-003njnbrup242.dialsprint.net [168.191.61.132]) by mail.marshill.com (NTMail 3.03.0014/1.afdv) with ESMTP id va016167 for ; Mon, 22 May 2000 14:58:22 -0500 To: Jackie22@IPMailBag.com From: Subject: <(©¿©)> Find Out What They Don't Want You To Know! Date: Mon, 22 May 2000 14:58:21 -0500 Message-Id: <19582168279067@marshill.com> Precedence: bulk Sender: VRRP-owner@drcoffsite.com Dear Friend: If you have already responded to the following announcement a few days ago, that means your package is already on its way and it should be arriving soon! If you have not responded to this before, please pay attention to it now. This is very important!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! IMPORTANT ANNOUNCEMENT IMPORTANT ANNOUNCEMENT ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Your Future May Depend On It! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Before you know about this 'Important Announcement', you must first read the following 'Editorial Excerpts' from some important publications in the United States: NEW YORK TIMES: "In concluding our review of Financial Organizations to effect change in the new millenium, special attention should be called to a California based organization, 'INTERNATIONAL EXCHANGE ALLIANCE'. Members of this organization are amassing hundred of millions of dollars in the currency market using a completely LEGAL method which has NEVER been divulged to the general public. While their purpose is not yet known, their presence has most certainly been felt". NBC NIGHTLY NEWS: "Members of 'International Exchange Alliance', who always keep a low profile, are considered to be some of the wealthiest people in North America". More excerpts later, but first let us give you this very "IMPORTANT ANNOUNCEMENT": ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' We are glad to announce that for the first time and for a very short period of time, INTERNATIONAL EXCHANGE ALLIANCE will instruct a LIMITED number of people worldwide on 'HOW TO CONVERT $25 INTO ONE HUNDRED OF LEGAL CURRENCY'. We will transact the first conversion for you, after that you can easily and quickly do this on your own hundreds or even thousands of times every month. TAKE ADVANTAGE OF THIS "SECRET FLAW"! ****************************************************** ****************************************************** It is even more explosive than we have yet disclosed. While currency does fluctuate daily, we can show you 'HOW TO CONVERT $99 INTO $588 AS MANY TIMES AS YOU WANT'. That means, you will be able to EXCHANGE $99, AMERICAN LEGAL CURRENCY DOLLARS, FOR $580 OF THE SAME. You can do this as many times as you wish, every day, every week, every month. All very LEGAL and effortlessly! It takes only 5 to 10 minutes each time you do this. You can do this from home, office or even while traveling. All you need is access to a phone line and an address. Best of all, you can do this from ANY CITY ON THIS EARTH!!! Again, we must reiterate, anyone can do this and the source is NEVER-ENDING. For as long as the global financial community continues to use different currencies with varying exchange rates, the "SECRET FLAW" will exist. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As we said earlier, we will do the first transaction for you and will show you exactly how to do this on your own, over and over again! The amount of exchange you would do each time is entirely up to you. Working just 2 to 10 hours a week, you can soon join the list of Millionaires who do this on a daily basis many times a day. The transaction is so simple that even a high school kid can do it! We at the International Exchange Alliance would like to see a uniform global currency backed by Gold. But, until then, we will allow a LIMITED number of individuals worldwide to share in the UNLIMITED PROFITS provided for by the world currency differentials. We will not espouse any more political views nor will we ask you to do so. We can say however, that our parent organization, CILS, benefits greatly by the knowledge being shared, as we ourselves, along with YOU, benefit likewise. Your main concern surely will be, how you will benefit. As soon as you become a member, you will make transactions from your home, office, by telephone or through the mail. You can conduct these transactions even while traveling. Don't believe us? Experience it for yourself! ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Unlike anyone else, we will assure you great financial freedom and you will add to our quickly growing base of supporters and join the list of MILLIONAIRES being created using this very "SECRET FLAW" in the world currency market. ****************************************************** ****************************************************** DON'T ENVY US, JOIN US TODAY!!! ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' There is a one-time membership fee of only $195. BUT, if you join within the next 10 days, you can join us for only the $25 administrative cost. Your important documents, instructions, contact name/address, phone number and all other pertinent information will be mailed to you immediately. So join us today! (If you are replying after the 10 day period, you must pay $195.00 for the membership fee. NO EXCEPTIONS, and no more E-mail inquiries please). Upon becoming a member, you promise to keep all information CONFIDENTIAL! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Should you choose to cancel your membership for any reason, you must return all papers/documents for a refund within 30 days. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ IMPORTANT: **************** 1...Please write your name & mailing address VERY CLEARLY on a paper. (No PO Boxes). Please also include your phone number for mailing purposes only. 2...Below your mailing address please write your E-mail address. 3...At the top left hand corner, please write the words "NEW MEMBER". 4...Attach a CHECK for $25 + $16 for the shipping and handling of documents (TOTAL = $41.00) (All documents shipped by courier) Make check PAYABLE TO "HELP" and FAX it to: 435-408-7613 or 612-632-2759 (Note: We are ONLY accepting CHECK-BY-FAX as a form of payment at this time. We WILL be able to cash the check you send us by fax, you do not need to mail us a check. If your check is dark, please PRINT ALL OF THE INFORMATION ON THE CHECK ONTO THE PAPER YOU ARE FAXING US so that it is clearly legible!) Please allow 2-4 weeks for delivery. No shipments will be made until the check has cleared. }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} Here are some more 'Editorial Excerpts': ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WALL STREET: "A discreet group of Americans, operating under the guise of International Exchange Alliance have recently begun making rumbles in world finance market. While at this time, their game is not completely known, they certainly will be watched by those making major moves in the currency contracts". FINANCIAL WEEK: "Watch them, monitor them, extract their knowledge and try to become one of them. That is the soundest financial advice we could give to anyone". NATIONAL BUSINESS WEEKLY: "While this reporter has been left in the cold as to its method of operation, we have been able to confirm that 'International Exchange Alliance' and its members are literally amassing great fortunes overnight". $$$$$$$$$$$$$$$$$$$$$$END$$$$$$$$$$$$$$$$$$$$$$$$$$$ To be removed from our list, simply click "reply" and put the words "Remove Currency" in the subject line. Warning: If you do not put the words "Remove Currency" in the s ubject line, you will not be removed. The process is automated. From VRRP-owner@drcoffsite.com Tue May 23 01:00:24 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15503 for ; Tue, 23 May 2000 01:00:24 -0400 (EDT) Received: from mail.chohungbank.co.kr [210.111.36.40] by drcoffsite.com with ESMTP (SMTPD32-5.05) id AF41A9E026E; Tue, 23 May 2000 00:55:29 -0400 Received: from 210.111.36.51 ([210.111.36.51] (may be forged)) by mail.chohungbank.co.kr (2.5 Build 2639 (Berkeley 8.8.6)/8.8.4) with SMTP id NAA02458; Tue, 23 May 2000 13:48:25 +0900 From: ReduceDebt@wiww.fsnet.co.uk Message-Id: <200005230448.NAA02458@mail.chohungbank.co.kr> Date: Tue, 23 May 00 23:29:20 EST To: ReduceDebt@wiww.fsnet.co.uk Subject: FREE! Confidential Debt Reduction Analysis Precedence: bulk Sender: VRRP-owner@drcoffsite.com Sign-up for a Completely FREE, Confidential Debt Reduction Analysis. ***Limited Time FREE Offer.*** http://3518593971/bin/redirector.cgi?http://3506561041/form_cgi? Our Non-Profit Organization can do the following JUST BY ASKING YOUR CREDITORS: (*)Cut your bills in half. (*)Consolidate your bills into ONE LOW monthly payment. (*)Eliminate interest and late fee charges. (*)Improve your credit rating. (*)NO Need To Own Any Property A trained professional negotiates with your creditors to: 1)Lower your monthly debt payments by 40-60% 2)End creditor harassment 3)Save thousands of dollars in interest and late charges 4)Start improving your credit rating. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ If you have received this message in error and would like to be removed from future mailings, please reply with the word remove in the subject. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From VRRP-owner@drcoffsite.com Tue May 30 11:53:57 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02335 for ; Tue, 30 May 2000 11:53:56 -0400 (EDT) Received: from pmr-linux.flowpoint.com [207.135.89.233] by drcoffsite.com with ESMTP (SMTPD32-5.05) id A1623B1E0486; Tue, 30 May 2000 11:42:26 -0400 Received: from localhost (pmr@localhost) by pmr-linux.flowpoint.com (8.9.3/8.9.3) with ESMTP id IAA02704 for ; Tue, 30 May 2000 08:43:19 -0700 X-Authentication-Warning: pmr-linux.flowpoint.com: pmr owned process doing -bs Date: Tue, 30 May 2000 08:43:19 -0700 (PDT) From: "P. Rakity" To: vrrp@drcoffsite.com Subject: VRRP Question (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Sender: VRRP-owner@drcoffsite.com Hi, I have just read draft 5 for VRRP and the RFC and I am very confused. I was wondering if you could answer some questions. Assuming I have a simple network. R1 has the IP address 192.168.254.254- It is also the Master R2 has IP address 192.168.254.253 - it is the Slave the subnet mask is 255.255.255.0 Each Router has a connection to a WAN. Either ISDN or some from of high speed DSL. The DSL links go to ISP's. There are 20 hosts on the LAN. They use DHCP to get their addreses. 10 of the hosts are active. 10 of the hosts are powered off. Questions are as follows a) What IP address(es) are contained in the IP Address field in the VRRP packet. From the point of view of the master and the slave (if it becomes a master). Eg I do not understand the meaning of the Phrase on Page 14 of the draft, "One or more IP address associated with the virtual router". b) The ARP request send by the Master - what IP address(es) is it ARPing for? I would appreciate the answer from the both the master and slave's point of view. c) Are any packets other the reponse to an ARP request sent to any of the Hosts on the LAN. d) Are any packets sent to any other IP addresses on the LAN other than the VRRP advertisements. kind regards, Philip Rakity From VRRP-owner@drcoffsite.com Tue May 30 12:13:21 2000 Received: from drcoffsite.com (dns1.drcoffsite.com [216.177.1.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03304 for ; Tue, 30 May 2000 12:13:20 -0400 (EDT) Received: from dialin156.ottawa.globalserve.net [205.205.36.156] by drcoffsite.com (SMTPD32-5.05) id A7B0475403B6; Tue, 30 May 2000 12:09:20 -0400 Received: (qmail 870 invoked by uid 1000); 30 May 2000 16:06:16 -0000 Date: Tue, 30 May 2000 12:06:16 -0400 From: Jerome Etienne To: "P. Rakity" Cc: vrrp@drcoffsite.com Subject: Re: VRRP Question (fwd) Message-ID: <20000530120616.C664@long-haul.net> Reply-To: jetienne@arobas.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0i In-Reply-To: ; from pmr@flowpoint.com on Tue, May 30, 2000 at 08:43:19AM -0700 Precedence: bulk Sender: VRRP-owner@drcoffsite.com On Tue, May 30, 2000 at 08:43:19AM -0700, P. Rakity wrote: > a) What IP address(es) are contained in the IP Address field in the VRRP > packet. From the point of view of the master and the slave (if it becomes > a master). Eg I do not understand the meaning of the Phrase on Page 14 > of the draft, "One or more IP address associated with the virtual router". It is the addresses you aim to take over using vrrp. In the rfc2338 you can read: " Virtual Router An abstract object managed by VRRP that acts as a default router for hosts on a shared LAN. It consists of a Virtual Router Identifier and a set of associated IP address(es) across a common LAN. A VRRP Router may backup one or more virtual routers." > b) The ARP request send by the Master - what IP address(es) is it ARPing > for? I would appreciate the answer from the both the master and slave's > point of view. see the thread 'gratuitous arp' on this mailing list, 1 or 2 months ago. > c) Are any packets other the reponse to an ARP request sent to any of the > Hosts on the LAN. please rephraase. i reread this sentence several time and still fail to understand its meaning. > d) Are any packets sent to any other IP addresses on the LAN other than > the VRRP advertisements. no, the only ip packets are the advertissement, and the destination is the multicast address 224.0.0.18