오랜만에 포스팅을 위한 글을 작성하게 되었다.

매주 1개씩 작성하려고 했었는 데, 이래 저래 치이다 보니 역시 쉽사리 잘 되지를 않는다.

하지만, 조금이라도 더 정신차려서 공부하는 겸 정리하는 겸 올릴 수 있도록 해야겠다.

 

오늘은 IP SLAEEM을 이용한 작업 예 내용입니다.

 

아래의 왼쪽의 구성도가 본사와 지사 간의 현재 구성인 것을, 신규 장비를 도입하면서 이중화 구성으로 변경을 하기 위해서

오른쪽 구성도와 같이 변경하려고 합니다.

 

 

 

현재의 제약사항과 구성 상황은 아래와 같습니다.

 

  ○ 방화벽 간의 Sync 불가 / VRRP 구성 불가

  ○ L4 구성 불가 (FWLB 불가)

  ○ 현재의 모든 Routing은 Static으로 구성되어 있다.

  ○ 본사 MR, BR에서는 지사에서 오는 HOST에 대해서 NAT를 수행하고,

      방화벽에서는 본사에서 지사로 가는 HOST에 대해 NAT를 수행한다.

 

  이 상태에서 이중화 구성을 어떻게 해야 정상적으로 문제가 되지 않을 수 있을까에 대한 부분이 이 작업에서 필요한 사항이었다.  변경 구성의 1번기 장비들을 Active로, 2번기 장비들을 Standby로 해서 이중화를 구성 했을 때 구간별 장애가 발생하였을 때 정상적으로 감지를 해서 Standby쪽으로 트래픽이 이동해서 정상적인 동작을 할 수 있을까?

 

 방화벽을 기준으로 상단의 본사 MR, BR측과 하단의 본사 R1,R2 측에서 구간 장애를 감시해서 Active쪽의 트래픽을 Standby쪽으로 변경해야 할텐데, 여기서는 상단의 MR, BR측에서만 살펴보려고 합니다.

 (어차피 한 쪽 구성을 하면 나머지도 유사하게 구성을 하면 되겠죠? )

 

우선 문제점을 살펴보면..

 

 

위의 그림과 같이, ① ~ ④ 중에 하나라도 장애가 발생할 경우에, Active로 가는 경로는 사용할 수 없게 됩니다.

따라서,  ① 구간의 문제가 발생하였을 때 본사 R1에서는 이를 감지해서 R2를 통해서 트래픽이 가도록 변경을 해야합니다.

본사 구간에서의 장비 문제 발생은 어차피 본사에서 라우팅을 수동으로 변경하는 등의 삽질(?)을 할 수도 있겠죠? ^^;

(물론 이러한 라우팅 변경은 자동화를 해야합니다. 아래의 본 예제와 유사하게 설정하면 됩니다.)

 

 하지만, 지사에서 보내오는 트래픽 경로는 본사 내부의 Active 경로의 문제 발생을 모르기 때문에 Bandwidth가 높은 본사 MR로 보내게 되고, 본사 MR에서는 해당 트래픽을 본사 R1으로 보낼 수 없기 때문에 정상적인 통신이 안되게 됩니다.

따라서, 지사에서 본사로 오는 경로도 Backup 경로를 통해서 올 수 있도록 자동화 해줘야 합니다.

 

 이제까지는 아래의 설정을 하기 위한 사설이었고, 이제부터 본 포스팅의 진짜 내용입니다.

위의 상황을 맞추기 위해서 아래와 같이 작업을 진행하려고 합니다.

 

  ※ 본사MR에서는 내부 구간(어느 구간이든 상관이 없이) 본사R1까지 가는 경로의 모든 경우의 수)의 장애 발생 시

      지사와 연결된 메인회선(512K) 대신에 백업회선(256K)로 트래픽을 받을 수 있게 해야 합니다

 

 물론 자동으로 감지해서, 경로 변경까지 자동으로 되야 합니다. 그래서 본사 MR에서 IP SLA와 EEM을 사용해서 이를 아래와 같이 구현해 보았습니다.

 

 I

 

ip sla 7

    icmp-echo 10.10.10.1

    delay up 60

ip sla schedule 7 life forever start-time now

 

track 10  ip sla 7 reachability

 

event manager applet TRACK_DOWN

 event track 10 state down

 action 1 syslog msg “Internal Link Fail"

 action 2 cli command "enable"

 action 3 cli command "conf t"

 action 4 cli command "int s0"

 action 5 cli command "shut"

 action 6 syslog msg “External Port Down"

 

event manager applet TRACK_UP

 event track 10 state up

 action 1 syslog msg “Internal Link Success"

 action 2 cli command "enable"

 action 3 cli command "conf t"

 action 4 cli command "int s0"

 action 5 cli command "no shut"

 action 6 syslog msg “External Port UP"

 

 

우선 IP SLA를 이용해서, 본사 R1의 IP까지의 ICMP를 체크하고. 본사MR에서 Active 상의 경로의 끝인 본사 R1의 IP를 체크하여 중간 구간상의 어떤 장애가 발생하더라도 감지를 할 수 있게 됩니다. 한 구간이라도 문제 발생 시에는 어차피 통신이 되지 않기 때문입니다.

 

 그리고 EEM을 이용해서 SLA로 설정한 Track 이벤트를 감지합니다. 만약 10.10.10.1까지의 통신이 안되는 순간이 발생하면, 이를 감지해서 track에서는 Down 이벤트를 발생하게 되고, 다시 정상적으로 통신이 되면 Up 이벤트를 발생하게 됩니다.

 EEM에서는 SLA에서 설정한 Track의 이러한 이벤트로 Active 구간 장애 발생 시, 지사와 연결된 Serial 포트를 강제로 Shutdown 합니다. 그러면 지사에서는 해당 경로로 통신이 안되기 때문에 자연스럽게 백업회선(256K)를 통해서 데이터를 보내오게 됩ㄴ다.  그리고 다시 내부 구간이 복구가 되게 되면, 다시 Serial 포트를 Up시켜야 하지만 문제가 완전히 처리되지 않은 상태에서 Up/Down이 발생하게 되면 해당 포트도 계속 Up/Down이 발생하게 되므로 Up시킬 때는 delay up 60 이라는 옵션을 통해서 60초정도 지연시킨 후에 Up 이벤트를 발생시킵니다.

 

 주저리 주저리 이상한 얘기를 많이 썼지만, 결국 장애가 발생할 수 있는 종단까지의 구간을 주기적으로 점검해서 문제 발생 시에, 반대편 Serial을 Shutdown 시키는 것을 IP SLA와 EEM을 이용해서 자동화하는 부분이었습니다.

 

 다음에는 좀 더 정리된 포스팅을 해야겠다는 생각을 유난히 많이하게 된 이번 포스팅이었습니다.

 

 

 

 

Posted by 네떡지기

티스토리 툴바