PicOS sFlow 연동 실패, 플로우 모니터링 해결 방법 결론

sFlow 책임자 Peter의 답변에서

1. prometheus.yml의 group param 추가 (필수사항)

해봤지만 실패

2. sflow-rt의 browse-flows, browse-metric, sflow-test 등 추가 App으로 Flow 시각화 및 테스트

추정 원인 발견

플로우 그래프의 뒷부분이 빨간 원처럼 곡선을 그린다.

이는 플로우 데이터가 t(평활화)의 영향을 받아 조작됨을 암시한다.

 

t의 값에 따라 여러번 테스트해본 결과

t = 500 (최댓값), 48분 동안 데이터 지속
t = 10, 3분 동안 데이터 지속, 측정값: 888.131557MB
t = 1, 70~75초 동안 데이터 지속, 측정값: 802.036606MB
t = 0.8, 70~75초 동안 데이터 지속, 측정값: 812.605983MB
t = 0.5, 70~75초 동안 데이터 지속, 측정값: 1,207.39316MB, 1,018.61167MB, 852.924301MB, 1,110.31862MB 등 다양
실제 전송량은 100MB * 60s = 715MB (iperf3), 757,034,382 (Wireshark) = 721.964247 MB

 

3. log: true로 하고 total bytes를 집계하는 방식으로 프로그램을 간단하게 작성했지만 부정확한 값 도출

측정 값: 53,039,504 MB 실제 값:35.9 MB

4. sflow-rt가 아닌 직접 sflow 패킷을 확인하고 샘플 값을 더하는 방식으로 간단한 파이썬 코드를 작성해봤더니 부정확한 값 도출

 

4번부터 뭔가 이상해서 PicOS가 아닌 다른 스위치에서 sFlow를 설정하고 실행해보니

prometheus exporter에선 t에 따라 값이 정확할 때도 있고 아닐 때도 있었다.

파이썬 코드로 다른 스위치를 테스트해보니 값이 정확했다.

 

결론은 PicOS 스위치 sFlow 기능이 애초에 부정확한 값을 내보내고 있었다.

따라서 PicOS 스위치의 플로우 모니터링 기능은 연결된 SDN Controller에서 수행해야했다.

SDN Controller에서 OpenFlow Flow Rule을 생성할 때 Selector로 IP_SRC, IP_DST, PROTO_NUM, TCP/UDP_SRC, TCP/UDP_DST를 넣어줘서 해결했다.

이때 Selector가 제대로 안만들어지는 일이 생기는데,

OvS 공식 문서에 따르면

IPv4의 정보가 필요하면 ETH_TYPE으로 IPV4를 지정해줘야한다.

 

원래는 sFlow가 안돼서 스위치 커널에 ipt-netflow를 설치하려고 했지만,

어차피 무선환경에서 NetFlow가 제대로 동작하지 않아서 SDN Controller에서 해결해야 할 일이긴 했다.