EIGRP

EIGRP
Link state protocol 처럼 작동하는 Distance vector protocol

1.Distance vector protocol
직접 연결된 네이버를 제외한 알고 있는 모든것을 공유

2.Link state protocol
직접 연결된 링크의 정보만 공유

3.Distance vector protocol은 routing loop을 유발하는 경향 있음
대책 = split horizon,route poisioning,holddown timer

4.Convergence 가 늦을수 있음
수신한 경로를 라우팅 알고리즘으로 계산후 네이버에게 전달해야 하므로
주요링크가 변경되면 변경된 수 많은 경로를 전파해야함->경로 자체를 전파하기 때문에

5.Update
비주기적-메트릭,토폴로지 변화시에만 전송
부분적-변경된 부분만 전송
제한적-연관된 라우터에게만 전송

6.Metric * 256

7.IP와 IPX,Appletalk도 라우팅 가능

8.EIGRP의 4가지 구성요소
1) protocol 종속모듈
ip,ipx,appletalk를 라우팅 시켜줌

2) 신뢰성 전송 프로토콜(RTP,Reliable transport protocol)
패킷 전달 보장 - multicast(224.0.0.10) 전송,unicast ack 송신
패킷 sequence number - 패킷 전송시마다 +1 증가 시킴

특별한경우 RTP를 사용 안하고 전송하는 경우가 있음

9.패킷 종류
1) hello - 비신뢰성 방식,multicast 사용
2) update - RTP방식,muliticast,unicast 사용
3) ack - 비신뢰성,unicast 사용
4) query - RTP방식,multicast,unicast 사용
5) reply - RTP방식,unicast 사용

10.ack 미수신시 작동순서
 eigrp 패킷 송신->ack 수신 실패->multicast flow timer 경과후 unicast 16번까지 송신->ack 수신실패->네이버 down 처리

11.ack을 수신해야 하는 패킷 종류
query,reply,update

12.SRTT
네이버에게 패킷 전송후 ack 수신까지 걸린 시간

13.RTO(retransmission time out)
multicast 전송에 대한 ack 수신 실패후 unicast 전송시 ack 수신을 기다리는 시간
단위 - ms
unicast 전송 주기 시간

14.DUAL(diffusion update algorithm)
업데이트 확산 알고리즘
일시적인 라우팅 루프조차 허용치 않겠다는 생각이 바탕이 됨

hello 송신->hello 수신->네이버 수립(adjacency)->update전송

수신되는 update에는 경로와 메트릭값이 들어있음
해당 목적지에 대해 네이버가 보낸 경로가 FC조건(AD<자신의 FD)을 만족하면 수신한 경로값을 선택함
해당 경로를 전송한 네이버는 feasible successor로 지정됨
수신한 경로의 메트릭 값과 네이버까지의 경로 메트릭 값 합산후 전체 메트릭 값 계산
경로를 토폴로지 테이블에 저장

15.네이버 수립조건
동일한 서브넷 - hello 송신자의 서브넷 주소가 수신자 인터페이스의 서브넷과 일치
AS번호,K 상수,인증

16.라우팅 루프를 막는 핵심 개념
feasible successor 와 feasible condition
feasible distance가 항상 기존 feasible distance보다 작기 때문에 라우터는 자신에게 돌아오는 경로를 결코 선택할 수 없다.

17.feasible successor 존재 이점
dual 계산 부하 감소
빠른 convergence 시간
라우터는 경로 변경시 먼저 topology table에서 해당 경로에 대한 feasible successor가 있는지 확인후 없으면 dual 시작

18.DUAL 작동 방식
1) input event 발생
직접 연결된 링크의 다운 또는 업
cost 값 변경
update,reply 수신

2) 모든 successor에 대해 지역계산(local computation) 실행
실행중 모든 경로는 passive 상태 유지
적당한 successor 발견시 update 패킷 전송

3) feasible successor가 토폴리지 테이블에 없을때 dual 시작
실행중 모든 경로는 active 상태 유지
dual 완료후 passive 상태 될때까지 또 다른 dual 계산 금지,FD 변경 금지,successor 변경 금지

4) query를 수신한 네이버가 적정 successor가 있다면 query를 전송한 네이버에게 reply 전송

5) 적정 succesor가 없다면 해당 경로를 active 상태로 변경후 dual 시작
query 전송->active timer 시작->query를 전송한 모든 네이버 항목에 reply status flag를 설정->query를 전송한 모든 네이버에게서 reply를 수신하면 dual 완료->active timer 종료시까지 reply를 받지 못했다면 해당 경로 SIA 선언->SIA 상태 경로 와 네이버는 삭제

19.FC(feasible condition)조건
FD>AD 이면 토폴로지 테이블에 저장
FD<AD 이면 토폴로지 테이블에서 삭제

20.특정 경로 장애시(link down시)
해당 경로에 대해 feasible successor를 발견 할수 없는 라우터->장애 경로에 대한 메트릭 값을 무한대로 설정한후 update를 네이버에게 전송->네이버에게 query를 전송->update를 수신한 네이버는 지역계산 수행

21. EIGRP 와 IGRP가 같은 process id 라면 재분배가 자동으로 이루어진다.

22. passive interface s0
s0 인터페이스로 hello 송신 안함->네이버 수립 안함->eigrp 패킷 전송 안함

23. eigrp는 네트워크 경계에서 address summarization 수행
#(config) int e0
#(config-if) ip summary-address eigrp 15 172.20.15.0 255.255.0.0

24. eigrp 장애처리

RIP 나 IGRP 에서는 라우팅의 부재 또는 부정확성만 체크 하면 됨

EIGRP에서는 4가지를 체크 해야함

1) 네이버 테이블

2) adjacency 관계

3) DUAL 과정

4) 자동요약

25. 네이버 사자지는 현상

1) 각 라우터의 라우팅 테이블 조사

2) 라우팅 테이블에서 이상한 라우터 발견

3) EIGRP 설정 확인

4) 네이버 테이블 확인

26. 반복되는 query 는 dual을 확장하는 원인

reply는 dual을 축소하는 원인

dual의 반경이 지나치게 크면 active timer가 모든 reply를 수신하기전에 종료될수 있음

26. 사용자가 간헐적으로 목적지에 연결 할수가 없다고 불평할때

네이버가 사라졌다가 나타났다가 반복->SIA 일경우 높음->라우터의 log 확인->%DUAL-3-SIA~~~~....라는 에러가 있으면 SIA가 확실

27. SIA 현상 해결책

주소를 주의해서 할당

경로 필터링,디폴트 경로,경로 요약을  결합하여 DUAL 계산의 범위를 적절히 조정