Showing posts with label Load Sharing Vs Load Balancing. Show all posts
Showing posts with label Load Sharing Vs Load Balancing. Show all posts

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.

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 

http://www.cisco.com/en/US/docs/ios-xml/ios/ipapp/configuration/12-4t/iap-12-4t-book.html

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 here
 real 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


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 = 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...
DEEPAK ARORA
EVIL CCIE

Sunday, 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