SONET觸發器

下載選項

PDF (411.0 KB)
在多種裝置上使用 Adobe Reader 檢視
ePub (100.3 KB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上的各種應用程式中檢視
Mobi (Kindle) (185.9 KB)
在 Kindle 裝置或多部裝置的 Kindle 應用程式上檢視

已更新: 2005 年 7 月 21 日

文件 ID:62622

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

簡介

觸發器是在IOS中的同步光纖網路(SONET)介面中實現cause在因果關係中的角色的任何事件。有時，可以使用pos delay triggers命令。有時，思科建議您不要使用pos delay triggers命令，尤其是當您嘗試滿足嚴格的服務級別協定(SLA)時。服務提供商根據某些協定銷售不同的服務級別。協定涉及網路內部路由、保護客戶流量或確定客戶流量的優先順序。這些命令可幫助提供商調整網路以滿足服務協定要求。

本文探討與介面開啟和關閉事件相關的觸發器。本文檔還說明了如何部署Packet Over SONET(POS)，並考慮第3層的SLA和收斂時間。

必要條件

需求

本文件沒有特定需求。

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。

慣例

如需文件慣例的詳細資訊，請參閱思科技術提示慣例。

導致POS介面關閉的事件

本節介紹導致POS介面關閉的事件，並列出相關命令。

小節和行級觸發器

本節中的觸發器清單是指GR-253-CORE同步光纖網路(SONET)傳輸系統：通用通用標準規範：

訊號丟失(SLOS) — 規範指示必須檢測到不小於2.5us且不大於100us(6.2.1.1.1)。
幀丟失部分(SLOF) — 規範指示您必須以至少3毫秒（或24個連續錯誤成幀模式）檢測到此情況(6.2.1.1.2)。
報警指示訊號 — 線路(AIS-L)-AIS-L必須在檢測到的125usec內根據情況傳送。如果裝置看到5個連續的幀，其中K2的位6、7和8設定為111(6.2.1.2.1)，則裝置必須檢測到AIS-L的接收。
Signal Degrade Bit Error Rate(SD-BER)- SD-BER僅在具有自動保護交換(APS)的介面上觸發（與B2 BER計算相關）。
Signal Failure Bit Error Rate(SF-BER)- SF-BER是APS和非APS介面（與B2 BER計算關聯）的觸發器。
遠端缺陷指示 — 線路(RDI-L)- RDI-L不是POS或APS的觸發器。（但是，RDI-L是MPLS FRR的觸發器）（第5.3.3.1節）。

有關此清單中提及的部分的詳細資訊，請參見Telcordia Information SuperStore Web站點。

路徑觸發器

僅當在介面上啟用pos delay triggers path後，這些特定的PATH級別缺陷才會啟動狀態更改：

AIS-P — 在檢測到導致AIS-P的缺陷後，必須在125usec內提出此缺陷。當STS路徑的H1和H2位元組包含連續3個幀的全部1時，路徑終止裝置(PTE)必須檢測到此缺陷。級聯路徑只需要觀察前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（閾值交叉警報） — 此警報與B3二進位制同步通訊(Bisync)IP(BIP)計算關聯。
LOP-P（指標路徑丟失）(如果IOS版本包括CSCdx58021) — 請參閱GR-253的6.2.1.1.3部分。

有關此清單中提及的部分的詳細資訊，請參見Telcordia Information SuperStore Web站點。

POS觸發器CLI行為摘要

此表列出了POS觸發器的條件和相關結果：

條件	結果
如果沒有配置與POS觸發器明確相關的任何內容。	將立即處理行級觸發器。
如果您已配置pos delay triggers line命令。	在延遲100毫秒後處理線路級觸發器。
如果您已設定pos delay triggers line x 命令。	在x毫秒後處理行級觸發器，其中x介於0和511之間。
如果您沒有配置任何與Path觸發器明確相關的內容。	不會處理路徑觸發器，不會導致採取任何操作。
如果您已設定pos delay triggers path命令。	在延遲100ms後處理路徑級觸發器。
如果您已設定pos delay triggers path x 命令。	x msecs之後會處理路徑級觸發器，其中x介於0和511之間。

SONET警報的反彈

缺陷清除後，由缺陷導致的SONET警報將保留10秒(10.5 +-.5)。

缺陷處理

在IOS中，POS卡通過兩種通用的缺陷處理方法因不同的觸發而改變其LINE狀態。這取決於介面的特定配置（APS或非APS），但通常有兩種故障：

受管
非託管

您必須瞭解本文檔使用的警報處理特定術語：

缺陷 — 硬體識別的故障狀態。
故障 — 在所需的~2.5秒內浸泡過的缺陷，然後通過SONET-4-ALARM消息報告。任何觸發缺陷都不會被浸透。
未管理的故障 — LOS、LOF等事件它們由SONET幀管理器通過一組定義的引數檢測，不需要計算。硬體存在並斷言缺陷，或者沒有缺陷。諸如此類的硬故障一般通過中斷來處理。LOS、LOF、AIS-L和在特殊情況下，AIS-P和RDI-P立即得到斷言。這些缺陷取決於幀器和定義的規則來檢測這些缺陷。這些缺陷的影響是直接的。但是，您可以指示路由器延遲將此缺陷斷言為失敗。有兩個計時器可以確定延遲值，pos delay triggers [path | line]和運營商延遲。這些將在本文檔後面部分討論。
託管警報 — 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（整合視窗已完全部署並開始滑動）後，演算法將用作漏桶演算法：

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的斷言，您只需等待，直到在相應的輪詢間隔超過限制。計算時，檢查Current_BER是否超過閾值，如果超過，可以通過軟體立即發出警報。

這是有效的，因為，如果Current_BER足夠大以最初觸發警報，則在BER_Period結束時該條件仍為真。這基於值的定義和比較方式（相對於計算視窗）。

清除警報時，需要等待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。您可以通過router(config-if)#提示符下的pos threshold b3-tca 3命令來執行該操作。

注意：由於輪詢間隔為一秒，這是我們將發現並提高TCA或SD/SF缺陷的最短時間。此外，由於TCA/SD/SF的累積性質，這些型別的故障在典型故障中快速出現時也會伴隨著其他故障。這樣可保持路由器處理器利用率和效能之間的平衡。無法配置輪詢間隔。

操作中的觸發器

本節提供一些背景資訊，以檢查IOS中某些使用者可調旋鈕的互動：

pos delay triggers [line |path]命令短暫延遲缺陷的報告和操作。

POS延遲觸發行是響應行警報之前的保持時間。預設為立即反應，這表示pos delay trigger line 0(pos延遲觸發行0)。如果直接配置pos delay觸發器行，而沒有任何值，則會考慮預設值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 delay triggers path，否則不會啟用路徑觸發器（換句話說，它們不會執行任何操作）。pos delay trigger path是對路徑警報作出反應之前的保持時間。預設設定為無反應。如果直接配置pos delay觸發器路徑，而不配置任何值，則將自動分配預設值100ms。其中包括AIS-P、RDI-P和B3-TCA。此功能是通過CSCds82814(大約12.0(15.5)S/ST)新增的。

Carrier-delay是POS延遲保持時間結束之間的保持時間，它將關閉IOS介面。預設值為2000毫秒。載波延遲是t3（IOS得知發生故障時）和t4（介面關閉時）之間的時間。預設情況下，此值設定為2秒，可以配置為msec值。如時間線所示，它是SONET級別保持計時器頂部的附加函式。其行為方式與POS觸發方式相同 — 如果警報在暫停週期結束前清除，則介面不會關閉。然而，這裡有一個難題。除非載波延遲較大（遠超過10秒），否則SONET反退回計時器在載波延遲啟用之前不會清除缺陷。這會導致載波延遲幾乎總是被啟用，因此在與POS介面一起部署時必須認為其相當小。在清除警報之後、介面宣告啟動之前，還會增載入波延遲。因此，您可以在介面重新開啟之前對載波延遲值進行兩次計數。

對於某些介面和物理介質，這很有幫助。但是，有了POS介面，您就可以使用許多觸發器和計時器，並將其組合起來達到預期效果，而電信級延遲不會起到這種主要作用。0-8毫秒的載波延遲值是客戶自行測試這些旋鈕時需要考慮的良好起點。通常，一個好的策略是使用pos delay triggers命令來吸收任何問題，並提供所需的保持效果。可以將載波延遲保持在較小範圍以最小化其影響。

上述SONET反退回計時器設定為10秒(+/- .5sec),GR-253要求此計時器確保不會出現小於10秒的翻動週期。清除缺陷後，計時器啟動。如果在計時器視窗過期之前發生另一個缺陷事件，則重置計時器。

時間表：

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

此處：

t0 — 缺陷清除。
t0 — 反退回計時器啟動。
t4 - t0 + 10sec（因此，如果t0和t4之間沒有出現新的缺陷，則必須清除故障）。

如果在t4之前發生事件（例如，在t2發生）（它可能是另一個缺陷，或者相同型別的缺陷再次發生），計時器停止直到清除這個新的缺陷。在t3時，如果沒有活動缺陷，計時器再次啟動，並計時~10秒。如果未遇到新事件，請清除t5處的警報，然後啟動載波延遲計時器。在t6清除載波延遲後，再次啟動介面。

此資訊應讓客戶更清楚地瞭解POS介面如何對各種SONET/SDH條件做出反應。這樣，便可以根據客戶預期的行為更精確地配置裝置。

為什麼要使用觸發器？

本節介紹何時必須使用pos delay triggers [line | path]命令，以及不得使用的時間。

以下是不能使用pos延遲觸發器的情況。有幾種情況：

不能將線路觸發器用於APS配置的介面。低於Cisco IOS軟體版本12.0(28)S的版本甚至不允許使用路徑觸發器。
如果明確不希望PATH級缺陷導致介面關閉，則不能使用這些觸發器。
如果希望線路級觸發器無延遲地關閉介面，則不能使用此命令。

以下是可以使用pos delay triggers命令時的情境：

當您想暫時減弱線級缺陷的影響時。
啟用PATH級別缺陷的能力，立即關閉介面。
啟用PATH級別缺陷以關閉介面，但包括一些暫停功能。

SLA和POS觸發器

檢視此時間表：

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

時間t=0(t0) — 檢測到缺陷時。
時間t2 — 所需的SLA恢復時間。
時間t1 — 所配置的pos delay triggers命令的任何保持狀態（LINE的預設值為0,PATH的預設值未啟用）。
X是保持值（因此X = t1的值）。
Y是第3層恢復服務所需的時間。

定理

有時，可以使用pos delay triggers命令，而在其他時候，則無法使用，尤其是當您嘗試滿足嚴格的服務級別協定(SLA)時。

假設

如果Y >(t2-t1)表示任意值t1，則最好不要進行暫掛，因為如果配置任何暫掛，您將無法滿足您的SLA。
如果為Y <=(t2-t1)，則可以考慮實施暫掛。如果故障持續時間小於(t1-t0)，則可以推遲處理，因為您無需利用路由器資源，而且您可以滿足所需的SLA。如果在過去t1時間缺陷仍然存在，您仍然可以滿足SLA，即使在IP級別啟動恢復之前會損失一些時間。

您必須對基礎傳輸網路和第3層網路的收斂時間有一定的瞭解，才能瞭解可以在這些公式中使用的值。您還需要執行一些測試。

以下是觸發器的運行方式：

pos delay triggers line n 命令在命令觸發器line down之前將LOS/LOF/AIS關閉n ms。預設值為100ms。您可以在任何非APS POS介面上使用此命令。pos delay triggers line n 命令不允許從發生內部DWDM保護交換機時開始在來自內部保護DWDM裝置的短暫LOS上關閉線路。如果在保持期間缺陷被清除，則好像缺陷從未發生。
pos delay triggers line命令將暫停基於缺陷的任何操作（除非增加缺陷計數器），直到指定的保持時間結束。

如果不啟用此命令，RP中會立即觸發APS和鏈路關閉。

SONET觸發器的部署

本節介紹SONET觸發器的部署。

受保護的SONET網路：路由器上沒有AP

圖1 — 內部保護的SONET網路

SONET網路具有內部保護，這意味著SONET網路內的故障會觸發某些保護交換機來快速恢復服務。因此，您需要考慮是否要關閉介面並通知第3層。大多數情況下，當SONET網路內發生保護開關時，路由器會看到一條短線或路徑AIS，而網路會採取恢復措施。但是，僅當故障距其中一台路由器只有一跳時，才會發生這種情況。SONET網路可能為直徑的多個NE，其中任一路由器都只將線路故障視為PATH故障。在這種情況下，如果想要暫停，請考慮路徑和行級觸發器。

要做出此決定，您需要瞭解這兩種方法的相關成本。作為網路運營商，您必須考慮以下問題：

網路收斂是否足夠快？否則，這種方法就不適合。
圍繞此類故障進行路由有何影響？對路由器的影響是否如此巨大，以至於效能下降到可接受的水準以下？

最後，您需要決定是否可以忽略潛在的~60msec命中，或者您是否喜歡在這種事件周圍路由。如果可以忽略該命中，則必須確定要新增的「模糊因子」的個數，因為，您不希望等到這個缺陷僅等待幾毫秒太久後再進行新增，因而會延遲糾正操作。

在此案例中，pos延遲觸發器行和路徑可能就足夠了。此外，如果保證保留值，請考慮至少60毫秒的值。如果網路足夠寬，並且您想對線路和路徑級別缺陷立即採取措施，則無需配置線路級別觸發器。但是，您需要將pos delay triggers path配置為值0，以便立即處理PATH級別缺陷。

內部未受保護SONET網路

圖2 — 內部未受保護SONET網路

在未受保護的SONET網路中，您運行的風險與第一種情況相同，而且還有一些。如果網路足夠大，則路由器在出現故障時可能永遠看不到線路級缺陷，因為這些缺陷都經過過濾。路由器可以看到上下游的PATH級缺陷。因此，在網路中發生故障的一些情況下，路由器只看到PATH級事件，並且路由器之間沒有端到端連續性。更糟糕的是，在SONET級別沒有進行恢復來糾正這種情況。

在此案例中，您必須設定Path觸發器，以便在路由器遇到PATH缺陷時，允許任一端的路由器執行操作，即使路由器不希望產生抑制效果。當配置了路徑觸發器時，作為網路操作員，您必須檢查是最好是暫緩還是觸發第3層恢復。

受保護或未受保護的SONET網路

圖3 — 內部未受保護SONET網路

在Cisco IOS軟體版本12.0(28)S中，您可以在APS電路上啟用PATH觸發器。在本地或遠端路由器上部署APS時，APS交換機會使遠端工作和保護路由器看到一個簡短的PATH級缺陷。如果觸發值較小，則介面會關閉，這種情況是不理想的。介面關閉會延遲正在進行的服務恢復。在雲中發生的短暫故障也會延遲服務恢復。但是，如果出現持續PATH級別錯誤，則表明電路保護（在網路內或遠端）無法恢復連線。在這種情況下，APS路由器必須採取行動，並啟動路由重新收斂。可以配置>= 100ms的路徑觸發器延遲值。通過此配置，當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 — 路由器背靠背連線

兩個POS介面之間背對背連線的兩台路由器必須像最後一個場景一樣運行。由於不存在在SONET開銷上運行的中介裝置或終止SONET級別訊號的任何部分，因此可以立即在任一路由器上看到故障。

有趣的情況是R1看到S-LOS，R2同時看到L-RDI和P-RDI，因為R1既是線路終端裝置(LTE)，也是路徑終端裝置(PTE)。由於L-RDI明確禁止在收到資料後執行任何生成的操作，因此R2不會因此丟棄該介面。此問題可能會導致出現R1的介面發生故障，但R2的介面仍處於開啟狀態並轉發流量的情況。當然，任何第2層keepalive(如高級別資料鏈路控制(HDLC)提供)都會超時並宣佈鏈路關閉，通常是30秒（基於配置的計時器）。但是，許多運算子會停用這些第2層keepalive，因此無法防止這種情況。為了解決此問題，您可以採取多種方法，每種方法從不同的角度解決此問題，如下所述：

開啟路徑觸發器 — 由於P-RDI在啟用路徑觸發器後使介面關閉，因此可以使用此方法引起快速響應並丟棄介面。需要注意的一點是，根據GR-253,L-RDI在正常操作下遮蔽了P-RDI。由於POS觸發器是在缺陷級別處理的，因此會在警報遮蔽之前處理這些觸發器，並且介面仍會根據配置的延遲時間進行丟棄。
Enable Layer 2 Keepalive — 此選項會導致R2上的介面在丟失3個keepalive後超時。這通常是總共30秒(3x10)，思科通常不建議將此選項作為調整快速鏈路收斂的工具。
Enable a Link-State Routing Protocol — 當R1上的介面因S-LOS而關閉時，會立即傳送鏈路狀態消息。即使R2上的介面仍然可以啟動，但當整個區域收到鏈路狀態消息時，SPF將運行，並且鏈路會因為雙向連線檢查失敗而從拓撲中刪除。這可以防止網路嘗試通過這種單純的情況進行路由。

基於訊號品質的遠端通知

當您連線兩台路由器（背對背或通過SONET網路）時，提供的OAM架構可檢測大多數故障場景。

通常情況下，存在本地通知和遠端通知。但是，當大量的BIP錯誤越過閾值（SD或SF，或B3-TCA）時，不會傳送遠端通知來指示發生了此情況。因此，當您採用多協定標籤交換(MPLS)快速重路由保護時，沒有觸發機制會啟用立即保護交換機。流量繼續被黑洞，直到失去足夠的流量導致連結上的第2層keepalive或內部閘道通訊協定(IGP)對等點之間的鄰居關係失敗。有時，這種情況不會發生，而是繼續使流量進入黑洞。

為了解決此問題，CSCec85117在POS和SONET命令結構中引入了pos action b3-ber prdi命令。

此命令允許操作員配置介面，使其在超過B3閾值時傳送P-RDI。使用此選項，您可以以最佳方式監控鏈路端對端，而不管其拓撲如何。如果在路由器上啟用pos delay triggers path,pos action b3-ber prdi命令就會啟用關閉的鏈路(以及相應的快速重新路由(FRR)或路由更新)。這樣可避免在降級鏈路上產生黑洞效應。

要更改此操作的敏感性，請調整b3-tca，如下所示：

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

提供的值是用於BER計算的指數分量(例如，pos threshold b3-tca 3將B3-TCA設定為1x10^-3的速率)。