nf_conntrack table full dropping packet 로그

 

 

 

 

 

부하테스트 중에 문제가 발생하여 장비들을 뒤지다가 서버 한대에서 아래와 같은 로그를 확인하였다.

nf_conntrack라는 애 table이 꽉차서 패킷을 드랍한다니

 

 

# cat /var/log/message

또는

# demsg

 

 

 

 

 

 

 

 

 

일단 conntrack이란

 

iptables의 상태추적 모듈로 NAT 테이블이나 FTP 등과 관련이 있으며

커넥션들에 대해 기록하고 추적하기 위한 모듈

 

 

 

 

nf_conntrack이 활성화되어 있을 경우, 커넥션 상태에 대해 일정시간 동안 기억하게 되며

기억하는 한계는 table의 크기값으로 지정되어 있으며 기본값은 65536이다.

table 한계치를 초과하면 이후 패킷들은 모두 드랍한다.

 

 

 

 

아래 명령어들로 관련 상태를 확인 할 수 있다.

 

 

모듈 확인

# lsmod | grep nf_conntrack

 

table 크기 확인

# cat /proc/sys/net/nf_conntrack_max

 

현재 접속 수 확인

# cat /proc/sys/net/netfilter/nf_conntrack_count

 

 

 

 

 

 

 

 

이슈가 발생했을 때 서버에서 확인해보니

nf_conntrack_ipv4 모듈이 떠있었고, table 크기는 65536(기본값), 현재 접속 수가 655XX로 한계치에 근접해 있었다.

 

 

 

 

아니.. 웨지

iptables 정책도 특이사항이 없이 비워놨고

같이 쓰고 있는 옆 서버와 비교해도 별다를게 없는데

 

 

 

 

nf_conntrack_ipv4 모듈이 떠있고 접속 수가 655XX다.....

(nf_conntrack_ipv6는 두 서버다 켜져있었지만 트래픽 테스트에 ipv6를 사용하지 않으니 일단 패스)

 

 

 

 

 

iptables 재시작하고 다시 정책 비워도 마찬가지..

애초에 재시작할 때 기본적으로 켜지는 정책들이 문젠가 싶어서

 

 

 

기본 정책들에 state 관련 룰 다 지우고 재시작해보았다

 

 

 

# vi /etc/sysconfig/iptables-config

 

 

 

 

 

 

 

 

 

어.....

 

 

 

 

 

된다

 

 

 

 

 

된다!!

 

 

 

 

 

 

 

 

애초에 떠있던 nf_conntrack_ipv4 모듈이 없고

table에 접속 수도 없다

 

 

 

 

처음 iptables이 올라올 때부터 해당 모듈이 안올라오게 해야 하는 것으로 추정된다.

 

 

 

아 물론 conntrack table의 최대 값을 늘려서 사용하는 방법이 있지만

근본적인 해결은 아닌 것으로 보이고

결국 최대값보다 더한 트래픽 또는 연결이 생겨버리면 다시 문제가 발생될 것으로 보인다.

 

 

 

일단 방법은 sysctl 설정파일에 해당 값을 추가해주고 적용하면 된다.

 

 

 

# /etc/sysctl.conf

 

net.nf_conntrack_max = [원하는 값]

 

# sysctl -p

 

 

 

 

 

 

 

 

로그도 안생기고 

패킷도 안끊긴다

 

아 편안...

 

 

 

 

 

 

 

 

 

 

 

 

 

 

- 참조

https://blog.naver.com/n_cloudplatform/221638712887

 

 

 

 

 

 

 

 

끝