If i set the timeout multiplier to be 3 on a content rule so it's 48 seconds, why when i look at the 'flow-agent show fcb' information does it give me the correct inactiveTimout but then allocate a 'New FCB time' of 120 which overrides my configured 48 seconds?
May timeout due to inactivity: Yes , inactiveTimeout: 48
New FCB time: 120, will consider inactivity in 86 secs
Inactive Secs: 34
Here you have a link:
A. FCB is a term used for two different things. There is a fastpath FCB that is used to map a flow and allow transformations on each frame in the flow to be done entirely by the fastpath microcode running on either the etherPIF (for 10/100 ports) or the XPIF (for Gigabit ports). Fastpath FCBs come out of memory that is local to the chip used for the port. For an etherPIF, this chip contains 4 10/100 Ethernet port interfaces. The memory used for FCBs is shared for each port in the etherPIF. In the CSS 11150 and CSS 11050 products, the ports 1-4 share memory, ports 5-8 share memory, and so on. For XPIF ports, the memory is not shared between ports. If you have uplink 10/100 ports, you will want to keep them isolated from any other ports that are occupied (like server ports) if you have that option. Obviously, if all ports are populated, you do not get to make this decision.
The flow manager also has FCBs. The flow manager FCBs contain all the information in the fastpath FCB, plus additional information to allow the flow manager to properly manage the flow. There is one FCB used per ingress direction of a flow. Thus, a TCP connection is going to take two FCBs, and a UDP flow is going to take one. UDP flows can be bi-directional, however, they often are not (for example, streaming audio).
Hope this helps!!!
Thanks for the link Jorge, but I've read that document before and i understand what the FCBs are but it doesn't help explain why when i explicitly configure a timeout of 48 seconds, the CSS overrides my configured timeout with this 'New FCB time' of 120 seconds.
The "New FCB time" is the time from the beginning of a connection before the CSS starts checking the inactivity timer for it. This means that, after the first 120 seconds, if the connection remains idle for 48 seconds (the inactivity timer you defined), it will become a candidate for garbage collection.
You should also be aware that, on CSS a flow may not be removed from the table as soon as the inactivity timer is reached. Instead, the CSS will mark it as a possible inactive flow but will leave it in the table until the resources associated to that flow are required.
I hope this answers your question
Many thanks for your reply Daniel. That makes perfect sense, I just wish that this 120 second window before configured timeouts become active was documented somewhere. If it is, could you point me to the illusive document please? Is this configurable in anyway etc. ?
Digging around in llama I noticed that when this new FCB 120 second timeout elapses the FCB flag changes from '0x0080 - In Proto List' to '0x0100 - In LL List'. I'm guessing internal to the CSS this flag change somehow alerts the CSS that this flow should now be tracked bases on the configured timeout values. Again, with the llama flags not being documented it's difficult to glean much from this though.
Thanks again for your post,
I'm afraid there is no external documentation on the llama commands or outputs. The reason for that is that the llama mode should not be accessed by customers without explicit guidance from TAC.
This mode is designed to be used by TAC when internal debug information is required, but, since it doesn't implement any kind of protection mechanisms if the wrong command is used, you may cause some unexpected effects.
To answer your question, this 120 seconds period is hard coded and cannot be modified.