Troubleshooting

네트워크와 관련된 문제를 분석할 때 Packet을 Capture해서 분석하는 것 만큼 효과적인 방법이 있을까? 이 글의 소재가 되는 (제목이 아직은 잘못 붙여진) “Vyatta Network Interface Down Issue” 역시, 결과적으로는 통신 내용을 확인하는 Packet Dump 분석을 통해 증상이나마, 증상이나마 확인할 수 있었다.

2018년의 첫 글은 2017년의 마지막 사건으로 시작하려고 한다. 이 마지막 사건을 “Vyatta Network Interface Down Issue“라는, 알고 보면 문제를 정확하게 기술하지 못하는, 잘못된 제목으로 일단 부를 것이다. 아무튼 (사건의 제목이 맞든 틀렸든) 어떤 프로젝트의 Vyatta 네트워킹에 문제가 발생했고, 이 글은 이차 저차 내게 넘어온 이 “네트워크 관련 문제"를 정확하게 파악하기 위한 추적 과정을 정리하는 글이다.

상용 제품의 한계로 인하여, 내게는 매우 중요한 문제이고 빠른 해결을 바라고 있지만 그것을 내가 어떻게 할 수 없는 경우가 있다. 바로 지금이 그런 상황인데, 이렇게 문제의 핵심에 접근하는 것이 제한적이거나, 원인을 정확히 알 수 없는 경우, 또는 원인을 안다 해도 근원적인 해결방법을 찾을 수 없을 때 우리가 할 수 있는 최선은 우회경로(Work Around)를 찾아 문제를 피하는 것이다.

“Linux Bridge로 네트워크 문제 추적하기“에서 얘기했던 것과 같이, 리눅스의 내장 Bridge 기능은 네트워크 통신과 연관된 문제를 뭐랄까… 대상의 OS 또는 구성과 관계없이 객관적 위치에서 추적할 때 유용하게 사용할 수 있다. 이번엔 VMware vSphere 가상환경 속에 위치한 VM을 대상으로 한 네트워크 분석 방법이다.

리눅스는 스스로가 Network Bridge¹로 동작할 수 있는 커널 기능과 유틸리티를 기본적으로 제공하고 있는데, 이 기능이 시스템 간 통신을 끼고 발생하는 문제점을 추적하는 과정에서 유용할 때가 있다. 이 글은 리눅스 Bridge를 이용하여 시스템 바깥에서 네트워크 흐름을 분석했던 경험을 기록한 것이다.

그냥 급하게 진행해버려서 로그를 다 놓쳤다. 아무튼, 내 kvm Guest가 미친듯이 달렸다. 이게 처음 겪는 일은 아닌데, 지난 번 사고때는 그냥 “뭐냐~” 하면서 재시작해버렸다. 그러나 이번엔 원인 규명을 위해 약간의 정보를 더 얻어봤다.