상위 메트릭에서 하위 메트릭으로 EIGRP 조작

소개

이 문서에서는 알려진 EIGRP 동작으로 인해 수정된 메트릭이 적용되지 않는 EIGRP(Enhanced Interior Gateway Routing Protocol) 경로 메트릭 조작의 문제를 설명합니다.

배경

이 문제는 IWAN(Intelligent WAN) 구축 중 하나에서 네트워크 운영자가 브랜치 라우터에서 EIGRP 지연 메트릭을 사용하여 트래픽 경로 기본 설정에 영향을 미치려고 시도하면서 발견되었습니다. 경로 기본 설정은 EIGRP 컨피그레이션의 distribute-list와 지연 메트릭의 조정에 의해 영향을 받았습니다. 그림 1의 토폴로지를 확인합니다.

그림 1 - IWAN 토폴로지

이 토폴로지에서는 네트워크 운영자가 두 데이터 센터의 모든 브랜치 라우터에서 distribute-list를 사용하여 경로 조작을 수행하여 특정 링크를 기본 경로로 사용하는 접두사에 대한 기본 설정을 제공하려고 합니다. 예를 들어, DC2의 접두사 10.2.0.0/16은 기본 설정 시퀀스 DC2-BR2, DC2-BR1, DC1-BR2, DC1-BR1에서 스포크 라우터의 기본 설정 경로입니다. 다시 말해, 스포크 라우터(예: Spoke-1)에 대한 트래픽을 전송하기 위한 경로 기본 설정은 먼저 DC2-BR2 라우터로 향하고, 그 다음 DC2-BR1 라우터로 향하며, 그 다음 DC1-BR2 라우터로 향하며, 마지막으로 DC1-BR1 라우터로 향합니다. 또한 네트워크 운영자는 DC1-SW1 노드의 DCI 인터페이스에 EIGRP 지연이 구성되어 있습니다.

EIGRP 메트릭 조작을 위한 DC1-BR1 라우터의 샘플 컨피그레이션은 다음과 같습니다.

! Configuration from DC1-BR1 router
router eigrp TEST
 !
 address-family ipv4 unicast autonomous-system 100
 !
 af-interface default
 passive-interface
 exit-af-interface
 !
 af-interface Tunnel100
 summary-address 10.0.0.0 255.0.0.0
 summary-address 10.2.0.0 255.255.0.0
 no passive-interface
 no split-horizon
 exit-af-interface
 !
 af-interface GigabitEthernet0/0/1
 no passive-interface
 exit-af-interface
 !
 af-interface GigabitEthernet0/0/3
 no passive-interface
 exit-af-interface
 !
 topology base
 distribute-list route-map set-metric-Gig out GigabitEthernet0/0/1
 distribute-list route-map set-metric-tag-all out Tunnel100
 exit-af-topology
 network 10.1.2.0 0.0.0.255
 network 10.1.10.0 0.0.0.3
 network 10.1.123.0 0.0.3.255
 eigrp router-id 10.1.0.11
 exit-address-family 
!
route-map set-tag-all deny 10
 match tag 102 201 202
!
route-map set-tag-all permit 100
 match ip address prefix-list set-spoke-delay-4000
 set metric 100000 4000 255 1 1500
 set tag 101
!
route-map set-tag-all permit 300
 match ip address prefix-list set-spoke-delay-1000
 set metric 100000 1000 255 1 1500
 set tag 101
!
route-map set-tag-all permit 400
 match ip address prefix-list set-spoke-delay-2000
 set metric 100000 2000 255 1 1500
 set tag 101
 
!
ip prefix-list set-spoke-delay-4000 seq 100 permit 10.2.0.0/16
. . . 
! 

Tunnel100은 INET 링크를 통해 스포크 라우터로 향하는 DMVPN(Dynamic Multipoint VPN) 터널입니다. 이전 컨피그레이션에서는 접두사 10.2.0.0/16이 지연 시간 4000으로 설정됩니다. 마찬가지로, 동일한 접두사에 대해 DC2-BR2, DC2-BR1 및 DC1-BR2 노드에서 지연 시간을 1000, 2000 및 3000으로 설정하여 우선 순위를 설정합니다. 이 예에서는 데모용으로 DMVPN 터널을 사용하지만 이 문제는 인터페이스에 종속되지 않습니다.

문제

이 문제는 실제로 스포크 라우터에서 나타납니다. 여기서 접두사 10.2.0.0/16은 DC2 브랜치 라우터에서 받으면 다른 메트릭으로 표시되지만 DC1 브랜치 라우터에서 받으면 동일한 메트릭을 갖습니다. 스포크 라우터의 이 출력은 다음 동작을 보여줍니다.

Spoke-1# show ip eigrp topology 10.2.0.0/16 | in delay
        Total delay is 60000000000 picoseconds  (from DC 2 BR2)
        Total delay is 100020000000 picoseconds  (From DC 1 BR1)
        Total delay is 70000000000 picoseconds  (From DC 2 BR1)
        Total delay is 100020000000 picoseconds  (From DC 1 BR2)

이 동작으로 인해 DC1-BR1 및 DC1-BR2 라우터에서 수신된 경로에 대한 우선순위가 지정되지 않습니다.

솔루션

네트워크 운영자가 메트릭을 수신된 값보다 낮은 절대값(낮은 메트릭)으로 설정하려고 한 것이 문제의 주요 원인이었다. 이 문제는 show ip eigrp events 명령을 실행합니다. 이 출력은 route-map이 접두사에 대해 실제로 존재하는 값보다 낮은 값으로 메트릭을 조작하려고 시도한다는 것을 보여줍니다.

DC1-BR1# show ip eigrp events
. . .
06:47:11.891 Can't reduce rtmap metric, old/new: metric(2950430720) metric(1972633600)
. . .

모든 라우팅 프로토콜에서 메트릭을 줄일 수 없습니다. 마이너스 비용이 있는 인터페이스가 있음을 의미하기 때문입니다. 이는 결국 루프 방지 조건을 무력화시키고 네트워크에 불일치를 초래할 수 있습니다. 이 문제에 대한 해결책은 두 가지 방법으로 할 수 있습니다.

• 수신된 접두사 경로의 지연 값을 줄입니다. 이전의 경우 DCI 인터페이스의 EIGRP 지연 값을 줄이면 문제를 완화하는 데 도움이 되었습니다.
• 메트릭 조작을 수행할 때 더 높은 절대 메트릭을 구성합니다.