네트워크를 하시다보면 설계 단계에서 빠지지않고 등장하는 다중화에 대해서 설명해보고자 합니다.
우리가 서울에서 부산으로 간다고 했을때, 도로에 문제가 생겼거나, 너무 막히는 상황이라면 다른길로 향하듯,
특정 상황을 대비하여 이중화 삼중화 혹은 다중화하여 문제가 발생하지 않은것처럼 네트워크를 구성해야만 하죠
중요한 것은 서비스의 연속성이니까요 !
우리가 L3 level에서 Dynamic routing Protocol을 활용한다던가,
Floating routing 을 활용하여 Static 라우팅에서도 다중화를 하고 있다는 것은 많이 아실겁니다.
이번 포스팅은 L3의 Redundant 프로토콜을 완벽하게 이해하기 전에,
L2부터 짚고넘어가자는 취지에서 작성하였고, 몰랐던 내용이 있으면 알아가셨으면 좋겠습니다.
사실 여기에 SLA, track list를 활용한 FHRP의 Master role 변경 방식까지 하려고 했는데,
생각보다 내용이 길어져서 이후 포스팅으로 다루겠습니다.
1. FHRP란
FHRP는 First Hop Redundant Protocol의 줄임말로, 쉽게말해 Gateway에 대한 다중화 프로토콜이라고 생각하면 됩니다.
Gateway라고 하면 살짝 어렵게 느껴지실수도 있지만,
네트워크 직무를 하시기 이전에, PC의 IP setting을 한번이라도 해보신 분에게는 익숙하실겁니다.
목적지가 어디던지, 어떤 서버, PC 등 host는 인터페이스에 설정된 Gateway로 보내게 됩니다.
* 여기서 Proxy ARP에 대한 내용은 모두 배제했습니다
이 때, Gateway의 다중화를 위하여 개발된 프로토콜이 바로 VRRP, HSRP, GLBP와 같은 FHRP 입니다.
2. FHRP 목적
설명하기에 앞서 제 PC의 IP 셋팅 환경을 한번 보시죠.
맥북이라 게이트웨이라는 표현 대신, 라우터라고 명시되어있으나, 같은 말 입니다.
네이버를 접속하던, 구글을 접속하던 LoL을 하던, 제 PC에서 나온 모든 패킷(프레임)은 모두 .254로 되어있는 라우터로 향하게 됩니다.
제 현재 상황을 토대로 아래처럼 네트워크를 구성했을때, 어떤일이 발생할까요?
인터넷 회선, NW 장비가 모두 정상인 상황에서는 평소와 같이 인터넷을 이용할 수 있습니다.
구축시 가장 저렴하고, 이슈만 없다면 이보다 완벽할 수 없습니다.
단, 이슈가 없을 때라는 가정은 불가능하죠.
Router의 Down-Link interface가 다운되거나, Up-link 인터넷 회선이 Down되거나, 혹은 Router자체가 Down될 수도 있죠.
어느 상황이던지, 저는 인터넷을 이용하지 못합니다. 서비스 연속성이 끊기는 셈이죠.
그렇다면 똑같은 조건에 아래처럼 구성했다고 가정해보겠습니다.
아까보다 장비도 1대 늘어났고, 인터넷 회선도 하나 증가했네요. 장비의 이중화, 인터넷 회선의 이중화까지 챙긴 엔지니어네요.
그렇다면 좀 전의 서비스 연속성이 끊기는 상황에서 뭔가 달라졌을까요?
답은 하나도 개선되지않았습니다.
왜냐하면 제 PC는 여전히 .254 즉 Router2를 바라보고 있고, 아무리 ARP request를 던져도, .254에 대한 ARP reply는 오지 않습니다.
물론 취할 수 있는 Action이 있습니다.
바로 제 PC의 게이트웨이를 수동으로 .253으로 변경해주는 것입니다.
Router1은 정상적으로 동작하고 있고, 연결된 Link들도 다 정상이니까요.
그러면 제 PC는 Router2에 이상이 생겨도 인터넷을 할 수 있습니다만, 다른 사용자는 어떨까요?
구성을 인지하고있는 엔지니어는 본인의 PC의 게이트웨이를 바꾸면 된다지만,
대부분의 사용자는 IP 변경에 익숙하지 않으며, 일련의 과정을 어렵고 번거롭게 생각합니다.
Gateway에 대한 장애가 있을때마다 PC 혹은 Server의 Gateway를 변경해야하는 상황이라면, 아주 쉽지않은 상황입니다.
이럴때 사용하는 것이 FHRP 입니다.
아래 그림을 보시죠.
제 PC가 Gateway로 설정한 IP가 VIP로 설정되었습니다.
VIP(Virtual IP)는 말그대로 가상의 IP이고, FHRP 별로 아래 처럼 동작하게 됩니다.
VRRP, HSRP : 우선순위에 따라 VIP를 소유하는 장비(Active)와 대기중인 장비(Standby)가 있음
Master에 이상이 생길 경우, Standby장비가 Active로 바뀌면서 VIP에 대한 소유권 이전
Gateway는 Active-standby로 동작함
GLBP : VIP에 대한 ARP reply를 프로토콜 멤버의 vMAC로 지정하여, Gateway를 Active-Active로 동작하게 함
이렇게 될 경우, Router1,2가 동시에 Down되지않는 이상 어떤 경우에서든지 Gateway에 대한 ARP 응답을 받을 수 있고,
인터넷 회선만 정상이라면 서비스 연속성이 끊기지 않을 겁니다.
3. FHRP 동작 방식
앞서서는 개념에 대해 누구든지 이해할 수 있도록 설명을 아주 쉽게 풀어서 적었지만 이후의 내용에서는 조금 심화해서 다루겠습니다.
VRRP와 HSRP는 표준 프로토콜이냐 Cisco 한정 프로토콜 이냐의 차이만 있지 동작 방식 상 크게 다르지는 않습니다.
2대 이상의 장비 중 1장비는 Active, 1장비는 Standby 그 외 장비는 LIstening 중이라고 이해하면 됩니다.
Active, Standby와 Listening 장비는 각 FHRP가 설정된 인터페이스의 Priority 값을 통해 역할이 정해지며,
각 장비들은 서로 Multicast 트래픽을 이용하여, 주기적으로 서로의 Health를 check하게 되고,
Hold time동안 Active 장비로부터 Hello message를 받지 못한다면, Master의 Role이 Standby 장비로 옮겨가고,
Listening 중이였던 장비중 1대가 Standby로 올라오게 됩니다.
여기서 Active 장비의 역할은 VIP에 대한 ARP Request를 자신이 응답하는데 있습니다.
.254 IP의 Mac address는 내가 가지고 있다고 응답하고, 하단의 L2의 Mac address table에는 Router1 향 포트에 해당 Mac이 있다고
기록하게 될겁니다.
물론 Router1의 실제 IP인 .252(혹은 Standby에 설정된 .253)에 대한 ARP request에도 응답을 하겠지만, 모든 PC의 Gateway가 VIP로 설정되어있다면,
그 빈도는 VIP에 비할바는 아니고, 아예 없을수도 있습니다.
GLBP는 제가 이 포스팅을 작성하고자 마음먹었던 프로토콜입니다.
1년 전까지만 해도 CIsco에서 지원하는 FHRP는 단 2개인줄 알았고, 이런 프로토콜이 있는지도 몰랐습니다.
GLBP의 경우에는 VRRP, HSRP와는 다르게, 모든 그룹 멤버들이 Traffic flow에 참여합니다.
물론 Active, Standby의 개념은 있지만, 이는 멤버들을 관리하는 장비가 누구인지를 나타내는것이며,
실제로는 그룹 내의 모든 장비가 Gateway가 됩니다.
GLBP가 설정된 라우터 2대에는 192.168.100.1 이라는 VIP가 설정되어있고,
2대가 Member로 등록되어있는 환경에서 Debug를 진행해보았습니다.
아래 Debug의 내용을 보면서 설명하겠습니다.
Client가 ARP request를 할때, VIP에 대한 Default MAC을 가지고있는 해당 장비에서 프로세스를 진행합니다.
보통 상황이라면, 자기가 가진 vMAC을 주면되지만, 그렇지 않습니다.
GLBP의 경우에는 실제 Frame의 Src MAC과 ARP replay에 기재될 Src MAC이 다를 수 있습니다. 마치 Proxy ARP의 내용과 비슷하죠.
ARP Reply에 들어가는 vMAC은 본인의 vMAC일수도, 다른 Member의 vMAC일 수 있고,
이런 동작방식때문에 Gateway 전부가 Active 처럼 동작하는것이죠.
쉽게 정리하자면, Client에 부과되는 Gateway의 MAC address가 달라지고,
설정 내용에 따라 어떤 Gateway를 어느 비중으로 사용할 것인지도 커스터마이징이 가능합니다.
이로 인해 얻을 수 있는 이점은 이중화된 장비를 Active로 사용하여,
번잡한 설정 추가 없이, Link에 대한 부담을 줄여주는 자동 Load Balancing기능이 된다는 것이죠.
제가 생각하는 번잡한 추가 설정은, 해당 VLAN을 반으로 쪼개서 각각 Gateway가 되는 장비를 나누는 방법이며,
이는 DHCP 서버나 인증 서버의 설정 변경을 동반하기에,
Trouble shooting을 위한 즉조치로는 적절치 않다고 판단했습니다.
추가로 사이트를 구축할때, 대다수의 Host의 IP는 DHCP를 통해 받아오게 될겁니다.
DHCP에 대한 세부 내용은 지난 시간에 다뤄봤으니, 궁금하신 분은 한번 읽어보시는 것도 좋습니다.
어느 FHRP를 사용하던지, client의 Router(gateway)는 VIP로 받아오게끔 설정해줘야,
End단에서 별도의 설정변경없이 서비스가 가능한 점 기억해주시면 됩니다.
그럼 이제 실습을 진행해보겠습니다.
========================================================================================
1. FHRP Lab 구성도
2. FHRP(VRRP) Lab Configuration
3. 결과
Configuration에서 보실 수 있듯이, VLAN 100에 대한 Active는 SW1이, VLAN 101에 대한 Active는 VLAN SW2가 가져가도록 설정하였습니다.
OSPF쪽은 추후 Track 설정을 위해 추가한 내용으로, 본 내용에서는 무시해주시면 감사하겠습니다.
여기서 제가 진행해본 내용은 Preempt에 대한 설정입니다.
Preempt는 선점을 의미하며, Active 장비라던지, Standby장비라던지 초기 Config할때 반드시 설정을 해줘야 했는데,
사실 Master기능을 '선점'한다라는 측면에서 Standby장비에는 설정하지 않아줘도 되지않나는 취지에서 실습을 진행했습니다.
Case #1
우선 Active/Standby 장비 모두에 Preempt설정을 했을때를 보겠습니다.
Master를 가지고 있던 VLAN100을 shutdown하는 순간 Master상태에서 내려왔고,
Standby에서는 Hold time동안 기다린 후 Master가 정상적이지않다고 판단하고 역할을 변경했을겁니다. ( Standby -> Master)
그리고 다시 SW1에서 VLAN 100을 살렸을때, 우선적으로 Init상태에서 Backup상태로 들어왔고,
얼마지나지않아 Master Role을 가져왔습니다.
이러한 동작 방식을 저는 '정상 동작'이라고 판단하겠습니다.
Case #2
다음은 Standby 장비만 Preempt설정을 했을때를 보겠습니다.
참고로 VRRP의 경우 Preemp기능이 Default 설정이라, Config를 하더라도 보이지가 않고, No를 했을때만 'sh run' 상에 노출이되더라구요.
VRRP에 대한 상태를 보고싶으시다면, 'sh run' 보다는 'sh vrrp brief'설정을 추천 드립니다.
위에서부터 하나씩 확인을 해보겠습니다.
Case #1과 동일하게 VLAN 100을 SW1에서 죽였고, Master의 Role을 잃었습니다.
SW1에서 'sh vrrp brief'를 했을 때, 'Pre' 부분을 봤을때, VL100 부분에 Y가 없는것으로 봐서 preempt설정이 꺼져있습니다.
그리고 다시 VLAN 100을 살렸을때, Init-> Backup이후 다시 Master를 가져왔다는 로그가 없습니다.
Priority도 SW2보다 높은데 가져오지 못하는 이유는 Preempt 기능이 꺼저있기 때문이라고 판단할 수 있습니다.
따라서 Standby 장비에만 Preempt를 설정하는 경우, '정상적으로 동작하지 않는다' 라고 볼 수 있네요
Case #3
마지막으로 Master장비에만 Preempt 설정을 넣어보겠습니다.
이번에는 좀 다르게 SW2에서의 로그를 가져왔습니다.
왜냐면 Backup 장비에서 Preempt 설정이 Off되어있다는 것을 보여드리기 위해서입니다.
특정 시점에서 Master에 대한 Role을 가져왔고, 그 이후 Master의 Role을 잃고 다시 Backup장비가 되어버린 모습입니다.
이로써, 양쪽에 Preempt 설정을 하지않고 Master 장비에만 Preempt설정을 하더라도 동일한 효과를 볼 수 있습니다.
다만 이는 특정 장비를 Master의 목적으로 사용한다는 가정하에서 정상 동작을 의미하는 것으로,
Master장비가 반드시 특정 Device일 필요가 없는경우에는 굳이 Preempt기능을 활용하여, Master의 Role을 가져오지 않아도,
서비스에는 무관할 것입니다.
단 !!! 본 포스팅에서는 Track을 활용한 Priority 값 변동이 없을때라고 가정하겠습니다.
Track을 활용하여 특정 상황에서 Master 변경을 원한다면,
Standby 장비에도 무조건 Preempt 설정이 있어야만 합니다!!!!
Case #4
이번에는 GLBP에 대한 LAB을 진행해보겠습니다.
Config의 방식은 VRRP나 GLBP와 거의 유사합니다.
위와 같이 SW1, SW2에 설정을 진행했을 때, SW1의 GLBP detail을 한번 보겠습니다.
뭐가 막 많이 써있는데, 주목해야할 Section은 Load Balancing, Group members와 Forwarder 부분입니다.
우선 Load-balancing부분은 Default로 Round-robin방식이 적용되어있습니다.
L4를 다뤄보셨다면, Round-robin방식은 순차적으로 응답하는 방식임을 아실겁니다.
다른 방식으로는 Host 특정방식과 비중을 두는 방식이 있습니다.
host 특정은 static하게 특정 Host에 대한 ARP request응답은 누구로 하겠다는 설정이고,
Weight방식은 균등하게 1:1 방식으로 지정하는것이 아닌, 2:1 혹으 그외의 비율로 ARP reply에 대한 Src mac 부분을 채워주는것이죠.
장비의 Performance나 Link의 BW가 차이가 날 경우에 사용될 수 있을것으로 생각합니다.
Group member의 경우는 현재 GLBP group domain에 참여한 장비들의 현황이고,
이에 따라 Forwarder의 갯수가 지정되는 것이지요.
각 Forwarder는 각 Member 별 한개씩 Active role을 가지고 있고, 특정 Host의 Gateway가 될 수 있게 됩니다.
Client 별로 ARP Request에 대한 응답으로 forwarder 별로 가지고 있는 vMAC을 받기때문에,
Gateway 이중화가 가능한 프로세스 입니다.
GLBP에서는 AVG, AVF 등과 같이 각 라우터의 역할을 지정하는 용어가 있는데,
관리를 하는 Active장비, Gateway로 동작하는 장비 정도로 이해해주시면 되며,
본 Config에서는 SW1이 AVG임과 동시에 AVF이고, SW2는 AVF입니다.
🔵추가로 하나 더 알아두시면 좋을 Config를 공유드리겠습니다.
사용자 대역에서는 흔히 DHCP를 위해서 Cisco Switch 혹은 Router에 IP helper-address설정을 합니다.
DHCP relay를 위해서 반드시 설정해줘야하는 Config인데,
만약 별도의 Config가 없다면, Active/Standby장비에서 모두 DHCP discovery 패킷이 DHCP 서버로 향하게 됩니다.
왜냐하면 브로드캐스트로 DHCP discovery를 뿌려지다보니, 도메인 안에 relay설정이 된 장비에서 모두 프로세스를 진행하는것이죠.
이 때, 불필요한 중복 Relay를 줄이기 위하여, 아래처럼 설정하실 수 있습니다.
HSRP 그룹에 name을 적용해주는것이죠.
흔히들 'Description', 'name' command는 가시성을 확보하기 위해서 많이 사용하지만,
이 경우에서는 특정 Config에 연계되어 사용하기도 하는것을 알았습니다.
ip helper-address x.x.x.x redundancy <HSRP group name> 은 VIP의 Active role을 가지고 있는 장비만,
요청받은 DHCP discovery에 대해 이후 프로세스를 진행하게 됩니다.
Standby 장비는 DHCP discovery에 대한 프로세스를 전담하지않게 되는것이지요.
확인해보니까 VRRP에서는 제공을 하지않는것으로 보이는데, 제가 잘못 알고 있는것이라면 공유해주세요.
================================================================================
맺으며.
이후 포스팅에서 Track을 활용하여, 다양한 경우에서 FHRP의 Master role을 바꾸는 방식을 소개하겠습니다.
이해하기 쉽게 쓴다고 썼는데,
모든 개념에 대해서 네트워크를 모르시는 분들이 이해하기 쉽도록 쓰는게 얼마나 어려운것인지 깨달았습니다.
그래서 기본적인 내용과 심화 내용을 분리해봤고,
도움이 되셨다면 바로 다음 Posting도 읽어보시면 실무에 조금 더 도움이 되지않을까 싶습니다.
정말 중요한 개념은 다음 글이니까 한번씩 봐주세요 !!
'Network 모험기' 카테고리의 다른 글
[L3]OSPF 설정 따라하기 (1) | 2024.11.07 |
---|---|
[L2]Track을 활용한 Gateway 다중화 (0) | 2024.11.03 |
[L2]VTP와 MST 연계 구성 (3) | 2024.10.28 |
[#3-7]BGP route-reflector 공부하기 (0) | 2024.03.20 |
[#3-6]BGP aggregate 활용하기 (0) | 2024.03.16 |