An Engineer by Heart !!! A Dreamer, A Pioneer, A Blogger. A Network Engineer Trying to overtake the world with his network engineering skills :) Opinions expressed here are solely my own and do not express the views or opinions of my Present or Past employer.
Showing posts with label Load Sharing Vs Load Balancing. Show all posts
Showing posts with label Load Sharing Vs Load Balancing. Show all posts
Sunday, April 5, 2015
Friday, August 10, 2012
Load Balancing - Using Cisco IOS SLB Dispatched Mode
PHYSICAL TOPOLOGY
LOGICAL TOPOLOGY
In Today's post I am going to present fairly an old IOS feature Called Server load balancing, but still I believe not many people are aware of it. Most importantly the feature is documented very well in IOS 12.4(15)T guides
which means some Evil CCIE Proctor or lab writer can turn your lab day into horrific experience by introducing something like this into configuration section of lab or into troubleshooting, which of course will be more obnoxious.
which means some Evil CCIE Proctor or lab writer can turn your lab day into horrific experience by introducing something like this into configuration section of lab or into troubleshooting, which of course will be more obnoxious.
Now Before moving onto the configuration part, let's talk a little about Load Balancer or I should say application load balancing. The idea is simple: The traffic towards the Application originated from outer world is going to hit the Virtual IP or VIP. The VIP basically represents the IP Address towards which the traffic is sent out in order to access the application. Now Behind the load balancer we have our Physical Servers running that application. The job of the load balancer now is to distribute the incoming connections from outer world towards the Physical Servers. The distribution pretty much depends upon the Algorithm we have chosen for configuration. While most of load balancers in market choose ROUND ROBIN as the default method. Other may choose different ones like Weight Based where a certain Weight is assigned to a physical server to ensure it handles more requests compare to server with
less weight. Which of course makes sense if server with Higher weight is a large Server compare to server with less weight which is say a P4 PC running Server application.
If you really want to dig a little deeper about load balancers from vendor independent point of view, I would recommend a fairly small book: Server Load Balancing From O'Reilly Publishers.
Now talking about Vendors, actually there are couple market players in Load Balancer Segment like - F5, Cisco, Citrix, Barracuda etc.
From Implementation perspective, The load balancer can work on LAN side as well as WAN side. For example F5 has LAN Based load balancer products called LTM and WAN based load balancer products called GTM. In similar fashion Cisco has dedicated load balancer products for LAN side called ACE series and WAN based called GSS.
Now coming back to IOS Based SLB implementation. It provides a very basic LAN based load balancing features. Since it's not a dedicated load balancer products so granularity is of course going to be less. But again an idle feature for SOHO environments for things like FTP load balancing etc.
Talking about IOS SLB implementation, there are basically two ways of doing it or I should say two modes:
> Dispatched Mode
> Directed Mode
The basic difference between Dispatched Mode Vs Directed Mode is that in Dispatched mode the limitation is the Physical Servers should have direct Layer 2 reach-ability with Load Balancer. While this is not the case with Directed mode which essentially uses NAT feature to load balance.
From CCIE Lab perspective, since the current IOS version devices running is 12.4(15)T. The feature is documented under - Server Load Balancing Configuration Guide. Which I believe is recent change since if I remember correctly when I took the lab last year it was documented under - IP Application Services Configuration Guide. Same logic applies to Command Reference guide just in case.
IP Application Services Configuration Guide, Cisco IOS Release 12.4T
Server Load Balancing Configuration Guide, Cisco IOS Release 12.4T
Now in this post I'll be covering "Dispatched Mode" Implementation. Let's first establish the basic connectivity using our initials before jumping into SLB specific configuration:
R1
==
!
en
!
conf t
!
no ip do lo
no cdp run
!
ho R1
!
int lo0
ip add 1.1.1.1 255.255.255.255
exit
!
int f0/0
ip add 12.12.12.1 255.255.255.0
no sh
exit
!
router eigrp 100
no auto
net 1.1.1.1 0.0.0.0
net 12.12.12.1 0.0.0.0
exit
!
end
!
wr
!
=============================================
R2
==
!
en
!
conf t
!
no ip do lo
no cdp run
!
ho R2
!
int lo0
ip add 2.2.2.2 255.255.255.0
exit
!
int f0/0
ip add 12.12.12.2 255.255.255.0
no sh
exit
!
int f0/1
ip add 23.23.23.2 255.255.255.0
no sh
exit
!
router eigrp 100
no auto
net 2.2.2.2 0.0.0.0
net 12.12.12.2 0.0.0.0
net 23.23.23.2 255.255.255.0
exit
!
end
!
wr
!
=============================================
R3
==
!
en
!
conf t
!
no ip do lo
no cdp run
!
ho R3
!
int lo0
ip add 3.3.3.3 255.255.255.0
exit
!
int f0/0
ip add 23.23.23.3 255.255.255.0
no sh
exit
!
int f1/0
ip add 33.33.33.3 255.255.255.0
no sh
exit
!
int lo 100
ip add 100.100.100.100 255.255.255.255
exit
!
router eigrp 100
no auto
net 3.3.3.3 0.0.0.0
net 23.23.23.3 0.0.0.0
net 33.33.33.3 0.0.0.0
net 100.100.100.100 0.0.0.0
exit
!
line vty 0 4
no login
exit
!
end
!
wr
!
=============================================
R5
==
!
en
!
conf t
!
no ip do lo
no cdp run
!
ho R5
!
int lo0
ip add 5.5.5.5 255.255.255.0
exit
!
int f0/0
ip add 33.33.33.5 255.255.255.0
no sh
exit
!
int lo 100
ip add 100.100.100.100 255.255.255.255
exit
!
router eigrp 100
no auto
net 5.5.5.5 0.0.0.0
net 33.33.33.5 0.0.0.0
net 100.100.100.100 0.0.0.0
exit
!
line vty 0 4
no login
exit
!
end
!
wr
!
=============================================
R6
==
!
en
!
conf t
!
no ip do lo
no cdp run
!
ho R6
!
int lo0
ip add 6.6.6.6 255.255.255.0
exit
!
int f0/0
ip add 33.33.33.6 255.255.255.0
no sh
exit
!
int lo 100
ip add 100.100.100.100 255.255.255.255
exit
!
router eigrp 100
no auto
net 6.6.6.6 0.0.0.0
net 33.33.33.6 0.0.0.0
net 100.100.100.100 0.0.0.0
exit
!
line vty 0 4
no login
exit
!
end
!
wr
!
========
Now as you can see, the VIP or virtual IP address we chose earlier - 100.100.100.100 is configured not only on Router R3 acting as SLB but also on physical servers. Actually it's one of requirements of IOS SLB Dispatched Mode implementation. In dispatched mode the VIP address needs to configured on Physical Servers either as Secondary Address or on the loopback. In our scenario I am using loopbacks for this purpose.
Now let's configure Router R3 as Server Load Balancer (SLB):
!
ip slb serverfarm DISPATCHED_MODE <- Pick any name you want herereal 33.33.33.5 <- Physical Address Of First Server
inservice <- This Command Enables the real server for use by IOS SLB
maxconns 2 <- Optional
weight 1 <- Optional
exit
real 33.33.33.6 <- Similar Steps to be repeated for 2nd Physical Server
inservice
maxconns 2
weight 1
exit
exit
exit
!
ip slb vserver ANYCAST_ADDRESS <- Let's Create the VIP
virtual 100.100.100.100 tcp telnet <- Here we are configuring Telnet SLB
serverfarm DISPATCHED_MODE <- Server Farm Configured Earlier
inservice
advertise
exit
!
Verification:
========
R1>telnet 100.100.100.100
Trying 100.100.100.100 ... Open
R5>exit
[Connection to 100.100.100.100 closed by foreign host]
R1>telnet 100.100.100.100
Trying 100.100.100.100 ... Open
R6>exit
[Connection to 100.100.100.100 closed by foreign host]
So as you can see our Telnet connections are getting load balanced between both Physical Server.
R3#sh ip slb stats
Pkts via normal switching: 60
Pkts via special switching: 0
Connections Created: 2
Connections Established: 2
Connections Destroyed: 2
Connections Reassigned: 0
Zombie Count: 0
DISPATCHED_MODE, predictor = ROUNDROBIN, nat = none
virtuals inservice: 1, reals = 2, bind id = 0
Real servers:
33.33.33.5, weight = 1, OPERATIONAL, conns = 0
33.33.33.6, weight = 1, OPERATIONAL, conns = 0
Total connections = 0
Since there is no active connection, the connection count is 0. Let's initiate one connection:
R1>telnet 100.100.100.100
Trying 100.100.100.100 ... Open
R5>
R3#sh ip slb serverfarms detail
DISPATCHED_MODE, predictor = ROUNDROBIN, nat = none
virtuals inservice: 1, reals = 2, bind id = 0
Real servers:
33.33.33.5, weight = 1, OPERATIONAL, conns = 1
33.33.33.6, weight = 1, OPERATIONAL, conns = 0
Total connections = 1
The IOS Version used for this SLB Test Bed is:
R3#sh ver | i IOS
Cisco IOS Software, 3600 Software (C3640-JK9O3S-M), Version 12.4(13a), RELEASE SOFTWARE (fc1)
HTH...
R3#sh ver | i IOS
Cisco IOS Software, 3600 Software (C3640-JK9O3S-M), Version 12.4(13a), RELEASE SOFTWARE (fc1)
DEEPAK ARORA
EVIL CCIESunday, January 29, 2012
CCIE R&S Routing Study Plan - IPv4
Every once in a while I get this request to write a CCIE R&S Routing Study Plan similar to CCIE R&S Switching study plan :
So lets list all routing topics and allow me to list my attack plan for each of those starting with RIP today... I'll keep adding for rest soon...
1. RIPv2
2. EIGRP
3. OSPF
4. BGP
5. REDISTRIBUTION
6. Learning each of above mentioned routing protocol from MPLS prospective.
Misc :
1. ODR
2. PBR
3. OER/PFR
4. Understanding CEF & IOS Switching
5. Understanding Load Sharing Vs Load Balancing
6. Protocol independent features
So lets begin with RIP for today :)
RIP
####
1. INE R&S ATC VODs RIP Lectures
2. Jeff Doyle's TCP/IP Vol 1(2nd Edition)
Two Chapters Just Talking about RIP along with some very good corner case scenarios. Technically one chapter talks about RIPv1 which is not on blueprint but still a good read to grasp fundamentals.
Make sure you test all RIP labs given in this book along the way.
3. Read about RIP from Ruhann's R&S Handbook :
4. Enough Theory ? .... Not yet :) ... Move onto RIP Technology Page
5. Okay... Enough Theory...Time to get some hands dirty with RIP Labs.
Alternatively you can follow any good R&S workbook vendor's RIP Technology Labs like - INE (www.ine.com) , IP Expert (www.ipexpert.com) Or Narbik (www.micronicstraining.com) ...Whatever works best for you
6. Some important blog posts.
7. Enough ? :)... Not Yet... Lets move to final phase and read through IOS 12.4T RIP configuration & command reference guides along with 12.4 T IOS Independent Feature Guide/Command Ref and make sure next time you know where to find what.
8. Though by this time you should be good with RIP troubleshooting as well, but just to add one extra bit, INE R&S Troubleshooting Class On Demand is an excellent resource to prepare for this part.
HTH...
Deepak Arora
EVIL CCIE
Friday, December 10, 2010
Static Routing Myth - Exit Interface Vs Next Hop
Myth : It's been long time since I wanted to talk about this Myth which every CCNA deals with once in a while. It's a very common misconception that If we point two static routes for same destination with one being having next hop address vs other with exit interface; in such case load balancing will not occur. The reason given being is that the static route with exit interface option will show up in local routing table as "connected" and as we all know that connected has AD value of "0" Vs static route pointing towards next hop with AD value of "1". So by that rule the route with exit interface wins over route with next hop and because of that load balancing won't occur.
Let's hop on to command line to verify whats going on. I am going to use two routers connected back to back using two WAN interfaces. We will create 1 loopback on each router as "x.x.x.x/24" where X = Router Number.
After this we will point out one static route toward destination loopback of other router with same prefix length and then we will examine if load balancing is occurring for traffic or not.
Lets Hop on to routers and put the config:
R1(config)#int lo0
R1(config-if)#ip add 1.1.1.1 255.255.255.0
R1(config-if)#exit
R1(config)#int s0/0
R1(config-if)#ip add 12.12.12.1 255.255.255.0
R1(config-if)#no sh
R1(config-if)#exit
R1(config)#int s0/1
R1(config-if)#ip add 112.112.112.1 255.255.255.0
R1(config-if)#no sh
R1(config-if)#exit
R1(config)#ip route 2.2.2.0 255.255.255.0 12.12.12.2
R1(config)#ip route 2.2.2.0 255.255.255.0 serial 0/1
=====================================================
R2(config)#int lo0
R2(config-if)#ip add 2.2.2.2 255.255.255.0
R2(config-if)#no sh
R2(config-if)#exit
R2(config)#int s0/0
R2(config-if)#ip add 12.12.12.2 255.255.255.0
R2(config-if)#no sh
R2(config-if)#exit
R2(config)#int s0/1
R2(config-if)#ip add 112.112.112.2 255.255.255.0
R2(config-if)#no sh
R2(config-if)#exit
R2(config)#ip route 1.1.1.0 255.255.255.0 12.12.12.1
R2(config)#ip route 1.1.1.0 255.255.255.0 s0/1
=====================================================
R1#sh ip ro | b ^G
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback0
2.0.0.0/24 is subnetted, 1 subnets
S 2.2.2.0 [1/0] via 12.12.12.2
is directly connected, Serial0/1
112.0.0.0/24 is subnetted, 1 subnets
C 112.112.112.0 is directly connected, Serial0/1
12.0.0.0/24 is subnetted, 1 subnets
C 12.12.12.0 is directly connected, Serial0/0
R2#sh ip ro | b ^G
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
S 1.1.1.0 [1/0] via 12.12.12.1
is directly connected, Serial0/1
2.0.0.0/24 is subnetted, 1 subnets
C 2.2.2.0 is directly connected, Loopback0
112.0.0.0/24 is subnetted, 1 subnets
C 112.112.112.0 is directly connected, Serial0/1
12.0.0.0/24 is subnetted, 1 subnets
C 12.12.12.0 is directly connected, Serial0/0
=====================================================
R1#debug ip packet detail
IP packet debugging is on (detailed)
R1#ping 2.2.2.2 so lo0 r 4
Type escape sequence to abort.
Sending 4, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!
Success rate is 100 percent (4/4), round-trip min/avg/max = 4/5/8 ms
R1#
*Mar 1 00:11:24.651: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via FIB < Packet 1
*Mar 1 00:11:24.651: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending
*Mar 1 00:11:24.651: ICMP type=8, code=0
*Mar 1 00:11:24.655: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
*Mar 1 00:11:24.655: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4
*Mar 1 00:11:24.655: ICMP type=0, code=0
*Mar 1 00:11:24.655: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via FIB < Packet 2
*Mar 1 00:11:24.655: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending
*Mar 1 00:11:24.655: ICMP type=8, code=0
*Mar 1 00:11:24.663: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
*Mar 1 00:11:24.663: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4
*Mar 1 00:11:24.663: ICMP type=0, code=0
*Mar 1 00:11:24.663: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via FIB < Packet 3
*Mar 1 00:11:24.663: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending
*Mar 1 00:11:24.663: ICMP type=8, code=0
*Mar 1 00:11:24.667: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
*Mar 1 00:11:24.667: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4
*Mar 1 00:11:24.667: ICMP type=0, code=0
*Mar 1 00:11:24.667: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via FIB < Packet 4
*Mar 1 00:11:24.667: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending
*Mar 1 00:11:24.667: ICMP type=8, code=0
*Mar 1 00:11:24.671: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
*Mar 1 00:11:24.671: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4
*Mar 1 00:11:24.671: ICMP type=0, code=0
=====================================================
Umm....Looks like CEF is not happy with us :-P Lets turn it off :-)
R1(config)#no ip cef
R1#ping 2.2.2.2 so lo0 r 4
Type escape sequence to abort.
Sending 4, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!
Success rate is 100 percent (4/4), round-trip min/avg/max = 4/5/8 ms
R1#
*Mar 1 00:12:25.703: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via RIB< Packet 1
*Mar 1 00:12:25.703: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending
*Mar 1 00:12:25.703: ICMP type=8, code=0
*Mar 1 00:12:25.707: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
*Mar 1 00:12:25.707: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4
*Mar 1 00:12:25.707: ICMP type=0, code=0
*Mar 1 00:12:25.707: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/1), routed via RIB< Packet 2
*Mar 1 00:12:25.707: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/1), len 100, sending
*Mar 1 00:12:25.707: ICMP type=8, code=0
*Mar 1 00:12:25.715: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
*Mar 1 00:12:25.715: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4
*Mar 1 00:12:25.715: ICMP type=0, code=0
*Mar 1 00:12:25.715: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via RIB
*Mar 1 00:12:25.715: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending < Packet 3
*Mar 1 00:12:25.715: ICMP type=8, code=0
*Mar 1 00:12:25.719: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
*Mar 1 00:12:25.719: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4
*Mar 1 00:12:25.719: ICMP type=0, code=0
*Mar 1 00:12:25.723: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/1), routed via RIB
*Mar 1 00:12:25.723: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/1), len 100, sending< Packet 4
*Mar 1 00:12:25.723: ICMP type=8, code=0
*Mar 1 00:12:25.723: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
*Mar 1 00:12:25.727: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4
*Mar 1 00:12:25.727: ICMP type=0, code=0
Everything seems to be in shape now :-)
R1#sh ip route 2.2.2.0
Routing entry for 2.2.2.0/24
Known via "static", distance 1, metric 0 (connected)
Routing Descriptor Blocks:
* 12.12.12.2
Route metric is 0, traffic share count is 1
directly connected, via Serial0/1
Route metric is 0, traffic share count is 1
so conclusion is that despite of how you configure the static route (Exit Interface Vs Next Hop), the AD is always going to be 1.
Though specifying next hop has some advantages over exit interface option on Multi Access network types. But personally I like to use what I call mix of both in which while adding static route you specify exit interface with next hop address. This way we can make sure that no route-recursion issue will occur. And if you are thinking " Route Recursion issues with Static routing - what the hack is that" ?..ummm....let me save it for my next post for CCNA guys :-)
here is the syntax BTW which I just talked about
R1(config)#ip route 2.2.2.0 255.255.255.0 s0/0 12.12.12.2
R1(config)#ip route 2.2.2.0 255.255.255.0 s0/1 112.112.112.2
Further Readings:
HTH...
Deepak Arora
Subscribe to:
Posts (Atom)







