어제 터진 KT장애건으로 불현듯  저와 주변에서 발생한 장애 히스토리가 주루룩 지나가더군요.

네트웍 밥 먹고 산지 어언 15년이 넘었습니다만, 이 분야는 바닥도 좁고 급변하는 클라우드 환경보다

기술발전이 더딘 혹은 정체되어 있는 분야다 보니 갈수록 유입 인원은 줄고 클라우드 쪽으로 진출하는 

인원만  늘어나는 고인물 바닥이 되고 있습니다. 15년차인 제가 우리 파트에서 아직도 밑에서 서열 3위라니..

각설하고 일반인은 잘 접하기 힘드실 네트웍 장애 사례를 두루뭉실하게 (너무 구체적으로,기술적으로 

쓰면 알아보실 분들도 계시므로) 적어보겠습니다. 뭐 비단 네트웍 뿐 아니라 IT infra쪽 필드에서

워낙 비일비재하게 일어나는 장애들이므로 클리앙에선 친숙하신 분 들도 많을테고, 

태클 거실 거리도 많겠지만, 태클 들어오신 분들. 네 일단 맞습니다 맞구요..

조금 긴 글이 될테니, 기술적인 얘기 싫다 싶으시면 지금 백스페이스를 누르시면 됩니다.

장비 오류로 발생하는 장애가 아닌 휴먼에러 위주로 기술하겠습니다.

1. 니가 보고 있는 터미널이 그 터미널이 맞냐?

휴먼 에러의 가장 빈도가 높은 원인 중 하나가 잘못된 장비에 config을 넣는데서 발생합니다.

비단 네트웍 어드민 뿐 아니라 서버,클라우드등 어드민이라면 화면에 터미널을 여러개 띄워놓고

작업하는건 기본일텐데, 본인이 작업하려는 장비에 접속한 터미널이 아닌 엉뚱한 장비의 터미널에

준비한 config을 붓는 순간, X발 X됐다가 육성으로 튀어나오며, 머리끝이 쭈뼛 서는 경험을 하게

됩니다. 물론 네트웍 장비는 privileged mode라고 config을 넣을수 있는 상위 권한 모드가 있어

일반적인 모니터링 시에서는 그 모드에 절대 들어가지 말라고 선배 사수들에게 귀가 따갑게

들어와서 문제가 되지 않지만, 문제는 정상적인 작업 땐 여러 대의 장비에 거의 동시에 작업이 

필요한 경우도 있어 이때는 정말정말 주의가 필요합니다. 저는 한 5번 정도 제가 작업하고 있는

장비의 터미널이 맞는지 확인하고 나서야 들어갑니다. 그래도 config이 들어갈 때의 불안함은

지금도 여전합니다. 요즘은 이런 불상사를 막기 위해 여러가지 기술적인 보완책들이 나와있긴

하지만, 그래도 실행주체가 인간이어서 발생할수 있는 실수는 아마도 100% 자동화가 되기 전까진

여전히 생길것 같습니다.

그럼 이렇게 잘못된 config이 들어가면 어떻게 해결을 하느냐? 

1) config 복원

아마도 대부분의 엔지니어는 이런 사태를 대비해 복원 config을 준비해 놓습니다.

문제는 그 복원 config은 내가 작업 하려던 장비에만 적용되는 config이라는데 있습니다.

다른 장비에 들어간 config은 복원 config으로 바로 원 상태로 돌아가지 않을 확률이 높습니다.

제조사마다 스타일도 다 달라서 no로 지워지는 장비가 있는 반면, 다른 방식으로 지워야하는

장비가 있고 해서 잘못 들어간 config을 한땀 한땀 다시 원래대로 돌려놔야 하죠

그래도 이 케이스는 쉽고, 행복한(!) 장애복구 케이스입니다. 아래에 비하면...

2) reload

여타 다른 IT 장비와 달리 네트웍 장비의 가장 큰 문제는 config을 잘못 넣으면 그 네트웍 장비로의

원격접속이 끊길수 있고, 이 경우 장비에 물리적으로 접근을 해야 문제의 원인을 해결할수 있다는데

가장 큰 애로사항이 있습니다. 

네트웍장비는 config 입력후 save(구원 아님 저장)을 하지 않으면 기존 config이 유지가 됩니다.

따라서 reload를 하면 기존의 config으로 부팅이 되면서 장애복구가 가능합니다.

근데 만약 지구 반대쪽 브라질의 네트웍 장비를 작업하다 이런 일이 발생한다?

그쪽 엔지니어가 물리적으로 문제를 해결해주기 전까지 손 빨고 있어야합니다.

(물론 대부분의 경우 이런 사태를 대비해 local assistant가 대기합니다)

자.. reload를 해서 문제해결이 되면 그나마 다행입니다. reload를 했는데도 문제가 해결되지 않는다

이러면 "난이제 죽었다"를 복명복창하시면 되겠습니다. 이 문제의 원인은 앞서 말씀드린 config 후

save에서 발생합니다. 바로 전 작업때 작업자가 save를 안한거죠. 전 작업자가 어떤 작업을

했는지 모립니다 ㅠㅠ 이때부터 정말 머리 터지는 장애복구 시간과의 싸움입니다. 

정말 재수없게 config이 꼬이면 아예 장비를 초기화 하고 제가 준비한 config을 때려 붓는게

오히려 장애시간을 단축할수 있습니다. 여기서부턴  정말 경험의 영역입니다. 한번 당해봐야 어떤게

더 빠를지 판단이 옵니다. 처음으로 이런 장애를 맞닥뜨리면 머리 속이 하얘집니다..

그래서 선배 사수로부터 배울때 작업 1원칙은 무조건 작업후 save입니다. 한번으로 모자르니 세번쳐라 꼭..

(웃긴건 모 벤더에선 장비에 config 저장하면 오류가 나는 버그가 있었..읍읍)

이와 같이 정상적인 변경작업이 장애복구로 이어지는 케이스가 많은 이유이고, 이를 방지하기 위해

2인 1조 상호 cross check를 기본으로 진행하게끔 하지만, 현실은... 잘 지켜지지 않는 경우가 생기고

인간은 또 같은 실수를 반복하겠죠.

2. 민폐갑 라우팅 장애

네트웍에는 많은 종류의 라우팅 알고리즘이 있습니다. Static, ISIS, OSPF,BGP,EIGRP 등등..

각각의 알고리즘이 어떻게 동작하는지 숙지하고 잘 설계하는게 엔지니어의 기본 소양입니다.

최근에 클라우드 환경이 도입되면서 BGP를 클라우드와 기존 onpremise 연동시에 적극적으로

사용하고 있습니다. 사실 BGP는 굉장히 큰 규모의 네트웍을 운영하는데 쓰이는 알고리즘으로

KT 등 ISP에서 주로 운용하던 지난 시절과 달리 이제는 저같은 일반 엔지니어도 쉽게 접하게

되었습니다. 예전에는 저 BGP 할줄할면 오오~~ 하던 시절에서 이제는 너 아직도 BGP할줄 모르니?

하는 시절이 된거죠.

각설하고 BGP는 굉장히 강력한 라우팅 control을 제공합니다. 큰 힘에는 큰 책임이 따르는 법이죠

라우팅 장애의 가장 큰 문제는 나만 X되는게 아니라, 내가 흘려준 라우팅을 받아간 이웃들에게도

큰 폐를 끼치는데 있습니다. 내 잘못된 config 한줄이 작게는 한 빌딩,혹은 기업망 전체를 

흔들리게 할수 있습니다.  BGP 라우팅 장애를 기술적으로 풀려면 지면도 부족하고 재미도 없으니..

더이상 자세한 설명은 생략한다. (사실 BGP장애는 저도 보질 못했.. 터지면 이번과 같은 국가급 장애)

3. 네트웍의 영원한 숙명 접근제어

초창기 네트웍 장비의 역할 중 하나는 접근제어였습니다. (지금까지 그래와꼬 아패로도 여전히..)

Access Controll list 일명 ACL을 통해서 장비를 드나드는 패킷들을 제어할수 있습니다. 

이를 발전시킨게 방화벽 Firewall이죠. 네트웍 엔지니어라면 방화벽도 한번쯤은 운영을 해봤을겁니다. 

ACL은 정말 강력한 패킷제어 control입니다. IP address 및 Mac address 단위까지 제어가 가능합니다. 

ACL의 형태는 blacklist,whitelist 방식 둘다 운용이 가능합니다. (방화벽도 큰 틀은 동일합니다) 

whitelist 방식 : 너 허용, 너 허용, 너 허용 ~~~ 나머진 다 안돼 (All deny)

blacklist 방식 : 너 안됨, 너 안됨. 너 안됨 ~~~ 나머진 다 허용 (All permit)

뭐가 문제가 될지 좀 보이시죠? 바로 All deny 구문입니다. 이걸 잘못 적용하는 순간

내 접속 세션도 끊겨버리고 다 막힙니다. 뭘 해야 하죠? 불이 나게 뛰어가서 장비 껏다 켜야합니다.

Again 큰 힘에는 큰 책임이 따르는 법입니다 (그만 좀 시켜라 이것들아 ㅠㅠ)

ACL은 가능하면 운영에서 배제하는게 장애요소를 줄이는데 큰 도움이 됩니다.

변경은 너무나 쉽고 간단합니다만, 문제 발생시 리스크가 너무 크기 때문이죠.

그러나 현실은 "야 방화벽 비싸자나. 그냥 장비 ACL 올려서 니가 관리해 ㅋㅋ"

그러다 장애나면 제가 다 뒤집어 씁니다. 하아..

4. 그깢 케이블 잘못 한번 꽂았다고..(추가분)

사무실에서 근무하시는 분들 대부분 책상에는 케이블 한개 정도는 나와있을 겁니다.

문제는 이 케이블들이 부족해지면서 허브나 공유기 같은 것들을 추가로 사용하게 되죠

주로 회의실에서 많이 발생하는데, 허브에서 나온 케이블을 다시 허브에 꽂으면... 말그대로 뒤집니다.

허브가 연결된 상위 네트웍 장비 전체가 Loop이 돌면서 다 뻗습니다. 어디까지 뻗는지는

설계에 따라 다르지만 아무튼 X되는 겁니다. 네트웍 어드민을 엿먹이고 싶다 그러면 위의

방법을 실행하시고 Run 하시면 됩니다. (I will find you and kill you)

Loop을 자세히 설명하진 않겠지만 트래픽이 죽지도 않고 좀비처럼 증폭되면서 네트웍 장비의

자원을 고갈시킨다고 이해하시면 됩니다. 그리고 지금은 기술이 발달하여 간단한 loop은 

방어가 가능하도록 되어 있습니다만, 이전에는 정말 비일비재하게 일어나는 장애였습니다.

심지어 네트웍 어드민이 케이블을 잘못 꽂아서 직접 loop을 일으킬 정도였으니까요..(그게 접니다! 후후)

이거 어떻게 해결하냐고요? 그 포트 찾아서 뽑기 전까진 해결이 안됩니다. 

지금까지 전능하게 쓰였던 Reload까지 소용없는 진짜 X같은 장애에요.

님이 무심코 꽂은 케이블 하나에 네트웍 엔지니어의 주말이 날라갈수도 있는겁니다.

이 글을 보시는 분들은 케이블 연결하실때 주의좀 해주십시요 흑흑

지금까지 보신것처럼 네트웍 장애는 일단 터졌다하면 대규모 장애로 이어지기 때문에

스트레스가 꽤 심합니다. 그래서 이걸 못 견디고 타 분야로 이직하신 분들도 많고요.

그리고 IT인프라계의 "노가다 십장"이라 불릴 만큼 커버해야 할 범위가 넓습니다.

이론적인 지식 뿐만 아니라 UTP 케이블 따는 법부터 전산실 바닥의 케이블 추적등 허드렛일

까지.. 어디 프로젝트 가면 다른데는 팀단위로 나와서 지원하는데 네트웍 엔지니어는

혼자서 케이블부터 장애까지 모두 책임져야 하는 경우도 많습니다 

제일 먼저 투입되서 제일 늦게 빠지는 일당백의 역할을 감당해야 하죠.

근데 재밌습니다. 세상(패킷)이 어떻게 흘러가는지, 마치 네오가 매트릭스의 이진수를 보는것처럼

건물의 패킷들이 어디로 모여 어디로 어떤 식으로 나가는지, 또 어떻게 모여서 처리되는지..

이런 큰 그림을 설계하고 구현하고 운영하는게 재밌습니다. (장애는 빼고요..)

그러니까 개발자 그만하고 여기 노가다 십장하러 좀 오세요! ㅋㅋㅋ

장애 얘기하다 구인글로 마무리 하는군요. 긴 글 읽어주셔서 감사합니다.