Re: Re: HSRP [7:47177]
Howard C. Berkowitz wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 9:21 PM -0400 6/23/02, Kevin Cullimore wrote: It's a problem when: people assume that symmetry exists when HSRP similar L3 failover technologies are implemented. It's a problem getting in the way of: people's understanding of those failover technologies. Otherwise, I'm thinking that the flexibility (wherein conversations in different directions may be treated differently) is quite welcome. Comments? I was not assuming load-sharing (i.e., multiple HSRP groups), so I'd expect to have the two routers essentially with the same routing table. What would be different would be their uplinks, unless, possibly, there were an additional link connecting the two routers. In other words, I had considered the simple case of two redundant routers, each of which could handle the full load. Perhaps they might have physically diverse uplinks, but I wouldn't expect them to have radically different optimal routes. Consider the following: Local_LAN | -- | | R1 R2 | | telco_1 telco_2 | | R3 R4 | | -- Corporate_Network Seems to me that of R3 and R4, the coproarate network knows one of those as the route to the Local_LAN, preferably the router that is the HSRP primary. hhh thinking about this, interesting design study. HSRP effects only Local_LAN traffic to the Corporate_net. Does return traffic route matter? hhm. would good design consider that R3 and R4 also be an HSRP pair? If they were, what would the effect be, as opposed to if they were not? Maybe I'm outsmarting myself about the data flow implications? Certainly, one can create scenarios where load-sharing or other factors make the two routers significantly different. Depending on the goals and budget, you might even have HSRP in edge routers and more complex routing at a distribution tier. For that matter, people often don't consider L2 failover techniques (e.g., UplinkFast and EtherChannel) with switches feeding the HSRP routers as another aspect of no-single-point-of-failure. - Original Message - From: Howard C. Berkowitz To: Sent: 23 June 2002 3:54 pm Subject: Re: Re: HSRP [7:47177] At 3:08 PM -0400 6/23/02, Kevin Cullimore wrote: 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). Kevin, how is the asymmetry a problem? The HSRP linked routers presumably have the same routing tables, although the backup might have to ARP for its first packet forwarded. Even if that's an issue, promiscuous ARP learning shouldn't be all that much of a problem. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=47289t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Re: HSRP [7:47177]
I think the picture got messed up. But, let's say R1 and R2 are running HSRP on the Local LAN. It doesn't matter which one becomes primary. If the clients send to one router, but the other router has a better route, than the router will send the packet back out the Local LAN to the other router. It's the typical extra hop that many networks have. The router should send an ICMP Redirect (although that is disabled by default when using HSRP.) But it works without any major hitches because both routers have complete routing tables that describe the entire internetwork. Since your picture is symmetrical (or at least I think it was?) the same thing can occur on the Corporate LAN. R3 and R3 can run HSRP too. Now, for traffic coming back, we have a more interesting problem It would depend on the routing protocol and the maximum-paths configuration, wouldn't it? For some routing protocols, each router would only know one way back. If that way includes the broken interface, then the protocol will have to converge before traffic can make it back. A few more comments in line... Consider the following: Local_LAN | -- | | R1 R2 | | telco_1 telco_2 | | R3 R4 | | -- Corporate_Network Seems to me that of R3 and R4, the coproarate network knows one of those as the route to the Local_LAN, preferably the router that is the HSRP primary. You mean the HSRP primary on the Local LAN? Of course the routers on the Corporate Network don't know anything about HSRP on the Local LAN. Plus, it doesn't matter whether their path goes back via R1 or R2. Which one it chooses would depend on the routing protocol. Maybe it's IGRP and one of the links has much less bandwidth so the other is preferred. Maybe you're using variance so that both routes are known. hhh thinking about this, interesting design study. HSRP effects only Local_LAN traffic to the Corporate_net. Does return traffic route matter? HSRP on the Local LAN doesn't affect it. Other things do. hhm. would good design consider that R3 and R4 also be an HSRP pair? In your simple design, sure, I would say make them HSRP pairs too. You might want to know some load balancing and make one the active for some VLANs and the other the active for other VLANs. I know you know all this basic stuff. ;-) If you meant for this to be a more advanced discussion, just let me know. Thanks. Priscilla If they were, what would the effect be, as opposed to if they were not Maybe I'm outsmarting myself about the data flow implications? Certainly, one can create scenarios where load-sharing or other factors make the two routers significantly different. Depending on the goals and budget, you might even have HSRP in edge routers and more complex routing at a distribution tier. For that matter, people often don't consider L2 failover techniques (e.g., UplinkFast and EtherChannel) with switches feeding the HSRP routers as another aspect of no-single-point-of-failure. - Original Message - From: Howard C. Berkowitz To: Sent: 23 June 2002 3:54 pm Subject: Re: Re: HSRP [7:47177] At 3:08 PM -0400 6/23/02, Kevin Cullimore wrote: 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). Kevin, how is the asymmetry a problem? The HSRP linked routers presumably have the same routing tables, although the backup might have to ARP for its first packet forwarded. Even if that's an issue, promiscuous ARP learning shouldn't be all that much of a problem. Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=47300t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HSRP [7:47177]
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. RouterA/B tells ClientB -- RouterA will be handling your requests to ClientA ClientA then sends more packets to ClientB via RouterA. ClientB responds to ClientA via RouterA. Janitor comes in and accidentally unplugs RouterA's power cord. ClientA now has to re-establish a connection with ClientB. I have seen the above scenario happen in a failover test when implementing a new core but did not have a bug in my ear to watch the MAC addresses. It has my curiosity perked. In theory I beleive RouterB would re-establish communication after a failed hi are you there packet to RouterA. I will have to wait until a lab is set up to play out the scenario. Kim Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=47232t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
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=7i=47235t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Re: HSRP [7:47177]
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=7i=47236t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
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=7i=47238t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Re: HSRP [7:47177]
Generally speaking, people tend to configure hsrp for addresses serving as default gateways. When the client's NIC software initializes gathers values for the default gateway (dynamically or otherwise), it arps for the gateway's mac address, which, under ideal conditions, is answered by the active member of the HSRP group. If the active member of the HSRP group fails, and the standby ISs can detect this, They will begin answering on behalf of the mac address associated with the ip default gateway address. If the client attempts to speak directly to the other address the router is maintaining on the same ip network it will arp for the BIA of the IS's ethernet interface. - Original Message - From: LongTrip To: Sent: 23 June 2002 12:44 pm Subject: Re: Re: HSRP [7:47177] 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=7i=47243t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
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=7i=47244t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Re: HSRP [7:47177]
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). - 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=7i=47247t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com
Re: HSRP [7:47177]
Sometimes I suspect we get lost in forest, and all we can see are the trees. Let's look at this from the perspective of how data is moved from here to there. 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 CL: The ARP process is used by any host ( router or PC or other workstation ) when it has data for a particular host at a particular IP address. The host knows through the XOR process that the destination host is on th same subnet. Since devices on the same subnet are operating at the L2 layer, a MAC is required. The host says, essentially I have data for network address. What MAC should I use? and the appropriate host replies use this one - I'm that IP address, here is my MAC address CL: So in the case you state, there is no reason for Router B to do anything. It does not have data to transmit to host A. 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 CL: Not exactly. The router that is the HSRP primary does all the talking to host A. RouterA/B tells ClientA -- RouterA will be handling your requests. CL: not exactly. The HSRP primary device, using the virtual IP/MAC, does all the communication at this point. there is no provision for a process as you describe. Well, maybe proxy ARP falls into this kind of category, but that's different. RouterA/B tells ClientB -- RouterA will be handling your requests to ClientA ClientA then sends more packets to ClientB via RouterA. CL: sure, in practical terms. But host A is still sending packets to the virtual IP/ virtual MAC address, not to physical addresses. ClientB responds to ClientA via RouterA. Janitor comes in and accidentally unplugs RouterA's power cord. ClientA now has to re-establish a connection with ClientB. CL: well, in theory, host A never knows that a failover has occured. So far as host A is concerned, it is still communicating with the physical device whose IP and MAC are those that it learned at the beginning of tis process. that is, the virtual IP/MAC I have seen the above scenario happen in a failover test when implementing a new core but did not have a bug in my ear to watch the MAC addresses. It has my curiosity perked. In theory I beleive RouterB would re-establish communication after a failed hi are you there packet to RouterA. I will have to wait until a lab is set up to play out the scenario. CL: what you should find is that from the host perspective, nothing changes. I don't have sniffer experience, but I would hazzard the guess that your sniffer traces will see no changes to source and destination IP's, and no change to source and destination MACs. I base this upon my understanding of the process of how a host sends packets. A more detailed look at the theory may be found in Comer's Internetworking with TCP/IP volume 1. CL: My point being that the rules of host to host communication do not split off into a zillion different special cases every time some fix or other is introduced. HSRP is based on the router side, and is designed specifically to keep things simple and consistent as far as the hosts on the particular segment are concerned. Packets move from host to host using the same rules and processes every time. These rules don't change just because there is an HSRP router pair on the segment. they do not change just because there is an OSPF virtual link somewhere along the line. They do not change just because you are on dial backup, rather than the primary WAN link. It becomes far easier to understand when you start from the fundamental principal, and move outwards, than if you get lost in the maze of looking at everything as a special case. CL: sorry for the soap box. over the past few days there have been several threads which have indicated to me that certain fundamentals are not understood. Kim Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=47248t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
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 usin
Re: Re: HSRP [7:47177]
I will keep that in mind while investigating this and other things. Thx :) Kim From: Kevin Cullimore Date: 2002/06/23 Sun PM 03:08:54 EDT To: [EMAIL PROTECTED] Subject: Re: Re: HSRP [7:47177] 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). - 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
Re: Re: HSRP [7:47177]
At 3:08 PM -0400 6/23/02, Kevin Cullimore wrote: 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). Kevin, how is the asymmetry a problem? The HSRP linked routers presumably have the same routing tables, although the backup might have to ARP for its first packet forwarded. Even if that's an issue, promiscuous ARP learning shouldn't be all that much of a problem. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=47251t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Re: HSRP [7:47177]
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]"&
Re: HSRP [7:47177]
At 10:19 AM 6/23/02, Kim Graham wrote: 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). Well, there's not really an initial hi, although I like the literary sound of that. The client ARPs for its default gateway and the router answers. The client has been configured with the virtual IP address for the gateway. The active router responds with the virtual MAC address in the ARP reply. 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? It's completely transparent to the client. The standby router takes over and forwards packets addressed to the virtual MAC address. 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. RouterA/B tells ClientB -- RouterA will be handling your requests to ClientA ClientA then sends more packets to ClientB via RouterA. ClientB responds to ClientA via RouterA. Janitor comes in and accidentally unplugs RouterA's power cord. ClientA now has to re-establish a connection with ClientB. I have seen the above scenario happen in a failover test when implementing a new core but did not have a bug in my ear to watch the MAC addresses. It has my curiosity perked. In theory I beleive RouterB would re-establish communication after a failed hi are you there packet to RouterA. I will have to wait until a lab is set up to play out the scenario. Kim Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=47261t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Re: HSRP [7:47177]
At 02:22 PM 6/23/02, LongTrip wrote: 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. . Each request from the host uses the virtual MAC address in the destination. In my experiments, I was only doing a single ping. There was just one request. 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. You jumped to the wrong conclusion. Theoretically, the client doesn't even know any other address. How could it use it? Also, how could redundancy work if it used an actual address for an interface that might go down?? In actuality, the client could know other addresses, by the way, since the ping (or whatever) replies that the router forwards come from the router's real MAC address. But the PC ignores this. Some operating systems could use it though. UNIX used to just reverse the MAC addresses on the next packet. (Long story, not relevant). Also, you might find it interesting (and confusing) to know that the ARP reply from the active HSRP router actually does come from the real address. But the ARP data in the reply supplies the virtual MAC address. Here is the ARP reply from the active HSRP router after the client ARPed for the virtual IP address of the gateway, which was 10.10.0.3. Notice that the source Ethernet address and the Sender's Hardware address in the ARP data don't match? Cool, eh? Ethernet Header Destination: 00:00:0E:D5:C7:E7 Source: 00:00:0C:05:3E:80 Protocol Type:0x0806 IP ARP ARP - Address Resolution Protocol Hardware: 1 Ethernet (10Mb) Protocol: 0x0800 IP Hardware Address Length:6 Protocol Address Length:4 Operation:2 ARP Response Sender Hardware Address:00:00:0C:07:AC:00 Sender Internet Address:10.10.0.3 Target Hardware Address:00:00:0E:D5:C7:E7 Target Internet Address:10.10.0.10 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. Why is it a question? I did a bunch of research for you. Why don't you read what I have written and what others wrote? (Although doing your own research is a good idea too.) Priscilla 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
Re: Re: HSRP [7:47177]
It's a problem when: people assume that symmetry exists when HSRP similar L3 failover technologies are implemented. It's a problem getting in the way of: people's understanding of those failover technologies. Otherwise, I'm thinking that the flexibility (wherein conversations in different directions may be treated differently) is quite welcome. Comments? - Original Message - From: Howard C. Berkowitz To: Sent: 23 June 2002 3:54 pm Subject: Re: Re: HSRP [7:47177] At 3:08 PM -0400 6/23/02, Kevin Cullimore wrote: 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). Kevin, how is the asymmetry a problem? The HSRP linked routers presumably have the same routing tables, although the backup might have to ARP for its first packet forwarded. Even if that's an issue, promiscuous ARP learning shouldn't be all that much of a problem. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=47267t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Re: HSRP [7:47177]
At 9:21 PM -0400 6/23/02, Kevin Cullimore wrote: It's a problem when: people assume that symmetry exists when HSRP similar L3 failover technologies are implemented. It's a problem getting in the way of: people's understanding of those failover technologies. Otherwise, I'm thinking that the flexibility (wherein conversations in different directions may be treated differently) is quite welcome. Comments? I was not assuming load-sharing (i.e., multiple HSRP groups), so I'd expect to have the two routers essentially with the same routing table. What would be different would be their uplinks, unless, possibly, there were an additional link connecting the two routers. In other words, I had considered the simple case of two redundant routers, each of which could handle the full load. Perhaps they might have physically diverse uplinks, but I wouldn't expect them to have radically different optimal routes. Certainly, one can create scenarios where load-sharing or other factors make the two routers significantly different. Depending on the goals and budget, you might even have HSRP in edge routers and more complex routing at a distribution tier. For that matter, people often don't consider L2 failover techniques (e.g., UplinkFast and EtherChannel) with switches feeding the HSRP routers as another aspect of no-single-point-of-failure. - Original Message - From: Howard C. Berkowitz To: Sent: 23 June 2002 3:54 pm Subject: Re: Re: HSRP [7:47177] At 3:08 PM -0400 6/23/02, Kevin Cullimore wrote: 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). Kevin, how is the asymmetry a problem? The HSRP linked routers presumably have the same routing tables, although the backup might have to ARP for its first packet forwarded. Even if that's an issue, promiscuous ARP learning shouldn't be all that much of a problem. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=47273t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Re: HSRP [7:47177]
Comments in line. From: Priscilla Oppenheimer Date: 2002/06/23 Sun PM 08:19:23 EDT To: [EMAIL PROTECTED] Subject: Re: Re: HSRP [7:47177] At 02:22 PM 6/23/02, LongTrip wrote: 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. . Each request from the host uses the virtual MAC address in the destination. In my experiments, I was only doing a single ping. There was just one request. 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. You jumped to the wrong conclusion. Theoretically, the client doesn't even know any other address. How could it use it? Also, how could redundancy work if it used an actual address for an interface that might go down?? Agreed, hence my curiosity. As mentioned earlier it was a misinterruptation on my part. Thank you for taking the time to explain. Also, you might find it interesting (and confusing) to know that the ARP reply from the active HSRP router actually does come from the real address. But the ARP data in the reply supplies the virtual MAC address. Here is the ARP reply from the active HSRP router after the client ARPed for the virtual IP address of the gateway, which was 10.10.0.3. Notice that the source Ethernet address and the Sender's Hardware address in the ARP data don't match? Cool, eh? Very cool :) Ethernet Header Destination: 00:00:0E:D5:C7:E7 Source: 00:00:0C:05:3E:80 Protocol Type:0x0806 IP ARP ARP - Address Resolution Protocol Hardware: 1 Ethernet (10Mb) Protocol: 0x0800 IP Hardware Address Length:6 Protocol Address Length:4 Operation:2 ARP Response Sender Hardware Address:00:00:0C:07:AC:00 Sender Internet Address:10.10.0.3 Target Hardware Address:00:00:0E:D5:C7:E7 Target Internet Address:10.10.0.10 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. Why is it a question? I did a bunch of research for you. Why don't you read what I have written and what others wrote? (Although doing your own research is a good idea too.) I am not dismissing anyone's research or explainations, I am thankful there are others out there willing to share thoughts, research and ideas. But as you say doing your own research is a good idea. I learn a lot by reading, as well as a lot from doing. It is a kin to if you push the wagon down the hill full it goes faster than if it was empty. We all know that fact, but the ride down the hill in a speeding red, wood panelled wagon is much more fun than watching it go down the hill empty. Kim Priscilla 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 under
Re: HSRP [7:47177]
Tim, If you have not hard configured the MAC address then it will be the MAC of the virtual router. This MAC address is a combination of 3 things; vendor code, well known HSRP virtual MAC address, and the group number of the active router. Below are listed some sources of information. http://www.cisco.com/warp/public/473/62.shtml#addressing Quote: HSRP Standby IP Address Communication (All Media Except Token Ring) Since host workstations are configured with their default gateway as the HSRP standby IP address, hosts must communicate with the MAC address associated with the HSRP standby IP address. This MAC address will be a virtual MAC address composed of .0c07.ac**, where ** is the HSRP group number in hexadecimal based on the respective interface. For example, HSRP group one will use the HSRP virtual MAC address of .0c07.ac01. Hosts on the adjoining LAN segment use the normal ARP process to resolve the associated MAC addresses. End Quote: Building Cisco Multilayer Switched Networks (chapter 7) MAC - .0c07.ac01 .0c - Vendor identifier Cisco 07.ac- Well known HSRP Virtual MAC address 01 - Group address http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/1214ea1/3550scg/swhsrp.htm It is configurable if you need to do so with the following command. standby [group-number] mac-address mac-address or standby use-bia Kim From: Tim Potier Date: 2002/06/22 Sat AM 12:17:36 EDT To: [EMAIL PROTECTED] Subject: HSRP [7:47177] Lets say I have HSRP configured on a series of routers... I know clients are sending packets to the MAC/IP of the well known virtual MAC with Cisco equipment. Assume the receiving station recieves the packet directly from the router participating in HSRP with the highest priority... what is the source MAC the receiving station sees? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=47189t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HSRP [7:47177]
At 12:17 AM 6/22/02, Tim Potier wrote: Lets say I have HSRP configured on a series of routers... I know clients are sending packets to the MAC/IP of the well known virtual MAC with Cisco equipment. Assume the receiving station recieves the packet directly from the router participating in HSRP with the highest priority... what is the source MAC the receiving station sees? The reply will come from the actual MAC address of the router interface. At this point, the router is just forwarding packets. It doesn't care that HSRP is configured. I tried a test. I have 2 routers (Albany and Charlotte) and a PC, like this: more nets more nets | | | | Albany--EthernetCharlotte 10.10.0.1| 10.10.0.2 00 00 0C 05 3E 80| 00 00 0C 00 2E 75 standby ip 10.0.0.3 | standby ip 10.0.0.3 | | PC address = 10.10.0.10 gateway = 10.10.0.3 running EtherPeek Albany#show standby Ethernet0 - Group 0 Local state is Active, priority 100 Hellotime 3 holdtime 10 Next hello sent in 0:00:02 Hot standby IP address is 10.10.0.3 configured Active router is local Standby router is 10.10.0.2 expires in 0:00:09 charlotte#show standby Ethernet0 - Group 0 Local state is Standby, priority 100 Hellotime 3 holdtime 10 Next hello sent in 0:00:00 Hot standby IP address is 10.0.0.3 configured Active router is 10.10.0.1 expires in 0:00:07 Standby router is local charlotte# Albany is active. The MAC virtual address is 00:00:0C:07:AC:00. I ping to anything on the network from my PC. If the destination is reachable via Charlotte, then I see the packet go from my PC MAC to 00:00:0C:07:AC:00 (the virtual MAC address.) Then I see the same packet go from Albany's real MAC address to Charlotte's real MAC address (with no ICMP Redirect, by the way). If the destination is reachable via Albany, then I don't see the second packet. Regardless, in all cases the ping reply comes back from the real MAC address of Albany or Charlotte. Here's the simpler case where I pinged 172.16.50.1 which is reachable via Albany. Ping: Ethernet Header Destination: 00:00:0C:07:AC:00 Source: 00:00:0E:D5:C7:E7 Protocol Type:0x0800 IP IP Header - Internet Protocol Datagram Version: 4 Header Length:5 (20 bytes) Type of Service: % Total Length: 60 Identifier: 6400 Fragmentation Flags: %000 Fragment Offset: 0 (0 bytes) Time To Live: 32 Protocol: 1 ICMP - Internet Control Message Protocol Header Checksum: 0x999C Source IP Address:10.10.0.10 Dest. IP Address: 172.16.50.1 No IP Options ICMP - Internet Control Messages Protocol ICMP Type:8 Echo Request Code: 0 Checksum: 0x355C Identifier: 0x0200 Sequence Number: 0x0016 Ping Reply: Ethernet Header Destination: 00:00:0E:D5:C7:E7 Source: 00:00:0C:05:3E:80 Protocol Type:0x0800 IP IP Header - Internet Protocol Datagram Version: 4 Header Length:5 (20 bytes) Type of Service: % Total Length: 60 Identifier: 6400 Fragmentation Flags: %000 Fragment Offset: 0 (0 bytes) Time To Live: 255 Protocol: 1 ICMP - Internet Control Message Protocol Header Checksum: 0xBA9B Source IP Address:172.16.50.1 Dest. IP Address: 10.10.0.10 No IP Options ICMP - Internet Control Messages Protocol ICMP Type:0 Echo Reply Code: 0 Checksum: 0x3D5C Identifier: 0x0200 Sequence Number: 0x0016 HTH. Priscilla Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=47212t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HSRP [7:47177]
Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 12:17 AM 6/22/02, Tim Potier wrote: Lets say I have HSRP configured on a series of routers... I know clients are sending packets to the MAC/IP of the well known virtual MAC with Cisco equipment. Assume the receiving station recieves the packet directly from the router participating in HSRP with the highest priority... what is the source MAC the receiving station sees? The reply will come from the actual MAC address of the router interface. At this point, the router is just forwarding packets. It doesn't care that HSRP is configured I was thinking the same thing. Sure, a client that sends to the Virtual IP for the HSRP gateway uses the virtual MAC to send to, but as far as return traffic, it seems the router would just receive the packet, lookup which interface it should go out, then rewrite the source/dest MACs in the frame and send it out no HSRP involved Mike W. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=47213t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HSRP [7:47177]
There might be a Howard-inspired lesson in this. ;-) In the Control Plane, the host ARPs for its default gateway, which in this case is configured to be the HSRP virtual IP address of the routers. In the Management Plane, the routers talk amongst themselves to make sure that the virtual IP and MAC addresses stay live. In the User Plane, the host sends user traffic (Ping in my case) and the routers forward traffic, without regards to HSRP. Sure, the host uses the virtual MAC address as its destination, but it doesn't know there's anything virtual about it. The routers forward the reply without any concerns about HSRP. I did run this on some rather old routers running IOS 11.0, but I'm pretty sure the results would be the same on newer IOS (although you can get an HSRP-configured router to do ICMP Redirects now.) Also, it wasn't exactly the scenario the original poster asked about, in that he seemed to be implying the source and dest were out the same interface on the router, and he was asking about just the request maybe, whereas I got the reply involved. His exact scenario was harder to set up. Hm. I'll give it a try. Unfortunately, my routers don't do VLANs (too old), but I could try it with secondary addresses. OK, tried it, same result. 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. Gotta run. I really do have a life outside my lab?! ;-) Priscilla At 08:31 PM 6/22/02, Michael L. Williams wrote: Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 12:17 AM 6/22/02, Tim Potier wrote: Lets say I have HSRP configured on a series of routers... I know clients are sending packets to the MAC/IP of the well known virtual MAC with Cisco equipment. Assume the receiving station recieves the packet directly from the router participating in HSRP with the highest priority... what is the source MAC the receiving station sees? The reply will come from the actual MAC address of the router interface. At this point, the router is just forwarding packets. It doesn't care that HSRP is configured I was thinking the same thing. Sure, a client that sends to the Virtual IP for the HSRP gateway uses the virtual MAC to send to, but as far as return traffic, it seems the router would just receive the packet, lookup which interface it should go out, then rewrite the source/dest MACs in the frame and send it out no HSRP involved Mike W. Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=47218t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HSRP [7:47177]
Thank you all! Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=47225t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
HSRP [7:47177]
Lets say I have HSRP configured on a series of routers... I know clients are sending packets to the MAC/IP of the well known virtual MAC with Cisco equipment. Assume the receiving station recieves the packet directly from the router participating in HSRP with the highest priority... what is the source MAC the receiving station sees? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=47177t=47177 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
