本文檔回答了有關WAN壓縮的常見問題(FAQ)。本檔案包括壓縮概觀、在Cisco路由器中實作壓縮和壓縮疑難排解一節。
A.數據壓縮的工作原理是識別資料流中的模式。資料壓縮選擇更有效的方法來表示相同的資訊。 實質上,對資料應用了一種演算法,以儘可能地消除冗餘。 壓縮方案的效率和效果由其壓縮比、未壓縮資料大小與壓縮資料大小之比來衡量。 2:1的壓縮比(相對常見)意味著壓縮的資料大小是原始資料的一半。
有許多不同的演算法可用於壓縮資料。 一些演算法旨在利用特定介質和其中發現的冗餘。然而,應用於其他資料來源時,它們的工作效果並不好。例如,運動影象專家組(MPEG)標準旨在利用視訊資料中一個幀與另一個幀之間相對較小的差異。它在運動影象的壓縮方面表現得很出色,但是對文本壓縮效果不佳。
壓縮理論中最重要的思想之一是存在一個理論極限,稱為香農極限。此限制告訴您可以壓縮給定資料來源的距離。 在此之後,無法可靠地恢復壓縮資料。 現代壓縮演算法與當今可用的快速處理器相結合,使使用者可以接近香農極限。然而,他們永遠無法跨越它。
有關Shannon's Limit的詳細資訊,請參閱以下文檔:
A.硬體壓縮和軟體壓縮是指應用壓縮演算法的路由器站點。在軟體壓縮中,它作為軟體進程在主CPU中實現。 在硬體壓縮中,壓縮計算被解除安裝到輔助硬體模組。這樣可免除中央CPU執行計算密集型壓縮計算任務。
如果您假設路由器具有可用的時鐘週期來執行壓縮計算(例如,CPU利用率仍低於100%),則硬體壓縮或軟體壓縮的效率沒有任何差異。 所實現的壓縮比是所選擇的壓縮演算法和待壓縮資料中的冗餘量的函式。這不是壓縮計算發生的地方。
A.第2層負載壓縮涉及第2層WAN協定負載的壓縮,例如PPP、幀中繼、高級資料鏈路控制(HDLC)、X.25和鏈路接入過程平衡(LAPB)。第2層報頭不受壓縮行為的影響。但是,負載的全部內容(包括高層協定報頭)都將被壓縮。 它們按照資料壓縮如何工作?中所述進行壓縮,並使用一種形式的「堆疊」演算法(基於行業標準Lemple Ziv演算法;請參閱美國國家標準協會(ANSI) (X3.241-1994)文檔,或「預測器」演算法,後者是舊式配置中最常用的一種演算法。
A. TCP/IP報頭壓縮可刪除TCP/IP連線報頭中的某些冗餘欄位。 標頭壓縮在鏈路的兩端保留原始標頭的副本,刪除完全冗餘的欄位,並對剩餘欄位進行差分編碼,以便將40位元組的標頭壓縮為平均5位元組。這使用圍繞TCP/IP報頭的常數結構設計的非常具體的演算法。 它不會以任何方式接觸TCP封包的負載。 請參閱RFC 1144,壓縮低速序列連結的TCP/IP標頭 。
A. TCP/IP報頭壓縮用於速度小於或等於32 k的慢速串列鏈路,並對效能產生顯著影響。它需要具有小資料包大小的高度互動式流量。 在此類流量中,第3層和第4層報頭與負載的比率相對較高。因此,如果收縮報頭,效能可能會提高。
第2層負載壓縮將選定的壓縮演算法應用於包括TCP/IP報頭的整個幀負載。 它設計用於速度為56 k至1.544 M的鏈路。 只要流量之前未被高層應用程式壓縮,它對所有型別的流量都非常有用。
答:不。您不會同時實施第2層負載壓縮和TCP/IP報頭壓縮,因為:
它是多餘和浪費的。
通常,鏈路不啟動或不通過IP流量。
僅使用第2層負載壓縮,而不是同時使用第2層負載壓縮和TCP/IP報頭壓縮。
A.建議使用Cisco IOS®軟體版本11.3T或12.0(mainline、S或T)系列的最新版本,以確保硬體和軟體相容性。 此外,思科強烈建議您在廣域網鏈路兩端運行相同版本的代碼,以確保相容性。
A.此表顯示支援硬體壓縮的所有路由器和支援的模組:
路由器 硬體壓縮配接器 7200和7500 SA-COMP/1=和SA-COMP/4= 3620和3640 NM-COMPR= 3660 AIM-COMPR4= 2600 AIM-COMPR2= 註:Cisco 7200 VXR系列路由器不支援SA-COMP/1=或SA-COMP/4=。 7200 VXR系列路由器沒有硬體壓縮介面卡。
答:Cisco硬體壓縮介面卡僅支援PPP堆疊壓縮和幀中繼FRF.9堆疊壓縮。 所有壓縮介面卡都支援這兩種協定。 有關FRF.9規範的詳細資訊,請參閱幀中繼論壇 (Frame Relay Forum Web站點),然後選擇Frame Relay選單下的Implementation Agreements。
答:由於流量模式和給定路由器的可能配置的不同,這個問題沒有簡單的答案。
壓縮對處理器來說非常密集,而且處理器利用率與您要壓縮的流量成正比。 如果問題路由器上已經運行許多處理器密集型功能,則只有少數時鐘週期可用於壓縮。
壓縮還需要記憶體以儲存重建字典。因此,記憶體不足的路由器可能會出現問題。在集中星型配置中,集線器通常需要壓縮模組,而輻條不需要。
回答此問題的唯一方法是建議您分階段實施壓縮,並監控處理器利用率。
A.當要壓縮的介面位於多功能介面處理器2(VIP2)插槽中時,可以使用分散式壓縮。壓縮計算然後解除安裝到VIP2處理器。
A.路由器預設為將壓縮計算儘可能地解除安裝到CPU之外。整個硬體壓縮點是從路由器CPU移除負載,並將其放在硬體模組上。如果有一個壓縮模組可用,則用於壓縮。 如果壓縮模組不可用,且有問題的介面位於VIP2插槽中,則VIP2上的處理器用於壓縮計算。 如果該處理器不可用,則使用軟體進行壓縮。 在compression命令末尾指定software、distributed或csa #可以強制路由器分別使用主CPU、VIP2 CPU或硬體模組。
A.兩個壓縮服務介面卡的板載處理器相同。唯一的區別在於板載記憶體。 它們可以處理相同數量的流量,包括資料量和每秒資料包數(pps)。
服務介面卡可處理高達60 Mbps的聚合雙向未壓縮頻寬,其中40,000 pps為雙向頻寬,30,000 pps為單向頻寬。根據經驗,一個服務介面卡可以運行八個壓縮E1。此假設採用2:1的壓縮比;1.7:1或1.8:1更常見。
COMP/1具有768 KB記憶體,支援64個不同的「情景」。
COMP/4有3 MB的記憶體,可支援256個不同的「情景」。
一個上下文基本上是一個雙向重建字典對,即一個點對點連結。 因此,每個幀中繼點對點子介面都是一個上下文。(更具體地說,每個單獨的vc都有一個關聯上下文,因為思科壓縮以「每個資料鏈路連線識別符號(DLCI)」為基礎。)
A.支持具有軟體壓縮的多鏈路PPP,其包括具有交織加壓縮的多鏈路PPP。
Cisco 7200和3600路由器上的Cisco IOS軟體版本12.0(7)T和12.0(7)支援帶硬體壓縮的多鏈路PPP。但是,Cisco 7500路由器不支援多鏈路PPP和壓縮服務介面卡(CSA)。
A.發出show compression命令和show interface命令,以確定吞吐量、壓縮資料包數和壓縮比。
使用軟體第2層負載壓縮,思科僅支援先進先出(FIFO)隊列,因為資料包在呈現給介面隊列之前被壓縮。加權公平隊列預設處於開啟狀態。若要將其關閉,您需要發出no fair-queue命令。
使用硬體第2層負載壓縮,由於資料包在壓縮之前排隊,因此支援花式隊列,從而實現成功分類。
A.運行軟體壓縮時,所有資料包無論如何都必須通過處理器,並且它們會被進程交換。 這就是壓縮工作的方式。
A. Show compress在早期版本的Cisco IOS軟體版本12.0程式碼中中斷。 升級至Cisco IOS軟體版本12.0(7)(mainline、S或T)以進行修復(CSCdk15127(僅限註冊客戶))。這僅是表面問題。
A.遞增框上的預設配置存在問題。請聯絡您的Lucent Technologies技術支援代表。
A.這是已知問題Cisco錯誤ID CSCdk39968(僅限註冊客戶)。解決方案是升級到Cisco IOS軟體版本11.3(7)或更高版本的代碼。
A.這種情況可能出於多種原因:
如果連結處於關閉狀態,請發出show compress指令,顯示其執行軟體壓縮。 當鏈路接通時,顯示硬體壓縮。 命令會顯示此情況,因為必須通過PPP的CCP或幀中繼的FRF.9進程協商硬體壓縮。 若要執行此交涉,不得關閉連結。
在使用某些舊版Cisco IOS軟體的PPP上運行硬體壓縮時,不要鍵入compress stac以發出命令,必須鍵入ppp compress stac以發出命令。 這是舊版命令語法的遺留。
要在7500系列路由器中運行硬體壓縮,壓縮服務介面卡必須與要壓縮的介面位於同一個VIP2中。 其他VIP2和介面處理器卡上的介面無法與壓縮服務介面卡通訊。
A.壓縮比小於1意味著壓縮演算法會增加資料的大小。它不會減小資料的大小。 這是由下列原因之一導致的:
如果嘗試壓縮已經過更高層壓縮演算法的資料。壓縮演算法的設計假定存在要移除的冗餘,並且演算法會相應地執行計算。如果資料已壓縮,冗餘已移除,並且如果對相同的資料應用另一個壓縮演算法,則可能導致資料擴展。如果嘗試在第2層壓縮包含壓縮資料的大型資料包,則會出現此結果。負載中唯一以前未壓縮的部分是TCP/IP報頭。 大型資料包(如FTP)可以擴展,以便總壓縮比小於1。
CPU負擔過重可能導致壓縮率小於1。如果在沒有週期執行的路由器上運行軟體壓縮,以便執行必要的計算,該過程將停止。此問題的症狀之一是壓縮率小於1。唯一的解決方案是從某些鏈路中刪除壓縮,或安裝硬體壓縮模組。