Cisco CSS L4 switch examples for use with Novell Access Manager 3.1

Cisco CSS L4 switch examples for use with Novell Access Manager 3.1

Since the Novell documentation for Access Manager does not include samples for Cisco L4 switches, I felt it necessary to include an example here so that others may be able to more easily get NAM to work with Cisco networking gear.

First, we use a Cisco CSS 11501 "layer 4 switch". Unfortunately the model we have does NOT have the ability to perform SSL/HTTPS health checks. As a result, we had to modify a few things to get it to work.

Our setup has an Identity Provider Cluster with 2 IDP servers. We also have an Access Gateway cluster with two LAGs that have multiple IP addresses on them. We use HTTPS/SSL for all components, EXCEPT we have a LAG Proxy that we can only use HTTP for. We have configured the IDP to use the "Redirect" feature so that the 8443 ports are redirected to 443.

For the sake of illustrating:

IDP3 has an IP of: 192.168.112.151
IDP4 has an IP of: 192.168.112.152

LAG3 has these IPs:
192.168.112.156
192.168.112.166
192.168.112.171

LAG4 has these IPs:
192.168.112.157
192.168.112.167
192.168.112.172

As per Novell's documentation, we have segregated the traffic so that the IDP and the LAGS cannot talk to each other directly, but instead, must talk to each other via the VIP (Virtual IP) that's on the CSS.

Our IDP VIP is:
192.160.112.150

Our LAG VIPs are:
192.168.112.155
192.168.112.165
192.168.112.170

The .112.155 IP is the VIP of our embedded service provider (ESP).

Now you might ask, why don't we have the "heartbeat" on the CSS (the healthcheck, if you will) set to do a simple PING?

Quite simply the reason is that it is entirely possible to have the tomcat service "die" and still have the IP address respond via a PING. In this situation, the CSS would think both servers are up and functional based upon a simple ICMP response, when in fact- for NAM purposes- the services are down.

Also, remember we cannot perform the healthcheck via SSL/HTTPS because of the model of our CSS. Therefore, we have to perform the healthcheck via HTTP instead. Because of that, we had to use Novell's docs to setup a dedicated "heartbeat" proxy on the non-secure port.

With that explained, here's our configuration (the relevant portions/samples) of our CSS configuration.

Since I'm not in our networking department, I don't know what everything below means, but I assume your Cisco gurus will be able to ascertain what's going on:

CSS-DMZProd-1# sh run

!Generated on 01/06/2010 12:03:18
!Active version: sg0820303

configure


!************************** SERVICE **************************
service HTTP-IDP3
ip address 192.168.112.151
port 80
keepalive type http
keepalive port 80
keepalive uri "/nidp/app/heartbeat"
active

service HTTP-IDP4
ip address 192.168.112.152
port 80
keepalive port 80
keepalive uri "/nidp/app/heartbeat"
keepalive type http
active

service HTTP-LAG3
ip address 192.168.112.156
port 80
keepalive uri "/nesp/app/heartbeat"
keepalive type http
keepalive port 81
active

service HTTP-LAG3-Download
port 80
ip address 192.168.112.166
keepalive port 80
keepalive type tcp
active

service HTTP-LAG4
ip address 192.168.112.157
port 80
keepalive uri "/nesp/app/heartbeat"
keepalive type http
keepalive port 81
active

service HTTP-LAG4-Download
port 80
ip address 192.168.112.167
keepalive type tcp
keepalive port 80
active


service HTTPS-IDP3
port 443
keepalive uri "/nidp/app/heartbeat"
ip address 192.168.112.151
keepalive port 80
keepalive type http
active

service HTTPS-IDP4
port 443
keepalive uri "/nidp/app/heartbeat"
keepalive port 80
ip address 192.168.112.152
keepalive type http
active

service HTTPS-LAG3
ip address 192.168.112.156
port 443
keepalive uri "/nesp/app/heartbeat"
keepalive type http
keepalive port 81
active

service HTTPS-LAG3-Internal1
port 443
keepalive type ssl
ip address 192.168.112.171
active

service HTTPS-LAG4
ip address 192.168.112.157
keepalive uri "/nesp/app/heartbeat"
port 443
keepalive type http
keepalive port 81
active

service HTTPS-LAG4-Internal1
port 443
keepalive type ssl
ip address 192.168.112.172
active



!*************************** OWNER ***************************
owner ProdDMZ

content HTTP-ESPEXT
add service HTTP-LAG3
add service HTTP-LAG4
port 80
protocol tcp
advanced-balance sticky-srcip-dstport
vip address 192.168.112.155
active

content HTTP-ESPEXT-Download
protocol tcp
add service HTTP-LAG3-Download
vip address 192.168.112.165
add service HTTP-LAG4-Download
port 80
advanced-balance sticky-srcip-dstport
active

content HTTP-IDPEXT
vip address 192.168.112.150
add service HTTP-IDP4
add service HTTP-IDP3
port 80
protocol tcp
advanced-balance sticky-srcip-dstport
active


content HTTPS-ESPEXT
application ssl
vip address 192.168.112.155
port 443
protocol tcp
add service HTTPS-LAG3
add service HTTPS-LAG4
advanced-balance sticky-srcip-dstport
active

content HTTPS-ESPEXT-Internal1
protocol tcp
add service HTTPS-LAG3-Internal1
vip address 192.168.112.170
add service HTTPS-LAG4-Internal1
port 443
application ssl
advanced-balance sticky-srcip-dstport
active

content HTTPS-IDPEXT
advanced-balance sticky-srcip-dstport
application ssl
vip address 192.168.112.150
port 443
protocol tcp
add service HTTPS-IDP3
add service HTTPS-IDP4
active


!*************************** GROUP ***************************
group ESPEXT
add destination service HTTP-LAG3
vip address 192.168.112.155
add destination service HTTP-LAG4
add destination service HTTPS-LAG3
add destination service HTTPS-LAG4
active

group ESPEXT-Download
add destination service HTTP-LAG3-Download
vip address 192.168.112.165
add destination service HTTP-LAG4-Download
active

group ESPEXT-Internal1
add destination service HTTPS-LAG3-Internal1
vip address 192.168.112.170
add destination service HTTPS-LAG4-Internal1
active

group IDPEXT
add destination service HTTPS-IDP3
vip address 192.168.112.150
add destination service HTTPS-IDP4
active


Labels (1)

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Comments
Thank you very much for posting this detailed configuration.

"Also, remember we cannot perform the healthcheck via SSL/HTTPS because of the model of our CSS. Therefore, we have to perform the healthcheck via HTTP instead. Because of that, we had to use Novell's docs to setup a dedicated "heartbeat" proxy on the non-secure port."

The CSS that we have does not support health checks via SSL/HTTPS. We also force SSL on all our proxy connections. How did you handle that? So if our resource is called teaming.novell.com, if I navigate to http://teaming.novell.com/nesp/app/heartbeat I am redirected to https://teaming.novell.com/nesp/app/heartbeat and then I see the success page. Since the CSS cannot make SSL/HTTPS connections, when I use this as a keepalive, the status is always dead.
Top Contributors
Version history
Revision #:
3 of 3
Last update:
‎2020-01-31 22:08
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.