本文档回答了有关WAN压缩的常见问题(FAQ)。本文档包括压缩概述、在Cisco路由器中实施压缩和排除压缩故障。
答:数据压缩通过识别数据流中的模式来工作。数据压缩选择一种更有效的方法来表示相同的信息。 本质上,算法被应用到数据中以尽可能地消除冗余。 压缩方案的效率和有效性由压缩比、未压缩数据的大小与压缩数据的比来衡量。 压缩比为2:1(相对常见)意味着压缩数据的大小是原始数据的一半。
为了压缩数据,有许多不同的算法。 一些算法旨在利用特定介质及其中的冗余。但是,当应用到其他数据源时,它们的工作不够出色。例如,运动图像专家组(MPEG)标准旨在利用视频数据中一个帧和另一个帧之间相对较小的差异。它在运动图像的压缩方面做得很好,但对文本的压缩效果不好。
压缩理论中最重要的思想之一是存在一个理论极限,即香农极限。此限制告诉您对给定数据源的压缩程度。 此外,无法可靠地恢复压缩数据。 现代压缩算法与当今可用的快速处理器相结合,使用户能够接近香农极限。但是,他们永远不能跨越它。
有关香农限制的详细信息,请参阅以下文档:
答:硬件压缩和软件压缩是指应用压缩算法的路由器中的站点。在软件压缩中,它作为软件进程在主CPU中实现。 在硬件压缩中,压缩计算被卸载到辅助硬件模块。这使中央CPU不再受计算密集型压缩计算任务的影响。
如果假设路由器具有可用的时钟周期以执行压缩计算,则硬件压缩或软件压缩的效率没有差别。 实现的压缩比是所选择的压缩算法和要压缩的数据中的冗余量的函数。压缩计算不在此进行。
A.第2层负载压缩涉及对第2层WAN协议的负载进行压缩,如PPP、帧中继、高级数据链路控制(HDLC)、X.25和平衡链路访问过程(LAPB)。第2层报头未受压缩操作影响。但是,负载的整个内容(包括更高层协议报头)会被压缩。 按照How does data compression work?中所述,对它们进行压缩,并使用一种“stacker”算法(基于行业标准的Lemple Ziv算法;请参阅美国国家标准协会(ANSI) (文档X3.241-1994),或“predictor”算法,该算法是旧版配置中最常用的一种算法。
答:TCP/IP报头压缩删除了TCP/IP连接报头中的一些冗余字段。 报头压缩将原始报头的副本保存在链路的任意一端,删除完全冗余的字段,并对剩余字段进行差分编码,以便将报头的40字节压缩到平均5字节。这使用一种针对TCP/IP报头的恒定结构而设计的非常具体的算法。 它不会以任何方式触碰TCP数据包的负载。 请参阅RFC 1144,压缩低速串行链路的TCP/IP报头 。
答:TCP/IP报头压缩设计用于32 k或更低的慢速串行链路,并对性能产生显着影响。它需要具有小数据包大小的高交互性流量。 在此类流量中,第3层和第4层报头与负载的比率相对较高。因此,如果缩小报头,性能可以提高。
第2层负载压缩将所选压缩算法应用于包括TCP/IP报头的整个帧负载。 它设计用于以56 k到1.544 M的速度运行的链路。 它适用于所有类型的流量,只要流量之前未被更高层的应用压缩。
答:不。您不会同时实施第2层负载压缩和TCP/IP报头压缩,因为:
这是多余和浪费的。
通常,链路不接通或不传递IP流量。
仅使用第2层负载压缩,而不同时使用第2层负载压缩和TCP/IP报头压缩。
答:建议使用Cisco IOS®软件版本11.3T或12.0(mainline、S或T)系列中的最新版本,以确保硬件和软件兼容性。 此外,思科强烈建议您在WAN链路的两端运行相同版本的代码,以确保兼容性。
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系列路由器没有硬件压缩适配器。
答:思科硬件压缩适配器仅支持PPP stacker压缩和帧中继FRF.9 stacker压缩。 所有压缩适配器都支持这两种协议。 有关FRF.9规范的详细信息,请参阅帧中继论坛 网站,并在“帧中继”菜单下选择“实施协议”。
答:由于给定路由器的流量模式和潜在配置不同,因此没有简单的答案。
压缩对处理器非常密集,并且处理器利用率与您想要压缩的流量量成比例。 如果所讨论的路由器上已经运行了许多处理器密集型功能,则压缩时钟周期将很少。
压缩还需要内存来存储重建字典。因此,内存不足的路由器可能会出现问题。在中心辐射型配置中,中心通常需要压缩模块,而辐射型则不需要。
回答此问题的唯一方法是建议您分阶段实施压缩并监控处理器利用率。
答:当要压缩的接口位于通用接口处理器2(VIP2)插槽中时,可使用分布式压缩。然后,压缩计算会分流到VIP2处理器。
A.路由器默认为尽可能远离CPU卸载压缩计算。硬件压缩的整个点是从路由器CPU中卸下负载并将其放在硬件模块上。如果有可用的压缩模块,则用于压缩。 如果压缩模块不可用,并且所讨论的接口位于VIP2插槽中,则VIP2上的处理器用于压缩计算。 如果该处理器不可用,则压缩在软件中完成。 在压缩命令末尾指定软件、分布式或csa # 可以强制路由器分别使用主CPU、VIP2 CPU或硬件模块。
答:两个压缩服务适配器板载的处理器相同。唯一的区别在于板载内存。 它们可以处理相同流量,包括数据量和每秒数据包数(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个不同的“情景”。
一个上下文实质上是一个双向重建字典对,即一个点对点链路。 因此,每个帧中继点对点子接口都是一个情景。(更具体地说,每条虚电路都有一个与其关联的上下文,因为Cisco压缩基于“每数据链路连接标识符(DLCI)”工作。)
答:支持软件压缩的多链路PPP,包括带交织和压缩的多链路PPP。
在Cisco 7200和3600路由器上,Cisco IOS软件版本12.0(7)T和12.0(7)支持硬件压缩的多链路PPP。但是,Cisco 7500路由器不支持多链路PPP和压缩服务适配器(CSA)。
答:发出show compression命令和show interface 命令,以确定吞吐量、压缩数据包数和压缩比。
使用软件第2层负载压缩,思科仅支持先进先出(FIFO)队列,因为数据包在呈现到接口队列之前会被压缩。默认情况下,加权公平队列处于打开状态。要关闭它,您需要发出no fair-queue命令。
使用硬件第2层负载压缩,支持花式队列,因为数据包在压缩前排队,因此可成功分类。
答:当您运行软件压缩时,所有数据包都必须经过处理器,并且它们是进程交换的。 这就是压缩的工作方式。
答:在Cisco IOS软件版本12.0代码的早期版本中,Show compress已中断。 升级到Cisco IOS软件版本12.0(7)(mainline、S或T)以修复(CSCdk15127(仅注册客户))。这仅是表面问题。
答:这是Ascend框中默认配置的问题。请联系您的Lucent技术技术支持代表。
答:这是已知问题Cisco Bug ID CSCdk39968(仅注册客户)。解决方案是升级到Cisco IOS软件版本11.3(7)或更高版本的代码。
原因有很多:
如果链路处于关闭状态,请发出show compress命令以显示其运行软件压缩。 当链路接通时,它显示硬件压缩。 由于必须通过CCP进行PPP或通过FRF.9进程进行帧中继,命令显示了这一点。 要运行此协商,不能关闭链路。
当您使用某些早期版本的Cisco IOS软件在PPP上运行硬件压缩时,请不要键入compress stac以发出命令,必须键入ppp compress stac以发出命令。 这是早期命令语法的保留。
要在7500系列路由器中运行硬件压缩,压缩服务适配器必须与要压缩的接口位于同一VIP2中。 其他VIP2和接口处理器卡上的接口无法与压缩服务适配器通信。
A.压缩比小于1意味着压缩算法会增加数据的大小。它不会减小数据的大小。 这是由以下原因之一造成的:
如果尝试压缩已在较高层通过压缩算法的数据。压缩算法设计时假设存在要删除的冗余,并且算法会相应地执行计算。如果数据已经压缩,则已删除冗余,如果对同一数据应用其他压缩算法,则可能导致数据扩展。如果尝试压缩包含的第2层大数据包,则会出现此结果压缩数据。负载中唯一之前未压缩的部分是TCP/IP报头。 大数据包(如FTP)可以扩展,使总压缩比小于1。
压缩比小于1可能由过度负担的CPU造成。如果在没有执行必要计算周期的路由器上运行软件压缩,则进程将停止。这种情况的一个症状是压缩率小于1。唯一的解决方案是从某些链路中删除压缩,或安装硬件压缩模块。