SONET 트리거

다운로드 옵션

PDF (207.6 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (101.2 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (188.8 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2005년 7월 21일

문서 ID:62622

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

트리거는 IOS의 SONET(Synchronous Optical Network) 인터페이스에서 원인 및 영향 관계에서 원인의 역할을 수행하는 이벤트입니다. pos delay triggers 명령을 사용할 수도 있습니다. 다른 경우에는 pos delay triggers 명령을 사용하지 않는 것이 좋습니다. 특히 엄격한 SLA(Service Level Agreements)를 충족하려고 할 때 그렇습니다. 서비스 공급업체는 특정 계약에 따라 차별화된 수준의 서비스를 판매합니다. 이 계약은 네트워크에서 고객 트래픽을 내부적으로 라우팅, 보호 또는 우선 순위를 지정하는 방법을 다룹니다. 이러한 명령은 제공자가 서비스 계약을 충족하도록 네트워크를 조정하는 데 도움이 됩니다.

이 문서에서는 인터페이스 up 및 down 이벤트와 관련된 트리거를 살펴봅니다. 이 문서에서는 POS(Packet Over SONET)를 구축하는 방법에 대해 설명하고 레이어 3에서 SLA 및 컨버전스 시간을 고려합니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.

POS 인터페이스를 종료하는 이벤트

이 섹션에서는 POS 인터페이스를 종료하는 이벤트에 대해 설명하고 관련 명령을 나열합니다.

섹션 및 라인 레벨 트리거

이 섹션의 트리거 목록은 GR-253-CORE SONET(Synchronous Optical Network) 전송 시스템을 가리킵니다. 공통 일반 기준 사양:

SLOS(Section Loss of Signal) - 사양은 2.5us 이상 100us(6.2.1.1.1) 이하의 탐지를 해야 함을 나타냅니다.
SLOF(Section Loss of Frame) - 사양은 최소 3ms(또는 24개의 연속 오류 프레이밍 패턴)(6.2.1.1.2)에서 탐지해야 함을 나타냅니다.
Alarm Indication Signal - Line (AIS-L)(경보 표시 신호 - 회선(AIS-L)) - 125usec 이내에 적절한 경우 AIS-L을 전송해야 합니다. 디바이스에서 K2의 비트 6, 7 및 8이 111(6.2.1.2.1)으로 설정된 5개의 연속 프레임을 발견하면 디바이스가 AIS-L 수신을 탐지해야 합니다.
Signal Destruction Bit Error Rate (SD-BER)(신호 성능 저하 비트 오류율(SD-BER)) - SD-BER는 APS(Automatic Protection Switching)가 있는 인터페이스에서만 트리거됩니다(B2 BER 계산에 연결).
SF-BER(Signal Failure Bit Error Rate) - SF-BER는 APS 및 비 APS 인터페이스 모두에 대한 트리거입니다(B2 BER 계산에 연결).
RDI-L(Remote Defect Indication - Line (RDI-L) - RDI-L은 POS 또는 APS에 대한 트리거가 아닙니다. 그러나 RDI-L은 MPLS FRR에 대한 트리거입니다(섹션 5.3.3.1).

이 목록에 언급된 섹션에 대한 자세한 내용은 Telcordia Information SuperStore 웹 사이트를 참조하십시오.

경로 트리거

이러한 특정 PATH 레벨 결함은 인터페이스에서 pos 지연 트리거 경로를 활성화한 경우에만 상태 변경을 시작합니다.

AIS-P - 이 결함은 AIS-P를 발생시키는 결함을 발견한 후 125usec 이내에 제기해야 합니다. STS 경로에 대한 H1 및 H2 바이트가 연속된 3개의 프레임에 대해 모든 1을 포함할 경우 PTE(Path Terminating Equipment)는 이 결함을 탐지해야 합니다. 연결된 경로는 첫 번째 H1 및 H2 바이트만 관찰해야 합니다. 자세한 내용은 R6-175 및 R6-176의 6.2.1.2.2 섹션을 참조하십시오.
RDI-P - RDI-P가 있는 경우 10프레임 이내에 결함이 탐지되어야 합니다. R6-221의 6.2.1.3.2을 참조하십시오.
B3에 대한 B3-TCA(Threshold Crossing Alarms) - 이 경보는 B3 BIP(Binync) IP(Binary Synchronous Communications) 계산에 연결됩니다.
LOP-P(Path Loss of Pointer)(IOS 버전에 CSCdx58021이 포함된 경우) - GR-253의 6.2.1.1.3 섹션을 참조하십시오.

이 목록에 언급된 섹션에 대한 자세한 내용은 Telcordia Information SuperStore 웹 사이트를 참조하십시오.

POS 트리거 CLI 동작 요약

이 표에는 POS 트리거 조건 및 관련 결과가 나열되어 있습니다.

조건	결과
POS 트리거와 명시적으로 관련된 어떤 것도 구성하지 않은 경우	라인 레벨 트리거가 즉시 처리됩니다.
pos delay triggers line 명령을 구성한 경우,	라인 레벨 트리거는 100ms의 지연 후에 처리됩니다.
pos delay를 구성한 경우 line x 명령을 트리거합니다.	라인 레벨 트리거는 xmsecs 후에 처리됩니다. 여기서 x는 0~511 사이입니다.
경로 트리거와 명시적으로 관련된 항목을 구성하지 않은 경우	경로 트리거는 처리되지 않으며 작업을 수행하지 않습니다.
pos delay triggers path 명령을 구성한 경우,	경로 수준 트리거는 100ms의 지연 후에 처리됩니다.
pos delay triggers path x 명령을 구성한 경우	경로 레벨 트리거는 xmsecs 후에 처리됩니다. 여기서 x는 0~511 사이입니다.

SONET 경보 디베이션

결함으로 인한 SONET 경보는 결함이 제거된 후 10초(10.5 +-.5) 동안 유지됩니다.

결함 처리

IOS에서 POS 카드는 두 가지 일반적인 결함 처리 방법을 통해 서로 다른 트리거로 인해 LINE 상태를 변경합니다. 이는 인터페이스의 특정 컨피그레이션(APS 또는 비 APS)에 따라 달라지지만 일반적으로 두 가지 유형의 실패가 있습니다.

관리
관리되지 않음

이 문서에서 사용하는 경보 처리와 관련된 용어를 이해해야 합니다.

결함 - 하드웨어가 인식하는 실패 조건입니다.
Failure(실패) - 필요한 최대 2.5초 동안 흠뻑 적었던 후 SONET-4-ALARM 메시지를 통해 보고된 결함. 방아쇠인 결함은 물에 담기지 않는다.
관리되지 않는 실패 - LOS, LOF 등의 이벤트 SONET 프레임에서 정의된 매개 변수 집합으로 탐지되며 계산하지 않아도 됩니다. 하드웨어에 결함이 있거나 어설션된 경우 또는 결함이 없습니다. 일반적으로 이러한 하드 오류는 인터럽트를 통해 처리됩니다. LOS, LOF, AIS-L, 그리고 특별한 경우에는 AIS-P와 RDI-P가 즉시 입증됩니다. 이러한 결함은 프레임과 정의된 규칙에 따라 달라지며 이러한 각 결함을 탐지합니다. 이러한 결함의 효과는 즉시 나타납니다. 그러나 라우터에 이 결함의 어설션을 장애로 연기하도록 지시할 수 있습니다. 지연 값을 결정하는 타이머가 두 개 있습니다. pos delay triggers [path | 라인] 및 운송업체 지연. 이러한 내용은 문서의 뒷부분에서 다룹니다.
관리 경보 - TCA 및 SD/SF-BER 계산과 같은 이벤트입니다. 이러한 경우 해당 항목이 있는지, 증가 또는 감소 여부에 대한 계산을 수행해야 합니다. 예를 들어 라우터의 관점에서 "LOS-Ness"를 늘리는 LOS를 가질 수는 없습니다. 그러나 증가 또는 감소 상태의 BER를 사용할 수 있습니다. 수행한 작업이 다를 수 있습니다. BER 및 TCA와 같은 소프트 오류는 사용자가 구성할 수 있는 임계값, 비트 전송률 및 최대 BIP CV 수(B1, B2 및 B3에 대해 다르기 때문)에 여러 요소에 종속되므로 몇 가지 계산이 필요합니다. 이러한 오류는 BIP 카운터에 대해 하드웨어가 폴링되고 이러한 유형의 결함은 자연적으로 점진적으로 발생하며 시간이 지남에 따라 누적되기 때문에 탐지하는 데 더 오래 걸립니다. 일반적으로 네트워크에 다른 유형의 하드 장애가 발생하지 않으면 0 BIP에서 SD(신호 저하) 또는 SF(신호 실패)로 곧바로 이동하지 않습니다. 이러한 결함은 하드 장애에 비해 발생 속도가 더 느립니다.

다음은 BER를 계산하는 방법을 설명하는 일반적인 기본 계산에 대한 접근 방법입니다.

계산을 다시 시작할 때마다 BER_Period가 Required_BER_Period에 도달할 때까지(통합 창이 완전히 구축되지 않음) 알고리즘은 통합 또는 평균으로 엄격하게 작동합니다.

BER_Period = BER_Period + 1초.
Current_BIP = Current_BIP + BIP_new.
Current_BER = Current_BIP/BER_Period입니다.

BER_Period가 Required_BER_Period에 도달하면(통합 창이 완전히 배포되고 슬라이드가 시작됨) 알고리즘은 누수가 있는 버켓 1로 작동합니다.

BER_Period = Required_BER_Period입니다.
Current_BIP = Current_BIP + BIP_new - Current_BER * 1초.
Current_BER = Current_BIP/BER_Period입니다.

Required_BER_Period는 표준에 따라 라인 레이트 및 구성된 BER 임계값만 기준으로 결정됩니다(그림 5-5, 스위치 시작 시간 기준, GR-253 참조). 하지만, 이것은 1초로 제한되어 있습니다, 우리의 샘플링 속도입니다.

따라서 BER_Period(통합 창)가 각 폴링과 함께 이동하며 각 폴링으로 새 BER가 계산됩니다. Current_BER가 정의된 제한을 초과할 경우, 동일한 폴링 또는 계산 간격 동안 즉시 적절한 결함을 발생시키고 응답을 최소화합니다. 이러한 계산을 매 초마다 반복하며 세 이벤트 중 하나가 발생했는지 확인합니다.

BER는 여전히 동일한 범위에 속합니다. 새로운 작업이 없습니다.
BER가 다시 증가하여 SD 또는 SF 임계값(B2의 경우)을 초과했습니다. 새 경보를 발효합니다.
BER가 BER 임계값 미만으로 감소했습니다. 알람을 지웁니다.

TCA 또는 SD/SF의 assertion에 대해 해당 폴링 간격에서 제한을 초과할 때까지 기다려야 합니다. 계산 시 Current_BER가 임계값을 초과했는지 확인하고, 임계값을 초과했다면 소프트웨어를 통해 즉시 경보를 실행할 수 있습니다.

Current_BER가 처음에 알람을 트리거할 수 있을 만큼 크더라도 BER_Period의 끝에 조건이 여전히 true이므로 이 값이 유효합니다. 이는 계산 창과 관련하여 값이 정의되고 비교되는 방식을 기반으로 합니다.

경보를 지울 때 BER_Period 계산 창이 끝날 때까지 기다려야 합니다. 이는 임계값 이상으로 유지될 수 있는 창의 마지막 부분 동안 새 BIP가 누적되지 않도록 하기 위한 것입니다.

참고: GR-253에 따르면 SD-BER와 SF-BER는 모두 B2 BIP 개수와 엄격하게 연결됩니다. 현재 기본 임계값은 다음과 같습니다.

BER 임계값—SF = 10e-3 SD = 10e-6
TCA 임계값—B1 = 10e-6 B2 = 10e-6 B3 = 10e-6

참고: Engine2 OC-48 카드에는 다음과 같은 기본 임계값이 있습니다.

BER 임계값—SF = 10e-4 SD = 10e-6
TCA 임계값—B1 = 10e-6 B2 = 10e-6 B3 = 10e-6

B3 TCA 경로 트리거가 SF와 유사하게 작동하게 하려면 B3 임계값은 동일한 임계값인 10e-3으로 설정되어야 합니다. 라우터(config-if)# 프롬프트에서 pos threshold b3-tca 3 명령을 통해 설정할 수 있습니다.

주: 폴링 간격이 1초이므로 TCA 또는 SD/SF 결함을 알리고 발생시키는 최소 시간입니다. 또한 TCA/SD/SF의 누적된 특성으로 인해 이러한 유형의 장애는 일반적인 실패에서 빠르게 발생할 때 몇 가지 다른 장애와 함께 발생합니다. 따라서 라우터 프로세서 사용률과 성능 간의 균형이 유지됩니다. 폴링 간격을 구성할 수 없습니다.

실행 중인 트리거

이 섹션에서는 IOS에서 다양한 사용자 터널링 가능 노브의 상호 작용을 검사하는 몇 가지 배경 정보를 제공합니다.

pos 지연 트리거 [행 | path] 명령은 결함의 보고 및 조치를 잠시 지연시킵니다.

POS 지연 트리거 라인은 회선 경보에 반응하기 전의 보류 시간입니다. 기본값은 즉각적인 반응입니다. 즉, pos delay trigger line 0을 의미합니다. 값 없이 pos 지연 트리거 라인을 직접 구성하는 경우 기본값 100ms가 고려됩니다. 이렇게 하면 원하는 효과를 기준으로 즉시 또는 지연된 응답이 가능합니다. 이 중 하나가 구성된 경우, 전달 기간이 끝날 때까지 결함이 활성 경보로 표시되지 않습니다.

일정:

|----------|----------|----------|----------|----------|
T0         T1         T2         T3         T4         T5

여기:

t0 - 결함이 발생한 시간입니다.
t1 - 하드웨어가 결함을 탐지한 시간입니다.
t2 - 결함이 보고되는 시간입니다.
t2-t3 - 구성된 트리거에 대해 보류된 시간입니다.
t3-t4 - 캐리어 지연으로 인해 대기하는 시간입니다.
t4 - 인터페이스가 IOS에서 실제로 다운된 시간입니다.
t5 - 라우팅 프로토콜에 대한 인접성이 다운되는 시간입니다.

타임라인을 검토하여 다양한 결과를 얻기 위해 서로 다른 손잡이를 조정하는 방법을 관찰합니다.

post delay triggers 명령은 t2와 t3 사이의 기간에 영향을 미치며, 실제로, 전달 기간이 끝날 때까지 IOS에서 결함을 숨깁니다. 물론 t3에 도달하기 전에 결함이 제거되면 아무 것도 발생하지 않으며 아무 일도 발생하지 않은 것과 같습니다. 선 및 경로 트리거의 기본값은 100ms이며 범위는 0~511ms입니다. 경로 트리거는 POS 지연 트리거 경로를 처음 구성하지 않는 한 활성화되지 않습니다(즉, 경로 트리거는 어떤 작업도 수행하지 않습니다). pos delay trigger path는 경로 경보에 반응하기 전의 보류 시간입니다. 기본값은 no response입니다. 값 없이 pos 지연 트리거 경로를 직접 구성하는 경우 기본값 100ms가 자동으로 할당됩니다. 여기에는 AIS-P, RDI-P 및 B3-TCA가 포함됩니다. 이 기능은 CSCds82814(약 12.0(15.5)S/ST)를 통해 추가되었습니다.

Carrier-delay는 POS 지연 보류 시간의 끝 사이의 보류 시간이며 IOS 인터페이스를 종료합니다. 기본값은 2000msec입니다. 캐리어 지연은 t3(IOS에서 장애를 인식한 경우)에서 t4(인터페이스가 중단된 경우)까지의 시간입니다. 기본적으로 이 값은 2초로 설정되며 msec 값에 대해 구성할 수 있습니다. 타임라인이 나타내는 것처럼 SONET 수준 전달 타이머 위에 추가 함수입니다. 이는 POS 트리거와 동일한 방식으로 동작합니다. 경보는 전달 기간이 끝나기 전에 지워지면 인터페이스가 다운되지 않습니다. 그런데 난제는 따로 있다. SONET Debounce 타이머는 캐리어 지연이 큰 경우(10초 초과)가 아니면 캐리어 지연이 활성화되기 전에 결함을 지우지 않습니다. 이로 인해 캐리어 지연이 거의 항상 활성화되므로 POS 인터페이스와 함께 구축할 때 다소 작은 것으로 간주해야 하는 상황이 발생합니다. 또한 인터페이스가 선언되기 전에 경보가 지워진 후에도 캐리어 지연이 추가됩니다. 따라서 인터페이스가 복구되기 전에 캐리어 지연 값을 두 번 계산할 수 있습니다.

일부 인터페이스와 물리적 미디어에서는 이 기능이 유용합니다. 그러나 POS 인터페이스에는 여러 개의 트리거 및 타이머를 사용할 수 있으며, 이를 통해 캐리어 지연 없이 원하는 효과를 생성할 수 있습니다. 0-8msec의 캐리어 지연 값은 고객이 직접 이러한 손잡이를 테스트할 때 고려하는 좋은 시작점입니다. 일반적으로 pos delay triggers 명령을 사용하여 문제를 해결하고 원하는 전달 효과를 제공하는 것이 좋습니다. 캐리어 지연을 작게 유지하여 영향을 최소화할 수 있습니다.

위에서 언급한 SONET Debounce 타이머는 10초(+/-.5초)로 설정되며, 플랩 기간이 10초 미만인 경우 발생하지 않도록 GR-253이 필요합니다. 결함이 제거된 후 타이머가 시작됩니다. 타이머 윈도우가 만료되기 전에 다른 결함 이벤트가 발생하면 타이머가 재설정됩니다.

일정:

|----------|----------|----------|----------|----------|---------|
T0         T1         T2         T3         T4         T5        T6

여기:

t0 - 결함이 지워집니다.
t0 - Debounce 타이머가 시작됩니다.
t4 - t0 + 10sec(따라서 t0과 t4 사이에 새로운 결함이 발생하지 않는 경우 오류를 해결해야 함)

t2에서 t4(예: 다른 결함 또는 동일한 유형의 결함이 다시 발생할 수 있음) 이전에 이벤트가 발생하면 이 새 결함이 해결될 때까지 타이머가 중지됩니다. t3에서는 활성 결함이 없을 때 타이머가 다시 시작되고 최대 10초 동안 계산됩니다. 새 이벤트가 발생하지 않은 경우 t5에서 알람을 지운 다음 캐리어 지연 타이머를 시작합니다. 통신 사업자 지연이 t6에서 지워지면 인터페이스를 다시 시작합니다.

이 정보를 통해 고객은 POS 인터페이스가 다양한 SONET/SDH 조건에 어떻게 대응하는지 더 명확하게 이해할 수 있어야 합니다. 이를 통해 고객의 의도한 행동에 따라 장비를 보다 정확하게 구성할 수 있습니다.

트리거 사용 이유

이 섹션에서는 pos 지연 트리거를 사용해야 하는 시기에 대해 설명합니다. [line | path] 명령 및 이를 사용하지 않아야 하는 경우

다음은 pos 지연 트리거를 사용하지 않아야 하는 시나리오입니다. 몇 가지 시나리오가 있습니다.

APS가 구성된 인터페이스에서는 라인 트리거를 사용할 수 없습니다. Cisco IOS Software Release 12.0(28)S 이전 버전에서는 경로 트리거의 사용도 허용되지 않았습니다.
PATH 레벨 결함이 인터페이스를 종료하지 않도록 명시적으로 설정할 경우 이러한 트리거를 사용할 수 없습니다.
라인 레벨 트리거가 지연 없이 인터페이스를 종료하도록 하려면 이 명령을 사용할 수 없습니다.

다음은 pos delay triggers 명령을 사용할 수 있는 시나리오입니다.

라인 레벨 결함의 효과를 일시적으로 보류하려는 경우
PATH 레벨 결함이 즉시 인터페이스를 종료하도록 하는 기능을 활성화합니다.
PATH 레벨 결함을 활성화하여 인터페이스를 종료하지만 일부 보류가 포함됩니다.

SLA 및 POS 트리거

다음 시간 표시 막대를 검토합니다.

|----------|--------------------|
T0         T1                   T2

시간 t=0(t0) - 결함이 탐지된 경우
시간 t2 - 필요한 SLA 복원 시간입니다.
Time t1 - pos delay delay에서 오는 모든 보류는 구성된 명령(LINE의 기본값은 0이고 PATH의 기본값은 활성화되지 않음)을 트리거합니다.
X는 전달 값입니다(따라서 X = t1 값).
Y는 레이어 3에서 서비스를 복원하는 데 걸리는 시간입니다.

정리

때때로 pos delay triggers 명령을 사용할 수 있지만, 특히 엄격한 SLA(Service Level Agreements)를 충족하려고 시도할 때는 사용할 수 없습니다.

포스트토크

t1 값에 대해 Y > (t2-t1)인 경우, 전달을 구성하면 SLA를 충족할 수 없기 때문에 중단은 바람직하지 않습니다.
Y <= (t2-t1)인 경우 핸드오프의 구현을 고려할 수 있습니다. 실패 기간이 (t1-t0)보다 작으면 라우터 리소스를 사용할 필요가 없으므로 보류할 수 있으며 원하는 SLA를 충족할 수 있습니다. t1이 지난 후에도 결함이 계속되면 IP 레벨에서 복원을 시작하기 전에 시간이 조금 걸리더라도 SLA를 충족할 수 있습니다.

이러한 수식에서 사용할 수 있는 값을 확인하려면 기본 전송 네트워크 및 레이어 3 네트워크의 컨버전스 시간에 대한 지식이 있어야 합니다. 또한 몇 가지 테스트를 수행해야 합니다.

다음은 트리거가 작동하는 방법입니다.

pos delay triggers line n 명령은 nms의 LOS/LOF/AIS를 보류한 다음 명령을 트리거합니다. 기본값은 100ms입니다. 비 APS POS 인터페이스에서 이 명령을 사용할 수 있습니다. pos delay triggers line n 명령은 내부 DWDM 보호 스위치가 발생한 시점부터 내부적으로 보호된 DWDM 장비에서 오는 간단한 LOS에서 해당 라인이 다운되는 것을 허용하지 않습니다. 전달 기간 동안 결함이 지워지면 결함이 발생하지 않는 것과 같습니다.
pos delay triggers line 명령은 지정된 전달 기간이 끝날 때까지 결함 카운터를 증가시키는 것을 제외하고 결함을 기반으로 한 모든 작업을 보류합니다.

이 명령을 활성화하지 않으면 RP에서 APS 및 링크 다운이 즉시 트리거됩니다.

SONET 트리거 구축

이 섹션에서는 SONET 트리거 구축에 대해 설명합니다.

보호된 SONET 네트워크: 라우터에 APS 없음

그림 1 - 내부 보호 SONET 네트워크

SONET 네트워크에는 내부 보호 기능이 있으므로 SONET 네트워크 내부에서 장애가 발생하면 일부 보호 스위치가 서비스를 매우 빠르게 복구하도록 합니다. 따라서 인터페이스를 종료하고 레이어 3에 알리고자 하는지 여부를 고려해야 합니다. 대부분의 경우 SONET 네트워크 내에서 보호 스위치가 발생하면 네트워크가 복원 작업을 수행하는 동안 라우터는 간단한 회선 또는 경로 AIS를 볼 수 있습니다. 그러나 이 오류는 장애가 두 라우터에서 한 홉으로 떨어진 경우에만 발생합니다. SONET 네트워크는 지름이 여러 NE일 수 있습니다. 두 라우터 모두 LINE failure를 PATH failures로만 인식합니다. 이 경우 전달을 원하는 경우 경로 및 라인 레벨 트리거를 고려하십시오.

이 결정을 내리려면 두 접근 방식과 관련된 비용을 이해해야 합니다. 네트워크 운영자로서 다음 질문을 고려해야 합니다.

네트워크가 신속하게 통합됩니까? 그렇지 않으면 이 방식이 적합하지 않습니다.
이러한 장애 발생 시 라우팅이 미치는 영향은 무엇입니까? 라우터에 미치는 영향이 너무 커서 성능이 허용 가능한 수준 아래로 떨어질 수 있습니까?

궁극적으로 잠재적인 최대 60msec 적중률을 무시할 수 있는지 또는 그러한 이벤트를 우회할 것인지 여부를 결정해야 합니다. 히트를 무시할 수 있는 경우, 이 결함에 대해 몇 밀리초만 대기하는 것을 원치 않으므로, 추가할 "퍼지 팩터"의 양을 파악해야 합니다. 따라서 수정 조치가 지연됩니다.

이 시나리오에서는 pos delay가 라인을 트리거하고 경로로 충분할 수 있습니다. 또한 전달이 보증될 경우 60msec 이상의 값을 고려하십시오. 네트워크가 충분히 넓고 라인 및 경로 레벨 결함 모두에 대해 즉각적인 조치를 취하려는 경우 라인 레벨 트리거를 구성할 필요가 없습니다. 그러나 PATH 레벨 결함을 즉시 처리할 수 있도록 pos delay triggers path를 0 값으로 구성해야 합니다.

내부적으로 보호되지 않는 SONET 네트워크

그림 2 - 내부적으로 보호되지 않는 SONET 네트워크

보호되지 않는 SONET 네트워크에서는 첫 번째 시나리오와 동일한 위험을 실행하고 몇 가지 더 수행합니다. 네트워크가 충분히 크면 결함이 모두 필터링되므로 라우터는 장애가 발생할 경우 LINE 수준의 결함을 볼 수 없습니다. 라우터는 PATH 레벨 결함을 위/아래로 볼 수 있습니다. 따라서 네트워크 내에서 장애가 발생하는 경우 라우터는 PATH 레벨 이벤트만 확인하고 라우터 간에 엔드 투 엔드 연속성이 없는 경우도 있습니다. 더구나 SONET 수준에서는 이러한 상황을 해결하기 위한 복구가 이루어지지 않습니다.

이 시나리오에서는 라우터가 PATH 결함이 발생할 때 라우터가 동작을 수행하도록 하려면 경로 트리거를 구성해야 합니다. 라우터가 전달 효과를 원하지 않더라도 이 작업을 수행해야 합니다. 네트워크 운영자로 경로 트리거를 구성한 경우 레이어 3 복원을 보류하거나 트리거하는 것이 좋을지 확인해야 합니다.

보호 또는 보호되지 않는 SONET 네트워크

그림 3 - 내부적으로 보호되지 않는 SONET 네트워크

Cisco IOS Software Release 12.0(28)S에서 APS 회로에서 PATH 트리거를 활성화할 수 있습니다. 로컬 또는 원격 라우터에 APS를 구축하면 APS 스위치가 원격 작업 및 보호 라우터에 간단한 PATH 레벨 결함이 표시됩니다. 트리거 값이 작으면 인터페이스가 다운되며 이 상황은 바람직하지 않습니다. 중단된 인터페이스는 이미 진행 중인 서비스 복원을 지연시킵니다. 클라우드 내에서 일시적인 장애가 발생하면 서비스 복원이 지연될 수 있습니다. 그러나 영구 PATH 레벨 오류가 발생하면 회선 보호(네트워크 내 또는 원엔드)가 연결을 복원할 수 없음을 나타냅니다. 이 경우 APS 라우터는 조치를 취하고 라우팅 재컨버전스를 시작해야 합니다. >= 100ms의 Path 트리거 지연 값을 구성할 수 있습니다. 이 컨피그레이션에서는 SONET 네트워크 내에서 또는 원격 엔드에서 영구 오류가 발생할 경우 라우터는 두 APS 인터페이스를 링크 중단 상태로 가져옵니다. 따라서 라우터는 더 신속하게 서비스를 재라우팅하고 복원하기 시작합니다.

보호된 DWDM 네트워크

그림 4 - 보호된 DWDM 네트워크

이 시나리오에서는 DWDM 네트워크가 SONET 프로토콜 레벨에서 참여하지 않으므로 경로 트리거를 사용할 필요가 없습니다. 라우터는 SECTION 또는 LINE 레벨에서 장애를 탐지합니다.

DWDM 네트워크는 내부적으로 보호되므로 네트워크 내부 오류로 인해 곧 복구됩니다. 라우터는 일반적으로 매우 간단한 LOS, LOF 또는 BIP 오류 버스트를 확인합니다.

따라서 이 네트워크에서 전달이 바람직한지 판단만 하면 됩니다.

지연을 선택하는 경우 이 상황에서는 pos delay triggers line 명령만으로도 충분합니다.

보호되지 않은 DWDM 네트워크

그림 5 - 보호되지 않은 DWDM 네트워크

전송에서 보호되지 않는 DWDM 네트워크를 사용할 경우 라우터 내의 모든 장애를 해결해야 합니다. 이 경우 DWDM은 SONET 프로토콜에 참여하지 않으므로 기본 컨피그레이션을 통해 두 라우터에서 발생한 모든 오류에 즉시 응답할 수 있습니다. 이 효과를 원하는 경우 구성된 POS 트리거의 기본 컨피그레이션이 적합합니다.

일부 전달이 필요한 경우 pos delay triggers line 명령이 이 기능을 제공하기에 충분합니다.

라우터가 다시 연결됨

그림 6 - Router Connected Back-to-Back

두 POS 인터페이스 간에 다시 연결되는 두 라우터는 마지막 시나리오와 동일하게 작동해야 합니다. SONET 오버헤드에서 작동하는 중간 장비가 없거나 SONET 레벨 신호의 어느 부분이라도 종료되므로 두 라우터에서 장애를 즉시 확인할 수 있습니다.

R1은 LTE(Line-Terminating Equipment)와 PTE(Path-Terminating Equipment)가 모두 R1에서 S-LOS를 확인하고, R2는 L-RDI와 P-RDI를 모두 볼 수 있다는 점이 흥미로운 상황입니다. L-RDI는 결과 작업을 수신 시 명시적으로 허용하지 않으므로 R2는 그 결과로 인터페이스를 삭제하지 않습니다. 이 문제는 R1의 인터페이스가 다운되었지만 R2의 인터페이스가 여전히 작동 중이고 트래픽을 포워딩하는 상황으로 이어질 수 있습니다. 물론 HDLC(High-Level Data Link Control)와 같은 모든 레이어 2 keepalive는 시간이 초과되어 구성된 타이머를 기반으로 일반적으로 30초 내에 링크를 다운합니다. 그러나 많은 연산자가 이러한 레이어 2 keepalive를 비활성화하므로 이러한 상황을 방지할 수 없습니다. 이 문제를 해결하기 위해 몇 가지 방법을 사용할 수 있으며, 각 접근 방식은 여기에 설명된 대로 다른 관점에서 이 문제를 해결합니다.

Turn on Path Triggers(경로 트리거 켜기) - P-RDI가 Path 트리거가 활성화된 인터페이스를 다운할 때 이 방법을 사용하여 빠른 응답을 유발하고 인터페이스를 삭제할 수 있습니다. 주목할 점은 L-RDI가 GR-253에 따라 정상적인 작동 상태에서 P-RDI를 마스크 처리한다는 것입니다. POS 트리거는 결함 레벨에서 처리되므로, 트리거는 경보 마스킹 전에 처리되고 인터페이스는 구성된 지연 시간에 따라 계속 삭제됩니다.
Enable Layer 2 Keepalives(레이어 2 keepalives 활성화) - 이 옵션을 선택하면 R2의 인터페이스가 3개의 keepalive를 놓친 후 시간이 초과됩니다. 일반적으로 총 30초(3x10)이며, Cisco에서는 빠른 링크 컨버전스를 조정하기 위한 도구로 이 옵션을 권장하지 않습니다.
Enable a Link-State Routing Protocol(링크 상태 라우팅 프로토콜 활성화) - S-LOS로 인해 R1의 인터페이스가 중단되면 링크 상태 메시지가 즉시 전송됩니다. R2의 인터페이스가 여전히 작동 중일 수 있지만, 링크 상태 메시지가 영역 전체에 수신되면 SPF가 실행되고 링크가 양방향 연결 확인에 실패하여 토폴로지에서 링크가 제거됩니다. 이렇게 하면 네트워크가 해당 단방향 시나리오를 통해 라우팅하지 못하게 됩니다.

신호 품질 기반 원격 알림

두 라우터(백투백 또는 SONET 네트워크 간)를 연결할 때 제공된 OAM 아키텍처는 대부분의 장애 시나리오를 탐지합니다.

일반적으로 로컬 알림 및 원격 알림이 있습니다. 그러나 많은 수의 BIP 오류가 임계값(SD, SF 또는 B3-TCA)을 넘는 경우 이 조건이 발생했음을 나타내는 원격 알림이 전송되지 않습니다. 따라서 MPLS(Multi Protocol Label Switching) Fast Re-Route 보호를 사용할 경우 트리거가 즉시 보호 스위치를 활성화하지 않습니다. 충분한 트래픽이 손실되어 링크상의 레이어 2 keepalive 또는 IGP(Interior Gateway Protocol) 피어 간의 네이버 관계에 오류가 발생할 때까지 트래픽은 계속 블랙홀링됩니다. 때때로 이는 발생하지 않으며 트래픽을 블랙홀(blackhole)하는 경우가 있습니다.

이 시나리오를 해결하기 위해 CSCec85117에서는 POS 및 SONET 명령 구조에 pos action b3-ber prdi 명령을 도입했습니다.

이 명령을 사용하면 B3 임계값이 초과될 때 운영자가 P-RDI를 전송하도록 인터페이스를 구성할 수 있습니다. 이 옵션을 사용하면 토폴로지에 관계없이 엔드 투 엔드 링크를 최적의 상태로 모니터링할 수 있습니다. pos delay triggers path가 라우터에서 활성화된 경우 pos action b3-ber prdi 명령은 다운된 링크(및 해당 FRR(Fast ReRoute) 또는 라우팅 업데이트)를 활성화합니다. 이렇게 하면 성능이 저하된 링크에 대한 블랙홀 효과가 방지됩니다.

이 작업의 민감도를 변경하려면 다음과 같이 b3-tca를 조정합니다.

router(config-if)# pos threshold b3-tca ?

제공된 값은 BER 계산을 위한 지수 구성요소입니다(예: pos threshold b3-tca 3은 B3-TCA를 1x10^-3 환율과 동일하게 설정합니다).