Date: Tue, 02 May 2017 17:21:44 +0430 From: "Babak Farrokhi" <farrokhi@FreeBSD.org> To: Max <maximos@als.nnov.ru> Cc: freebsd-pf@freebsd.org Subject: Re: Similar entries in source tracking table Message-ID: <015E448C-4021-490D-A83E-1D1DB02110CB@FreeBSD.org> In-Reply-To: <96849677-28a6-1c7c-ccbb-2642aacd1813@als.nnov.ru> References: <5923A420-6BE6-4758-AE37-89C019F179E5@FreeBSD.org> <45a09f51-7b96-f7c1-e53b-9421fd1befbd@als.nnov.ru> <C22C7217-CE09-4C3B-89CC-8EA52E892C38@FreeBSD.org> <96849677-28a6-1c7c-ccbb-2642aacd1813@als.nnov.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_F1DACEB0-4942-44FF-ADBA-6D77B00540F5_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, After setting src.track to 0 I could reproduce the situation, but this ti= me both entries disappeared after a short while (as per =E2=80=9Cinterval=E2= =80=9D timer setting). =E2=80=94 Babak On 2 May 2017, at 16:26, Max wrote: > Could you set "src.track" to zero and check if the issue persists? > > > 02.05.2017 10:01, Babak Farrokhi =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> Hello, >> >> Here it is: >> >> # pfctl -vvsS >> No ALTQ support in kernel >> ALTQ related functions disabled >> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s = ) >> age 00:00:53, expires in 00:59:52, 6 pkts, 504 bytes, nat rule 0 >> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s = ) >> age 00:01:21, expires in 00:59:20, 16 pkts, 1344 bytes, nat rule 0= >> >> # pfctl -vvss >> No ALTQ support in kernel >> ALTQ related functions disabled >> >> I am running 11-STABLE r317643. Please note that this is only reproduc= ible when you reload your pf configuration and tables. >> >> =E2=80=94 >> Babak >> >> >> On 2 May 2017, at 10:41, Max wrote: >> >>> Hello, >>> Can you show "pfctl -vsS" output? And what version of FreeBSD are you= running? >>> >>> >>> 01.05.2017 17:59, Babak Farrokhi =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>>> Hello, >>>> >>>> I was running an experiment with pf in which I encountered an unusua= l case. >>>> >>>> In a nat setup, is this okay to have multiple similar entries in sou= rce tracking table? >>>> >>>> # pfctl -sS >>>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0= s ) >>>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0= s ) >>>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0= s ) >>>> >>>> There are actually three similar binding stuck in source tracking ta= ble. >>>> vmstat output also confirms separate memory allocation for three ent= ries in >>>> source tracking table: >>>> >>>> # vmstat -z | egrep 'ITEM|^pf' >>>> ITEM SIZE LIMIT USED FREE REQ FAIL S= LEEP >>>> pf mtags: 48, 0, 0, 0, 0, 0,= 0 >>>> pf states: 296, 8000005, 0, 1313, 2279, 0= , 0 >>>> pf state keys: 88, 0, 0, 2655, 4558, 0,= 0 >>>> pf source nodes: 136, 1500025, 3, 142, 7, 0= , 0 >>>> pf table entries: 160, 800000, 4, 121, 47, 0,= 0 >>>> pf table counters: 64, 0, 0, 0, 0, 0,= 0 >>>> pf frags: 112, 0, 0, 0, 0, 0,= 0 >>>> pf frag entries: 40, 100000, 0, 0, 0, 0,= 0 >>>> pf state scrubs: 40, 0, 0, 0, 0, 0,= 0 >>>> >>>> >>>> I can reproduce this behavior by reloading pf.conf and running traff= ic through >>>> the box and get a new entry added to source tracking table. >>>> >>>> Here is the nat rule: >>>> >>>> # pfctl -vsn >>>> nat on em0 inet from <internal-net> to any -> <external-net> round-r= obin sticky-address >>>> [ Evaluations: 368 Packets: 50 Bytes: 2084 S= tates: 0 ] >>>> [ Inserted: uid 0 pid 6418 State Creations: 28 ] >>>> >>>> and timers: >>>> >>>> # pfctl -st >>>> tcp.first 10s >>>> tcp.opening 10s >>>> tcp.established 4200s >>>> tcp.closing 10s >>>> tcp.finwait 15s >>>> tcp.closed 10s >>>> tcp.tsdiff 30s >>>> udp.first 60s >>>> udp.single 30s >>>> udp.multiple 60s >>>> icmp.first 20s >>>> icmp.error 10s >>>> other.first 60s >>>> other.single 30s >>>> other.multiple 60s >>>> frag 30s >>>> interval 30s >>>> adaptive.start 0 states >>>> adaptive.end 0 states >>>> src.track 3600s >>>> >>>> Any ideas if this behavior is expected? >>>> >>>> =E2=80=94 >>>> Babak >>> _______________________________________________ >>> freebsd-pf@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-pf >>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"= --=_MailMate_F1DACEB0-4942-44FF-ADBA-6D77B00540F5_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQJ8BAEBCABmBQJZCIDgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGMDgxNUY4ODYxQkYyREVBRjI2MUU5QzE2 QjI2N0FEODVENjMyRTlBAAoJEGsmethdYy6aRl8P/0+kooiVb/ScbZEA8eUbp/lM 1sDdqu0siKoIMQtF0JpITPnmcWEJvFZyJwDKsxEwGc9pWsIDjSO4xPR4zNMBbw3s /mDpLCuXV/pSztGpVgnuiGhWHaf93WVjtkvJNReRLvjoqTEt6piC5LLQnjxT1Wk0 vFgvpySpfBEz9dAu7OX86o+8itwOcD7/tGhcqUhyw9YuDFZy0FfvSxeWcoi9XEEc 5Sv0tXfjneTE2m8JEol7kQ++sezGf83yK41zuSXxxUhffPagR4WO0Q+tROhr1gBj ItmC+5eKln5gikLJBit2lq4ZrddCgUvptzJISBiJYHcfmqtrWDpqqLIsLIqJVfql aeKDoi0Sy2EgJlcsKrPnQ1BKq6eEl2vayhAkPk3z46yTDBSIKqQbnGHGP8I7LlYG Ab4tx/+/QNndTFzaXa3JeimXXHQNfHTWyjEP3/JOucMlS4P7LSzesS/ivE08UnOf khXdfx6NpyLAA6BW0lBTvBY4YuJFvKwUNafFs614jTnR6jnYnBVYi3t6QfZEZISO Y8CDZsdWaeGnhwAmG59qd5tPIOVxPeWp0aud3N3rZoc16jP1FdZfbo6UAl6zD9O/ QCdITOh1qfjDRoejn9X1krPwa5cCvJELQI6IKQ0JTcEojZhXYbDLCkp04pRFVhIP JDAyAXDEN/BlSuuOLXOy =3U3h -----END PGP SIGNATURE----- --=_MailMate_F1DACEB0-4942-44FF-ADBA-6D77B00540F5_=--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?015E448C-4021-490D-A83E-1D1DB02110CB>