Forum Discussion
catoverflow
Altocumulus
AltocumulusHow to add a timestamp on iRule
Hello, I would like to insert a timestamp on an iRule that reflects the current time at the irule creation and then somehow to be able to update that irule when is updated. I need this cuz I want to...
Kevin_Davies
MVP
MVPFrom the above can I assume that you dont really trust sync and want a way to verify it yourself?
catoverflowExactly, we want to have a way for us to validate with our control plane that the irules are effectively synchronized and are the same at all times, this, among other things, is because we need to be able to validate that if a request with a specific header enters through an F5, let's say of region A, then if it cannot satisfy the request based on the header, then to be able to evaluate before performing a fallback to the F5 of the other region (let's say B), and be able to control, among other things, that that header exists and that it can resolve it, in which case just there would proceed to perform the fallback and complete the request in the destination of region B, otherwise it would go to the default pool in the source region (in this case A).
Perhaps I am adding one more degree of complexity in the question, which would be the fallback part.
You can validate that the exact same rule is running across your devices with the script above.
The header stuff confused me. Not sure what you mean?
- Kevin_Davies
As Patrick suggested MD5 is a great way to determine the rules are the correct. If you want to verify they have been synced thats a great way to do it. It is also efficient in that if they have not changed you will know it.
If you want to verify the sync functionality itself is working as expected then you need something unique for every sync request. Hence the suggestion of adding a header line to your iRule with a millisecond timestamp. Its nothing complex, its just taking the iRule content and adding a string at the top, or bottom of the iRule with a # in front so the F5 ignores it. Then strip it off when you retrieve the iRule. It is probably useful to add a key marker so you know its your header to strip off when you retrieve the iRule. Something like...
### SYNC 1662070557000 ###
# Add specific headers required for application
# v1.7
iRule code here
As for the sending requests from one BIG-IP to another logging is key. Have the first rule add a tracking id (tid) header and log it with ingress information "tid: virtual source" when handling a request. Have subsequent iRules on different F5's pickup the tid and use it as "tid: log message" when they process the request. Then when you look at your aggregated logs you can track the flow based on the tid.Pro Tip: If the tid is for tracking TCP connections then the source address and port are a good way to do this as they are required to be unique. They also have the benefit of providing useful information as well.
Hope that helps!
