네트워크 시뮬레이션 공방

Feasibility Condition은 DUAL 알고리즘의 일부로써, 루프를 방지하기 위한 것이다. 그런데, 사용자가 주의를 기울이지 않으면 이 기능으로 인한 결과는 혼란스러운 면이 있으므로, 결과 해석시 주의가 필요하다.

"다중경로 라우팅(8) - UCMP 라우팅 테이블"에서 EIGRP는 동일한 비용을 가지는 경로가 없을 때에도 다음 그림처럼 다중경로로 라우팅 테이블을 구성해줄 수 있음을 확인한 바 있다.

그런데, "다중경로 라우팅(8) - UCMP 라우팅 테이블"의 예제망에서 R1 <-> R3 링크의 대역폭과 R3 <-> R4 링크의 대역폭을 서로 바꾸고 시뮬레이션을 수행하면, 다음 그림처럼 라우팅 테이블에 다중경로가 구성되지 않는 것을 볼 수 있다.

얼핏 생각하면, R1 노드에서 Server 노드로 향하는 경로의 전체 Metric 값에는 변화가 없으므로(R1 <-> R3 링크와 R3 <-> R4 링크의 대역폭을 서로 바꾸기만 하였으므로) 이전의 예제와 동일한 라우팅 테이블이 구성되어야 할 것처럼 생각된다. 하지만, 시뮬레이션 결과는 예상(?)과는 다르며, 이러한 차이가 발생한 원인은 Feasibility Condition 때문이다.
즉, EIGRP에서는 전체 경로의 Metric이 동일하더라도 Next-Hop 라우터에서 목적지까지의 경로 Metric 값이 어떻게 변화하는가에 따라 다중경로가 라우팅 테이블에 사용될 수도 있고 안될 수도 있다.

EIGRP에서는 Metric에 대한 변량(Variance)을 지정해 줄 수 있으며[1, 2], Riverbed Modeler(OPNET)에도 구현되어 있다. 이 variance 값은 다중경로 라우팅에 사용된다. 다음 그림은 Riverbed Modeler(OPNET)에서 제공하는 EIGRP Variance 설정창을 보인 것이다.

Variance 값은 어느 범위까지의 Metric을 가지는 경로들을 라우팅 테이블에 유지할 것인지를 지정하는 것으로, 현재 라우팅 테이블에 저장되어 있는 최소 Metric에 Variance를 곱한 것보다 작은 Metric 값을 가지는 경로들은 라우팅 테이블에 저장한다.
따라서, Variance가 1인 경우에는 Metric 값이 동일한 경로들만 라우팅 테이블에 저장하므로, ECMP("다중경로 라우팅(1) - ECMP" 참조)와 같아지지만, Variance가 2 이상인 경우에는 비용이 다른 여러 개의 경로들도 트래픽 부하분산(Unequal-Cost Load Balancing)이 이루어지므로 ECMP와는 큰 차이가 나게 된다.

[1] http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/16406-eigrp-toc.html#eigrpmetrics
[2] http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13677-19.html

EIGRP는 기본적으로 bandwidth와 delay 항목 정보로부터 계산된 Metric을 기반으로 라우팅 경로를 선정하므로, EIGRP에 의해 선정된 경로는 OSPF에 의해 선정된 경로와 동일한 경우가 많다("EIGRP 라우팅 예제(1) - 2홉 vs 1홉" 참조). 하지만, 기본 파라미터를 그대로 사용한다고 할지라도 EIGRP의 Metric 계산 공식("EIGRP 메트릭" 참조)과 OSPF의 Cost 계산 공식("OSPF에서의 링크 비용" 참조)이 정확히 일치하지는 않으므로, 일부 경우에 따라서는 EIGRP에 의해 선정된 경로와 OSPF의해 선정된 경로가 다를 수도 있다.
다음 그림은 "EIGRP 라우팅 예제(1) - 2홉 vs 1홉"의 첫번째 예제를 조금 변경(R2->R4 링크, R1->R3 링크와 R3->R4 링크의 bandwidth를 기존보다 낮게 설정)한 토폴로지에 EIGRP와 OSPF가 사용되었을 때 두 단말 사이의 라우팅 경로를 비교하여 나타낸 것이다. 그런데, 라우팅 프로토콜을 제외한 모든 조건이 동일하였지만, 두 시나리오에서 선정된 라우팅 경로가 서로 다른 것을 알 수 있다.

여기에서는 라우터 배치 순서도 동일하게 해 주었으므로 동작 순서의 차이에 의해 발생한 현상("라우터 배치 순서와 라우팅 경로 선정" 참조)이 아니며, EIGRP와 OSPF에서 계산한 경로 Metric이 서로 달라서 발생된 것이다. 이를 확인하기 위해서 각 라우팅 프로토콜이 사용된 경우에 R1 노드에서 구성된 라우팅 테이블을 비교해보면 다음 그림과 같다. R4 - Server 네트워크에 대한 Next Hop이 EIGRP에서는 R3 노드로 지정되는 반면, OSPF에서는 R2 노드로 한 개씩만 지정되어 있는 것을 확인할 수 있다. 이는 R2 노드를 경유하는 경로와 R3 노드를 경유하는 경로의 Metric이 서로 달랐으며 EIGRP에서는 R3 노드를 경유하는 경로가, OSPF에서는 R2 노드를 경류하는 경로의 Metric이 상대적으로 더 작은 것으로 계산되었음을 의미한다.

EIGRP는 bandwidth, load, delay, reliability 정보를 종합적으로 사용하여 Metric을 계산("EIGRP 메트릭" 참조)할 수 있도록 개발되었지만, 실제로는 대부분의 경우에 있어 load나 reliablity 항목은 사용되지 못하고 bandwidth와 delay 항목만이 사용된다[1].

형식상으로는 delay 항목이 추가로 사용되는 것만으로도 링크의 대역폭(bandwidth) 정보만을 사용하여 cost를 계산하는 OSPF("OSPF에서의 링크 비용" 참조)와는 차별화되어 보이기도 한다. 하지만, 여기에서의 delay는 인터페이스 전송 속도에 의해 지정[2]되는 것이므로, 실제로는 거의 동일하다.
"RIP 라우팅 예제"에서 사용한 예제망의 라우팅 프로토콜을 EIGRP로 변경하여 EIGRP의 동작을 확인해보기로 하자. 첫번째 예제의 네트워크 토폴로지와 실제로 할당된 IP주소 내역은 다음과 같다.

시뮬레이션을 수행한 후, R1 노드에서 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다. ("라우팅 경로 확인하기" 참조).

R2 - R4, R3 - R4, R4 - Server 네트워크에 대한 라우팅 정보가 EIGRP에 의해 생성되었으며, R2 - R4, R3 - R4 네트워크에 대한 Metric은 89,344, R4 - Server 네트워크에 대한 Metric은 91,904임을 확인할 수 있다. (R4 - Server 네트워크에 대해서 2개의 경로 정보가 구성된 것은 ECMP("다중경로 라우팅(1) - ECMP" 참조) 때문이다.)
"EIGRP 메트릭"에서 설명하였듯이 EIGRP는 bandwidth, load, delay, reliability, mtu 정보로부터 계산된 값을 Metric으로 사용하며, 기본값 사용시 DS3(44.746Mbps) 링크 2개로 구성된 경로의 Metric은 89,344, DS3(44.746Mbps) 링크 2개와 Fast Ethernet(100Mbps) 링크 1개로 구성된 경로의 Metric은 91,904로 계산된다. 따라서, R1 -> R2 -> (R4) 경로와 R1 -> R3 -> (R4) 경로의 Metric은 89,344가 되며, R1-> R2-> R4 ->(Server) 경로의 Metric은 91,904가 된다.

Client 노드로부터 Server 노드로의 트래픽 전달 경로는 다음과 같이 2홉 경로(R1 -> R2 -> R4 경로)으로 확인되며, 이는 라우팅 테이블과 일치한다. (이후의 1홉 예제의 결과와 비교할 것이므로 R1 -> R2 -> R4 경로, 또는 R1 -> R3 -> R4 경로 어느 쪽이던 별 상관은 없다)

이제 R1 노드와 R4 노드사이에 1홉 링크를 추가하여 EIGRP의 특성을 보다 자세히 살펴보자. 다음 그림은 첫번째 예제를 변형한 두번째 예제의 구조이다. R1 노드와 R4 노드 사이에 다른 링크(DS3)보다 작은 대역폭의 링크(DS1)를 추가하였다.

시뮬레이션을 수행한 후, 두 번째 시나리오에서 R1 노드에 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다.

R1 노드와 R4 노드를 연결하는 링크가 추가되었음에도 불구하고 R4 - Server 네트워크에 대한 경로는 변경이 없으며, Metric도 동일하게 91,904임을 확인할 수 있다.
이제 Client 노드로부터 Server 노드로의 트래픽 전달 경로를 살펴보면 라우팅 테이블의 구성과 같이 2홉 경로(R1 -> R2 -> R4)인 것을 알 수 있다.

즉, 기본적으로 EIGRP는 경로의 bandwidth와 delay 항목 정보로부터 계산된 Metric을 기반으로 라우팅 경로를 선정하며, Metric이 더 작은 경로가 존재하면 홉 수에 상관없이 해당 경로를 라우팅 경로로 선정한다. 따라서, EIGRP에 의해 선정된 경로는 OSPF에 의해 선정된 경로와 동일("OSPF 라우팅 예제" 참조)한 경우가 많다.

[1] http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/16406-eigrp-toc.html#eigrpmetrics

[2] http://www.ietf.org/staging/draft-savage-eigrp-00.txt

"EIGRP 메트릭"에서 설명하였듯이, EIGRP에서 Metric 계산시 Delay는 인터페이스 전송 속도에 의해 지정[2]된다. 다음은 Riverbed(OPNET) Modeler EIGRP 모델에서 사용하는 Delay 값 변환 표이다.

[1] http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/16406-eigrp-toc.html#eigrpmetrics
[2] http://www.ietf.org/staging/draft-savage-eigrp-00.txt

"EIGRP 메트릭"에서 살펴본 것처럼 EIGRP에서는 메트릭 계산시에 링크 부하도 사용된다. 링크 부하는 EIGRP에서 따로 측정하지 않으며, IP 모델에서 기록해준 정보("IP 트래픽 부하 정보" 참조)를 사용하되 EIGRP 메트릭에 맞추어 재조정하여 적용한다. 즉, IP 모델에서는 링크 부하에 대한 기록을 bps 단위로 남기지만, EIGRP에서는 이 bps 값을 다음 수식처럼 링크 사용률로 변환(단, 최대값은 255)하여 부하(load)로 사용한다.

한가지 주의할 사항은 IP 모델에서 링크 부하에 대해서 기록해주는 코드가 EIGRP 사용시에는 동작하지 않으므로(버그로 생각된다), EIGRP에서 load를 메트릭에 반영하고자 하는 경우에는 해당 소스 코드를 일부 수정해주어야 한다는 것이다.

EIGRP에서 라우팅 테이블을 구성할 때 사용되는 Metric은 bandwidth, load, delay, reliability 정보로부터 계산된다[1, 2]. CISCO사의 제품에서는 각 metric 항목별 비중을 계수를 통해 조정할 수 있으며, Riverbed(OPNET) Modeler의 EIGRP 모델 역시 이와 동일한 기능을 제공한다.
다음 그림은 Riverbed(OPNET) Modeler에서 제공하는 EIGRP 메트릭 계수(coefficient) 설정창을 보인 것이다.

이 계수들은 다음의 수식[1, 2]에서 Metric을 계산하는데 사용된다.

이 때 bandwidth는 대역폭값 그대로가 아니라 10^7/(인터페이스 전송 속도)로 조정된 값이다. Delay는 인터페이스 전송 속도에 의해 지정[2]된다.

[1] http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/16406-eigrp-toc.html#eigrpmetrics
[2] http://www.ietf.org/staging/draft-savage-eigrp-00.txt