Solved: GLBP Considerations Design

Carlo Zaina · ‎12-15-2008

Hi

I'm in this scenario: Multihomed site, Router1 linked to ISP1 and Router2 linked to ISP2.

Both Routers have the interface FastEthernet 0/0 with IP address belonging to the same network. GLBP is implemented in a round-robin fashion.

The routing table is quite simple: 1 static route pointing to the internal network and 1 default route pointing to the ISP's next-hop router.

Behind them, there is an ASA firewall, acting as termination point for VPN Remote access and L2L. ASA has only one default static route outside pointing to the virtual ip address advertized by GLBP (as well as an inside route pointing the the internal network)

The question i have is this: is it suitable deploying the GLBP in this scenario with loadsharing between the 2 links?

The load sharing is done on a per-packet basis or per-connection basis?

For example, if a VPN user connects to the corporate network using ISP2, do the traffic will flow for the whole session between ASA and R2 or some packet will be routed to the remote host across R1?

Thank you anticipately

CZ

Giuseppe Larosa · ‎12-16-2008

Hello Carlo,

you can install two default static routes on the ASA so you can get load balancing.

GLBP just operates during ARP resolution of default gateway IP for this reason is not effective when there is only one client.

If you only receive default routes the iBGP session is rather useless

Hope to help

Giuseppe

View solution in original post

viyuan700 · ‎12-17-2008

"if an outside user connects to the corporate LAN using for example, a public IP belonging to the ISP2's pool (VPN Remote access terminated on the ASA), the whole session will flow across R2 or do the packets will be switched between R1 and R2"

The whole session will be through R2.

HSRP is only first hop which is from Corportae to outside. For ur outside user to have load balncing they also shd load sharing setup at their end.

View solution in original post

Joseph W. Doherty · ‎12-15-2008

An issue you might encounter, GLBP works on the MAC level, so if all it "sees" is one "client" MAC from the ASA, all its traffic will go to just one gateway.

If you define multiple static routes on the ASA, and if it would load balance using them, an alternative would be to use MHSRP.

Giuseppe Larosa · ‎12-15-2008

Hello Carlo,

GLBP will not provide load balancing in this case:

once the ASA has performed an ARP request for its default route IPnext hop (the GLBP VIP) it will cache the answer and use it for all traffic: game over.

if ASA can install two default static routes you can use for them two HSRP VIPs/groups where in first R1 is master and in group2 R2 is master in normal conditions.

"You can define up to three equal cost default route entries per device. Defining more than one equal cost default route entry causes the traffic sent to the default route to be distributed among the specified gateways. When defining more than one default route, you must specify the same interface for each entry."

see

http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/ip.html#wp1047900

You should be fine in this way.

Hope to help

Giuseppe

Carlo Zaina · ‎12-16-2008

Grazie Giuseppe.

I was suspecting this, honestly: in fact, the ASA is the only device directly connected to the routers.

I think, at this point, that a balancing across the 2 links is not feasible in a such scenario: host dependent or round robin, the forwarding is always based on the source mac address, the ASA's one. (It could be different maybe with 2 ASA in Active/Active configuration)

As alternative path: defining 2 glbp group?

One used for critical services, the other for web connectivity to the end-users, with policy routing?

Setting up a iBGP session between the 2 routers looks a bit excessive.

Thank you

Carlo

Giuseppe Larosa · ‎12-16-2008

Hello Carlo,

you can install two default static routes on the ASA so you can get load balancing.

GLBP just operates during ARP resolution of default gateway IP for this reason is not effective when there is only one client.

If you only receive default routes the iBGP session is rather useless

Hope to help

Giuseppe

Carlo Zaina · ‎12-16-2008

Hi Giuseppe.

This is just what i am intended to do.

MHSRP (two groups) and two default static routes on ASA pointing to the HSRP advertized IP addresses.

However, if an outside user connects to the corporate LAN using for example, a public IP belonging to the ISP2's pool (VPN Remote access terminated on the ASA), the whole session will flow across R2 or do the packets will be switched between R1 and R2? This is my main concern.

Thank you

Carlo

viyuan700 · ‎12-17-2008

"if an outside user connects to the corporate LAN using for example, a public IP belonging to the ISP2's pool (VPN Remote access terminated on the ASA), the whole session will flow across R2 or do the packets will be switched between R1 and R2"

The whole session will be through R2.

HSRP is only first hop which is from Corportae to outside. For ur outside user to have load balncing they also shd load sharing setup at their end.

viyuan700 · ‎12-15-2008

"For example, if a VPN user connects to the corporate network using ISP2, do the traffic will flow for the whole session between ASA and R2 or some packet will be routed to the remote host across R1"

Is your VPN client who is connected to corportae network through ISP2 (which in turn connected to R2)lose connectivity when ISP2 fails or R2 fails?

If Yes then all your traffic for whole session is going through ASA and R2.

suppose if you have only one ISP, GLBP or HSRP is providing you redundancy if any of your Router i.e R1 or R2 fails.

They have no control if the ISP link fails. Means ur VPN client cannot connect to corporate netwrok even u have HSRP or GLBP.

But in your care you have 2 ISP also,Is one ISP fails does other takes over?

Means if your VPN client donot lose connectivity when one ISP fails then you already have load balacing based on your layer 3 protocol if the path have same metric. Only you have to see how to tune your GLBP parameters with other layer 3 protocol.