cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1369
Views
27
Helpful
13
Replies

GBLP vs HSRP on Layer2/3 Core

vaughancahill
Level 1
Level 1

Would I be correct in assuming that HSRP would be the ideal load balancing protocol where layer 2 and layer 3 termination happens on the core (collapsed core)?

I have MST to evenly segment VLAN root bridges across each core switch so I would think that HSRP would be ideal in this situation the as root bridge and active layer3 interface would be on the same MLS.

In GBLP it could be either core switching meaning a 50% increase of traffic across the layer2 link between the cores as clients are distributed among the cores.

Scenario.

VLAN 10,20 [SWITCH A] <Layer2> [CSW01] <-Layer2-> [CSW02] <Layer2> [SWITCH B] VLAN 20,30

Client in VLAN10 with AVF MAC of CSW02 sends data to CLIENT in VLAN20:

Client in VLAN10 gets the MAC address for AVF on CSW02, Client attempts to send network traffic to client in VLAN20, the spanning tree root bridge for VLAN10,20 is on CSW01, so the data first flows to CSW01 then to CSW02 where the MAC address for the AVF is located, the frame is layer3 switched onto VLAN20, the frame now has to traverse back to CSW01, and then SwitchA again.

Thus placing the unneeded traffic on the link between CSW01/CSW02.

Now considering my switches support CEF, there is no benefit in GBLP? In fact it looks more detrimental due to increase of traffic on the layer2 links between the core.

In HSRP this situation is remove because the traffic for each VLAN only traverse this link if it is destined for that a vlan that has its root on the other CSW. E.g. HSRP address configured as primary on the SPT bridge for each VLAN.

Should I be worried about this increase in traffic vs the fact that my clients are split across cores?

So I assume GBLP is ideal where we have layer 3 between core and distribution, or distribution and access, but not if we have layer 2/3 on the core?

Comments / criticisms welcome.

1 Accepted Solution

Accepted Solutions

Victor has this exactly correct. If you are using MST (and I assume you have it setup to load balance based on the tree), ensure the HSRP active router is the root of that tree.

GLBP wouldn't be good for the scenario you have described, which is exactly as you thought. It would load balance and then you would have a case where the forwarding router is not necessarily the root of the L2 tree, which leads to extra traffic on the trunk between the gateways.

View solution in original post

13 Replies 13

Jon Marshall
Hall of Fame
Hall of Fame

Vaughan

HSRP does not load-balance unless you are using MHSRP which you haven't said you are. So the load-balancing is done manually.

You are correct in what you say in that with GLBP there may well be more traffic across the L2 trunk between your core switches.

To be honest it really isn't going to make that much difference. Your L2 link between your switches should be an etherchannel anyway and probably has a lot more throughput than individual uplinks from access-layer switches.

Unless you find one of your core switches getting really hammered whilst the other is not doing anything i would just go with HSRP.

Edit - one point that needs to be cleared up though. The STP root is used to calculate a loop free topology. Traffic however does not necessarily have to always go to the root bridge.

Edit 2 - "So I assume GBLP is ideal where we have layer 3 between core and distribution, or distribution and access, but not if we have layer 2/3 on the core?"

Not really. If you have L3 between the distribution and access-layer then you can use GLBP in the distribution layer for clients in the access-layer as they are not L2 adjacent.

Edit 3 (sorry about this !). GLBP would be useful in a situation where you have L2 access-layer to distro but you connect your distro switches with a L3 link. That way both uplinks from the access-layer could be forwarding for the same vlan as there would be no loop.

Jon

Hi Jon,

Thanks for your reply, I am just trying to decide if it would be better to implement GBLP at this stage, rather than having to change over later.

If I were to use HSRP I would make the CSW the primary HSRP router for VLANs that it is currently the root bridge for.

Your comment regarding traffic direction.

"Traffic however does not necessarily have to always go to the root bridge."

Only when it is crossing layer3 boundaries correct?

Edit 3 (sorry about this !). GLBP would be useful in a situation where you have L2 access-layer to distro but you connect your distro switches with a L3 link. That way both uplinks from the access-layer could be forwarding for the same vlan as there would be no loop.

This is on my mind, creating L3 to the server block (3 x 4948s), but the issue is that I currently have no distribution switches.

I would use L3 links from the server access switches to the CSWs and create GBLP instances on the CSW & server access switches in order to load balance between the CSW/Server switches correct?

And just for clarification: This also forces my MSTIs to be placed into a new region in the "Server Block" segmenting the spanning-tree because of the layer3 boundary?

Vaughan

"Traffic however does not necessarily have to always go to the root bridge.

Only when it is crossing layer3 boundaries correct?"

Not necessarily eg.

core1 is STP root for vlan 10

core1 is also HSRP active for vlan 10

core2 is STP root for vlan 20

clientA is in vlan 10

clientB is in vlan 20 but is attached to core1.

So clientA sends packet to clientB. Packet is switched in vlan 10 from access-layer switch to Core1.

Core1 now routes the packet into vlan 20. Core1 will know (or will arp out if it doesn't know) that clientB is attached directly. So it will simply switch the packet to clientB.

What core1 won't do is forward the packet to core2 and then core2 send it back again. There is no need. That is what i meant about traffic doesn't have to go through the root bridge even if it is routed. The root and secondary bridges are used to stop loops in the initial STP calculation.

Jon

Thanks Jon.

I understand this situation, and if

core2 is also HSRP active for vlan 20

ClientB attached to core1 was sending packet to ClientA it would have to get to its L3 hop first that being CSW02 which would L3 switch the packet, then back to CSW01, then to clientB.

However if my switch has two uplinks one to each CORE, spanning tree would have blocked VLAN20 on the uplink to CSW01 and thus the link to CSW02 would be used.

In my situation VLAN20 would be blocked on Core1 and forwarding to Core2, thus ClientA ->B would have Core1 L3 switch and forward the L2 packet to Core2, Core2, then switches the L2 packet down the forwarding link for VLAN20.

This is what I meant by crossing layer3 boundaries. Obviously it only applies to when HSRP/GBLP is active for a VLAN that is on the same devices as the SPT root sorry for the confusion.

lamav
Level 8
Level 8

Maybe its just me, but Im a bit confused about your question.

Let me, however, offer you some opinion/comments in general regarding HSRP, STP and GLBP.

First, what you should do is make sure that the STP root bridge for a particular vlan is also the HSRP primary. This reduces the crosslink traffic that you're concerned with. A dual-homed switched-access-layer switch will forward its traffic to the core/distro (C1 and C2) via the L2 trunk that is in the forwarding state for that vlan. Assuming C1 is your root bridge, traffic will be forwarded to it and it will forward the traffic from there because it is the HSRP primary.

HSRP does not load balance, as GLBP does. So, if you're looking to load balance, HSRP isn't the solution. You can simulate load sharing with HSRP by creating more than one standby group per vlan, but that can get difficult to set up and manage. I wouldnt recommend it.

HTH

Victor

Hey Victor,

Thanks for your reply, it clarifies my thinking regarding HSRP vs GBLP and cross talk traffic.

What I am trying to decide is in the future is if I should use my server block 4948s access switches and create a layer3 link between the server block and the core.

Should I then use GBLP on the core, or just GBLP on the server block, would there be any benefit in running GBLP on the core when the rest of the network is collapsed and only will only have forwarding interface for that VLAN on each bridge..

Collapsed Core HSRP <-> ServerBlock GBLP?

Collasped Core GBLP <-> ServerBlock GBLP?

Collapsed Core HSRP <-> ServerBlock HSRP?

I like the idea of the load balancing for the server block..

Any help is appreciated.. thanks.

Hey, Vaughn:

I'll tell you, man, some people don't like the idea of deploying a routed access layer in a server farm because of the necessity to provide layer 2 adjacency between the switches to support NIC teaming or VMWare. So there is a need to span the vlan across the switches. Personally, I think that's easily fixed with an L2 crosslink, but some may argue that that is not a true routed access layer. Semantics, semantics.. :-)

Anyway, back to the GLBP/HSRP dilemmma, I have to say that in the server farm, I would probably stay away from GLBP. Chances are, as your server farm grows, you will deploy some sort of SERVER load balancing scheme (as opposed to network load balancing, which is what GLBP is for), such as SLB or an appliance. Cisco does not recommend using GLBP with either of those two server load balancing schemes, as it may create inconsisencies.

Moreover, the load balancing feature of GLBP leverages asymmetric routing, which can adversely effect applications whose connections must maintain a stateful nature. I also see that you work for a Pharmaceutical company, so you may have the need one day -- if youre not already -- to firewall between vlans within the server farm itself to maintain the privacy of client databases to conform to HIPAA and SOX requirements. The asymmetric routing jazz may break those stateful connections, too.

In summary, HSRP's routing is more deterministic than GLBP, although it may also require some route tuning to eradicate any client-to-application asymmetric routing.

I know I dumped a lot of crap on you, so in short, I would say leave the HSRP, configure it the way Jon and I recommend and leave the access layer switched, unless you can dig my L2 crosslink fix.

HTH

Victor

Thanks Victor,

Keep dumping! This is helping alot and Its better to know this stuff earlier rather than later ;)

In regards to NIC teaming and L2 adjacency, I don't have that issue yet because our server guys are teaming to the same switch (lol), anyway that's another story.

In my thinking for GBLP on the server access layer switches I was already thinking of creating a L2 Etherchannel between each of the 3 switches, and doing Host-Dependent load balancing keeping the session states. Obviously each switch would be an AVF. The idea is to bring the intervlan routing for the server block off the core block, and utilise the uplinks to the core more evenly than would be in the L2/HSRP example.

From your comments though if we ever go down the SLB path, that GLBP will cause inconsistencies?

How is this situation different from using GLBP/HSRP on distribution switches that connect to the access/core layers?

Vaughn:

IOS-SLB and appliance-oriented server load balancing leverage stateful packet inspection of application traffic to maintain connections between client and the application. Since GLBP creates a situation of asymmetric routing, it can create problems as a result of routing inconsistencies in the network.

Now, is it possible to deploy GLBP in this scenario? Probably, with some tweaking -- and some of that tweaking may seem counter-intuitive. For example, I had one client who actually disabled the load balancing feature of GLBP to make it work in the server farm! LOL...So why deploy it if you're going to disable its most prominent feature, its raison d'etre?

As for your second question is concerned, you can deploy GLBP more readily in the campus, the WAN edge and the core, but I think the more comprehensive solution to network load balancing across your enterprise is to utilize ECMP between the distribution blocks and the core and leave it to dynamic routing protocols, like OSPF and EIGRP to maintain multiple, equal-cost paths for load balancing and rapid covergence in the event of a link failure.

HTH

Victor

Awesome, Thanks!

Now, I was all set to start with HSRP design until I found....

http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/HA_campus_DG/hacampusdg.html#wp1108611

By tuning the STP cost for each vlan between the CSWs I can get each access switch to have both its uplinks in forwarding state for that VLAN, thus giving me L3 load balancing over my 2 L2 links.

But what are the Conns to this design??

Vaughn:

Im not sure I understand you completely.

HSRP and STP perform 2 separate functions but are typically deployed together in a symbiotic fashion to provide load sharing, redundancy and fast convergence.

Between the two L3 switches in the distro layer, you will want to run HSRP to provide first hop router redundancy. Remember, your clients have to forward their traffic to a particular default gateway for the vlan they're in. With HSRP, both routers share a virtual IP/MAC address, and each forwards for that address when it is the "active" HSRP router for that vlan. If it fails, the other takes over the virtual MAC and no reconfiguration of the clients will need to take place.

Without HSRP or GLBP or VRRP, how are you supposed to have router redundancy for your hosts without manual intervention?

STP is another story. It is meant to block parallel paths of L2 traffic to prevent loop formation. When STP converges, it elects a root bridge. With PVST+, a root bridge is elected for each vlan.

If you have L2 adjacency established via an L2 crosslink between the two distro switches, one of the uplinks from the access switch will be blocked to prevent a loop. You can omit an L2 cross link, and that will render all ports on the distro switches and the access switches for that vlan in a "Forwarding" state. However, with the L3 isolation between distro switches (assuming you do have an L3 crosslink to support fast reconvergence and route summarization), the access switch will still have only one path to the distro switch, and that is via the port on the access switch that faces the root bridge.

When you deploy PVST+ and HSRP, make sure that the HSRP primary for any particular vlan is also the STP root bridge (rig the election by setting the priority). This way you minimize needless crosslink traffic.

HTH

Victor

Victor has this exactly correct. If you are using MST (and I assume you have it setup to load balance based on the tree), ensure the HSRP active router is the root of that tree.

GLBP wouldn't be good for the scenario you have described, which is exactly as you thought. It would load balance and then you would have a case where the forwarding router is not necessarily the root of the L2 tree, which leads to extra traffic on the trunk between the gateways.

Thanks Everyone,

This has confirmed my suspicions in regards to the collapsed core MST and GLBP configuration option and also after considering the SPT path cost configuration required to make both uplinks of the access layer switches in forwarding, I've kind of feel it goes against the best practice methods, so I'll stick to the HSRP Active/SPT root on the same device, and maybe think about GLBP again if I can get some distribution switches. ;)

Thanks again!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: