[L2]Track을 활용한 Gateway 다중화

바로 Gateway의 이중화의 심화 과정에 대해서 진행해보겠습니다. 

 

우리가 Gateway를 이중화 하는 이유는 당연하게도 서비스의 연속성을 위함입니다. 

그렇다면 당연하게 바탕에 깔려있어야할 조건이 Gateway가 되는 장비에서 서비스를 위한 정상적인 Routing이 있어야 한다는것입니다. 

 

아래의 경우를 보시죠. 

 

 

 

Host의 Gateway는 정상적으로 연결이 되어있지만, Gateway가 되는 장비에서 Internet회선이 Down된 상황입니다. 

최악의 상황에서는 서비스 불가, 최선의 상황에서는 아래와 같은 불필요한 Traffic flow가 발생하게 되는것이죠

 

 

물론 어느정도 설계가 되있는 상태에서 위와 같은 Flow가 가능하지만, 굳이 Router1을 거쳐서 통신할 필요가 있을까요?

저는 없다고 생각합니다. 

 

트래픽이 적고 장비의 Performance가 충분하다고 하더라도 불필요한 Flow라는 생각을 버릴 수가 없었습니다. 

 

위와 같은 구성에서 Uplink 인터넷 회선이 Down되었을때, FHRP의 Master role이 같이 넘어간다면, 불필요한 Flow를 줄일 수 있습니다. 

 

이럴때 보통 Interface Line-protocol을 이용한 Track을 사용하여 Priority를 낮추곤 하죠. 

 

track에는 많은 trigger가 있고, Line-protocol, SLA 심지어 routing 여부나 해당 Routing의 Metric으로도 trigger를 걸 수 있습니다. 

여기까지는 많은 분들이 아실겁니다만, Track의 LIst기능은 제가 처음 알아서, 기본적인 동작에 대한 LAB과 track list를 활용한 FHRP master 전환 방식에 대한 LAB을 진행해 보겠습니다. 

 

Track list를 활용한다면, 위의 trigger 등을 여러개 사용하여, 조건을 더 복잡하게 사용할 수 있는 장점이 있습니다. 

 

 

========================================================================================

 

1. LAB 구성도 

 

Router1,2는 각자의 Lo0 interface가 설정되어있고, OSPF 설정을 통해 SW1이나, SW2에서  해당Loopback 까지 필이 가능합니다.

 

SW1은 VLAN100에 대한 VRRP master를 하고 있고, SW2는 VLAN101에 대한 VRRP master를 하고있습니다. 

 

여러 Case에서 VLAN100만을 가지고 진행할 예정입니다. 

 

2. LAB base config  
  

위 구성도의 Config는 직전 posting의 내용을 사용했기에 한번 더 작성하진않겠습니다. 

사실 구성도랑 위의 설명만 보셔도 이해가 가능하실만큼 기본적인 Config이고,

궁금하신 분은 직전 포스팅을 참고해주세요 

 

3. Lab 시나리오 

 

그럼 다양한 Case를 통해 Track을 활용한 Gateway 이중화에 대한 LAB을 진행해보겠습니다. 

 

Case #1 : 특정 Interface Down 시, VRRP master Role 변경 

 

본 case에서는 SW1의 E0/0 Interface가 Down되었을때, VRRP prority 감소를 해보겠습니다. 

 

E0/0의 경우, Router와 연결된 Serial link로, Down되더라도 VLAN 자체의 Priority랑은 무관하나,

해당 Interface를 트리거로 사용해보겠습니다. 

 

 추가 Config 

 

SW1

track 100 interface e0/0 line-protocol

int vlan 100

vrrp 100 track 100 decrement 10

 

간단히 설명하자면, Interface e0/0의 Line-protocol이 Down되었을때, Track 100이 Down 되고, 

Track 100이 Down 되었을때, VLAN 100의 Priority를 10감소시키는 Command입니다. 

 

제가 이전 포스팅에서 Preempt의 기능은 Master에만 적용해놔도 정상적으로 동작한다고 했는데, 

위처럼 직접적인 VLAN Down이 발생하는 장비 Fault나 VLAN hang과 같은 상황이 아니라,

Track과 같이 외부 요인에 대한 Priority 값 변동이 있다면, Backup 장비에도 반드시 Preempt설정이 되어있어야 합니다.

 

그래야지만 Priority 값의 변동을 알아채고 Standby 장비에서 Master role을 가져갈 수 있습니다. 

 

적용을 하고 난 이후에 SW1에서 E0/0을 다운시켜봤다가 업 시켰을때의 로그를 보시죠 

 

다운시키기전 VRRP group 100에 대해서 SW1은 Master role을 가지고 있었습니다. 

E0/0 인터페이스를 다운시키는 순간 track down log가 발생하게 되고,

VRRP group 100에 대한 Master role을 잃는것을 보실 수 있습니다. 

 

Track이 Down된 순간 105였던 Priority가 95로 감소하게되고, Preempt 설정된 Standby 장비에 의해서, 

Master role이 바뀌게된것이죠. 

 

인터페이스를 다시 살렸을때는, 반대로 Track이 Up되고, Priority는 105로 원복됨과 동시에 Master role을 가져오게 되죠. 

 

이러한 방식은 사이트 혹은 데이터 센터 등 인터넷이 인접한 부분의 VPN 장비를 Handling 할 경우에 자주 사용됩니다. 

Uplink가 없는 이상 굳이 해당 VLAN의 Gateway를 할 이유가 없으니까요 

 

Case #2 : Routing 여부에 따른 Role 변경  

 

이번에는 특정 라우팅이 없을때, Track이 Down되도록 해보겠습니다. 

 

 

 추가 Config

 

SW1

track 100 ip route 1.1.1.1/32 reachability

int vlan 100

vrrp 100 track 100 decrement 10

 

아래와 같이 OSPF를 통해 SW1의 라우팅 테이블에는 1.1.1.1/32에 대한 라우팅이 있는 상태이며,

R1에서 Loopback interface shutdown을 통해 라우팅을 삭제 시켜 보겠습니다. 

 

 

결과는 보시다시피 1.1.1.1/32에 대한 라우팅이 없어지면서 Track이 Down되고, VRRP의 Master의 Role을 잃었습니다. 

혹시 Default routing에 대한 라우팅이 있을 경우, 정상 동작하지 않을 수 있어 추가해봤는데,

정상적으로 Track이 Down된 것으로 보아, Prefix/subnet이 정확히 매칭되어야지만 Track이 Down되는것으로 보입니다. 

 

Case #3 :ICMP 응답 여부에 따른 Role 변경 

 

Case #2와 어느정도 비슷하지만, 본인의 Routing-table이 아닌, 특정 Destination의 ICMP 응답 여부에 따라,

Track에 Trigger가 발동되는 Command 입니다. 

 

 추가 Config

SW1

ip sla 100

icmp-echo 1.1.1.1

threshold 500

timeout 500

frequency 3

track 100 ip sla 100

delay down 3

int vlan 100

vrrp 100 track 100 decrement 10

ip sla schedule 100 start now life forever

 

일단 IP SLA에 대한 설정을 진행한 후, 너무 민감하게 반응하지않도록 Track의 Down에 대한 Delay를 3초를 줬습니다. 

SLA에 대한 세부 내용은 3초마다 ICMP 통신 시도를 하며, 응답이 제한 시간(Timeout) 내 없을경우,

SLA가 Down되도록 설정했습니다. 

 

IP SLA Status

 

Track Status

이제 R1에서 Loopback0(1.1.1.1)을 Shutdown해본 이후, SW1에서 어떤 변화가 있는지 확인해보겠습니다. 

 

 

위에 보시다시피, 06:44:10 경 인터페이스가 Down되었습니다. 

 

06:44:17 경에  IP SLA가 Down으로 변경되었고 20초에 VRRP Master role이 변경되었습니다. 

간략하게 정리해보자면 아래 Time table 순인데, 제가 해석한 내용이 이상하면 알려주세요. 

 

시간상으로 보면 13 ~14초 사이에 ICMP가 출발을 했어야 했고,

그렇다면 직전 ICMP의 경우 인터페이스가 다운되기 직전 10~11초 사이에 성공을 했어야 시간이 들어맞습니다. 

 

 

 

 ICMP 메세지에 대한 응답을 받지 못하고, IP SLA는 Down되고, 이어, Track에 대한 Down은 3초의 Delay가 있고, 

상호 VRRP priority를 비교하는 Hello time으로 인해 결과적으로 Down된지 10초 후에 VRRP에 대한 Master Role이 SW2로 변경되었습니다.  (타이밍만 잘 맞으면 더 짧긴 하겠네요)

 

보다 민감하게 즉, 빠른 시간안에 Conversion이 이뤄지게 하려면, IP SLA의 frequency를 작게 줄이고,

Track에 대한 Down delay도 줄이면 되나, 위처럼 LAN 구성 내에서의 ICMP 체크가 아닌,

대륙간을 넘는 Destination으로 ICMP ping check를 하는 경우, 

너무 민감하게 설정하면 오히려 잦은 Master전환으로 서비스 연속성에 영향을 줄 수 있으니, 적정값을 설정하는것이 중요해 보입니다. 

 

Case #4 : 다중 ICMP 응답 여부에 따른 Role 변경 (OR 조건) 

 

이번 시나리오는  두 곳의 ICMP체크를 하고 있다가, 다 떨어진 경우에 VRRP master role을 옮겨보도록 하겠습니다.

 

추가 Config

SW1

ip sla 100

icmp-echo 1.1.1.1

threshold 500

timeout 500

frequency 3

ip sla 200

icmp-echo 2.2.2.2

threshold 500

timeout 500

frequency 3

ip sla schedule 100 start now life forever

ip sla schedule 200 start now life forever

track 1 ip sla 100

delay down 3

track 2 ip sla 200

delay down 3

track 100 list boolean or

object 1

object 2

int vlan 100

vrrp 100 track 100 decrement 10

 

Config에 대한 설명을 하자면, IP SLA를 등록하고, Track을 설정하는 부분까지는 Case #3와 동일합니다. 

다만 실질적으로 VRRP command에 설정된 Track은 SLA마다 설정된 Track이 아닌 별도의 Track 100입니다. 

 

이는 다수의 Track을 Boolean으로 엮어서 하나의 Track으로 관리하는 방법이며, 

본 Config에서는 'or' 조건으로 설정되어있기 때문에, Object로 등록된 두 Track이 전부 Down되어야지만

Track 100이 Down되면서 VRRP master를 변경하게 됩니다. 

 

 

 

 

 

좌측 내용을 본다면 Object는 각각의 Track을 의미하며, 

아래처럼 SLA가 Up이라면, Track 1, 2는 UP 상태입니다. 

 

 

 

 

 

당연히 각 SLA는 정상적으로 Up입니다.

 

 

 

 

 

이제 R1의 Loopback interface를 Down시켜보겠습니다. 

 

SW1에서 봤을때, Track 1이 Down되었다는 로그가 확인되었지만, VRRP master 변경은 없습니다. 

왜냐하면 Track 100에 설정된 LIst의 Boolean type은 OR 이기 떄문에,

Object 1이 Down되었다고 Track 100이 Down되지 않습니다. 

 

이 상태에서 R2의 Loopback interface까지 Down시켜 보겠습니다. 

 

R2의 Loopback Interface를 Down시켰을때, 비로소 track 100의 상태 변환과 동시에 VRRP Master 전환이 이뤄졌습니다. 

 

 

 Case #5 : 다중 ICMP 응답 여부에 따른 Role 변경 (AND 조건) 

 

이번에는 Boolean 중 AND 조건에 대한 테스트를 진행해보겠습니다. 

 

추가 Config

SW1

track 100 list boolean and

object 1

object 2

 

Case #4에서 위의 Confing만 달라졌기 때문에, 그외 설정은 생략했습니다. 

 

 

이번에도 똑같이 R1의 Loopback0 interface만 Down시켜 보겠습니다. 

결과는 아래 보시는 것과 같습니다. 

 

 

Track 1이 Down되면서 뒤이어 Track 100까지 Down되고 VRRP의 Role이 변경되었습니다. 

Track 2는 정상적으로 UP인 상태인데도 말이죠. 

 

AND 연산자는 OR 연산자와는 다른 동작을 하는것을 볼 수 있는데,

Boolean특성을 이해하고 계시다면 크게 어려운 개념은 아니였을 겁니다. 

 

 

========================================================================================

 

맺으며 , 

 

사실 어디던 규격화된 Config나 Style등이 있습니다. 

다만, 몰랐던 유용한 설정등을 확인했을때, 적극적으로 검토하여 사용한다면, 보다 나은 환경을 구축할 수 있지않나 싶습니다. 

 

저의 경우에는 Track을 List 시켜 적용하는 방법을 이번에 처음알았고, 

이는 꼭 LAB환경과 같이 IP SLA 환경에서 뿐만 아니라, IP SLA + Interface line-protocol 등 얼마든지 섞어서 쓸 수 있을겁니다. 

 

내가 구축할 수 있는 기술, 혹은 바운더리가 늘어난다는 것은 생각보다 더 재밌습니다. 

누구든지 저한테 새로운 기술을 알려주신다면 감사한 마음으로 제것으로 만들겠습니다 !!