Denys Fedoryshchenko a écrit :
It looks like probably i did mistake while applying it. Very strange, cause i
rechecked it, and i did make clean before building system image.
I will make sure on vanilla code that everything is fine.
Btw, i see permanently 4 "delayed"(?) records.
[ 6261.050827] dstgc [0] lo 09E9FED5 09E9FED5
80000000 5 29 0 8F323353 0 0
0 00 -1 009E9FED5
[ 6261.050834] dstgc [1] lo 09E9FED5 09E9FED5
80000000 37 358 0 FC9B62D4 0 0
0 00 -1 009E9FED5
[ 6261.050838] dstgc [2] lo 09E9FED5 09E9FED5
80000000 4 8 0 7048DF48 0 0
0 00 -1 009E9FED5
[ 6261.050842] dstgc [3] lo 09E9FED5 09E9FED5
80000000 6 5 0 6924E846 0 0
0 00 -1 009E9FED5
[ 6261.050851] dst_total: 129123 delayed: 4 work_perf: 0 expires: 68000
elapsed: 27 us
Especially interesting one with refcnt 37 and dst.__use 358. I check for
around 5 minutes - there is no traffic at all. This record staying for long
time and there is no activity on it over "tcpdump -ni any host
212.98.155.252" , and it is not flushing it over ip route flush cache.
This route with refcnt 37 has Source IP = FC9B62D4, which is 212.98.155.252
Check that you dont have some tcp sessions with this remote address :
ss dst 212.98.155.252
As long as you have no activity on it, refcnt wont change.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
