Brocade ADX Persistence is useful when a user needs their traffic to go back to the same Server for the entire session. For example, a Website may require a login which needs to retain the Clients session for the duration the user is on the site. If the Client gets loadbalanced to another Server, this information could be lost and the Client would need to log back in and start over. Persistence would correct this issue and allow the user to stay connected to the same server.

IP Based Persistence

The easiest form of persistence is based on the Clients Source IP. We can do this at a per IP basis or for an IP range. To configure IP based persistence, we will need to enable something called sticky.

Single Source IP Based Persistence

server real Web1-172.24.16.25 172.24.16.25
port http
port http keepalive
port http url "HEAD /"


server real Web2-172.24.16.26 172.24.16.26
port http
port http keepalive
port http url "HEAD /"


server virtual VS-23.53.90.211 172.24.99.211
port http
port http reset-on-port-fail
port http sticky
bind http Web1-172.24.16.25 http Web2-172.24.16.26 http

The ‘port http sticky‘ is what enables per Client IP based persistence (sticky). When a new Client comes in, if the connection does not have a ‘sticky’ record on the Brocade, the connection will get loadbalanced to either Web1 or Web2. Once a loadbalancing decision is made, the Clients IP will be stored in the Brocade tying the users IP to the Server it was loadbalanced too.

Source IP Range Persistence

The command for IP range is similar to the previous command but will had the addition of a netmask. The command that would replace the one above would be ‘port http client-subnet-sticky subnet-mask 255.255.255.0‘ which would now persist on the entire /24 that the Source IP originates from.

How long IP Persistence stays in the table

By default, if the Client is idle for 5 minutes, this Persistence record will get deleted within the Brocade. To allow the Brocade to hold on to this record longer, the command to use is sticky-age <1-60> on the VIP. This command will allow the Brocade to hold on to the connection up to 60 minutes. If the persistence record needs to be held for longer then 60 minutes, you would need to add the command sticky-age-multiplier <1-60>. The multiplier will multiply the sticky-age value by the value used within the multiplier. For example:

server virtual VS-23.53.90.211 172.24.99.211
port http
port http reset-on-port-fail
port http sticky
port http sticky-age 60
port http sticky-age-multiplier 5
bind http Web1-172.24.16.25 http Web2-172.24.16.26 http

The Brocade will now hold the persistence record for 300 minutes (60 x 5).

Persistence Across Services

The Brocade can also persist across services when using IP Based Persistence. To perform this type of persistence, the track-group command will be used. This command will allow persistence records to exist across any ports bound within the track-group command. This command will also tie the Servers healthchecks together for the ports within the group as well. An example for this command would be like the one below.

server virtual VS-23.53.90.211 172.24.99.211
port http
port http reset-on-port-fail
port http sticky
port ssl 
port ssl reset-on-port-fail
port ssl sticky
bind http Web1-172.24.16.25 http Web2-172.24.16.26 http
bind ssl Web1-172.24.16.25 ssl Web2-172.24.16.26 ssl
track-group http 443

In this example, the Brocade is tracking both HTTP and SSL traffic for this VIP. Any traffic that gets a persistence record for HTTP will also get one for SSL. Keep in mind though this also tracks the ports healthchecks. If SSL for Web1 were to fail, this will also stop sending traffic for HTTP to Web1 even though HTTP may be passing its healthcheck.

Cookie Persistence

To enable Cookie Persistence on the Brocade, a CSW Policy needs to be created. A CSW policy is a mechanism on the Brocade to inspect or alter HTTP traffic that is destined to a VIP. Note, if Cookie Persistence is needed on SSL (https) traffic, the Brocade will need to be terminating SSL.

Types of Cookie Persistence

When doing Cookie Persistence on the Brocade, the cookie is usually injected by the Brocade referencing the Server ID. This can be a session based cookie or a time based cookie depending on the needs needed for the VIP. The Brocade can also use Passive Cookie Persistence based on a Cookie the Server provides but that is much more complicated and will be done in another article.

Basic Session Cookie Persistence

Session Cookie Persistence needs the real/remote servers in the VIP to have Server IDs and Group IDs to function. Group IDs range from 1 to 1023 and Server IDs range from 1024 to 2047. Group IDs are assigned as a range(s) while the Brocade can only have one Server ID per port on a real/remote server. Example configuration below:

server real Web1-172.24.16.25 172.24.16.25
port http
port http keepalive
port http url "HEAD /"
port http group-id 1 1
port http server-id 1024

server real Web2-172.24.16.26 172.24.16.26
port http
port http keepalive
port http url "HEAD /"
port http group-id 1 1
port http server-id 1025

server virtual VS-23.53.90.211 172.24.99.211
port http
port http reset-on-port-fail
bind http Web1-172.24.16.25 http Web2-172.24.16.26 http

The green is what needs to be configured on the real/remote servers before the Session Persistence can be used. If the CSW Policy is created and bound to the VIP without these set, the persistence will not function.

Now we will create the CSW Rule, CSW Policy and apply them to the configuration from before.

csw-rule "COOKIE" header "cookie" search "ServerID=" case-insensitive

csw-policy "COOKIE-PERSIST" case-insensitive
match "COOKIE" persist offset 0 length 4 group-or-server-id
default forward 1
default rewrite insert-cookie "ServerID" 

server virtual VS-23.53.90.211
port http csw-policy "COOKIE-PERSIST"
port http csw

With the above example, I create a rule called COOKIE and asked it to look at the HTTP header and search for a cookie with ServerID=. The policy, if it finds this cookie, will persist on the value of the ServerID cookie starting from 0 with a length of 4. This is because cookie value will be no longer then 4 digits and will use this to match against the Server.

The default portion of the CSW Policy tells the VIP to loadbalance to anything in group 1. Once a decision is made, the Brocade will insert a cookie called ServerID using the Server ID of the Server. If no Server ID is applied to the then the Group ID is used instead. (Note: The VIP has the “port http csw” command in red. If this command is not added to the VIP,  the CSW Policy will not be enabled)

Basic Time Based Cookie Persistence

A Time Based cookie means that the user does need to keep their session up in the browser to stay persisted. This cookie will stay in their browser for a certain amount of time and will delete itself one the time is up.

To configure a Time Based Cookie on the Brocade, we will just need to add a time to the cookie that is being inserted by the CSW Policy.

csw-policy "COOKIE-PERSIST" case-insensitive
match "COOKIE" persist offset 0 length 4 group-or-server-id
default forward 1
default rewrite insert-cookie "ServerID" * * 30

To insert a Time Based cookie, we need to add the values highlighted above. The orange *‘s are for adding a domain and path to the cookie. The first * is for adding a domain to the cookie but if a * is used instead of a domain, the domain is set to default. The second * is for adding the URL path to the cookie but having the * means to use the default path. These can be set if those values need to be set but in most cases using the * is fine. The green value is how many minutes this cookie should be stored in the Clients Browser. In this case, the cookie is stored for 30 minutes and then deleted. Having the value set at the end is the only difference between a Session Based Cookie and a Time Based Cookie on the Brocade ADX.

You can find more details about Brocade Real Servers and Remote Server configurations in my other Brocade article here.

Please feel free to reach out to me via my contacts page if you have any requests on more content or if you have any questions. If you want any help with an ADX in your Office, please feel free to contact me as well. I will work with you on configuring, upgrading or migrating the ADX.

The post Brocade ADX Persistence appeared first on Think Netsec.

We will use the configuration below:

server real WEB1-10.10.10.5 10.10.10.5
port http
port http keepalive
port http url "HEAD/"
port ssl
port ssl keepalive

server real WEB2-10.10.10.6 10.10.10.6 
port http 
port http keepalive 
port http url "HEAD/" 
port ssl 
port ssl keepalive

server virtual VS-10.10.10.100 10.10.10.100
port http
port http reset-on-port-fail
port ssl
port ssl reset-on-port-fail
bind http WEB1-10.10.10.5 http WEB2-10.10.10.6 http
bind ssl WEB1-10.10.10.5 ssl WEB2-10.10.10.6 ssl

Lets say we need our App Server with IP 10.10.10.50 to connect to the 10.10.10.100 VIP. If you try to connect to this VIP from the App Server, the connection will never complete. The flow would look like the following TCP flow below.

Source IP   ———-   Destination IP
10.10.10.50   —>     10.10.10.100 (VIP)
10.10.10.50   —>     10.10.10.5 (Member)
10.10.10.5     —>     10.10.10.50 (Client)

Notice that the Server responds back to the Client and not the VIP. The Client Server did not connect to the 10.10.10.5 but rather the VIP at 10.10.10.100. The Server will drop this traffic since it never had made a connection to the 10.10.10.5 so the TCCP connection will never complete.

With Source NAT

To correct the issue from before, we would need to enable Source NAT. This will allow the Brocade to translate the Source IP for any connections to the VIP as the closest egress interface IP. For the sake of the example, the IP on the Brocade is 10.10.10.1 and it is the gateway for these Servers. To enable Source NAT, you will add the source-nat keyword to the real servers.

server real WEB1-10.10.10.5 10.10.10.5 
source-nat

server real WEB2-10.10.10.6 10.10.10.6 
source-nat

The post Issues connecting to a VIP on the Brocade ADX from a Server appeared first on Think Netsec.