F5 Sites
  • F5.com
  • LearnF5
  • NGINX
  • MyF5
  • Partner Central
Contact
  • Under Attack?
  • F5 Support
  • DevCentral Support
  • F5 Sales
  • NGINX Sales
  • F5 Professional Services
Skip to contentBrand Logo
Forums
CrowdSRC
Articles
Groups
EventsSuggestionsHow Do I...?
RegisterSign In
  1. DevCentral
  2. CrowdSRC
  3. CodeShare

Single Node Persistence

Problem this snippet solves: A really slick & reliable way to stick to one and only one server in a pool. Requirement: Direct traffic to only a single node in a pool at a time. Initially, traffic ...
Published Mar 18, 2015
Version 1.0
application delivery
devops
iRules
persistence
CodeCentral_194's avatar
CodeCentral_194
Icon for Cirrus rankCirrus
Joined May 05, 2019
View Profile
CodeCentral_194's avatar
CodeCentral_194
Icon for Cirrus rankCirrus
Joined May 05, 2019
View Profile
Leonardo_Souza's avatar
Leonardo_Souza
Icon for Cirrocumulus rankCirrocumulus
Dec 08, 2020

I was reading an F5 configuration and saw the iRule in this codeshare link.

I knew it would have had to come from DevCentral. :D

 

The solution proposed here works fine.

However, as indicated in previous comments, destination address does the same job.

 

I just want to add more information about the performance side.

I hope this will make clear that destination address persistence is a better option.

 

As a general rule, only use an iRule if there is no builtin functionality for what you want to do.

Destination address persistence is a builtin functionality, universal persistence is also builtin but triggers an iRule.

 

I don't have access to F5 source code, so I will assume how the persistence table lookups work.

The iRule is using "1" as the key, so if you use the same persistence profile in multiple virtual servers, you will end up with multiple persistence with the key "1".

The persistence table does show the virtual server IP, so it lists the following.

universal (persistence type) - 1 (key) - virtual server IP and port - pool member ip and port - TMM number

I assume the system first do a lookup for key "1", and from that list, do another lookup for the virtual server IP and port.

As someone said in the comments, using something unique to the virtual server, like virtual IP and port, should remove the need for the second lookup.

 

All that to say, it is better to use destination address persistence than the solution proposed in this code share.

ABOUT DEVCENTRAL

DevCentral NewsTechnical ForumTechnical ArticlesTechnical CrowdSRCCommunity GuidelinesDevCentral EULAGet a Developer Lab LicenseBecome a DevCentral MVP

RESOURCES

Product DocumentationWhite PapersGlossaryCustomer StoriesWebinarsFree Online CoursesF5 CertificationLearnF5 Training

SUPPORT

Manage SubscriptionsProfessional ServicesProfessional ServicesCreate a Service RequestSoftware DownloadsSupport Portal

PARTNERS

Find a Reseller PartnerTechnology AlliancesBecome an F5 PartnerLogin to Partner Central

F5 logo©2024 F5, Inc. All rights reserved.
TrademarksPoliciesPrivacyCalifornia PrivacyDo Not Sell My Personal Information