EIGRP는 매우 빠르게 converge된다. 하지만 모든 상황에 있어서는 아니다.
One design goal might be to tune EIGRP configuration settings so that EIGRP uses the faster convergence methods for as many routes as possible, and when not possible, that EIGRP converge as quickly as it can without introducing routing loops. As a result, routers might converge in some cases in a second instead of tens of seconds (from the point of a router realizing that a route has failed).
Succesor and Feasible Successors Concept
이렇게 구성 된 후 Router E는 Router D가 가장 낮은 metric을 가지고 있는 것을 알 것이고.
Router E는 successor route로 라우팅 테이블에 추가할 것이다. 여기서 succesor의 FD는 14,000 이다.
EIGRP는 RD가 FD보다 낮다면 그 route를 feasible route라고 결정한다
When that neighbor has a lower metric for its route to the subnet in question, that route is said to have met the FS.
예를들어, ROuter E는 14,000의 FD를 가진 Router D를 통과하는 route를 successor route로 등록한다.
Router C의 RD는 13,000이다. E의 FD인 14,000보다는 낮은 값이다.
그 결과 E는 C의 최적의 경로가 router E를 통해 가는것이 아닌것을 알고, 그래서 Router E는 Router C를 통해 Subnet 1로 가는 경로를 믿는다. 이는 loop를 일으키지 않을 것이다. 그 결과 Router E는 자신의 토폴로지 테이블에 Router C를 통해 가는 것이 feasible successor route 라고 등록한다.
반대로, Router E의 Router B로 가는 RD는 FD보다 큰 15,000이다.
그래서 이 대안 경로는 feasibly condition을 만날 수 없다. 그래서 Router E는 Router B로 통하는 경로를 feasible succesor로 고려하지 않는것이다.
만약 Router D로가는 경로가 실패하면, Router E는 즉시 Router C의 경로를 routing table에 추가할 것이다. 이때 looping 에 대한 문제는 고려할 것이 아니다. 이 경우에는 즉각적으로 convergence가 일어난다.
그라나 C,D가 모두 실패됐을때, Router E 는 feasible succesor 경로를 가지고 있지 않다. 그리고 Router B를 통하는 경로를 사용하기 전에 추가적인 작업을 하려고 할 것이다. -> "Converging by Going Active"
Feasible successors에 대해 분석을 해보자
■ # show ip eigrp topology
command does not list all known EIGRP routes, but instead lists only successor and feasible successor routes.
모든 EIGRP의 경로를 표시하진 않고, successor과 feasible successor 경로만 표시한다.
■ # show ip eigrp topology all-links
command lists all possible routes, including those that are neither successor nor feasible successor routes.
successor와 feasible successor도 아닌 가능한 모든 경로를 출력한다.
위의 그림은 WAN1에서 세가지 가능한 경로를 보여준다.
WAN1#show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(10.9.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.11.1.0/24, 1 successors, FD is 2172416
via 10.1.1.2 (2172416/28160), Serial0/0/0.1
! lines omitted for brevity; no other lines of output pertain to 10.11.1.0/24.
WAN1#show ip eigrp topology all-links
IP-EIGRP Topology Table for AS(1)/ID(10.9.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.11.1.0/24, 1 successors, FD is 2172416, serno 45
via 10.1.1.2 (2172416/28160), Serial0/0/0.1
via 10.9.1.2 (2174976/2172416), FastEthernet0/0
! lines omitted for brevity; no other lines of output pertain to 10.11.1.0/24.
첫번째 명령어 show ip eigrp topology 는 오직 successor route 와 feasible successor route만을 보여준다.
두번째 명령어 show ip eigrp topology all-links 는 모든 경로를 보여준다.
여기서는 두가지 경로를 보여준다. B1으로 직접가는것과 WAN2를 통해서 가는경로를 보여준다.
그러나 B2를 통해서 가는 경로는 존재하지 않는다. 왜냐하면 B2의 10.11.1.0으로 가는 루트가 WAN1을 통해서 가는 것이 현재 successor route이기 때문이다. EIGRP split Horizon rule은 B2에게 10.11.1.0으로 가는 경로를 WAN1로 광고하지 못하게 한다.
그리고 WAN2를 통해서 가는 route의 RD는 2,172,416이다.
WAN1의 successor route는 이와 같은 값을 가지고 있다. 그래서 이것은 WAN2를 통해서 fesiblity condition을 만나지 않는10.11.1.0으로 가는 대안 루트가 될수 있다.
Feasible Successor route가 되기 위해 RD는 FD보다 낮아야 하며, 이 경우에는 똑같다.
이를 이제 FS로 등록시켜 보자
WAN1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
WAN1(config)#access-list 11 permit 10.11.1.0
WAN1(config)#router eigrp 1
WAN1(config-router)#offset-list 11 in 3 s0/0/0.1
WAN1(config-router)#^Z
WAN1#show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(10.9.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.11.1.0/24, 1 successors, FD is 2172419
via 10.1.1.2 (2172419/28163), Serial0/0/0.1
via 10.9.1.2 (2174976/2172416), FastEthernet0/0
! lines omitted for brevity; no other lines of output pertain to 10.11.1.0/24.
이제 앞의 값과 비교해 보자 offset을 통해서 FD의 값이 3이 증가된 것을 볼 수 있다.
그래서 이제 WAN2로 가는 경로의 RD가 FD보다 낮게 되었다.
Converging By Going Active?? 뭐?
EIGRP에서 successor을 제거하고 FS가 없을때, 라우터는 loop-free한 대안 경로를 찾는다.
이를 going active라고 부른다.
successor 경로를 가지고 있는 경로들가 실패가 아직 일어나지 않은 경로는 passive로 남아있다.
FS가 없고 successor route가 실패한 경로는 active state로 변경된다.
- from passive to active
- EIGRP query 메세지를 실패한 경로를 제외한 모든 경로로 보낸다. 쿼리는 loop-free한 경로가 있는지 없는지 물어본다.
- The neighbor considers itself to have a loop-free route if that neighbor is passive for that prefix/length.
이웃이 이웃이되는 접두사 / 길이에 대한 수동 경우 루프가없는 경로를 가지고 자신을 고려합니다 - 이웃은 자기자신을 고려한다. passive상태인 loop-free한 경로를 고려한다. 그리고 둘중 하나의 행동을 취한다.
- 정말 loo-free한 경로가 있다고 reply 메세지를 보낸다.
- query를 forward 하지 않는다.
- 만약 이웃자체가 이 경로에 active 되어 있으면,
- flood EIGRP query message
- 바로 reply를 보내지 않는다.
- Reply를 보냈던 라우터에게서 모든 reply를 받으면, 라우터는 필요에 따라 reply를 보낸다.
- 라우터가 query에 대한 reply를 받으면, 라우터는 안전하게 loop-free한 최적의 경로로 설정한다.
뭐라정리했는지............
The EIGRP convergence process when going active on a route is sometimes also referenced by the name of the underlying algorithm, named DUAL ( Diffusing Update Algorithm ).
이는 많은 경우에 있어서 이루어 지며, 새로운 경로의 convergence는 약 10초 이내로 작동한다.
그러나 많은 remote site가 있는 internetwork 에서는 going active가 비효과적이다.
예를들어 아래와 같은 경우일때 하나의 라우터가 route를 잃는다면, 이때 교환될 Query를 감당 못할 것이다.
위의 그림에서는 5개이지만 실제에서는 300개 정도의 라우터로 구성되는데, 그렇다면 299개의 query와 299개 이하의 query를 주고받을 것이다.
이는 FS route 가 존재하는 것보다는 확실히 느릴 것이다.
만약 FS가 존재한다면 successor에 장애가 발생하여도 query를 보내지 않는다.
그러나 몇몇 경우에서는 FS route 를 모든 routes에 만드는 것이 불가능하다, 그래서 엔지니어들은 query의 시야를 제한하는 action을 취하기도 한다.
The Impact of Stub Routers on Query Scope
Stub 라우터에서 eigrp stub 이라는 명령어를 사용할수 있다.
| Option | This router is allowed to... |
| Connected | 연결된 경로를 network command가 match 되는 인터페이스에만 광고한다. |
| Summary | auto-summary 됐거나 정적으로 summary된 경로를 광고한다. |
| Static | redistribute static 명령어가 설정되었을 때, static route를 광고한다 |
| Redistributed | Advertises redistributed routes, assuming redistribution is configured. redistribute static 명령어가 설정되었을 때, 재분배된 경로를 광고한다. |
| Receive-only | 광고하지않는다. 다른 옵션과 같이 쓰일 수 없다. |
위와 같은 명령어를 통해서 Query Scope 를 낮게 만들수 있다.
아래의 예제는 eigrp stub connected 커맨드를 통해 connect 된 route만을 광고한다.
그 외에도 혼합하여 옵션을 사용할 수 있다.
(~~~)# eigrp stub connected static
위와 같은 옵션을 주게 되면 connected routes 와 static routes 를 광고한다.
The Impact of Summary Routes on Query Scope
추가로 EIGRP stub routers에서 route summarization 을 통해서도 Query scope를 제한시킬수 있어, 이는 convergence 시간을 줄일 수 있다.
라우터가 prefix/prefix length가 확실하게 일치하지 않는 경로에 대한 EIGRP query를 받으면, 하지만 prefix와 prefix length를 포함하는 summary 경로를 받으면 즉시 EIGRP reply 패킷을 보내고 flood 하지 않는다.
If a router receives an EIGRP Query for a prefix/prefix length, does not have an exactly matching (both prefix and prefix length) route,but does have a summary route that includes the prefix and prefix length, that router immediately sends an EIGRP Reply and does not flood the Query to its own neighbors.
예를들어
Step 1. WAN1 과 WAN1 는 서머리된 경로를 광고하고, 코어에 있는 C1,C2 와 다른 라우터들은 10.11.0.0 으로의 경로를 가지고 있지만 10.11.1.0으로으 경로는 가지고 있지 않다.
Step 2. 미래에 가끔, WAN1은 10.11.1.0에 대한 경로를 잃을 것이고, WAN1은 10.11.1.0에 대해서 C1,C2에 query를 보낼 것이다.
Step 3. C1 and C2는 EIGRP Reply를 나중에 즉시 보낸다, 왜냐하면 prefix/length를 가지고 있지않기 때문이다.(10.11.1.0/24), 그러나 주소는 포함하고 있지만 (10.11.0.0/16) 안보낸다 ;;
Stuck in Active
라우터는 경로실패와 passive 에서 active 상태로 변햇을때, Query 메세지를 이웃에게 보낸다.
특히 꽤나 큰 네트워크에서 라우터들이 약간 hop들이 떨어져있을때, Query 의 수는 크지는 않을 것이다.?
하지만 아래 그림에서와 같이 R1은 R11,12,13이 Reply를 보내기를 기다려야 한다.
R1은 R21,22,23을 기다려야 하고... 이것은 R1은 꽤나 긴 시간을 기다려야 한다는 것을 의미한다.
비록 위의 그림이 그냥 고안한 것이라고 해도, 여기서 포인트는 active 상태에서 reply 메세지를 기다리는 것은 잠깐 기다려야 할 것이다.라우터는 이러한 메세지들이 모두 도착하기 전까지 대안 경로를 사용할 수 없을 것이다.
잠재적으로 긴 이 긴 시간을 처리하려면, IOS는 이에 대한 제한을 두어야 한다.
이것이 active timer라고 불리는 타이머이다. 이것은 3분을 default 설정되어 있다.
( 이는 timers active-time [time] EIGRP subcommand를 통해 설정할 수 있다. )
라우터가 active timer 동안 경로에 대한 reply를 받지 못하는 것을 Stuck-in-Active (SIA) 이라한다.....
IOS는 SIA에 대한 중요한 두가지 논리적 가지를 가지고 있다.
이전의 버전에서는 오히려 격렬하게 반응했다. EIGRP reply 패킷을 돌려보내지 않는 비협조적인 이웃들을 끌어내렸다.
예를들어 위의 그림에서 R1이 R11,12에게는 받았으나 13에게 받지 못했다면 (active timer expired) R1은 R13을 neighbor에서 끌어내렸다.
The active route would be considered to have failed, and all routes known through the failed neighbor would also be considered to have failed–possibly generating more Query messages for other routes.
이후의 버전에서는 ( 12.2 mainline 이후 ) neighborship이 실패하는 것을 피하게 시도했다.
active timer의 반이 지나가면 아직 reply를 보내지 않은 라우터들에게 router는 SIA-QUERY ( Stuck-in-Active query) EIGRP 메세지를 이웃들에게 보냈다.
이 메세지의 목적은 SIA-reply back, 을 받는 것이다. 이것은 neighbor가 아직 각자의 reply를 기다리고 있는지 확인하기 위함이고, 이제 neighborship을 끝낼 필요는 없게 되었다. 이번 케이스에서 neighor은 reply를 보내지 않으면 논리에 맞게 neighborship을 failing 시켰다.
