루프백 인터페이스 Loopback
- 가상의 인터페이스로 가상이기 때문에 원하는 수만큼의 네트워크를 구성할 수가 있다.
- 가상이기 때문에 인터페이스의 고장으로 인한 장애가 발생할 일이 없다.
- BGP, OSPF에서는 라우터를 구별하는 ID로 사용된다.
RIP에서는 특정 인터페이스의 고장으로 인한 네트워크 정보 업데이트 오류의 원인을 파악할 때 주로 사용된다.
명령어 : R1(config-if)#interface loopback 0
R1(config-if)#ip add [할당 IP] [서브넷]
Secondary IP
인터페이스의 하나 이상의 IP를 설정할 때 사용VLAN 기능을 지원하지 않을 때 모듈을 사야하는 대신에 사용하나의 인터페이스에 여러 네트워크 대역을 추가할 때 사용적용한들 그리 좋은 성능은 아니다.
가상 인터페이스와는 다른 개념이며, 그 외 다른 인터페이스에 모두 설정 가능하다.
명령어 : Ip add [IP] [서브넷] secondary
=========================================================
<RIP 응용 실습>
=========================================================
Gateway of last resort is not set
211.100.10.0/30 is subnetted, 3 subnets
C 211.100.10.8 is directly connected, Serial1/1
R 211.100.10.4 [120/1] via 211.100.10.9, 00:00:13, Serial1/1
[120/1] via 211.100.10.2, 00:00:00, Serial1/0
C 211.100.10.0 is directly connected, Serial1/0
162.10.0.0/24 is subnetted, 6 subnets
R 162.10.8.0 [120/1] via 211.100.10.9, 00:00:13, Serial1/1
R 162.10.9.0 [120/1] via 211.100.10.9, 00:00:13, Serial1/1
C 162.10.2.0 is directly connected, Loopback0
C 162.10.3.0 is directly connected, Loopback0
R 162.10.4.0 [120/1] via 211.100.10.2, 00:00:00, Serial1/0
R 162.10.5.0 [120/1] via 211.100.10.2, 00:00:00, Serial1/0
RIP 프로토콜의 로드밸런싱
R1에서 211.100.10.4 대역까지의 경로가 R2를 통과하는 방법과 R3를 통과하는 방법 2가지 존재하며, Metric이 서로 다를 경우 Metric 값이 낮은 경로 하나만 최적 경로로 판단하지만, Metric이 서로 같은 경우 두 개의 경로 모두 라우팅 테이블에 업데이트 이후 부하분산이 이루어진다.
만약 동일한 목적지까지 서로 다른 라우팅 프로토콜을 가진 경로가 여러개 존재한다면
AD값이 작은 라우팅 프로토콜의 경로가 우선시 된다.
* AD : Administrative Distance, 관리 거리 값,
RIP 120, EIGRP(내부) 90, OSPF 110, EIGRP(외부) 170
================================================================
<수동 축약>
162.10.2.0/24 -> 10100010.00001010.0000001|0|.00000000
162.10.3.0/24 -> 10100010.00001010.0000001|1|.00000000
--------------------------------------------------------
11111111.11111111.1111111|1|.00000000
162.10.2.0/24 -> 10100010.00001010.0000001|0|.00000000
162.10.3.0/24 -> 10100010.00001010.0000001|0|.00000000
--------------------------------------------------------
11111111.11111111.1111111|0|.00000000
10100010.00001010.0000001|0|.00000000 -> 162.10.2.0/23
162.10.4.0/24 -> 10100010.00001010.0000010|0|.00000000
162.10.5.0/24 -> 10100010.00001010.0000010|1|.00000000
--------------------------------------------------------
11111111.11111111.1111111|1|.00000000
162.10.4.0/24 -> 10100010.00001010.0000010|0|.00000000
162.10.5.0/24 -> 10100010.00001010.0000010|0|.00000000
--------------------------------------------------------
11111111.11111111.1111111|0|.00000000
10100010.00001010.0000010|0|.00000000 -> 162.10.4.0/23
162.10.8.0/24 -> 10100010.00001010.00001000.00000000
162.10.9.0/24 -> 10100010.00001010.00001001.00000000
10100010.00001010.00001000.00000000 -> 162.10.8.0/23
=> 공통되는 부분은 그대로 내려오고 다른 부분은 0으로 채운다음
서브넷 마스크를 다른 부분까지 잘라서 적용한다.
<R1>
interface Serial1/0
ip summary-address rip 162.10.2.0 255.255.254.0
interface Serial1/1
ip summary-address rip 162.10.2.0 255.255.254.0
<R2>
interface Serial1/0
ip summary-address rip 162.10.4.0 255.255.254.0
interface Serial1/1
ip summary-address rip 162.10.4.0 255.255.254.0
<R3>
interface Serial1/0
ip summary-address rip 162.10.8.0 255.255.254.0
interface Serial1/1
ip summary-address rip 162.10.8.0 255.255.254.0
=> 각 라우터의 출구 인터페이스에 축약한 내용을 설정한다.
===============================================================
- 확인 -
축약 전
<R1>
Gateway of last resort is not set
211.100.10.0/30 is subnetted, 3 subnets
C 211.100.10.8 is directly connected, Serial1/1
R 211.100.10.4 [120/1] via 211.100.10.10, 00:00:15, Serial1/1
[120/1] via 211.100.10.2, 00:00:05, Serial1/0
C 211.100.10.0 is directly connected, Serial1/0
162.10.0.0/24 is subnetted, 6 subnets
R 162.10.8.0 [120/1] via 211.100.10.10, 00:00:15, Serial1/1 --> 상세 경로로 광고
R 162.10.9.0 [120/1] via 211.100.10.10, 00:00:15, Serial1/1 --> 상세 경로로 광고
C 162.10.2.0 is directly connected, Loopback0
C 162.10.3.0 is directly connected, Loopback0
R 162.10.4.0 [120/1] via 211.100.10.2, 00:00:05, Serial1/0 --> 상세 경로로 광고
R 162.10.5.0 [120/1] via 211.100.10.2, 00:00:05, Serial1/0 --> 상세 경로로 광고
축약 후
<R1>
Gateway of last resort is not set
211.100.10.0/30 is subnetted, 3 subnets
C 211.100.10.8 is directly connected, Serial1/1
R 211.100.10.4 [120/1] via 211.100.10.10, 00:00:06, Serial1/1
[120/1] via 211.100.10.2, 00:00:00, Serial1/0
C 211.100.10.0 is directly connected, Serial1/0
162.10.0.0/16 is variably subnetted, 4 subnets, 2 masks
R 162.10.8.0/23 [120/1] via 211.100.10.10, 00:00:06, Serial1/1 -->축약된 주소로 광고
C 162.10.2.0/24 is directly connected, Loopback0
C 162.10.3.0/24 is directly connected, Loopback0
R 162.10.4.0/23 [120/1] via 211.100.10.2, 00:00:00, Serial1/0 --> 축약된 주소로 광고
==> 라우팅 테이블이 줄어든다.
효과적인 축약을 하면 네트워크의 안정성과 성능을 향상시킬 수 있다.
=========================================================
<EIGRP>
Cisco에서 만든 시스코 전용 라우터 프로토콜
RIP과 동일하게 Split-horizon이 적용되고, major 네트워크 경계에서 auto-summary가된다.라우팅 정보전송을 위해 IP프로토콜 88번 사용DUAL 알고리즘 사용한다.
AD(Administrative Distance)
값은 internet 90내부 external 170외부
AS(Autonomous System)
하나의 네트워크 관리자에 의해 관리되는 라우터의 집단, 하나의 관리전략으로 구성된 라우터의 집단, (한 회사, 기업, 단체의 라우터 집단)
클레스리스 라우팅프로토콜 => VLSM과 CIDR 사용
멀티캐스트 주소(224.0.010) 사용하여 정보를 전달한다.
-장점
빠르고, OSPF에 비해 설정이 간편하다. (DUAL)알고리즘 사용.
-단점
CISCO 전용 장비로 타 라우터에서 적용이 안된다.
중소규모 네트워크에서는 잘 돌아가지만 대규모 네트워크에서는 관리가 힘들다.
(SIA 현상이 발생할 수 있다.)
================================================================
AS(Autonomous System)
- 하나의 네트워크 관리자에 의해서 관리되는 라우터들의 집단, 하나의 관리 규정 아래서 운용되는 라우터들의 집단,
하나의 관리 전략으로 구성된 라우터 집단 (즉, 한 회사나 한 기업, 또는 단체의 라우터 집단)
-> 어떤 기업이 네트워크를 구축하면 이 기업에 소속된 모든 라우터들은 지역을 떠나서 그 기업의 네트워크 관리자에 의해 관리를 받게 되는데 이런 그룹이 바로 AS (KT같은 ISP업체들이 보유하고 있는 라우터의 그룹이 하나의 AS가 된다.)
기본 인터페이스 설정
Router Eigrp <AS number> ex) router_eigrp_10
// AS 번호를 지정한다.(1~65535) ->
BGP는 돈을 주고 AS번호를 사오지만 EIGRP는 관리자가 임의 값을 할당. EIGRP로 동작하는 모든 라우터는 동일한 AS번호를 가져야 한다.
No auto-summary
// 자동 축약을 취소한다.
Eigrp router-id x.x.x.x ex) eigrp_router-id 1.1.1.1
// 라우터ID. 임의로 설정하지 않을 경우 루프백 인터페이스에서 가장 높은 IP주소가 설정
루프백 인터페이스가 없을 경우 물리적 인터페이스에서 가장 높은 IP주소가 설정 (관리용)
(설정 안해도 EIGRP는 정상적으로 동작 (스스로 설정하니까)
Network x.x.x.x y.y.y.y ex) Network [광고할IP][와일드마스크]
// 자신에게 연결된 네트워크를 사용한다. 이때 wildcard mask를 같이 사용한다.
(Wildcard mask는 subnet 마스크에서 0과 1을 바꾼 값과 같다. 즉, 서브넷마스크 255.255.255.0은 와일드 카드 마스크로 0.0.0.255 이다.)
서브넷 마스크 IP 값이 아니다.
-> classful하게 설정이 가능하지만 불필요한 EIGRP 패킷 전송과 상대방 라우터에게 불필요한 라우팅 업데이트 문제를 해결하기 위해서 와일드 마스크로 최적 설정이 가능하다.
=========================================================
EIGRP 패킷 5가지
1.) Hello packet ->
네이버를 구성하고 유지하기 위한 패킷. 멀티캐스트(224.0.0.10)을 목적지 IP로 전송한다.
EIGRP는 인접라우터에게 주기적으로 헬로 패킷을 전송하고 기본적으로 헬로 주기의 3배에
해당하는 시간(Hold time)안에 상대방의 헬로 패킷을 받지못하면 네이버를 해제한다.
인캡슐레이션
|
헬로 주기(초)
|
홀드 시간(초)
|
이더넷, HDLC, F/R의 point-to-point 서브 인터페이스
|
5
|
15
|
T1 이하의 NBMA 인터페이스, F/R의 멀티포인트서브 인터페이스
|
60
|
180
|
=> 설정으로 변경 가능
2.) Update packet -> 라우팅 정보를 전송할 때 사용되는 패킷. 네이버를 맺은 라우터끼리 서로의 라우팅 경로에 대한 정보를 교환한다. 경우에 따라 유니캐스트 혹은 멀티캐스트(224.0.0.10) 주소를 사용해서 전송한다.
3.) Querty packet (라우팅 정보요청 패킷) -> 라우팅 정보를 요청할 때 사용되는 패킷으로
경우에 따라 유니캐스트 혹은 멀티캐스트(224.0.0.10)주소를 사용해서 전송한다.
=> 자신의 라우팅 테이블에 있는 경로가 다운되거나 메트릭 값이 증가하고, 토폴로지 테이블에 feasible successor(대체 경로)가
없을시 인접한 라우터들에게 해당 경로에 대한 정보를 요청하기 위해서 사용한다.
4.) Reply packet (응답 패킷) -> Querty 패킷을 수신한 라우터가 요청받은 라우팅 정보를 전송할 때 사용한다. 항상 유니캐스트로 전송한다. 즉, querty 패킷을 수신하면 해당 패킷을 전송한 인접 라우터의 IP주소를 목적지로 설정해서 응답패킷을 전송.
5.) Acknowledgement packet (수신확인 패킷) -> Ack 패킷은 update 패킷, query 패킷, reply 패킷의 수신을 확인할 때 사용된다. Ack 패킷과 hello 패킷에 대해서는 수신을 확인하지 않는다. 항상 유니캐스트로 전송.
=========================================================
- Eigrp가 라우팅 경로를 계산하는 절차
1) hello packet을 인접 라우터가 서로 교환하면 네이버 관계를 맺고 네이버 테이블 생성한다.
2) update packet을 통해 라우팅 정보를 교환하고 토폴로지 테이블 생성한다.
3) 라우팅 경로를 계산하고 최적경로를 라우팅 테이블에 저장한다.
- 특정 네트워크로 가는 경로 또는 인접 라우터가 다운되었을 때
1) query packet으로 다운된 네트워크의 라우팅 정보 요청 및 응답상태 테이블 생성
2) reply packet으로 라우팅 정보 수신 및 토폴로지 테이블 저장
3) 수신한 라우팅 정보들로 라우팅 경로 계산을 하고 최적 경로를 라우팅 테이블 저장한다.
=> 경우에 따라서 위의 절차를 거치지 않고 토폴로지 테이블에서 바로 새로운 경로를 찾아 라우팅 테이블에 올릴 경우도 있다. (Feasible Successor가 있는 경우)
=========================================================
EIGRP 메트릭 (Metric)
- Bandwidth(대역폭), Delay(지연), Reliability(신뢰성), load(부하), MTU 및 hop count를 기준으로 경로를 결정
(주로 Bnadwidth와 Delay) => 각각의 메트릭을 벡터 메트릭이라 한다.
=> 특정 공식에 각각의 값을 대입하여 최적의 경로를 결정한다. (때문에 복합 메트릭
라는 표현을 사용)
'show interface <인터페이스 (ex. serial 0/0)>명령어로 각 인터페이스별로 확인
=> MTU는 기본적으로 가장 작은값을 사용
=> hop count는 기본적으로 100, 명령어를 사용해 최대 255까지 늘릴 수 있다.
=> 계산에서 사용되는 Bandwidth (B/W)값은 목적지까지 가는 중의 모든 인터페이스의 대역폭 중 가장 낮은 값으로 10^7을 나눈값
(즉, B/W = 10^7/가장 느린 대역폭 * 256 (소수점 이하는 버림))
=> 계산식에서 사용되는 Delay값은 목적지까지 가는 경로중에 있는 모든 delay값을 더한 후 10으로 나눈 값
(즉, 경로상의 모든 delay를 합한 값/10 * 256)
=> reliability(신뢰도)는 인터페이스의 에러발생율
=> load는 인터페이스의 부하를 나타낸다.
* 메트릭 공식
기본적이니 K상수 값 => K1 = K3 = 1
K2 = K4 = K5 =0
1) K5 = 0인 경우 =>
[ K1 * (B/W) + K2 * (B/W)/(256 - load) + K3 * DLY ] * 256
2) K5 = 0 이 아닌 경우 =>
[ K1 * (B/W) + K2 * (B/W)/(256 - load) + K3 * DLY ] * 256 * K5/ (reliability + K4)
====> K 상수는 명령어도 변경이 가능하나 기본적으로 K5 = 0
즉, 기본적인 메트릭 계산식은 아래와 같다.
[ 1 * (B/W) + 0 * (B/W)/(256 - load) + 1 * DLY ] * 256 = ((B/W) + DLY) * 256
* 주의!!! 여기서 (B/W)는 10^7/가장 느린 bandwidth (소수점 이하는 버림), DLY는 경로상의 모든 delay를 합한 값/10 즉, ((10^7/가장 느린 bandwidth)*256 + (모든 delay를 합한 값/10) * 256)
====> 복합 메트릭 계산 시 reliability(신뢰성), load(부하)까지 계산하면 일시적으로는 부하가 적게 걸리고 에러 발생률이 낮은 경로로 라우팅되는 장점이 있지만 수시로 라우팅 경로가 변경되어 네트워크가 불안해지고 잦은 라우팅 계산으로 CPU사용이 많아진다. 또, 라우팅 정보 전송으로 인해 링크 점유율이 증가 되는 등의 부정적인 영향 때문에 기본적으로 계산 시 K2, K4, K5 상수의 값을 0으로 설정해서 load와 reliability를 제외한다.
=> EIGRP의 hello packet에는 패킷을 전송하는 해당 라우터들의 K 상수값들이 표시되며 네이버 사이에 이 값이 다르면 네이버를 맺이 않는다. (즉, 동일한 AS내의 모든 라우터들의 K 상수 값이 같아야 한다.)
=========================================================
EIGRP 정보 확인
- EIGRP를 설정한 라우터에서 'show ip protocols' 명령어로 구동중인 프로토콜의 여러 정보를 확인할 수 있다. (지금은 EIGRP)
- Neighbor 테이블 확인 : show ip eigrp neighbor
=> EIGRP가 구성된 라우터들은 hello packet을 교환해서 인접 관계를 형성. 즉 네이버 관계가 시작되면서 네이버 테이블을 생성하고 인접 라우터들의 목록이 저장된다. EIGRP 네이버간 통신 상태를 관리하는 테이블
- Topology 테이블 확인 : show ip eigrp topology
=> 네이버들에게서 업데이트 된 모든 EIGRP 네트워크와 그 네트워크의 메트릭 정보를 저장하는 데이터 베이스. 토폴로지 테이블에는 현재의 라우터에서 목적지 네트워크까지의 메트릭 값과 넥스트 홉 라우터에서 목적지 네트워크까지의 메트릭 값이
모두 저장되어 있다.
이러한 정보로 토폴로지 테이블 안에서 Successor(최적 경로)와 Feasible Successor(후속 경로)를 선출하여 Dual 알고리즘을 사용해 빠른
수렴이 가능하게 한다.
ps. 서로 패킷을 보낸 후 네이버 관계를 맺게 되고 네이버 테이블에 등록되어야만 공유가 된다.
=========================================================
DUAL 알고리즘
- EIGRP는 DUAL 알고리즘을 사용하여 최적의 라우팅 경로를 계산한다. (빠른 수렴(fast convergence)이 가능하다.)
- FD(Feasible Distance)와 AD(Advertised Distance)라는 메트릭을 사용하여 Successor(최적 경로)와
Feasible Successor(후속 경로)를 선출한다.
1) FD(Feasible Distance) - 출발지 라우터에서 목적지 네트워크까지 계산한 EIGRP 메트릭 값 (최적 경로의 메트릭이다.)
2) AD(Advertised Distance) - 출발지의 Next-hop 라우터에서 목적지 네트워크까지 계산한 EIGRP 메트릭 값 (RD라고도 한다.)
3) Successor(최적 경로상의 next-hop 라우터) - FD값이 가장 낮은 경로상의 next-hop 라우터 (즉 최적 경로상의 넥스트 홉 라우터)
4) Feasible Successor(후속 경로상의 next-hop 라우터) - 최적 경로(Successor)가 동작하지 못할때 Query나 계산없이 바로 라우팅 테이블에 등록되는 경로.
목적지 네트워크까지 FD값이 가장 낮은 경로가 Successor(최적경로)로 선출되고 남아있는 경로 중
AD값이 FD값보다 작은 경우 Feasible Successor(후속 경로)로 선출된다.
(즉, Successor가 아닌 라우터 중 AD(RD) < FD라는 조건을 만족하는 next-hop 라우터)
===> EIGRP는 인접 라우터와 네이버 관계가 구성되면 자신의 토폴로지 테이블에 있는 최적 경로를 업데이트 패킷을 사용해서 네이버에게 전송,
수신받은 라우터는 정보가 자신이 기존에 가지고 있는 정보보다 더 좋거나 동일한 정보를 업데이트 받았을 경우 새로운 경로를 알려준
네이버를 Successor로 지정하고 새로운 경로를 다른 네이버에게 알린다.
기존의 정보보다 나쁜 라우팅 정보를 Successor가 아닌 네이버에게 받았을 경우에는 이를 무시하고, Successor에게 기존의 라우팅 정보보다
더 나쁜 정보를 수신했다면 Feasible Successor를 새로 Successor로 지정하고 새로운 경로를 다른 네이버들에게 알린다. Feasible Successor가
없을 경우에는 네이버에게 Query 패킷을 전송하고 reply 패킷의 정보를 계산해서 Successor와 Feasible Successor를 지정한다.
=========================================================
EIGRP 축약
- EIGRP는 디스턴스 벡터 라우팅 프로토콜의 속성을 가지고 있기 때문에 메이져 네트워크 경계에서 자동 축약을 한다.
RIP과 마찬가지로 'no auto-summary' 명령어로 자동 축약을 정지시킨다.
- 수동 축약은 축약된 네트워크를 전송하려는 자신의 인터페이스에 들어가서 설정한다.
<ex>
R1(config)#router eigrp <AS번호>
R1(config-router)#no auto-summary
R1(config-router)exit
R1(config)#interface serial 0/0
// 라우팅 정보를 광고하는 인터페이스에서 축약을 설정한다.
R1(config-if)#ip summary-address eigrp <AS번호> x.x.x.x y.y.y.y // 축약 설정
------- -------
1 2
=> 1 : 축약한 네트워크
2 : 축약한 네트워크의 서브넷마스크
=> 네트워크의 수동 축약 방법은 RIP의 수동 축약과 동일하다.
- EIGRP 축약 네트워크는 축약을 설정한 라우터에서만 AD값이 5가 된다.
축약 네트워크의 메트릭은 상세 네트워크의 메트릭 중 가장 낮은 것이 되고, 모든 상세 네트워크가 모두 다운되어야
축약 네트워크의 광고를 중지한다.
- 축약을 설정한 EIGRP 라우터는 라우팅 looping을 방지하기 위해서 라우팅 테이블에 축약 정보를 'Null 0'라는 게이트웨이로
지정해서 올린다. => 상세 경로가 없을 경우 null 0라는 쓰레기 통으로 폐기하여 looping을 방지한다
만약 축약된 여러 네트워크 중 하나의 상세 경로에 문제가 생기고, 그 라우터에 패킷을 전송한 라우터 방향으로 디폴트 루트가
설정되었을 경우 다시 전송한 라우터로 패킷을 돌려보내기 때문에 루핑이 발생한다.
하지만 Null 0가 있을 경우 다시 디폴트 루트로 전송하지 않고 경로가 없기 때문에 패킷을 폐기한다.
=========================================================
EIGRP 인증
- EIGRP는 MD5 방식을 사용하여 네이버간의 인증을 지원한다.
<설정> R1(config)#key chain <word> -> 본인이 단어를 정해서 쓴다.
//key chain 명령어와 이름을 써서 암호 설정 모드로 들어간다. (인증하는 인접 라우터간 key chain 이름은 서로 달라도 된다.)
R1(config-keychin)#key1
// key 명령어로 암호 번호 부여 (인증하는 인접 라우터간 서로 동일해야 한다.)
R1(config-keychain-key)#key-string <word>
// 암호를 정의한다. (인증하는 인접 라우터가 서로 동일해야 한다.)
R1(config-keychain-key)#exit
R1(config-keychain)#exit
R1(config)#interface serial 0/0
// 인증하는 인접라우터와 연결된 인터페이스에서 설정
R1(config)#ip authentication key-chain eigrp <AS번호> <word>
// 아까 정의했던 key-chain 이름 사용
R1(config)#ip authentication mode eigrp <AS번호> md5
// 인증방식을 지정. md5와 text 두가지 방식이 있는데 특별히 설정하지 않으면
=> 확인은 'show run' 명령어를 사용해서 설정 내용을 확인하고,
'show ip eigrp neighbor'명령어로 네이버 관계를 확인한다. (서로 같은 암호키와 암호를 사용하지 않으면 네이버를 맺지 않는다.)
'debug eigrp packet hello'명령어로 헬로 패킷을 디버깅해본다.
=========================================================
Unequal cost 부하 분산(Load balancing)
- IOS 버전에 따라 최대 6개 또는 16개까지 동일한 메트릭 값을 갖는 경로에 대해 부하 분산을 지원한다.
- EIGRP는 다른 라우팅 프로토콜에서 지원하지 않는 unequal cost 부하 분산도 지원한다.
- Feasible Successor를 통하는 경로이어야 한다. -> 즉, AD값이 FD값보다 작은 경로 (FD > AD)
(show ip eigrp topology로 보이는 것들은 모두 Feasible Successor를 통하는 경로들이다.)
- 부하 분산을 시키고자 하는 경로의 메트릭이 'FD(최적 경로의 메트릭) x variance'의 값보다 작아야 한다.
즉, FD2(부하 분산을 시키고자 하는 경로) < FD x variance
=> 최적 경로에 variance를 곱한 값이 부하 분산을 하고자 하는 경로보다 더 커야 한다.
- 출발지의 라우터에서 variance 값 설정
<설정> R1(config)#router eigrp <AS 번호>
R1(config-router)#variance 2 // vairance는 1 - 128 사이에서 위의 공식을 만족시키는 값을 입력한다.
- 설정한 다음 'clear ip eigrp neighbor'로 네이버 구성을 다시 하면 경로가 부하 분산되고 있는걸 확인할 수 있다.
- Feasible Successor를 통하는 경로가 없다면, 즉 FD > AD 조건을 만족시키지 못하면 unequal cost 부하 분산을 할 수가 없다.
때문에 variance 값을 변경하기 전에 먼저 메트릭 값을 조정하여 FD > AD 조건을 만족시킨다.
=> 인터페이스에서 직접 Bandwidth나 Delay 같은 벡터 메트릭을 조정한 후 variance 값을 변경한다.
- offset-list를 사용해서 직접 메트릭 값을 변경시킬 수도 있다.
=========================================================
SIA(Stuck In Active) 현상
- SIA란 query packet을 전송한 후 reply packet을 받지 못한 상태가 장시간 유지되는 것을 의미한다.
=> topology 테이블에서 query 패킷에 대한 reply 패킷을 전부 받아야 정상적으로 경로를 계산하고 passive상태가 되어 정상적인 라우팅이 가능한데 active 상태(reply패킷을 받지 못하면 active상태로 유지)로 유지되는 경우.
(토폴로지 테이블은 show ip eigrp topology 명령어로 확인)
기본적으로 EIGRP는 query packet을 전송한 후 reply packet을 전송한 후 3분간 기다리는데 기간안에 reply packet을 보내지 않는 라우터와 네이버 관계를 해제한다. (그 후 hello packet을 수신하면 다시 네이버를 맺는다.)
만약 저속 링크로 연결된 라우터가 query 패킷을 받고 reply패킷을 시간내에 전송하지 못하면 모든 라우터가 해당 reply 패킷을 기다린다. (reply 패킷을 받기 전까지 EIGRP 네트워크를 계산하지 못하기 때문에) 이런 상태가 지속되는 것을 SIA현상이라고 한다.
3분이 지나고 네이버를 해제한 후 다시 헬로 패킷을 교환해 네이버를 맺는 과정을 반복하면 전체 EIGRP 네트워크가 불안정해진다.
=> SIA는 대규모 네트워크일 경우 장애의 원인을 찾기가 힘들다.
<SIA 해결 방법>
1) SIA 타이머 조정
-> R1(config)#router eigrp <AS 넘버> R1(config-router)#timers active-time <제한 시간(분)> -> reply 패킷을 기다리는 시간을 변경한다. (디폴트 3분)2) 축약에 의한 SIA 방지
=> 하지만 다운된 네트워크에 대체 경로가 있을 경우 오히려 대체 경로가 새로운 라우팅 테이블에 저장되는 시간을 지연시켜 컨버젼스 시간을 길어지기 때문에 주의해야 한다.
3) 네트워크 차단을 통한 SIA 방지
4) 스텁 라우팅에 의한 SIA 방지
5) 재분배에 의한 SIA 방지
=========================================================
재분배
- 네트워크 규모가 커질 경우 여러 라우팅 프로토콜을 혼용하여 사용하는 경우가 존재한다.
이 때 서로 다른 라우팅 프로토콜을 사용하는 라우터들 간의 정보교환은 이루어지지 않는다. 따라서 이 경우에는 Redistributed를 사용해야만 서로 다른 라우팅 프로토콜 간에 정보를 교환할 수 있다.
Static
|
<->
|
RIP
|
Static
|
Eigrp
| |
Eigrp
|
RIP 등등
|
- 재분배는 단방향과 양방향 재분배가 있다.
단방향 : 한쪽 라우팅 프로토콜로만 재분배시키는 것, 다른 라우팅 프로토콜 쪽의 라우터에는 Static or default로 지정된다.
양방향 : 2개 이상의 라우팅 프로토콜을 상호간 재분배 하는 것, 양방향보다는
단방향이 안정적이다.
ex)
RIP에게 재분배 : router rip
redistributed [프로토콜] metric [1~15]
EIGRP 재분배 : router eigrp [as번호]
redistributed [프로토콜] metric [B/W] [DLY] [R] [load] [MTU]
1544 2000 255 1 1500
=> router eigrp 100
redistributed eigrp 200 metric 1544 2000 255 1 1500
network 1.1.12.2 0.0.0.0
network
OSPF 재분배 : router ospf [번호]
redistributed [프로토콜] subnet
댓글 없음:
댓글 쓰기