A general point to keep in mind is that failover, like monitoring CAN be over-engineered to the point where mechanisms put in place to address high-availability needs get in each other's way and undermine the original intent.
----- Original Message ----- From: "Chuck" To: Sent: 23 June 2002 3:30 pm Subject: Re: Re: HSRP [7:47177] > ""Kevin Cullimore"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > A useful notion to keep in mind is that hsrp and its un-patented > > counterparts (you'd think that during the past century, people would learn > > from IBM's example, but apparently that isn't the case) are profoundly > > asymmetric in scope: > > > > they are concerned with the host->default gateway portion of the > > conversation, not the return path (although implementational specifics > might > > force them to address the return path in some circumstances). > > > > CL: good point. in my experience, in the quest for 100% up time, the process > still depends upon routers at either end to determine the reachability and > account for that in the routing protocol. for example, I have my HSRP pair, > and each has a WAN link to different carriers. Those links terminate into > some central network somnewhere. > > CL: so when the remote site HSSRP primary fails, two things have to happen. > 1) the failover router has to take over and 2) the routers at the far end of > the links have to note the link failure to the primary, mark that route as > down, and start using the secondary path. > > CL: seems to me this is the flaw in the system. Might be fine if you are > using HSRP merely as failover connectivity to the internet. May not be so > fine if you are using HSRP as failover from a branch office to HQ. Depending > on the aplication. Depending upon the time it takes to get the new routes in > place. > > > CL: as an aside, I just had a convcersation along these lines with a > customer, to whom I had to explain at length what HSRP was, what it did, how > it behaved, and therefore why what he was thinking was probably not a good > idea. Not that we couldn't have done it. But that in the end what the > customer wanted me to do wuld have put him at more risk than if he left > things as they were. Not to mention the loss of bandwidth that HSRP would > have created for him. > > > > > > > > ----- Original Message ----- > > From: "LongTrip" > > To: > > Sent: 23 June 2002 2:22 pm > > Subject: Re: Re: HSRP [7:47177] > > > > > > > hmmm maybe there was a misunderstanding on my part of an earlier post > that > > > mentioned "The only time you see the virtual MAC address is on the > > original > > > request from the host. Forwarded requests and replies don't use it. ". > > > > > > I understood this to mean that after the initial set up of > communications > > > that the virtual mac address was not used in subsequent data > > transmissions. > > > > > > This will be one for a lab experiment on my part. Until I see it the > > result > > > with my own eyes it will be a question. > > > > > > > > > Kim > > > > > > > > > > > > > > > > > From: "Thomas E. Lawrence" > > > > Date: 2002/06/23 Sun PM 01:08:17 EDT > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: Re: HSRP [7:47177] > > > > > > > > Perhaps this will help explain > > > > > > > > > > > > > > http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c > > > > /ipcprt1/1cdip.htm#xtocid23 > > > > > > > > Yes, HSRP creates a single "virtual" IP and MAC pair. Yes, when one > > router > > > > fails, the standby router "assumes" control of this virtual IP and MAC > > > pair. > > > > > > > > From an end station standpoint, nothing has changed. The end station > > knows > > > > the virtual IP, as configured in it's own settings, or as received as > > part > > > > of its DHCP configuration. In either case, no end station knows all of > > the > > > > IP's of all of the members of the HSRP group. Unless things have > changed > > > > recently, there is no way to configure multiple default gateways on a > > > > Windows machine, at least. This is the reason HSRP, and now VRRP, were > > > > developed. If the end station does not already know the MAC of the > > default > > > > gateway, it sends an ARP request, as is standard operating procedure > for > > > any > > > > host seeking the MAC of an IP. The active router replies with the > > virtual > > > > MAC. > > > > > > > > You may also want to refer to the VRRP RFC. VRRP is the open standard > > > > intended to replace the several proprietary methods that now exist. > The > > > > first couple of pages provide a good explanation and a good background > > of > > > > the problem to be solved. > > > > > > > > ftp://ftp.isi.edu/in-notes/rfc2338.txt > > > > > > > > Tom > > > > > > > > > > > > > > > > ""LongTrip"" wrote in message > > > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > > So you are saying the client never sees the MAC address of RouterA? > > It > > > > only > > > > > sees the MAC address of the "Virtual Router"? > > > > > > > > > > Kim > > > > > > > > > > > > > > > > > From: "Michael L. Williams" > > > > > > Date: 2002/06/23 Sun AM 11:29:24 EDT > > > > > > To: [EMAIL PROTECTED] > > > > > > Subject: Re: HSRP [7:47177] > > > > > > > > > > > > This isn't quite right. See comments below. > > > > > > > > > > > > "Kim Graham" wrote in message > > > > > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > > > > This brings up a question. I understand that after the initial > > "hi I > > > > > will > > > > > > > be handling your requests please use me as your destination mac > > > > address". > > > > > > > (Router talking to client). > > > > > > > > > > > > > > But what happens when the initial router fails and HSRP kicks > in? > > > > After > > > > > an > > > > > > > unreachable, would ClientA send out an arp or would RouterB > > initiate > > > > the > > > > > > > arping to re-establish connections to any client that was using > > > > RouterA > > > > > > > after it noticed that RouterA was not responding? > > > > > > > > > > > > > > Scenario: > > > > > > > > > > > > > > > > > > > > > ClientA ----- RouterA/B(HSRP) ------ ClientB > > > > > > > > > > > > > > ClientA sends a packet to ClientB > > > > > > > ClientA talks to the Virtual RouterA/B -- RouterA/B sends to > > ClientB > > > > > > > RouterA/B tells ClientA -- RouterA will be handling your > requests. > > > > > > > > > > > > Router A never tells Client A that "Router A will be handling your > > > > > > requests". As you mentioned, Client A talks to the Virtual Router > > via > > > > the > > > > > > Virtual IP address which it ARPs to find the Virtual MAC. Client > A > > > > never > > > > > > knows which of the HSRP routers is "intercepting" and processing > > it's > > > > > > requests.... When Client A sends a frame to the Virtual MAC to go > > out > > > > of > > > > > > it's gateway, both Router A and Router B "hear" the packet, but > only > > > the > > > > > > HSRP Active router will process it. So if, the janitor steps in > and > > > > > unplugs > > > > > > Router A, then after Router B misses enough Hello packets from > > Router > > > A, > > > > it > > > > > > declares itself the Active HSRP router for that HSRP group, and at > > that > > > > > > point it starts to process the information sent to the Virtual > > > > IP/Virtual > > > > > > MAC. This is all transparent to the end clients, Client A in this > > > > example. > > > > > > So as far as Client A knows, it's still sending traffic to the > > Virtual > > > > IP > > > > > > via the Virtual MAC address it has in its ARP cache..... > > > > > > > > > > > > HTH, > > > > > > Mike W. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=47252&t=47177 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
