محدّث قبل شهر واحد
EIGRP (Enhanced Interior Gateway Routing Protocol)는 Cisco가 근본적인 문제를 해결하기 위해 만든 프로토콜입니다. 거리 벡터 프로토콜은 단순하지만 루프와 느린 수렴에 취약하고, 링크 상태 프로토콜은 빠르지만 복잡하고 대역폭을 많이 소모합니다. EIGRP는 거리 벡터의 핵심 방식—이웃 라우터에서 경로를 학습하는 것—을 그대로 유지하면서, 루프를 완전히 방지하고 거의 즉각적으로 수렴할 수 있도록 충분한 지능을 더했습니다.
핵심은 백업 경로를 미리 검증하여 준비해 두는 것입니다. 기본 경로가 실패하면 EIGRP는 아무것도 재계산할 필요가 없습니다. 어떤 백업이 안전한지 이미 알고 있기 때문입니다.
EIGRP가 해결하는 문제
거리 벡터 프로토콜에는 불편한 진실이 있습니다. 바로 라우팅 루프에 취약하다는 것입니다. 경로가 실패하면 라우터들은 이웃에게 변경 사항을 알리고, 이웃은 또 자신의 이웃에게 알립니다. 이 수렴 과정에서 패킷이 끝없이 순환할 수 있습니다. RIP의 해결책—경로 시간 초과를 최대 180초 기다리는 것—은 작동하지만 매우 느립니다.
OSPF 같은 링크 상태 프로토콜은 다른 방식으로 이 문제를 해결합니다. 모든 라우터가 전체 네트워크 토폴로지를 파악하고 각자 최단 경로를 계산합니다. 루프도 없고 수렴도 빠릅니다. 하지만 이를 위해 토폴로지 정보를 네트워크 전체에 플러딩하고 복잡한 최단 경로 우선(SPF) 계산을 실행해야 합니다.
EIGRP는 제3의 방법을 찾았습니다. 거리 벡터 모델—라우터는 이웃이 알려주는 것만 알 수 있다—을 유지하면서도, 전체 토폴로지 정보 없이 루프를 수학적으로 보장하여 방지합니다.
EIGRP가 루프를 방지하는 방법
EIGRP의 루프 방지는 DUAL(Diffusing Update Algorithm)과 실현 가능성 조건(feasibility condition)이라는 개념에서 비롯됩니다.
EIGRP의 모든 경로에는 두 가지 메트릭이 있습니다.
실현 가능 거리(FD, Feasible Distance): 목적지까지의 최적 메트릭—현재 최선 경로의 비용입니다.
보고된 거리(RD, Reported Distance): 이웃 라우터가 그 목적지까지의 비용으로 주장하는 값입니다.
실현 가능성 조건은 아름다울 정도로 단순합니다. 이웃이 목적지에 나보다 더 가깝다면, 그 이웃이 목적지로 가는 도중에 나를 통해 되돌아올 리가 없습니다.
수학적으로: 이웃의 보고된 거리(RD)가 나의 실현 가능 거리(FD)보다 작으면, 그 백업 경로는 루프가 없음이 보장됩니다. 이웃이 이미 목적지에 더 가깝다면, 그 이웃이 나를 통해 라우팅할 이유가 전혀 없습니다.
이를 통해 두 가지 경로 범주가 생깁니다.
후계자(Successor): 현재 최선 경로—목적지까지 총 비용이 가장 낮은 이웃.
실현 가능 후계자(Feasible Successor): 실현 가능성 조건을 통과한 백업 경로. 루프가 없음이 수학적으로 보장되므로 즉시 사용할 수 있습니다.
수렴이 그토록 빠른 이유
후계자가 실패했을 때 실현 가능 후계자가 있다면, 수렴은 사실상 즉각적입니다—1초 이내입니다. 계산도, 이웃 조회도, 대기도 필요 없습니다. 라우터는 이미 안전하다고 알고 있던 백업으로 그냥 전환합니다.
이것이 바로 EIGRP의 가장 큰 차별점입니다. 잘 설계된 네트워크에서는 실현 가능 후계자가 존재하므로 대부분의 장애가 즉각적인 페일오버를 트리거합니다.
실현 가능 후계자가 없을 때, EIGRP는 실제 작업을 해야 합니다. 이웃에게 쿼리를 보냅니다. "이 목적지까지의 경로가 실패했습니다. 아는 게 있나요?" 이웃은 자신의 경로로 응답하거나, 실패한 라우터를 직접 사용하고 있었다면 쿼리를 그대로 전달합니다. 모든 응답이 도착하면 EIGRP가 재계산합니다.
이런 경우에도 일반적으로 수 초 내에 수렴합니다—RIP의 수 분에 비하면 훨씬 빠릅니다.
토폴로지 테이블
각 목적지까지의 최선 경로만 유지하는 RIP와 달리, EIGRP는 모든 이웃에서 학습한 모든 경로를 포함하는 토폴로지 테이블을 유지합니다. 이것이 즉각적인 페일오버를 가능하게 합니다—백업은 이미 거기에 있고, 이미 검증되어 있습니다.
토폴로지 테이블은 대부분의 프로토콜이 답하지 못하는 질문에 답합니다. "지금 당장 현재 경로가 실패하면, 다음 최선 옵션은 무엇이고 안전하게 사용할 수 있나요?"
이웃 관계
EIGRP 라우터들은 Hello 패킷을 통해 서로를 발견합니다. 빠른 링크(이더넷)에서는 5초마다, 느린 링크에서는 60초마다 전송됩니다. 이웃 관계가 성립되면 전체 토폴로지 테이블을 교환한 다음, 변경 사항이 생길 때만 업데이트를 보냅니다.
이는 변경 여부와 관계없이 30초마다 전체 라우팅 테이블을 브로드캐스트하는 RIP 방식보다 훨씬 효율적입니다.
메트릭: 홉 수보다 스마트하게
RIP는 홉 수를 셉니다. 세 라우터를 거치는 경로가 네 라우터를 거치는 경로를 이깁니다. 그 세 라우터가 전화 접속 모뎀으로 연결되어 있고 네 라우터 경로가 기가비트 링크를 사용하더라도 말입니다.
EIGRP는 대역폭과 지연을 고려합니다. 기본적으로 경로상의 최소 대역폭과 누적 지연을 조합한 복합 메트릭을 계산합니다. 대역폭이 넓고 지연이 낮은 경로가 혼잡하고 느린 링크를 거치는 짧은 경로를 이깁니다.
프로토콜은 신뢰성과 부하도 고려할 수 있지만, 이 값들은 경로 불안정을 유발하기 때문에 거의 활성화하지 않습니다—변동하는 메트릭은 경로 플래핑을 일으킵니다.
효율적인 업데이트
EIGRP는 대역폭을 놀랍도록 효율적으로 사용합니다.
부분 업데이트: 변경된 경로만 알리고, 전체 테이블은 알리지 않습니다.
전파 범위 제한 업데이트: 변경 사항은 필요한 범위까지만 전파됩니다. 경로 변경이 네트워크의 일부에만 영향을 미치면, 다른 부분의 라우터들은 업데이트를 수신하지 않습니다.
신뢰할 수 있는 전달: EIGRP는 업데이트 수신을 확인하고, 필요한 경우 재전송합니다. 업데이트가 손실되지 않습니다.
안정적인 네트워크에서 EIGRP는 라우팅 트래픽을 거의 생성하지 않습니다—이웃이 살아 있는지 확인하는 주기적인 Hello만 있을 뿐입니다.
EIGRP의 아킬레스건: Stuck-in-Active
EIGRP가 실현 가능 후계자를 찾지 못해 이웃에게 쿼리를 보내야 할 때, 응답을 기다립니다. 응답이 오지 않으면—라우터 충돌, 링크 혼잡, 네트워크 분할 등의 이유로—EIGRP는 기다립니다. 그리고 계속 기다립니다.
기본적으로 3분이 지나면 EIGRP는 해당 경로를 "stuck-in-active" 상태로 선언하고 응답하지 않은 이웃과의 관계를 해제합니다. 이것이 연쇄적으로 발생하면 심각한 장애로 이어질 수 있습니다.
Stuck-in-active는 거의 항상 네트워크 설계 문제의 징후입니다. 쿼리 범위가 너무 넓거나, 요약이 부족하거나, 링크가 불안정한 경우입니다. 잘 설계된 EIGRP 네트워크에서는 거의 발생하지 않습니다.
비동일 비용 부하 분산
대부분의 라우팅 프로토콜은 동일 비용 경로에서만 트래픽을 분산합니다. EIGRP는 variance 명령어를 사용하여 메트릭이 다른 경로들 사이에서도 트래픽을 분산할 수 있습니다.
variance를 2로 설정하면, EIGRP는 최선 메트릭의 2배 이내인 모든 실현 가능 후계자를 사용합니다. 트래픽은 비례적으로 분산됩니다—더 좋은 경로가 더 많은 트래픽을 받습니다.
속도가 다른 여러 경로가 있을 때 백업 용량을 그냥 놀려두지 않고 모두 활용하고 싶다면 이 기능은 실질적으로 매우 유용합니다.
EIGRP vs. OSPF
실용적인 선택은 보통 벤더 환경에 달려 있습니다.
EIGRP는 Cisco 중심 네트워크에서 빛을 발합니다. 더 간단한 설정(영역 설계 불필요), 실현 가능 후계자를 통한 빠른 수렴, 더 효율적인 대역폭 사용, 비동일 비용 부하 분산. SPF 계산이 없으므로 CPU 부하도 적습니다.
OSPF는 멀티 벤더 환경에서 우위를 점합니다. 범용 지원을 갖춘 개방 표준이며, 더 넓은 전문가 풀과 더 나은 벤더 중립적 도구를 갖추고 있습니다. 계층적 영역 구조는 명시적인 확장성 구조를 제공합니다.
EIGRP를 잘 아는 엔지니어들이 있는 Cisco 환경에서는 EIGRP가 더 나은 선택인 경우가 많습니다. 혼합 환경이거나 일반 네트워크 엔지니어를 채용할 때는 OSPF의 보편성이 더 중요합니다.
현대의 EIGRP
EIGRP는 IPv6를 기본 지원하며, IOS 15.0에서 도입된 "named mode" 설정 방식을 통해 설정을 단순화하고 단일 설정 블록에서 두 주소 패밀리를 모두 지원합니다.
2016년에 Cisco는 EIGRP를 정보성 RFC로 게시하여 기술적으로 개방 표준으로 만들었습니다. 실제로는 여전히 Cisco 기술로 남아 있습니다—OSPF와 IS-IS가 동일한 목적을 수행하는 만큼, 다른 벤더들이 이를 구현할 유인이 거의 없습니다.
EIGRP가 적합한 경우
EIGRP는 다음과 같은 경우에 올바른 선택입니다.
- 네트워크가 주로 Cisco 장비로 구성된 경우
- 빠른 수렴이 중요한 경우(실현 가능 후계자를 통한 1초 이내 페일오버)
- OSPF의 영역 계층보다 더 단순한 설정을 원하는 경우
- 비동일 비용 부하 분산으로 백업 경로를 더 잘 활용하고 싶은 경우
- 팀이 이미 EIGRP를 알고 있는 경우
다음과 같은 경우에는 적합하지 않습니다.
- 멀티 벤더 상호운용성이 필요한 경우
- 일반 네트워크 엔지니어를 채용하는 경우(OSPF 지식이 더 보편적)
- 현재 벤더 관계보다 오래 지속될 수 있는 네트워크를 구축하는 경우
EIGRP에 대해 자주 묻는 질문
EIGRP가 "하이브리드" 프로토콜이라고 하는 이유는 무엇인가요?
EIGRP는 거리 벡터 방식—완전한 토폴로지 맵을 구축하는 대신 이웃에서 경로를 학습—을 사용하지만, 링크 상태와 유사한 기능들을 추가합니다. 백업 경로가 포함된 토폴로지 테이블 유지, 주기적 브로드캐스트 대신 트리거 업데이트, 정교한 메트릭이 그것입니다. 엄밀한 기술적 의미의 하이브리드는 아니지만, 두 방식의 장점을 두루 결합하고 있습니다.
EIGRP의 수렴 속도는 얼마나 빠른가요?
실현 가능 후계자가 있으면 수렴은 1초 이내—사실상 즉각적입니다. 없을 경우 EIGRP는 이웃에게 쿼리하고 응답을 기다려야 하며, 일반적으로 수 초 내에 수렴합니다. RIP의 수렴 시간이 수 분에 달할 수 있다는 것과 비교해 보세요.
EIGRP가 Cisco 외 네트워크에서도 작동할 수 있나요?
기술적으로는 가능합니다—이제 RFC가 되었으니까요—하지만 실제로는 Cisco 외의 벤더 지원이 미미합니다. Cisco가 아닌 장비가 있다면 OSPF나 IS-IS가 더 안전한 선택입니다.
Stuck-in-active 문제의 원인은 무엇인가요?
Stuck-in-active는 EIGRP가 이웃에게 쿼리를 보냈는데 응답을 받지 못할 때 발생합니다. 일반적인 원인: 라우터 장애, 쿼리를 처리할 수 없을 정도로 과부하된 CPU, 네트워크 분할, 또는 너무 넓은 쿼리 범위. 해결책은 대개 쿼리 전파를 제한하기 위한 더 나은 경로 요약입니다.
هل كانت هذه الصفحة مفيدة؟