From: Kenneth Wygand (KWygand@customonline.com)
Date: Tue Oct 12 2004 - 12:20:29 GMT-3
Cisco states the following in their comparison of GLBP to HSRP:
<SNIP>
GLBP performs a similar, but not identical, function for the user as the
HSRP and the VRRP. HSRP and VRRP protocols allow multiple routers to
participate in a virtual router group configured with a virtual IP
address. One member is elected to be the active router to forward
packets sent to the virtual IP address for the group. The other routers
in the group are redundant until the active router fails. These standby
routers have unused bandwidth that the protocol is not using. Although
multiple virtual router groups can be configured for the same set of
routers, the hosts must be configured for different default gateways,
which results in an extra administrative burden. GLBP provides load
balancing over multiple routers (gateways) using a single virtual IP
address and multiple virtual MAC addresses. Each host is configured with
the same virtual IP address, and all routers in the virtual router group
participate in forwarding packets.
</SNIP>
So essentially, GLBP is the same as HSRP in the way in which it was
programmed to work with the exception that a virtual MAC address is
assigned to each router in the GLBP group (this is different from HSRP
where a single virtual MAC address is assigned for all of the routers in
the HSRP group).
GLBP takes advantage of the layer-3 to layer-2 resolution inherent in
IPv4. Obviously, whenever a client tries to send traffic to an IP
address, an ARP is sent out to determine the physical MAC address to
send the traffic to in order to reach the client with the appropriate IP
address.
When using HSRP and the client tries to access the Virtual Default
Gateway (Virtual IP address), this is translated by the Active HSRP
router to the Virtual MAC address assigned to the HSRP group. When the
client then sends traffic to this MAC address, this traffic is handled
by the active HSRP router with the standby routers remaining idle
waiting to take over if the Active router fails.
When using GLBP and the client tries to access the Virtual Default
Gateway (Virtual IP address), this is pseudo-randomly translated to one
of the Virtual MAC addresses assigned to one of the routers in the GLBP
group. When the client then sends traffic to this MAC address, this
traffic is handled by the router that was assigned to handle that
Virtual MAC address. Since a different MAC address will be distributed
to different clients whenever a layer-3 to layer-2 ARP request comes in,
clients will automatically load-share traffic across all of the routers
in the GLBP group.
Now for the real-world spin (that, to me, doesn't make this a very
useful enhancement):
1) All traffic sent from a particular client will always cross the same
router so as long as that router remains active. So if you have one
client sending traffic at full speed and another client sending a
continuous stream of small ping packets, each client will be "assigned"
to one of the routers in the GLBP group and will not spill over to (or
be shared across) the other routers in the GLBP group. Of course, once
the ARP cache times out, a particular client may end up using another
virtual MAC address and thus another router in the GLBP group to send
traffic, but this is only after 2 minutes (Windows PC) of no traffic
whatsoever to that IP address. This will hardly ever happen since the IP
address we are referring to is usually a default gateway and is almost
always contacted by background applications, even when the computer is
sitting "idle".
2) Perhaps the largest disadvantage of all is that the load sharing
mechanism depends on a large number of clients on the same layer-2
topology as the GLBP group of routers. Since this load-balancing
mechanism is based upon distributing traffic through layer-3 to layer-2
resolution, load-balancing will only affect devices on the same layer-2
topology as the GLBP group of routers. So, for example, if you have a
network with clients spread out amongst VLANs with a layer-3 device in
the middle, or if you have any type of router or firewall device between
the clients and the GLBP group of routers, only the last layer-3 device
that's on the same layer-2 subnet as the GLBP group of routers will
actually be communicating with the GLBP routers at layer-2 and will thus
only resolve to a single MAC address from the virtual IP address
assigned to the GLBP group of routers. Therefore, all traffic that
crosses this common layer-3 aggregation point (firewall, router, etc)
will be forced to cross the same physical router in the GLBP group.
Having that said, in the real world, I don't see much of a practical
benefit in GLBP over HSRP, unless, of course, you have a small client
running a single small LAN (no VLANs) with no firewall or perhaps
firewall functionality built into the same boxes as the GLBP set of
routers.
If anyone else has any thoughts on practical applications of the benefit
of GLBP over HSRP, I'd love to hear them! :)
Hope this helps!
Kenneth E. Wygand
Systems Engineer, Project Services
CCIE #13720, CISSP #37102, CCNP/DP, ACSP,
Cisco IPT Design Specialist, MCP, CNA, Network+, A+
Custom Computer Specialists, Inc.
"Failure only occurs at the point in which one stops trying."
-Anonymous
Custom Computer Specialists, Inc.
"Celebrating 25 Years of Excellence"
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
mohamed_n@sifycorp.com
Sent: Tuesday, October 12, 2004 4:20 AM
To: tasuka@mac.com
Cc: ccielab@groupstudy.com
Subject: Re: What different between GLBP and HSRP
HSRP is a high availability protocol,the standby remains idle and
takesover when master fails, GLBP is also a high availability protocol
but the standby dont sit idle but it does load balancing also
Cheers
Mohamed.
> Hi, thanks for your time,
> What different between GLBP ( Gateway load balanancing protocol ) and
> HSRP ( hot standby router protocol )?
>
> I read the 12.2 new feature documents and found this, is that
different
>
> to HSRP ?
>
> Sincerely,
> Tasuka
>
>
This archive was generated by hypermail 2.1.4 : Sat Nov 06 2004 - 17:11:46 GMT-3