Berk D. Demir wrote: > Because source tracking entries lives with state entries. As soon as the > state between the peers expire, your source tracking entry also > disappears by default. > Setting the time out "src.track" to any value other than zero (0) (whic > is the default value) will tell the kernel to keep the this tracking > entry after the expiration of last related state.
Ok. I will refine my question. Why one machine with a source track entry and with it's states not expired, suddenly get the packets redirected to the other gateway? (Note, that the machine lose the internet connectivity) > I can not comment on this since I don't know the topology and your exact > config but sure, round-robin load balancing with sticky addresses works > perfectly in enterprise environments with huge loads (like 500K states). > > "pfctl -k" (with lower k) will kill the states. Not source tracking. I > explain above how these src-track entries disappear after state > expiration (or kill). > I know that pfctl -k kill only the states of one specific host. But, correct me i I'm wrong. If the src.track is on it's default of 0s, and i kill the states, then the src.track entry will expire, and will be removed right? > > Ok. It's becoming funnier. You don't even read the replies to you with > enough care. I've pasted you an excerpt from the man page. > > "increase the global options with set timeout source-track" > > ...What do you think this very particular line means? > > BTW. "set timeout source-track" is not valid in current pf > configuration. This line on man page may be changed with > s/source-track/src.track/ > > But following the man page will lead you to the related line > "src.track Length of time to retain a source tracking entry after > the last state expires." > > Sorry but man pages are not like HOWTOs in Linux world. They won't > generally give you "copy & paste to make it work" guidance. > > bdd > > Yes, i read with much care what you wrote. I've read the pf.conf man page from top-down and from bottom-up many times. Again, correct me if i'm wrong, but let's say that I'm using the sticky-address with the src.track within it's default value. If i open a connection from a machine, one state will be created and, because of the sticky-address, one source track entry will be created. If the connection is passing packets, the state will not expire and, consequently, the source track entry will not expire, right? Then, if i close my connection, let's say a TCP connection, it will enter in the FIN_WAIT state. Normally, after 2 minutes, this state expire. And then the source track enter in the expire time stage, right? In this case, the expire time is 0, so the source track entry is deleted, right? If i open another connection before the FIN_WAIT state is deleted, then the source track entry will have another state, and another connection, so it will not enter in the expire time stage. Then, i played with the src.track timeout and put 320 seconds, or 5,33333... minutes. When there where no more states, the source track entry started to countdown from 00:05:33, to 00:00:00. If no state where created within this time, only then the source track were deleted. I tested it in my test firewall, and things remained the same: working. But when i replicated the sticky-address and the src.track 320 timeout to my main firewall, then the same weird behavior started: some machines , some times got to the internet, some times not. I am starting to look to other things. I do have 5 ethernet cards in my firewall. One fxp(4) and 4 rl(4). But all the rl(4) are in the same IRQ Address. I already had some problems with these cards, but the kernel showed watchdog timeouts and other things in the logs. But i'm not getting any of these in my logs. Both in the test firewall nor in my main firewall. I know that howto and man pages are not the "de facto" word about something. If you want real documentation, look at the sources. I only said it because it's true. I'm very well familiarized with the linux howto and guides, and know that many of them are just what you said, copy & paste, or "cake recipe" as we call them here. You don't need to be angry or impatient for answering my e-mails because trust me: i searched the man pages, the faq, google, google/bsd, and many other sources before asking in this list. And thanks for the help, anyway. My regards, -- Giancarlo Razzolini Linux User 172199 Moleque Sem Conteudo Numero #002 Slackware Current OpenBSD Stable Snike Tecnologia em Informatica 4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
