 |
||
백서
Cisco Catalyst 6500 시리즈 스위치의 고가용성
그림 1
Cisco Catalyst 6500 시리즈 WS-6503, WS-C6506, WS-C6509, WS-C6509-NEBS 및 WS-C6513
개요
Cisco Catalyst® 6500 시리즈 멀티레이어 스위치는 오늘날의 엔터프라이즈 및 서비스 제공업체 환경에서 강력한 네트워크 설계의 필수 컴포넌트가 되었습니다. 이처럼 중요한 역할을 수행하기 때문에 Cisco Catalyst 6500 시리즈는 안정적인 스위칭 플랫폼을 제공해야 하며 고성능과 지능형 네트워크 서비스를 지원해야 합니다. Cisco Catalyst 6500 시리즈의 고가용성은 수퍼바이저(supervisor) 엔진의 장애 복구 중에 IP 폰 호출을 유지보수할 수 있는 기능까지 지원합니다. 이 백서에서는 Cisco Catalyst 6500 시리즈가 하드웨어 및 소프트웨어 리던던시 기능을 통해 높은 시스템 가용성을 제공하는 방식을 다루며 특히 다음 세 가지 영역을 중점적으로 설명합니다.
- SFM(Switch Fabric Module)의 패브릭 리던던시
- 상태 보존형(stateful) 프로토콜 리던던시 및 이미지 버저닝 기능을 포함한 고가용성 기능과 Cisco Catalyst OS를 이용한 수퍼바이저(Supervisor) 엔진 리던던시
- MSFC(Multilayer Switch Feature Card) Cisco IOS® 소프트웨어 리던던시 기능 - DRM(Dual Router Mode), config-sync 및 SRM(Single Router Mode)
이 백서는 Cisco IOS 소프트웨어 모델(native Cisco IOS 소프트웨어)이 아니라 Cisco Catalyst 6500 시리즈용 하이브리드 소프트웨어 모델(수퍼바이저 엔진에는 Cisco Catalyst OS를 사용하고 MSFC에서는 Cisco IOS 소프트웨어 사용)을 기초로 하여 작성되었습니다. 모든 기능 세트의 참조 내용은 수퍼바이저 엔진의 Cisco Catalyst OS 기능과 MSFC의 Cisco IOS 소프트웨어 기능으로 설명됩니다. Cisco Catalyst OS 고가용성 기능은 Cisco Catalyst OS 5.4 릴리즈에서 처음 소개되었으며, Cisco Catalyst Supervisor Engine 1A와 Catalyst Supervisor Engine 2에서 모두 사용할 수 있습니다. DRM은 Cisco IOS 소프트웨어 릴리즈 12.0(7)XE1부터 지원되었습니다. DRM에 대한 MSFC config-sync 리던던시 기능은 MSFC 및 MSFC2용 Cisco IOS 소프트웨어 릴리즈 12.1(3a)E4에서 모두 지원됩니다. MSFC SRM 기능은 Cisco Catalyst OS 6.3.1 및 MSFC2용 Cisco IOS 소프트웨어 릴리즈 12.1(8)E2에서 처음으로 지원되었습니다.
이 백서는 두 번째 버전이며, 초본은 2000년 9월에 작성되었습니다. 이 버전에는 SRM에 대한 보다 정확한 이해와 논의가 추가된 업데이트 단원이 포함되어 있습니다.
컴포넌트 수준의 리던던시도 매우 중요하기는 하지만, 고가용성 네트워크 설계는 각 시스템 리던던시와 총체적 네트워크 리던던시를 적절하게 조합함으로써 달성할 수 있습니다. 고가용성 네트워크 설계에 대한 자세한 내용을 보려면 아래 링크를 클릭하여 Gigabit Campus Design 백서를 참조하십시오.
SFM(Switch Fabric Module) 리던던시
처음 발표되었을 때부터 Cisco Catalyst 6500 시리즈는 모든 패킷에 대해 시스템 전체의 데이터 경로를 제공하는 단일 32Gbps 버스 스위칭 아키텍처를 바탕으로 구현되었습니다. Cisco Catalyst 6500 시리즈에는 256Gbps 크로스바 스위칭 패브릭(고대역폭 용량을 위한 SFM과 30Mpps 이상의 포워딩 성능)이 포함되어 있습니다. SFM은 Cisco Catalyst 6506 및 Cisco Catalyst 6509 섀시에서 지원됩니다. SFM2는 본질적으로 동일한 패브릭이지만 모든 Cisco Catalyst 6506, 6509 및 6513에서 작동하도록 설계되었습니다.
스위칭 패브릭 장애 복구
SFM은 시스템에 하드웨어 리던던시 단계를 하나 더 추가합니다. 패브릭 방식 라인 카드의 단일 패브릭 채널 버전은 스위칭 패브릭과 기존 시스템 버스 백플레인에 대한 연결을 모두 제공합니다. 덕분에 Cisco Catalyst 6500 시리즈는 SFM을 패브릭 방식 라인 카드 간의 기본 데이터 경로로 사용할 수 있습니다. SFM에 장애가 발생할 경우, 시스템은 32Gbps 버스로 복구하여 패킷 스위칭을 계속합니다. 비록 버스 용량은 15Mpps의 처리 속도와 32Gbps 대역폭으로 제한되지만 네트워크를 계속 온라인 상태로 유지할 수 있습니다. 이 외에도 Cisco Catalyst 6500 시리즈는 3단계의 패브릭 리던던시를 제공하는 듀얼 SFM(Catalyst 6506이나 Catalyst 6509의 슬롯 5와 슬롯 6 또는 Catalyst 6513의 슬롯 7과 슬롯 8)으로 구성할 수 있습니다. 이 구성에서 기본 패브릭 모듈에 장애가 발생하면 30Mpps의 처리 속도를 계속 유지하기 위해 보조 패브릭 모듈로 전환(switchover)됩니다. 패브릭 모듈에 추가 장애가 발생할 경우 시스템 버스로 다시 전환될 수도 있습니다.
스위칭 패브릭 작동 방식
섀시에서 SFM, 패브릭 방식 라인 카드 및 섀시 라인 카드를 어떻게 조합하느냐에 따라 내부 스위칭 작동 방식이 달라지며, 궁극적으로 장애 복구 특징에 영향을 주게 됩니다. 패브릭-투-패브릭 또는 패브릭-투-버스 장애 복구 시나리오를 검토할 때 이 점을 이해하는 것이 중요합니다. SFM을 장착한 시스템에 패브릭 방식 라인 카드만 설치되어 있는 경우 이 스위칭 작동 방식을 compact 모드라고 합니다. 이 작동 방식에서는 버스를 통해 32바이트 컴팩트 헤더(전체 패킷이 아님)를 수퍼바이저 엔진으로 보내 각각의 포워딩을 결정합니다. 이렇게 하면 효율성이 향상되므로 기본 시스템 성능을 30Mpps까지 증대시킬 수 있습니다. 패브릭 방식 카드의 데이터 경로는 SFM을 사용합니다.
SFM 시스템에 클래식 라인 카드가 설치되어 있을 경우에는 버스의 헤더 포맷이 시스템의 모든 라인 카드와 호환되어야 합니다. 클래식 라인 카드가 compact 모드를 지원하지 않으므로 패브릭 방식 라인 카드는 스위칭 모드를 truncated 모드로 변경합니다. 패브릭 방식 라인 카드는 truncated 모드를 사용함으로써 클래식 라인 카드가 이해할 수 있는 64바이트 헤더 전용 포맷으로 패킷을 보낼 수 있습니다. truncated 모드에서도 SFM이 패브릭 방식 라인 카드 간의 데이터 경로로 사용된다는 것에 주의할 필요가 있습니다. 클래식 및 패브릭 카드 시스템에서 중앙 집중식 최대 포워딩 성능은 15Mpps에 불과하지만, 스위치 패브릭을 사용하여 보다 높은 대역폭을 시스템에 제공할 수 있습니다. SFM을 지원하지 않는 시스템에 설치되어 있을 경우 패브릭 방식 라인 카드는 클래식 카드가 있더라도 flow-through 모드로 작동합니다. 이 모드에서 라인 카드는 클래식 모드로 작동하도록 프로그래밍되므로 시스템 버스를 통해 전체 패킷을 전송하여 각각의 포워딩을 결정합니다. flow-through 모드의 시스템은 15Mpps의 스위칭 처리 속도를 제공하고 데이터 경로는 32Gbps 버스를 사용합니다.
설치된 하드웨어에 따라 스위칭 모드는 자동으로 변경됩니다. 일반적인 작동일 경우, SFM에서 특정 구성을 수행할 필요가 없습니다. 스위치 패브릭 모듈의 현재 스위칭 모드는 Catalyst OS 명령줄 인터페이스(CLI)에서 show fabric channel switchmode 명령을 사용하여 모니터할 수 있습니다. 예제 1에서는 완벽한 패브릭 방식 시스템(완전 compact 모드)을, 예제 2에서는 SFM 시스템의 클래식 라인 카드 및 패브릭 방식 라인 카드(flow-through 모드 및 truncated 모드)를 보여 줍니다.
예제 1: 패브릭 방식 시스템
아래는 듀얼 수퍼바이저 엔진과 SFM 1개를 사용하고 슬롯 3에 패브릭 방식 라인 카드를 구성한 경우의 출력 결과입니다.
Sup2-A> (enable) show fabric channel switchmode
Module Num Fab Chan Fab Chan Switch Mode Channel Status ------ ------------ -------- ------------ -------------- 1 1 0, 0 compact ok 2 1 0, 1 compact ok 3 1 0, 2 compact ok 5 18 0, 0 n/a ok 5 18 1, 1 n/a ok 5 18 2, 2 n/a ok 5 18 3, 3 n/a unknown 5 18 4, 4 n/a unknown 5 18 5, 5 n/a unknown 5 18 6, 6 n/a unknown 5 18 7, 7 n/a unknown 5 18 8, 8 n/a unknown 5 18 9, 9 n/a unknown 5 18 10, 10 n/a unknown 5 18 11, 11 n/a unknown 5 18 12, 12 n/a unknown 5 18 13, 13 n/a unknown 5 18 14, 14 n/a unknown 5 18 15, 15 n/a unknown 5 18 16, 16 n/a unknown 5 18 17, 17 n/a unknown 15 0 n/a n/a n/a 16 0 n/a n/a n/a
show fabric channel switchmode 명령에 대한 CLI 출력 내용을 간단히 설명하면 다음과 같습니다.
Num Fab Chan—해당 모듈이 연결되어 있는 패브릭 채널 수
Fab Chan—첫 번째 숫자는 해당 모듈이 연결되어 있는 패브릭 채널 번호를 나타내고, 두 번째 숫자는 SFM이 연결되어 있는 패브릭 채널 번호를 나타냅니다.
Switch mode—"flow through", "truncated" 또는 "compact"가 출력될 수 있습니다. 스위치 모드는 패브릭 및 버스 연결을 사용하는 라인 카드에만 적용됩니다.
Channel status—"ok", "sync error", "CRC error", "heartbeat error", "buffer error", "timeout error" 또는 "unknown"이 출력될 수 있습니다. 채널 상태는 패브릭 및 버스 연결을 사용하는 라인 카드에만 적용됩니다.
예제 2: 클래식 및 패브릭 방식 시스템
아래는 듀얼 수퍼바이저 엔진과 SFM 1개를 사용하고 슬롯 3에 클래식 라인 카드 1개를, 슬롯 7과 슬롯 9에 패브릭 방식 라인 카드 2개를 구성한 경우의 출력 결과입니다.
Sup-A> (enable) show fabric channel switchmode
Module Num Fab Chan Fab Chan Switch Mode Channel Status
------ ------------ -------- ------------ --------------
1 1 0, 0 flow through ok
2 1 0, 1 truncated ok
3 0 n/a n/a n/a
5 18 0, 0 n/a ok
5 18 1, 1 n/a ok
5 18 2, 2 n/a unknown
5 18 3, 3 n/a unknown
5 18 4, 4 n/a unknown
5 18 5, 5 n/a unknown
5 18 6, 6 n/a ok
5 18 7, 7 n/a unknown
5 18 8, 8 n/a ok
5 18 9, 9 n/a unknown
5 18 10, 10 n/a unknown
5 18 11, 11 n/a unknown
5 18 12, 12 n/a unknown
5 18 13, 13 n/a unknown
5 18 14, 14 n/a unknown
5 18 15, 15 n/a unknown
5 18 16, 16 n/a unknown
5 18 17, 17 n/a unknown
7 1 0, 6 truncated ok
9 1 0, 8 truncated ok
15 0 n/a n/a n/a
16 0 n/a n/a n/a
자동 스위칭 모드 변경이 가능하므로 수동으로 구성을 변경하지 않아도 클래식 또는 패브릭 방식 카드를 시스템에 설치할 수 있습니다. 앞에서 설명했듯이, 클래식 라인 카드를 패브릭 방식 시스템에 설치할 경우 성능과 호환성 간에 타협이 이루어집니다. 성능을 더 중시하는 네트워크 환경이 많기 때문에 패브릭 방식 시스템에서 클래식 카드를 거부하도록, 즉 flow-through 모드를 지원하지 않도록 구성할 수 있습니다. set system crossbar-fallback none 명령을 실행하면 섀시에 설치된 클래식 라인 카드가 시동되지 않으므로 compact 스위칭 모드(30Mpps)로만 실행됩니다.
Sup-A> (enable) set system crossbar-fallback none
crossbar-fallback의 기본값은 버스 모드입니다. 현재 시스템 상태를 확인하려면 show system crossbar-fallback 명령을 사용합니다.
Sup-A> (enable) show system crossbar-fallback Cross-fallback: bus-mode
요컨대 SFM은 패브릭-투-패브릭 및 패브릭-투-버스 장애 복구를 제공하도록 섀시에 리던던시로 구성할 수 있습니다. 듀얼 SFM으로 구성된 시스템은 장애 복구를 위해 대기 SFM을 사용할 수 있습니다. 또한 패브릭 방식 라인 카드가 설치된 단일 SFM 시스템은 32Gbps 버스로 복구되어 계속 작동할 수 있습니다. 두 시나리오에서 모두 3초 이내에 시스템이 정상 작동으로 복구됩니다. 이처럼 복구 시간이 빠르기 때문에 두 시나리오에서 각 라인 카드, 수퍼바이저 엔진 및 SFM 패브릭 채널 간에 스위칭 모드 변경과 동기화 프로세스가 가능합니다. 리던던시형 SFM을 구성할 수 있는 기능은 최대 3단계의 백플레인 리던던시를 제공하므로 하드웨어 장애가 발생할 경우 네트워크 가용성에 미치는 영향을 최소화하여 계속 작동할 수 있도록 도와줍니다.
리던던시형 수퍼바이저 엔진
앞에서 설명했듯이, Cisco Catalyst 6500 시리즈의 고가용성 기능은 리던던시형 수퍼바이저 엔진 간에 저영향의 상태 보존형 전환(stateful switchover)을 제공합니다. 이 기능은 Cisco Catalyst OS Software 버전 5.4에서 처음 소개되었습니다.
수퍼바이저 엔진 전환(Switchover)
듀얼 수퍼바이저 엔진은 Cisco Catalyst 6500 시리즈의 지능형 포워딩 기능에 대해 하드웨어 리던던시를 제공합니다. Cisco Catalyst 6500 시리즈는 슬롯 1과 슬롯 2에서만 최대 2개의 수퍼바이저 엔진을 지원할 수 있습니다. 하나는 활성(active) 수퍼바이저 엔진이고 다른 하나는 대기(standby) 수퍼바이저 엔진입니다. 활성 수퍼바이저 엔진이 먼저 온라인으로 연결됩니다. 활성 수퍼바이저 엔진은 수퍼바이저 엔진에 나타나는 "Active" LED를 통해 확인하거나 콘솔에서 show module 명령을 입력하여 확인할 수 있습니다. 두 수퍼바이저 엔진은 모두 동일한 하드웨어 모델이어야 합니다. 즉 슬롯 1의 Supervisor Engine 1A에 PFC(Policy Feature Card)와 MSFC가 있으면 슬롯 2의 Supervisor Engine 1A에도 PFC와 MSFC가 있어야 합니다. 또는 슬롯 1에 Supervisor Engine 2가 있으면 슬롯 2에도 Supervisor Engine 2가 있어야 합니다. Supervisor Engine 1A와 Supervisor Engine 2는 Cisco Catalyst 6000 및 6500 시리즈에서 사용할 수 있습니다. 활성 수퍼바이저가 오프라인 상태이거나 장애가 발생하면 대기 수퍼바이저가 시스템을 제어합니다.
리던던시형 수퍼바이저 구성에서는 두 수퍼바이저 엔진이 각각 다른 역할을 수행합니다. 활성 수퍼바이저 엔진은 시스템 버스와 모든 라인 카드를 제어합니다. 모든 프로토콜은 활성 수퍼바이저 엔진에서 실행되고, 모든 패킷 포워딩도 여기서 수행됩니다. 대기 수퍼바이저 엔진은 라인 카드와 통신하지 않습니다. 대기 수퍼바이저 엔진은 네트워크에서 패킷을 받아서 이 정보로 포워딩 테이블을 채우지만 어떠한 패킷 포워딩에도 관여하지 않습니다. 시스템의 해당 프로토콜은 활성 수퍼바이저 엔진이 아니라 대기 수퍼바이저 엔진에서 초기화됩니다. Cisco Catalyst 6500 시리즈 수퍼바이저 엔진은 핫 스왑이 가능하므로 네트워크 작동에 영향을 주지 않고 활성 시스템에 대기 수퍼바이저 엔진을 설치할 수 있습니다. 리던던시형 수퍼바이저 엔진에서 로드를 공유하지 않는다는 것에도 주의할 필요가 있습니다. 활성 수퍼바이저 엔진은 시스템 전체에 대한 지능형 패킷 포워딩을 제공합니다(N+1 리던던시). 활성 수퍼바이저 엔진에 장애가 발생하면 대기 수퍼바이저 엔진이 동일한 시스템 로드를 유지관리할 수 있습니다.
대기 수퍼바이저 엔진은 5-10밀리초마다 EOBC(Ethernet Out-of-Band Channel)를 통해 활성 수퍼바이저 엔진을 폴링하여 활성 수퍼바이저 엔진의 온라인 상태를 모니터링합니다. 활성 수퍼바이저 엔진은 하드웨어 장애, 시스템 과부하 및 메모리 충돌이 발생하거나 섀시에서 엔진을 제거하거나 운영자가 엔진을 리셋하는 등의 다양한 이유로 오프라인 상태가 될 수 있습니다. 대기 수퍼바이저 엔진은 이러한 유형의 장애를 탐지하여 새로운 활성 수퍼바이저 엔진이 됩니다. 수퍼바이저 엔진의 Cisco Catalyst OS 소프트웨어는 프로토콜, 라인 카드 및 포워딩 엔진이 정상 작동하도록 복구하고 이 복구 작업은 빠른 전환(Fast Switchover)이나 고가용성 전환을 통해 수행됩니다.
수퍼바이저의 빠른 전환(Fast Switchover) 기능
Cisco Catalyst OS 고가용성 기능은 기본적으로 사용되지 않으므로 그 대체 방법으로 빠른 전환(Fast Switchover) 기능이 사용됩니다. 빠른 전환 기능은 고가용성 기능의 이전 기능이므로 고가용성이 비활성화되거나 해당 소프트웨어 버전에서 지원되지 않을 때 대신 적용되는 수퍼바이저 전환 메커니즘입니다. 이 기능은 수퍼바이저에 장애가 발생할 경우 일반적으로 수행되는 일부 이벤트를 건너뛰어 전환 시간을 단축시킵니다. 특히 빠른 전환 메커니즘을 사용하면 각 라인 카드가 시스템 재초기화 과정의 일부인 해당 소프트웨어 다운로드와 진단 부분을 건너뛸 수 있습니다. 하지만 Layer 2 이상의 모든 프로토콜을 다시 시작하고 모든 포트를 재설정하는 동작은 전환 과정에서 그대로 수행됩니다. 따라서 기본 설정을 사용할 경우 전환 성능에는 약 28초에 프로토콜 재시작 시간을 더한 시간이 소요됩니다. 예를 들어 STP(Spanning-Tree Protocol)에 대해 기본 시간값을 사용하는 스위치는 빠른 전환 후 약 58초만에 다시 트래픽 포워딩을 시작했습니다. 하지만 빠른 전환 후 트래픽 포워딩을 다시 시작할 때까지의 시간은 기본 설정에서 스위치를 튜닝함으로써 단축시킬 수 있습니다. Portfast를 사용하고 포트 채널(PagP)을 비활성화하고 워크스테이션이 직접 연결되어 있는 포트에 대해 트렁킹 기능을 해제하면 빠른 전환 시간을 약 10초로 단축시킬 수 있습니다. 라이브 네트워크 환경에서 이러한 전환 시간은 네트워크
작동에 중요한 방해 요소가 됩니다.
수퍼바이저의 고가용성 기능
Cisco Catalyst OS의 고가용성 소프트웨어 기능은 Cisco Catalyst 6500 시리즈의 하드웨어 리던던시를 향상시키는 동시에 프로토콜 리던던시를 제공합니다. 이 기능에는 상태 보존형(stateful) 프로토콜 리던던시와 이미지 버저닝이 포함되어 있습니다. 이 기능을 작동시키려면 CLI에서 고가용성 기능을 실행해야 합니다.
Sup-A> (enable) set system highavailability enable System high availability enabled.
리던던시형 수퍼바이저 구성에서는 정상 작동을 위해 고가용성 기능을 사용하는 것이 좋습니다.
수퍼바이저의 상태 보존형(Stateful) 프로토콜 리던던시
상태 보존형(stateful) 수퍼바이저 전환이란 활성 수퍼바이저로부터 대기 수퍼바이저로의 전환 시간이 3초 미만인 것을 말합니다. 이렇게 다운타임을 단축하려면 활성 및 대기 수퍼바이저 엔진 간의 Layer 2, Layer 3 및 Layer 4 프로토콜1의 대부분을 동기화해야 하며, 이를 프로토콜 상태 유지관리라고 합니다.
듀얼 수퍼바이저 엔진 간의 상태 보존형(stateful) 프로토콜 리던던시를 위해 각 수퍼바이저 엔진에는 고가용성 지원이 필요한 모든 프로토콜과 기능을 관리하는 프로토콜 상태 데이터베이스가 있습니다. 이 프로토콜은 대부분 활성 수퍼바이저 엔진에서만 실행됩니다. 고가용성 전환을 수행할 경우, 새로운 활성 수퍼바이저 엔진은 초기화 상태가 아니라 업데이트된 데이터베이스 상태로부터 프로토콜을 시작할 수 있습니다. 이와 같이 리던던시 시스템은 활성 수퍼바이저 엔진이 오프라인 상태가 될 때 상태 보존형(stateful) 프로토콜 리던던시를 유지관리하고 네트워크 다운타임을 최소화할 수 있습니다.
- 고가용성 지원 기능 - 완전히 지원되면 고가용성이 됩니다. 프로토콜 데이터베이스의 활성 및 대기 수퍼바이저 엔진에서 기능 상태가 동일하게 유지됩니다.
- 고가용성 호환 기능 - 이들 기능에 대한 고가용성은 지원되지 않습니다. 이 기능에 대한 프로토콜 데이터베이스가 수퍼바이저 엔진 간에 동기화되지 않습니다. 고가용성 기능을 사용할 경우 이 기능도 사용할 수 있습니다. 예를 들어 GMRP(GARP Multicast Registration Protocol) 및 고가용성이 모두 사용되고 고가용성 수퍼바이저 엔진에서 장애 복구를 수행할 경우 GMRP 프로토콜은 초기화 상태부터 다시 시작됩니다(상태 비보존형[non-stateful]). 호환 기능을 사용할 경우에도 지원 기능에 대한 상태 보존형(stateful) 프로토콜 리던던시는 그대로 적용됩니다.
- 고가용성 비호환 기능 - 고가용성이 지원되지 않습니다. 이 기능에 대한 프로토콜 데이터베이스가 수퍼바이저 엔진 간에 동기화되지 않습니다. 고가용성 기능을 사용할 경우 이 기능을 사용해서는 안 됩니다. 잘못된 동작을 일으킬 수 있기 때문에 이들 기능은 고가용성을 사용할 경우 지원되지 않습니다.
중요: 고가용성 시스템이 필요하면 이 기능을 사용하지 마십시오.
표 1은 Cisco Catalyst OS 버전 7.5를 기준으로 고가용성 지원, 호환 및 비호환 기능과 프로토콜을 보여줍니다.
표 1: 고가용성 기능 지원
| 지원 기능 | 호환 기능 | 비호환 기능 |
|---|---|---|
| COPS-DR 및 COPS-DR |
ASLB |
동적 VLAN |
| Dynamic Trunk Protocol |
Cisco Discovery Protocol |
Generic VLAN Registration Protocol (GVRP) |
| CEF(Cisco Express Forwarding) 및 인접 테이블 |
GMRP |
프로토콜 필터링 |
| 사설 VLAN |
IGMP(Internet Group Management Protocol) 스누핑 |
|
| 라우터 ACL(Access Control List) |
Remote Monitoring (RMON) |
|
| 멀티레이어 스위칭(MLS) |
Resource Reservation Protocol (RSVP) |
|
| Port Aggregation Protocol/Link Aggregation Protocol (PAgP/LACP) |
Simple Network Management Protocol (SNMP) |
|
| QoS ACL 및 폴리서(policer) |
텔넷 세션 |
|
| Switched Port Analyzer (SPAN) |
VTP 제거 |
|
| STP |
Uplinkfast |
|
| 트렁킹 |
|
|
| UDLD(UniDirectional Link Detection) 프로토콜 |
|
|
| VLAN ACLs |
|
|
| VLAN Trunking Protocol (VTP) |
|
|
| 포트 보안 |
|
|
| 802.1X |
|
|
현재 고가용성 기능에서 지원되는 기능 목록은 Cisco Catalyst 6500 Series Software User Guide의 "Configuring Redundancy" 장과 릴리즈 노트를 참조하십시오.
대부분의 Layer 3 및 Layer 4 프로토콜이나 기능은 수퍼바이저 엔진에 내장되어 있는 PFC 또는 PFC2의 ASIC(Application-Specific Integrated Circuit)에 프로그래밍되어 있습니다. 이러한 기능에는 액세스 목록(라우터 기반 및 VLAN 기반), 포워딩 테이블(멀티레이어 스위칭 캐시 및 CEF 테이블), QoS 설정 등이 있습니다. 프로토콜은 프로토콜 데이터베이스에서 유지관리되며, 수퍼바이저 엔진에서 장애 복구가 수행될 경우 하드웨어에서 계속 스위칭됩니다. 일부 프로토콜은 듀얼 MSFC 구성에 의존하기도 합니다. 이 내용은 이 백서의 뒷부분에서 설명합니다.
아래의 그림 2에서 설명하는 프로토콜 상태 데이터베이스는 최신 프로토콜 상태 정보의 리포지토리입니다. 이 리포지토리는 활성 수퍼바이저에 의해 생성되고 대기 수퍼바이저에 의해 저장됩니다. 데이터베이스에는 모듈과 포트 상태, VLAN 정보, 비휘발성 RAM(NVRAM) 구성, 다양한 프로토콜별 데이터 등 특정 시스템 정보가 포함됩니다. 두 수퍼바이저 엔진은 이 데이터의 전송을 위해 동기화 작업을 실행합니다. 데이터베이스 항목이 활성 수퍼바이저 엔진에서 업데이트되면, 이 업데이트는 동기화 작업에 의해 FIFO(First-In, First-Out) 대기열에 놓이게 됩니다. 이 대기열은 정기적으로 비워져서 대기 수퍼바이저로 전송되도록 예약되어 있습니다. 전송은 백그라운드 프로세스이므로, 시스템에서 실행 중인 다른 활성 프로세스의 수에 따라 업데이트 간격이 달라집니다. 업데이트 간격은 1초에서 5초 사이이며 대략적인 평균 시간은 2초입니다. 대기 수퍼바이저 엔진의 동기화 프로세스는 이러한 비동기 업데이트를 수신하여 대기 수퍼바이저 엔진에 있는 프로토콜 상태 데이터베이스에 입력합니다. 시스템이 시작되거나 보조 수퍼바이저 엔진이 핫 인서트(hot-insert)되면 프로토콜 데이터베이스 간에 글로벌 동기화가 수행되어 모든 프로토콜 상태를 최신 정보로 업데이트합니다.
그림 2
상태 보존형(Stateful) 프로토콜 데이터베이스 설명
상태 보존형(stateful) 프로토콜 기능을 요약하자면, 고가용성 전환 성능은 구성의 복잡성보다 동기화 프로시저 상태에 더 많은 영향을 받습니다. 시스템과 프로토콜이 안정적인 운영 상태에 도달하면 각 수퍼바이저 엔진의 프로토콜 상태 데이터베이스는 대기열에 있는 업데이트에 따라 상당히 비슷한 상태를 갖게 됩니다. 전환 성능의 결정 요인은 아직 완료되지 않은 대기열의 업데이트 수입니다. 따라서 고가용성 수퍼바이저 엔진의 전환 성능은 3초 미만입니다.
수퍼바이저 엔진 소프트웨어 이미지 업그레이드
리던던시형 수퍼바이저 엔진 구성에서 시스템의 고가용성을 보장하려면 Cisco Catalyst OS 이미지를 올바르게 관리해야 합니다. 다음 단원에서는 Cisco Catalyst OS 이미지 관리에 필요한 몇 가지 옵션에 대해 설명합니다.
수퍼바이저 엔진 이미지 동기화
Cisco Catalyst 6500 시리즈에서는 기본적으로 활성 및 대기 수퍼바이저 엔진의 Cisco Catalyst OS 소프트웨어 이미지가 동일해야 합니다. 이 때문에 시스템은 새로운 활성 수퍼바이저 엔진에서 이전의 활성 수퍼바이저 엔진과 동일한 소프트웨어 기능과 개정 버전을 사용하여 수퍼바이저 엔진 전환이 수행되도록 함으로써 안정적인 운영 환경을 유지할 수 있습니다. 시스템 부팅 중에 두 이미지의 버전이 같지 않으면 활성 수퍼바이저 엔진은 현재 부트 이미지를 대기 수퍼바이저 엔진으로 다운로드합니다. 활성 수퍼바이저 엔진의 NVRAM 구성도 수퍼바이저 엔진 간에 동기화됩니다.
Cisco Catalyst OS의 이미지 동기화 기능은 수퍼바이저 엔진 간에 소프트웨어 일관성을 제공하지만, 장기간 동안 시스템을 오프라인 상태로 만들지 않고 소프트웨어 업그레이드를 수행할 수는 없습니다. 업그레이드를 수행하려면 활성 수퍼바이저 엔진을 리셋하여 새 소프트웨어 버전을 로드해야 합니다. 그러면 활성 수퍼바이저 엔진이 새 소프트웨어 이미지를 대기 수퍼바이저 엔진과 동기화합니다. 전체 시스템을 웜 부팅해야 하기 때문에 일반적으로 이 과정은 예약된 다운타임이나 시스템 점검 기간 동안 수행되어야 합니다. 또한 MSFC의 Cisco IOS 소프트웨어는 이 동기화 프로세스에 포함되지 않습니다.
수퍼바이저 엔진 버저닝 기능
버저닝은 Cisco Catalyst OS 고가용성 기능의 두 번째 부분이며, 듀얼 수퍼바이저 엔진 구성에서 고가용성 기능의 사용 여부에 따라 결정됩니다. 따라서 서로 다르지만 호환되는 이미지를 활성 및 대기 수퍼바이저 엔진에서 실행할 수 있으며, 이로 인해 수퍼바이저 이미지 동기화 기본 프로세스가 비활성화됩니다. 이 기능을 응용하면 고가용성 기능의 수퍼바이저 전환을 사용하여 실시간으로 소프트웨어를 업그레이드할 수 있습니다. 이렇게 함으로써 장치를 재부팅하지 않고 Cisco Catalyst OS 소프트웨어를 업그레이드할 수 있을 뿐만 아니라, 소프트웨어 업그레이드가 실패할 경우 폴백(fallback) 계획의 일환으로 대기 수퍼바이저 엔진에서 이전에 사용하고 테스트한 Cisco Catalyst OS 버전을 유지관리할 수 있습니다. 두 수퍼바이저 엔진은 이미지 버전을 제한 없이 실행할 수 있으므로 Catalyst OS 이미지를 업그레이드하거나 다운그레이드할 수도 있습니다.
서로 다른 두 가지 이미지 버전을 실행하면 시스템은 이미지 버전이 호환되는지 확인합니다. 활성 및 대기 수퍼바이저 엔진은 두 소프트웨어 이미지가 호환되는지 확인하기 위해 이미지 버전 정보를 교환합니다. 이미지 버전은 호환, 비호환 또는 업그레이드 가능 중 하나로 정의됩니다. 호환 버전은 서로 다른 이미지 간에 상태 보존형(stateful) 프로토콜 리던던시를 지원할 수 있음을 의미합니다. 활성 수퍼바이저 엔진의 NVRAM에 설정한 모든 구성 내용은 대기 수퍼바이저로 전송될 수 있습니다. Cisco Catalyst OS의 두 버전 간에 프로토콜 상태 데이터베이스를 동기화할 수 없으면 두 버전은 서로 호환되지 않습니다. 두 소프트웨어 이미지가 호환되지 않으면 소프트웨어 업그레이드 프로세스는 시스템 작동에 영향을 주게 되고(즉 고가용성 전환 시간이 1-3초보다 더 길어짐), NVRAM 구성 변경 내용이 두 수퍼바이저 엔진 간에 동기화되지 않습니다. 비호환 버전의 특수한 경우가 업그레이드 가능입니다. 이 시나리오에서도 고가용성 수퍼바이저 전환은 수행할 수 없지만 활성 수퍼바이저 엔진의 NVRAM에 대한 구성 변경 내용을 대기 수퍼바이저 엔진과 동기화할 수 있습니다. 이것은 서로 다른 두 소프트웨어 버전을 동기화된 구성으로 실행할 수 있지만 장애 복구 기능이 없다는 점 때문에 특별한 경우가 됩니다.
Cisco Catalyst OS 소프트웨어 이미지가 호환되지 않으면 고가용성 전환은 수행할 수 없습니다. show system highavailability 명령으로 출력된 운영 상태를 모니터하면 Cisco Catalyst OS 이미지 2개의 고가용성 호환성을 확인할 수 있습니다. 운영 상태는 ON 또는 OFF로 표시되며 일부 시스템 특정 상태 메시지가 함께 표시됩니다. 아래 출력 내용은 고가용성이 사용되며 Cisco Catalyst OS 버전이 고가용성과 호환됨을 보여줍니다(Op-status: ON).
Sup-A> (enable) show system highavailability Highavailability: enabled Highavailability versioning: disabled Highavailability Operational-status: ON
일반적으로 고가용성 버저닝은 Cisco Catalyst OS 소프트웨어를 업그레이드할 때에만 사용하는 것이 좋습니다. 정상적인 작동 상태일 경우 일반적인 이미지 동기화 프로세스(고가용성 버저닝 사용 안 함)를 구현해야 합니다. 일반적으로 고가용성 호환 이미지는 Cisco Catalyst OS 소프트웨어의 유지보수 릴리즈 간에만 사용할 수 있습니다. 유지보수 릴리즈는 버전 5.5.1에서 버전 5.5.2로의 업그레이드와 같이 기능 업그레이드와 버그 수정이 점증적으로 이루어지는 새 소프트웨어 버전입니다. 정식 릴리즈는 고가용성 호환 기능을 지원하지 않습니다. 다음 URL의 릴리즈 노트에는 고가용성 호환성 목록이 포함되어 있습니다.
Cisco Catalyst OS 이미지 업그레이드 절차
위에서 설명한 내용에 따라 고가용성 기능을 사용하여 최소 다운타임으로 소프트웨어를 업그레이드하는 데에는 다음과 같은 절차가 권장됩니다. 이미지 간의 고가용성 호환성은 이 절차를 수행하는 동안 결정됩니다. MSFC도 이 절차에 의해 영향을 받지만 MSFC에 대해서는 "MSFC 고가용성 기능" 단원에서 설명합니다.
이 예제에서는 슬롯 1의 수퍼바이저 엔진(Sup-A)이 활성 모드로 시작되고 슬롯 2의 수퍼바이저 엔진(Sup-B)이 대기 모드로 시작됩니다. 이 절차와 관련하여 두 수퍼바이저에서 모두 콘솔 연결을 사용할 수 있는 것이 좋습니다.
Sup-A> (enable) set system highavailability disable
이 기능은 기본적으로 사용되지 않습니다.
Sup-A> (enable) copy slot0:cat6000-sup2k8.7-2-2.bin bootflash:cat6000-sup2k8.7-2-2.bin
Sup-A> (enable) dir bootflash:
Sup-A> (enable) clear boot system all
Sup-A> (enable) set boot system flash bootflash:cat6000-sup2k8.7-2-2.bin
약 120초 후에 활성 수퍼바이저 엔진에서 부트 항목으로 설정된 이미지가 대기 수퍼바이저 엔진의 부트 플래시에 복사됩니다(이미지 동기화). 이것은 Cisco Catalyst OS 이미지 파일의 내부 TFTP이며 완료하는 데 몇 분이 걸립니다. 이미지 파일은 파일명의 시작 부분에 BTSYNC가 추가되어 활성 수퍼바이저 엔진의 부트타임 이미지로부터 동기화되었음을 나타냅니다.
Sup-A> (enable) dir 2/bootflash: Sup-A> (enable) show boot 2
이제 새 Cisco Catalyst OS 이미지가 두 수퍼바이저 엔진에 모두 놓여 있습니다.
Sup-A> (enable) set system highavailability enable Sup-A> (enable) set system highavailability versioning enable
새 소프트웨어를 실행하는 대기 수퍼바이저 엔진이 활성 상태가 되기 전에 버저닝을 활성화해야 합니다. 이렇게 하면 대기 수퍼바이저 엔진이 대기 모드를 유지하면서 새로운 Cisco Catalyst OS 버전으로 재부팅될 수 있습니다.
Sup-A> (enable) set boot system flash bootflash:cat6000-sup2k8.old.bin
주: 버저닝을 사용하면 부트 변수를 설정해도 이미지 동기화가 수행되지 않습니다.
Sup-A> (enable) reset 2
대기 수퍼바이저 엔진은 새 Cisco Catalyst OS 이미지로 재부팅되어 그대로 대기 모드를 유지하며 활성 수퍼바이저의 작동에 영향을 주지 않습니다.
Sup-A> (enable) show module
대기 수퍼바이저 엔진이 새 소프트웨어 버전을 표시해야 하고, 이 버전은 활성 수퍼바이저 엔진의 버전과 달라야 합니다.
Sup-A> (enable) show system highavailability
고가용성 전환을 수행하려면 고가용성 기능의 작동 상태가 ON이어야 합니다. 그렇지 않으면 시스템은 빠른 전환(상태 비보존형[non-stateful])으로 업그레이드되므로 프로토콜을 다시 시작해야 합니다.
Sup-A> (enable) reset 1
이제 대기 수퍼바이저 엔진이 새 소프트웨어를 실행하는 활성 수퍼바이저 엔진으로 바뀌고 이전의 활성 수퍼바이저 엔진은 재부팅되어 대기 모드로 작동합니다. 이 장애 복구(failover)는 장치를 통과하는 약간의 트래픽을 혼란시킵니다. 고가용성 전환을 수행하는지 또는 빠른 전환을 수행하는지에 따라 영향을 받는 트래픽 양이 결정됩니다.
14. 시스템이 예상한 대로 작동하면 대기 수퍼바이저 엔진(이제 Sup-A)의 부트 구성을 업데이트해야 합니다. 이렇게 하려면 새 활성 수퍼바이저 엔진에서 버저닝을 비활성화하여 이미지 동기화 기능이 자동으로 활성화되게 합니다.
Sup-B> (enable) set system highavailability versioning disable Sup-B> (enable) reset 1
이제 수퍼바이저 엔진의 Cisco Catalyst OS 소프트웨어 업그레이드 절차가 완료되었습니다.
MSFC 고가용성 기능
MSFC 라우팅 엔진은 수퍼바이저 엔진의 선택적 보조 카드(daughter card)이며, 두 가지 버전인 MSFC 및 MSFC2로 사용할 수 있습니다(구성 요건은 MSFC 데이터시트 참조). 또한 리던던시형 수퍼바이저 하드웨어 구성에는 리던던시형 MSFC 라우팅 엔진이 포함될 수 있습니다. 따라서 MSFC가 올바로 작동하려면 수퍼바이저 엔진이 올바로 작동해야 합니다. 수퍼바이저 엔진을 리셋하거나 장애를 복구하면 MSFC 라우팅 엔진도 리셋됩니다.
Cisco Catalyst OS 고가용성 기능은 리던던시형 수퍼바이저 엔진 간에 프로토콜 상태를 유지관리하지만 듀얼 MSFC는 DRM 및 SRM 리던던시 모드로 작동합니다. MSFC 리던던시 모드를 실행할 경우 Cisco Catalyst OS 고가용성 기능을 사용하는 것이 좋습니다.
DRM(Dual Router Mode)
DRM은 리던던시형 수퍼바이저 엔진의 원래 MSFC 구성이거나 MSFC 구성입니다. 이 모드에서는 두 MSFC가 모두 네트워크의 활성 라우터가 됩니다. 단일 섀시에 2개의 활성 MSFC가 있다고 해서 2개의 라우터가 별도로 있는 것은 아닙니다. 실제로 두 MSFC는 거의 동일한 구성을 가져야 하며, 이에 대해서는 아래에서 보다 자세히 설명합니다. DRM의 기본 개념은 각각의 MSFC가 정확한 구도의 Layer 3 네트워크를 독립적으로 구축한다는 것입니다.
DRM 작동 방식
DRM에서 MSFC 간의 장애 복구 메커니즘은 HSRP(Hot Standby Routing Protocol)입니다. HSRP는 두 MSFC가 내부 통신을 유지하도록 돕고 MSFC 장애 복구에도 영향을 미칩니다. HSRP는 첫 번째 홉(hop) 기본 게이트웨이 리던던시가 필요한 각각의 VLAN에 대해 두 MSFC에서 모두 구성되어야 합니다. MSFC 간의 내부 HSRP는 라우팅 엔진 간에 헬로우(hello) 메시지를 전송함으로써 물리적으로 떨어진 장치 간의 HSRP와 동일한 방식으로 작동합니다.
두 MSFC에 모두 각각의 라우팅 테이블이 있기 때문에 하나의 MSFC에 장애가 발생하더라도 라우팅 프로토콜을 통합할 필요가 없습니다. DRM으로 구성되고 HSRP 타이머를 바탕으로 할 경우 LAN 인터페이스에 대한 MSFC 장애 복구를 3초 내에 구성할 수 있으므로 수퍼바이저 엔진의 장애 복구 시간에 맞춰 MSFC의 Layer 3 장애 복구를 수행할 수 있습니다.
다른 MSFC의 기능을 수행해야 할 경우도 있으므로 두 MSFC는 서로 동일한 구성을 유지할 필요가 있습니다. DRM에서는 특히 이 점에 주의해야 합니다. 두 MSFC에서 인터페이스, 액세스 목록, 정책 라우팅 등의 구성 파라미터를 똑같게 구성해야 합니다. IP 주소와 HSRP 설정 등 네트워크에서 복제할 수 없는 파라미터만 각각의 MSFC에서 다르게 구성할 수 있습니다.
MSFC는 PFCx에서 ASIC 하드웨어의 특정 기능을 프로그래밍합니다. 처음 온라인 상태가 되는 MSFC는 지정(designated) 라우터가 되고 두 번째 MSFC는 비지정(nondesignated) 라우터가 됩니다. Supervisor Engine 1A 시스템에서 지정 라우터와 비지정 라우터는 모두 Layer 3 항목을 PFC Netflow 라우팅 기능 테이블에 프로그래밍할 수 있습니다. Supervisor Engine 2 시스템에서는 지정 라우터만 Layer 3 항목을 PFC2 CEF(Cisco Express Forwarding) 테이블에 프로그래밍합니다. Supervisor Engine 1A 및 Supervisor Engine 2에서 모든 라우터 ACL과 멀티캐스트 바로가기는 지정 라우터에서 프로그래밍됩니다. 두 MSFC는 반드시 서로 동일한 구성을 가져야 합니다. DRM의 MSFC 구성이 서로 다르면 포워딩 ASIC가 잘못 프로그래밍되어 예상치 못한 동작이 발생합니다.
MSFC 구성 동기화
MSFC Cisco IOS 소프트웨어 릴리즈 12.1(3a)E4에서 처음 소개되었으며 config-sync라고도 불리는 MSFC 리던던시 기능으로 MSFC 및 MSFC2에 대한 리던던시형 MSFC 구성 프로세스를 간소화할 수 있게 되었습니다. 이 기능을 사용하여 두 MSFC의 구성을 간소화하고 구성이 서로 일치하도록 보장할 수 있습니다. 지정(기본) MSFC와 비지정(보조) MSFC 간의 시작 및 실행 구성이 동기화됩니다. 특히 지정 MSFC에서 write memory 또는 copy startup-config 명령을 실행하면 두 MSFC의 NVRAM에 있는 시작 구성이 업데이트됩니다. 이렇게 함으로써 지정 MSFC와 비지정 MSFC의 구성은 각 명령을 수동으로 두 번 입력하지 않아도 동일한 구성을 유지할 수 있습니다.
다음 명령은 MSFC config-sync를 활성화합니다.
MSFC-Sup-15 (config)# redundancy MSFC-Sup-15 (config-r)# high-availability MSFC-Sup-15 (config-r-ha)# config-sync
config-sync를 사용할 경우 지정 MSFC의 CLI를 통해 지정 MSFC와 비지정 MSFC의 모든 구성을 설정할 수 있습니다. 비지정 MSFC 구성은 alt 키워드를 사용합니다. config-sync를 사용할 경우 이 키워드를 사용해야만 비지정 MSFC를 구성할 수 있습니다. 예를 들면 다음과 같습니다.
MSFC-Sup-15 (config-if)# ip address a.b.c.1 x.x.x.0 alt ip address a.b.c.2 x.x.x.0 MSFC-Sup-15 (config-if)# standby 10 priority 100 alt standby 10 priority 50
명령 구문은 바뀌지 않습니다. alt 키워드 앞에 오는 명령 부분은 슬롯 1의 MSFC에 적용되고, alt 키워드 뒤에 오는 명령 부분은 슬롯 2의 MSFC에 적용됩니다. config-sync 기능은 일반적인 IP 또는 IPX 구성에 대해서만 지원됩니다. Appletalk, DECnet 등에 대한 구성 파라미터에는 해당 alt 키워드 옵션이 없습니다.
DRM의 WAN 인터페이스
DRM에서 WAN 모듈의 OSM(Optical Service Module) 또는 FlexWAN 인터페이스는 지정 MSFC에 의해서만 관리됩니다. config-sync 기능을 사용하기 전에는 비지정 MSFC 구성에 WAN 인터페이스가 표시되지 않으므로 비지정 MSFC에서 구성할 수 없습니다. 수퍼바이저 엔진 또는 MSFC 장애 복구 중에 새로운 지정 MSFC가 되는 MSFC에는 WAN 인터페이스가 올바로 구성되지 않습니다. 이 때문에 WAN 모듈이 설치되어 있을 경우 config-sync 기능이 없는 리던던시형 수퍼바이저 또는 MSFC 구성은 지원되지 않았습니다. MSFC config-sync 기능을 사용하면 이러한 제한이 제거되고 리던던시형 수퍼바이저 구성에서 WAN 모듈이 지원됩니다. config-sync를 사용할 경우, 고가용성 전환 중에 WAN 모듈이 리셋되지 않아야 합니다.
DRM의 문제점
DRM은 MSFC 리던던시를 위한 최초의 옵션이었습니다. 이 솔루션은 MSFC 간에 상태 보존형(stateful) Layer 3 장애 복구를 가능하게 함으로써 큰 성공을 거두었지만 네트워크 설계와 관리가 복잡해지는 문제가 있습니다. 예를 들어 다음 세 가지 시나리오에서 DRM은 Layer 3 리던던시를 위한 최상의 솔루션을 제공하지 못합니다.
- 각각의 MSFC에 VLAN 인터페이스에 대한 고유 IP 주소가 있어야 합니다. DRM과 듀얼 섀시를 사용하는 분배 또는 코어 구현에서 이러한 요구 사항을 충족시키려면 VLAN당 최대 5개의 라우터 IP 주소를 할당해야 합니다(라우터 주소 4개와 HSRP 주소 1개). 또한 라우팅 프로토콜 인접 장치의 수도 증가하므로 라우터의 CPU 사용량이 증대될 수 있습니다. 이 경우 4개의 라우터에 주소를 지정하고 관리하는 작업은 리던던시를 추가함으로써 얻을 수 있는 이점보다 더 큰 문제가 됩니다.
- 여러 개의 MSFC가 동일한 이더넷 세그먼트에 연결되어 있는 리던던시형 구성에서 하나의 MSFC만 멀티캐스트 트래픽을 소스에서 발신 인터페이스의 수신기로 포워딩합니다. PIM-DF(Protocol Independent Multicast Designated Forwarder)는 공통 VLAN의 데이터를 포워딩하지만 비-PIM-DF는 포워딩된 멀티캐스트 트래픽도 수신합니다. 이 트래픽은 잘못된 인터페이스에 도착하여 RPF(Reverse Path Forwarding) 검사를 통과하지 못하기 때문에 리던던시형 MSFC(비-PIM-DF)는 이 트래픽을 폐기해야 합니다. RPF 검사를 통과하지 못한 트래픽을 비-RPF 트래픽이라고 합니다. 일반적으로 라우터는 비-RPF 트래픽을 효율적으로 처리하지 못합니다. DRM으로 구성될 경우 각각의 VLAN에는 이러한 비-RPF 트래픽을 수신하는 라우터(다른 MSFC)가 하나 이상 있습니다.
- 두 MSFC에서 구성 파라미터를 정확하게 설정해야 한다는 요건은 많은 고객에게 복잡한 문제가 되었습니다. Cisco IOS 구성 파일의 크기가 클 경우 모든 구성 파라미터를 똑같게 설정하기란 쉬운 작업이 아닙니다. 이 프로세스를 간소화하기 위해 config-sync와 같은 향상된 기능이 개발되었지만 확장할 수는 없습니다.
이상과 같은 시나리오에서는 SRM을 사용할 수 있습니다.
SRM(Single Router Mode)
SRM은 섀시에 활성 라우터가 하나뿐인 시스템에 리던던시형 수퍼바이저 엔진 또는 MSFC를 구현하려는 고객을 위한 옵션으로 제공됩니다. SRM은 수퍼바이저 엔진에서 Cisco Catalyst OS의 Layer 2 및 Layer 4 리던던시를 사용할 수 있는 동시에 Layer 3 리던던시를 효율적으로 사용할 수 있습니다. 최소 소프트웨어 요건은 Cisco Catalyst OS 6.3.1 및 MSFC용 Cisco IOS 소프트웨어 릴리즈 12.1(8)E2입니다.
SRM은 DRM이 개선된 것이며 특히 SRM은 다음과 같은 기능을 제공합니다.
- IP 주소 지정 및 라우팅 프로토콜 인접 장치 관계에 대한 Layer 3의 복잡성이 줄어듭니다.
- 2개의 활성 멀티캐스트 라우터가 같은 세그먼트에 있을 때 발생하는 비-RPF 트래픽 문제가 해결됩니다(SRM으로 구성된 섀시에는 활성 라우터가 하나뿐임).
- 단일 CLI에서 1개의 명령 집합만 입력하면 활성 라우터에 적용되기 때문에 구성이 더 간단합니다. 따라서 두 MSFC의 구성을 일치시켜야 하는 수고를 덜 수 있습니다.
MSFC-Sup-15 (config)# redundancy MSFC-Sup-15 (config-r)# high-availability MSFC-Sup-15 (config-r-ha)# single-router-mode
SRM 작동 방식
이 모드에서는 항상 지정 라우터만 네트워크에 표시됩니다. 비지정 라우터도 시작되며 지정 라우터와 똑같은 구성을 유지합니다(SRM이 활성 상태가 되면 자동으로 구성이 동기화됨). 하지만 비지정 라우터의 인터페이스는 라인 다운(line-down) 상태를 유지하며 네트워크에 표시되지 않습니다. 비지정 라우터에서 라우팅 프로토콜 프로세스도 생성되지만, 모든 인터페이스가 다운 상태이기 때문에 이 프로세스는 업데이트를 보내거나 네트워크에서 업데이트를 받지 않습니다. 이것은 다음 Cisco Catalyst OS 명령줄에서 확인할 수 있습니다. 슬롯 2의 수퍼바이저 엔진과 MSFC가 standby 상태로 표시되는 것에 주의하십시오.
SRM> (enable) show module Mod Slot Ports Module-Type Model Sub Status --- ---- ----- ------------------------- ------------------- --- -------- 1 1 2 1000BaseX Supervisor WS-X6K-SUP2-2GE yes ok 15 1 1 Multilayer Switch Feature WS-F6K-MSFC2 no ok 2 2 2 1000BaseX Supervisor WS-X6K-SUP2-2GE yes standby 16 2 1 Multilayer Switch Feature WS-F6K-MSFC2 no standby
SRM 구성에서 지정 라우터에 장애가 발생하면 다른 MSFC의 상태가 비지정 라우터에서 지정 라우터로 변경됩니다. 새로운 지정 라우터는 인터페이스 상태를 업링크(link up)로 변경하고 라우팅 테이블을 구축하기 시작합니다. 제어 평면의 장애 복구 시간은 라우팅 프로토콜 구성 및 복잡성에 비례해서 늘어납니다. 하지만 PFCx에는 하드웨어 경로에 있는 라우팅된 트래픽을 포워딩하는 데 사용되는 Layer 3 포워딩 항목이 있습니다. Catalyst OS의 고가용성 기능은 장애 복구 후에 이 포워딩 정보를 유지관리하는 데 사용됩니다. 이렇게 함으로써 Layer 3 제어 평면이 통합되는 동안 Layer 3 데이터 평면 트래픽에 미치는 영향을 최소화할 수 있습니다. MSFC에서 라우팅 테이블이 구축되면 PFCx의 항목을 업데이트할 수 있습니다.
Cisco Catalyst OS 버전 12.1(11b)E부터 시작하여 수퍼바이저 엔진 2/PFC2에서 SRM을 실행하기 위한 전환 타이머(transition timer) 기능이 제공됩니다. 이 타이머는 새로운 지정 라우터가 새 하드웨어 CEF 항목을 PFC2로 다운로드하기 전에 대기할 시간을 구성합니다. 라우팅 통합 시간의 차이로 인해 PFC2 하드웨어를 프로그래밍하기 전에 120초의 기본값 내에 통합을 완료하지 못할 수도 있습니다.
MSFC가 지정 라우터인지 여부에 관계없이 지정 라우터에 대해 동일한 IP 및 MAC(Media Access Control) 주소가 사용됩니다. 지정 라우터로 선택된 MSFC는 기본 MAC 주소를 비지정 라우터인 MSFC로 전달할 것입니다. 비지정 라우터에서 이후에 만들어진 모든 인터페이스는 사용자가 명시적으로 다른 MAC 주소를 구성하지 않는 한 이 MAC 주소를 사용합니다.
부팅할 때 두 MSFC는 약 1분 정도가 걸리는 "핸드셰이크" 프로세스를 수행한 후 SRM 모드를 시작합니다.
중요: 핸드셰이크 프로세스 중에 비지정 라우터에서 구성을 변경하지 마십시오.
다음 명령을 사용하여 SRM이 활성화되었는지 확인할 수 있습니다.
SRM# show redundancy Designated Router: 1 Non-designated Router: 2 Redundancy Status: designated Config Sync AdminStatus : enabled Config Sync RuntimeStatus: enabled Single Router Mode AdminStatus : enabled Single Router Mode RuntimeStatus: enabled Single Router Mode transition timer : 120 seconds
SRM 구성에 대한 자세한 내용을 보려면 아래 링크를 클릭하여 Cisco Catalyst OS Configuration Guide의 "MSFC Redundancy-Single Router Mode Redundancy" 절을 참조하십시오.
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_6_3/confg_gd/redund.htm
SRM의 WAN 인터페이스
SRM의 기본 기능으로서 MSFC 구성이 동기화되기 때문에 리던던시형 수퍼바이저 엔진 또는 SRM용으로 구성된 MSFC에서 모든 OSM 및 FlexWAN WAN 모듈이 지원됩니다. DRM에서와 마찬가지로 지정 라우터가 WAN 인터페이스를 관리합니다. 인터페이스는 지정 라우터에서만 구성되어 이 구성이 비지정 라우터에 동기화됩니다. 장애 복구 시나리오의 경우 새 지정 라우터는 MSFC가 지정 라우터가 되면 즉시 WAN 인터페이스를 소유합니다. 또한 고가용성 전환 시 WAN 모듈이 다시 로드되지 않아야 합니다. SRM을 사용할 경우 WAN 인터페이스를 수동으로 구성하지 않아도 MSFC 장애 복구를 지원할 수 있습니다.
SRM 구성 및 변환 절차
Catalyst 6000 Family Configuration Guide에서 SRM 구성, DRM을 SRM으로 변환, SRM을 사용하여 소프트웨어 업그레이드 수행 등에 대한 절차를 설명합니다.
SRM 및 IP 멀티캐스트
SRM을 사용할 경우 비지정 라우터의 VLAN 인터페이스는 다운(down) 상태가 됩니다. 장애 복구 후에도 VLAN 인터페이스는 VLAN에 포워딩 상태의 연결된 물리적 인터페이스가 1개 이상 있다는 것을 수퍼바이저 엔진이 확인할 때까지 작동(up) 상태로 전환하지 않습니다. 이러한 작동 중단으로 인해 수퍼바이저 엔진이 PFCx의 모든 멀티캐스트 항목을 삭제하게 되면서 멀티캐스트 포워딩은 혼란에 빠지게 됩니다. 원래의 SRM 구현을 향상시킨 Cisco Catalyst OS 릴리즈 7.1에서는 IP 멀티캐스트 상태 보존형(stateful) 리던던시를 지원합니다. Cisco Catalyst OS 버전 7.1에서 SRM을 사용하면 장애 복구 동안 멀티캐스트 흐름을 보존할 수 있습니다.
수퍼바이저 및 MSFC 장애 복구 테스트
테스트 환경은 샘플 고가용성 전환 시나리오를 시연하고 해당 장애 복구 시간을 기록할 수 있도록 구성되었습니다. 테스트 설치 구성에는 Cisco Catalyst 6509 섀시 하나에 Cisco Catalyst OS 버전 7.2.2를 실행하는 듀얼 수퍼바이저 엔진 2 라인 카드 또는 Cisco IOS Software 릴리즈 12.1(11b)E4를 실행하는 MSFC2 하드웨어가 장착되었습니다. 또한 기본적인 테스트로만 제한하여 쉽게 시연할 수 있도록 했습니다. 테스트 메커니즘은 스위치에 직접 연결되어 있는 2개의 엔드 장치 간에 ping을 수행하는 것이었습니다. 모든 시나리오에 사용되는 포트에 대해 스패닝 트리(Spanning-Tree)를 활성화했습니다. 스위치 수퍼바이저 엔진을 리셋하여 테스트를 초기화했습니다. 각 시나리오는 8번 테스트하여 결과에 대한 평균을 내었습니다.
Layer 2 장애 복구
동일한 VLAN 내에서 2개의 엔드 스테이션 간의 Layer 2 트래픽인 경우, 장애 복구로 인해 한두 개의 ping 시간 초과(약 1-2초의 장애 복구 시간)가 발생했습니다.
주: 이 테스트는 MSFC가 없는 수퍼바이저 엔진에서도 수행할 수 있습니다.
Layer 3 장애 복구
Layer 3 트래픽의 경우 DRM을 먼저 구성한 후 이어서 SRM을 구성한 단일 Cisco Catalyst 6500 시리즈의 수퍼바이저 또는 MSFC 장애 복구를 측정하기 위한 일반 테스트 환경을 만들었습니다. 각각의 VLAN에 2개의 ping 장치를 배치했습니다. 기본 소프트웨어 구성에는 Cisco Catalyst OS의 고가용성 기능을 사용한 다음 MSFC2에서 Cisco IOS 소프트웨어의 DRM 또는 SRM 리던던시를 사용했습니다. 전체 구성은 아래에 설명되어 있습니다.
SRM
hostname SRM ! redundancy high-availability single-router-mode ! interface Vlan20 ip address 10.20.1.3 255.255.255.0 no ip redirects ! interface Vlan30 ip address 10.30.1.3 255.255.255.0 no ip redirects ! end
hostname DRM ! redundancy high-availability config-sync ! interface Vlan20 ip address 10.20.1.3 255.255.255.0 alt ip address 10.20.1.2 255.255.255.0 standby ip 10.30.1.4 standby priority 100 alt standby priority 50 no ip redirects ! interface Vlan30 ip address 10.30.1.3 255.255.255.0 alt ip address 10.30.1.2 255.255.255.0 standby ip 10.30.1.4 standby priority 100 alt standby priority 50 no ip redirects ! end
DRM의 경우 평균 장애 복구 시간은 2.56초로 측정되었으며 SRM의 경우에는 평균 장애 복구 시간이 2.31초로 측정되었습니다. DRM과 SRM 모두 하드웨어 포워딩 테이블에서 Layer 3 포워딩 항목을 유지관리한다는 것을 명심하십시오(Cisco Catalyst OS 고가용성 기능). 차이점은 DRM이 섀시에 2개의 활성 라우터를 사용하는 반면 SRM은 1개의 라우터만 사용한다는 것입니다. 따라서 SRM은 DRM과 달리 소프트웨어에서 라우팅 테이블을 다시 계산해야 하지만, 둘 모두 Layer 3 트래픽의 장애 복구 시간에 직접 영향을 주지는 않습니다.
두 번째 테스트는 두 워크스테이션에 각각 FTP(File Transfer Protocol) 클라이언트와 FTP 서버를 실행하여 실시했습니다. 정상 작동 중에 Layer 3에서 스위치를 통해 10MB 파일을 전송하는 데 걸린 시간은 평균 16초였습니다. 동일한 FTP 세션에서 수퍼바이저 전환이 수행될 경우 전송 시간은 평균 18초입니다. 전환 중에 FTP 전송 시간의 차이는 2초에 불과합니다. 이 예제는 실제 TCP 애플리케이션을 시연하기 위해 사용됩니다.
Cisco Catalyst 6500 시리즈에 연결된 IP 폰을 사용한 세 번째 테스트는 로컬 IP 폰과 원격 IP 폰 간에 IP 전화를 거는 것이었습니다. Cisco Catalyst OS 고가용성 기능을 사용하여 수퍼바이저 엔진 전환이 초기화되었습니다. IP 폰 통화는 전환 중에도 그대로 유지되었으며 통화 참가자는 거의 불편을 느끼지 못했습니다. 이 테스트는 네트워크의 모든 레이어에서 고가용성을 제공하는 Cisco Catalyst 6500의 기능을 현실적으로 보여주는 예제입니다.
일반적으로 대부분의 실제 시나리오를 충족시키기 위해 Layer 2 및 Layer 3 상태 보존형(stateful) 수퍼바이저 엔진 전환은 3초 이내에 수행될 것입니다.
리던던시형 전원 공급장치
현재 Cisco Catalyst 6500 시리즈는 1000W(6슬롯 섀시 전용), 1300W, 2500W 또는 4000W로 전원 공급장치를 구성할 수 있습니다. 아울러 전원 리던던시 기능을 사용하여 소프트웨어를 통해 전원 구성을 보다 자세히 지정할 수도 있습니다. 전원 리던던시(또는 로드 공유) 기능은 기본적으로 사용됩니다. 2개의 전원 공급장치가 설치되어 있고 전원 리던던시를 사용할 경우 두 전원 공급장치에서 출력된 총 전원은 전원 공급장치 1개의 용량을 넘지 않습니다. 하지만 한 전원 공급장치에 장애가 발생하면 다른 전원 공급장치가 이 로드를 넘겨 받아 전체 시스템에 계속 전원을 공급할 수 있습니다. 전원 리던던시를 사용하지 않으면 시스템은 두 전원 공급장치의 출력이 더해진 총 전원을 사용할 수 있습니다. 이 구성에서는 한 전원 공급장치에 장애가 발생할 경우 시스템이 모든 모듈에 충분한 전원을 공급하지 못할 수도 있습니다. 전원 리던던시를 활성화 또는 비활성화하려면 다음 명령을 사용합니다.
Sup-A> (enable) set power redundancy enable | disable
라인 카드마다 전원 요구 사항이 다르므로 각 섀시에 대한 전원 요구 사항도 달라집니다. Catalyst 6000 Series Switch Installation Guide에는 각 라인 카드의 전원 요구 사항에 대한 이해를 돕기 위해 Cisco Catalyst 6500 시리즈의 전원 요구 사항이 수록되어 있습니다. 이러한 요구 사항에 대한 자세한 내용은 아래 웹 사이트를 참조하십시오.
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/6000hw/inst_aug/02prep.htm
결론
Cisco Catalyst 6500 시리즈의 고가용성 및 리던던시 기능은 매우 안정적인 스위칭 및 라우팅 플랫폼을 제공합니다. 듀얼 수퍼바이저 엔진, 듀얼 라우팅 엔진, 듀얼 스위칭 패브릭 및 듀얼 전원 공급장치가 제공하는 하드웨어 리던던시를 통해 네트워크의 잠재적 다운타임을 줄일 수 있습니다. Cisco Catalyst OS의 고가용성 기능 및 MSFC 장애 복구용 DRM 또는 SRM 옵션과 같은 소프트웨어 리던던시는 하드웨어 리던던시를 바탕으로 하여 안정적인 운영 환경을 구현합니다. 시스템 성능 및 지능형 네트워크 서비스와 이러한 기능을 결합함으로써 Cisco Catalyst 6500 시리즈는 업계에서 그 어떤 제품보다 우수한 솔루션을 제공합니다.
1Layer 4 프로토콜은 확장 IP 액세스 목록에 Layer 4 정보를 포함합니다.
2PFC가 플로(flow) 기반의 포워딩 아키텍처를 사용하고 모든 새 플로는 처음부터 MSFCx 소프트웨어 경로로 전송되기 때문에 supervisor1a/PFC/MFSCx에는 이 기능이 적용되지 않습니다.
<업데이트: 2003년 04월 02일>