Brocade ADX – Persistence

The Brocade ADX offers 2 main persistence methods ; sticky and cookie. Within this article we will look at both of these methods and the various configuration options of each one.

Types

Sticky

With sticky traffic is sent to the same server based on the clients IP for duration of the sticky timeout duration. Sticky also offers 2 other features,

Track Port – A group of ports are defined. One of the ports is defined as a primary port. If a connection is initiated to the the primary port and then any further connections to any of the other ports within the group, persistence is applied. However if a connection is destined to a non-primary port(s) no persistence is applied.
Track Group – A group of ports are defined. If a connection goes to either of these ports then persistence is applied. This is typically used when SSL termination is used and traffic is sent to a different backend port.

Cookie

Cookie persistence (as the name suggests) uses a HTTP cookie to persist requests to the same server.
There are 3 main types of cookie persistence,

Cookie Insert – A cookie is inserted into the HTTP header. The cookie is then used for persistence.
Cookie Passive – A cookie is inserted by the server. The cookie is then used to balance traffic for the remainder of the session to the same server.
Cookie Hashing – A cookie is generated on the server. The ADX generates a hash of this cookie and balances traffic based upon the cookies hash value.

Sticky

Here persistence (on a per client IP basis) is applied to port 80.

Note : When configuring the subnet mask sticky command (‘port 80 client-subnet-sticky subnet-mask 255.255.255.240‘) the command ‘no port sticky 80‘ is also applied.

server virtual VIP1 192.168.1.3
  port sticky 80

Track Port

The track command is configured using the following construct ‘track <primary-port> <port>’. Within this example if traffic is sent to the primary port (80) and any further connections to the other ports within the group (port 23 and 69) then connections are sent to the same server. If any connections are destined for any port that is not defined as the primary port no persistence is applied.

server virtual VIP1 192.168.1.3
  port sticky 80
  port sticky 69
  port sticky 23
  track 80 23 69

Track Group

Within this example traffic destined for either port 80, 69 and 23 is distributed to the same server.

server virtual VIP1 192.168.1.3
   port sticky 80
   port sticky 69
   port sticky 23
   track-group 80 69 23

Cookie

Cookie Insert

Within this example cookie persistence is achieved by injecting a cookie named “ServerID” (containing the server ID). The value of this cookie is then used to maintain persistence to the necessary server. It is worth noting that the offset/length settings ensure that the beginning of the cookie value is matched for a length of 4 characters.

Note : The cookie that is inserted is a session cookie. This means that it does not have a date expiration set. These cookies display “session” under the Expires column. As the ADX does not maintain a timeout for this persistence, for the lifetime that the browser sends the cookie the session will always persist to the same server.
However an expiration time can be set within the CSW so that an expiry time/date is added to the cookie.

csw-rule "r1" header "cookie" search "ServerID="

csw-policy "p1"
  match "r1" persist offset 0 length 4 group-or-server-id 
  default forward 1
  default rewrite insert-cookie "ServerID"

server real RS1 10.1.1.1
  port http
  port http url "HEAD /"
  port http server-id 1211
  port http group-id 1 1

server real RS2 10.1.1.2
  port http
  port http url "HEAD /"
  port http server-id 1212
  port http group-id 1 1

server virtual VIP1 192.168.1.3
  port http
  port http csw-policy "p1"
  port http csw
  bind http RS1 http RS2 http

Note : To configure cookie persistence based on URI please see Brocade ADX – Cookie Persistence based on URI

Cookie Passive

Within the following example the string “ServerID=” is searched for within the header ‘cookie’. The value following this string is then used to balance the traffic.

csw-rule "r1" header "cookie" search "ServerID="

csw-policy "p1"
  match "r1" persist offset 0 length 4 group-or-server-id
  default forward 1

server real RS1 10.1.1.1
  port http
  port http url "HEAD /"
  port http server-id 1211
  port http group-id 1 1

server real RS2 10.1.1.2
  port http
  port http url "HEAD /"
  port http server-id 1212
  port http group-id 1 1

server virtual VIP1 192.168.1.3
  port http
  port http csw-policy "p1"
  port http csw
  bind http RS1 http RS2 http

Cookie Hashing

Within the following example the string “JSessionID=” is searched for within the header ‘cookie’. The value following this string is then hashed and used to balance the traffic.

csw-rule r1 header cookie pattern “JSessionID=”

csw-policy p1
  match r1 persist offset 0 length 16 persist-to-hash-bucket
  default forward 1
    
server real RS1 10.1.1.1
  port 80
  port 80 group-id 1 1

server real RS2 10.1.1.2
  port 80
  port 80 group-id 1 1

server virtual VIP1 192.168.1.3
  port http
  port http csw-policy p1
  port http csw
  bind http RS1 80 RS2 80

Note : For all cookie persistence methods, should you require persistence between HTTP and HTTPS then the same server-id should be applied to both HTTP and HTTPS on the real server. Along with applying the same CSW policy to both HTTP and HTTPS on the virtual server.

Rick Donato
Latest posts by Rick Donato (see all)

Want to become a networking expert?

Here is our hand-picked selection of the best courses you can find online:
Cisco CCNA 200-301 Certification Gold Bootcamp
Complete Cyber Security Course – Network Security
Internet Security Deep Dive course
Python Pro Bootcamp
and our recommended certification practice exams:
AlphaPrep Practice Tests - Free Trial