Radware’s AppDirector

Recently I have finished integration of Radware’s load balancer called AppDirector.
You can install it using one leg implementation with NAT, or something called local triangulation. You also can use two or more legs for installation. You can install it as gateway for your servers or at level two by the OSI, as cross between two VLANs. Every installation has it con and pros. Take a look at the table in order to understand cons and pros of each installation.

Installation type	Pros	Cons
One Leg - NAT	simple, fast.	Server can’t see users IP addresses.
One Leg - Local triangulation	simple, doesn’t use resources of the AppDirector.	You can't use Acceleration, Caching, TCP multiplexing, SSL Offloading. Need to install virtual IP adapter on servers.
Inline - level 2 by the OSI	No need to change IP routes	Can’t use multiple VLANs, No proper DOT1Q support. Need to change cabling.
Inline - level 3 by the OSI	Secure.	Need to reconfigure routing. Need to change cabling. Need to configure access to servers for management.

It also has many good features, that you can use like traffic acceleration, TCP multiplexing, caching and SSL offloading with or without using special hardware card.

• Acceleration - modifies TCP slow start and makes it faster.
• TCP multiplexing - uses only few TCP connection to servers to serve many TCP connections from the AppDirector to users.
• Caching - caches objects that repeat and send them to users directly without taking these objects from servers.
• SSL offloading - users open SSL to the AppDirector. You can configure SSL between the AppDirector and servers using less bits for encryption. This taking less resources from servers.
• AppDirector is the only product that I know of that have HTTP probes with authentication.
• Easy configuration and installation.
• Great and fast failover. The standby machine holds table of users to servers sessions. If the Active machine fails, the backup machine immediately takes control. Users don’t have to refresh their browsers or reload their applications.

But there few things in the AppDirector that not only makes it far from perfect, but these few things also make me frustrated.

• Security. I would like the application and system people to have read only access to the AppDirector. But I cannot do it using Radius. Anyone , doesn't matter to what group in Radius he or she related, can receive only RW or RO privileges. AGHHHH!!! You have to use local SNMPv3 users.
• SNMPv3 only get local users. No active directory or Radius connectivity for SNMP.
• You can control the AppDirecor using web (browser) access or using InSite program created in Java. Some features easier to create using the web access others using the InSite program. Why not just create simple management with both of them ?
• You can create probes for your servers from the Farm Server window. But you can also create probes in other menu called Health Monitoring. In the Health Monitoring window you assign probes to specific server and not to farms. Why? Seriously, why not just assign probes to server farms, and why should I define probes in different windows ?
• The InSite program. Sometimes it executes this code : Do Nothing; Loop; and it gets stuck.
• When you synchronize configuration from your Active to Standby machine, the Standby machine have the need to reboot. Annoying.

In general I like the AppDirector. I hope Radware will fix all the cons in time, and the cons should not prevent from anyone to use AppDirectors as Load Balancers or as the new generation of load balancers called : Application Delivery Controllers.

Using Microsoft NLB with CISCO switches in multicast mode

I have two ISA servers installed, that run Microsoft NLB. I want to connect them to two 6500 switches, in order to create a fault tolerant environment.

But there is a problem. The NLB in ISA servers generate a virtual IP (VIP) and a virtual MAC (I'll call it VMAC from now and on). In multicast mode the servers with the NLB installed preventing from the CISCO switches to learn their VMAC address. This why the switches broadcasting all traffic, that is coming to the NLB's VMAC address, to all the ports on the VLAN. Please note that all of the packets destined to the NLB need to arrive simultaneously to all of the servers.

In order to solve this problem all I need to do is to tell the switches, to what physical ports the VMAC is connected, by updating the MAC-ADDRESS-TABLE with a static MAC value. Also you'll need to add a static ARP value to the switches ARP table. My 6500 switches are connected using port channel between them. The commands I used in both switches are:

conf t

mac-address-table static 03bf.1234.4321 vlan 100 interface g2/10 port-channel1

arp 100.10.100.50 03bf.1234.4321 arpa

end

This way packets destined to the VMAC address will only be flooded to the interfaces I wrote in my command: g2/10 and port-channel 1.

When packets going on the port-channel 1 to the second switch, they won't come back to the first switch, the second switch will not allow it. Therefore there are no loops between the two switches.

This is how I solved the NLB multicast with cisco switches flooding problem. It works for about two month now without any problem.