本文档讨论ATM网络性能下降的一般原因和具体原因,以及帮助排除故障的步骤。本文档的重点是排除IP性能问题,特别是ATM网络的故障。通常,性能通过使用延迟和吞吐量来衡量。性能通常通过使用FTP或其他TCP/IP应用程序在两个终端设备之间传输文件,然后测量传输文件所花的时间来测试。当文件传输的吞吐量速率不等于ATM电路上的可用带宽时,这被视为性能问题。TCP窗口设置、MTU、丢包和延迟等许多因素决定了ATM电路中的吞吐量。本文档讨论影响ATM路由永久虚电路(PVC)、交换虚电路(SVC)和LAN仿真(LANE)实施性能的问题。性能问题的原因在路由PVC、SVC和LANE实施之间很常见。
本文档没有任何特定的要求。
本文档不限于特定的软件和硬件版本。
有关文件规则的更多信息请参见“ Cisco技术提示规则”。
排除任何性能相关问题故障的第一步是选择单个源设备和目标设备进行测试。确定问题发生的条件和未发生的条件。选择测试设备以降低问题的复杂性。例如,如果在经过两台路由器时出现问题,请勿在相距十跳的设备之间进行测试。
选择测试设备后,确定性能是否与TCP应用的固有特性有关,或问题是否由其他因素引起。在终端设备之间执行ping操作,以确定是否发生数据包丢失以及ping数据包的往返延迟。Ping测试应使用不同的数据包大小来完成,以确定数据包的大小是否影响数据包丢失。应该从测试的终端设备而不是路由器执行ping测试。从路由器执行ping操作时看到的往返时间(RTT)可能不准确。这是因为ping过程是路由器上的低优先级进程,它可能不会立即应答ping。
客户在纽约和洛杉矶之间有一条ATM PVC。虚电路(VC)的持续信元速率(SCR)配置为45 Mbps。客户使用FTP从FTP服务器向客户端传输文件来测试此电路,发现文件传输的吞吐量约为7.3 Mbps。当它们使用TFTP时,吞吐量会降至58 Kbps。客户端和服务器之间的ping响应时间约为70毫秒。
在本例中,首先要了解的是TCP在设备之间提供可靠的数据传输。发送方发送数据流中的数据,在数据流中,字节由序列号标识。接收方通过发送其预期接收的下一字节数据的序列号(确认号)来确认已收到数据。接收方还向发送方通告其窗口大小,以通告其可接受的数据量。
TCP/IP终端设备通常包括配置TCP/IP窗口大小的功能。
如果设备的TCP窗口大小设置得太低,则这些设备可能无法利用ATM VC的整个带宽。
如果窗口大小太小,ATM VC上的RTT可以显着降低TCP吞吐量。
终端设备每个RTT发送大约一个窗口大小的流量(以字节为单位)。
例如,如果RTT为70毫秒,则使用此公式计算填充整个DS3带宽所需的窗口大小:
.07s * 45 Mbps * 1字节/8位= 393,750字节
标准TCP允许最大窗口大小为64,000字节。如果两端的设备都支持此选项,并且FTP应用程序也支持此选项,则WINScale TCP选项允许窗口大小更大。
使用此公式将窗口大小设置为64,000字节,并使用RTT 70毫秒解决吞吐量问题。
.07x * 1字节/8位= 64000字节
其中x= 7.31428 Mbps
如果FTP应用程序仅支持32,000字节的窗口大小,请使用此公式。
.07x * 1字节/8位= 32000
其中x= 3.657142 Mbps
使用TFTP时,发送方发送512字节数据包,在发送下一个数据包之前,必须收到每个数据包的确认。最佳情况是每70毫秒发送1个数据包。使用此吞吐量计算。
1个数据包/.070s = 14.28571个数据包/秒
512字节/数据包* 8位/字节* 14.28571数据包/秒= 58.514 Kbps
此吞吐量计算表明,当链路使用TCP/IP应用来测量吞吐量时,链路上的延迟和TCP窗口大小会严重影响该链路的吞吐量。确定每个TCP连接的预期吞吐量。如果使用FTP测试吞吐量,请启动不同客户端和服务器之间的多个文件传输,以确定吞吐量是否受TCP/IP的固有性质限制,或ATM电路是否存在其他问题。如果TCP应用限制吞吐量,您应该能够同时发送多个以类似速率发送的服务器。
接下来,证明您可以以电路的SCR速率通过链路传输流量。为此,请使用不使用TCP的流量源和链路,并通过ATM VC发送数据流。另外,验证接收速率是否等于发送速率。从路由器发送扩展ping数据包,其超时值为0,以通过ATM电路生成流量。这证明您可以按照电路的配置速率通过链路发送流量。
解决方案:增加TCP/IP窗口大小。
重要信息:由于RTT非常小,窗口大到理论上足以填充SCR,因此ATM开销,您将永远无法到达SCR。如果考虑通过4 Mbps(SCR=PCR)AAL5SNAP PVC发送的512字节数据包的示例,请计算所测量的实际IP吞吐量。假设TCP窗口大小和RTT为源可以以4 Mbps的速率发送数据。首先,ATM自适应第5层(AAL5)和SNAP引入了每8个字节的开销。因此,可能需要填充以确保AAL5协议数据单元(PDU)可以被48除以。然后,在每个信元中,每个信元会引入5个字节的开销。在本例中,这意味着AAL5层为512+8+8=528字节(无需填充)。 这528字节需要传输11个信元。这意味着,对于要发送的每个512字节数据包,583字节在线路(11 * 53)上发送。 换句话说,将引入71字节的开销。这意味着IP数据包只能使用88%的带宽。因此,使用4 Mbps PVC,意味着可用IP吞吐量仅约为3.5 Mbps。
数据包大小越小,开销越大,吞吐量越低。
出现性能问题的最常见原因是ATM电路上的丢包。ATM电路上的任何信元丢失都会导致性能下降。丢包意味着重新传输,也意味着TCP窗口大小的减少。这会降低吞吐量。通常,简单的ping测试可确定两台设备之间是否丢失了数据包。ATM电路上的循环冗余校验(CRC)错误和信元/数据包丢包导致数据重新传输。如果ATM交换机因管制或缓冲区耗尽而丢弃ATM信元,则当信元重组为数据包时,终端设备上会出现CRC错误。当虚电路上的出站数据包速率超过虚电路上配置的流量整形速率时,ATM边缘设备可能会丢弃或延迟数据包。
有关排除ATM网络中数据包丢失最常见原因的详细信息,请参阅以下文档:
解决方案:排除故障并消除数据包丢失。
数据包从源到目的地传输,然后确认返回到发送方所花费的时间,会显着影响通过该电路看到的吞吐量。ATM电路上的延迟可能是正常传输延迟的结果。从纽约到华盛顿发送数据包所需的时间比从纽约到洛杉矶的时间要短,而ATM电路的速度相同。延迟的其他来源是通过路由器和交换机排队延迟以及通过第3层路由设备处理延迟。与路由设备相关的处理延迟在很大程度上取决于所使用的平台和交换路径。与路由延迟和内部硬件延迟相关的详细信息不在本文档的讨论范围之内。无论接口类型如何,此延迟都会影响任何路由器。与与数据包传输和队列相关的延迟相比,它也可忽略不计。但是,如果路由器处理交换流量,可能会导致严重延迟,因此必须考虑。
延迟通常通过在终端设备之间使用ping数据包来确定平均和最大往返延迟来测量。应在高峰使用期间以及非活动期间执行延迟测量。这有助于确定延迟是否可归因于拥塞接口上的排队延迟。
接口拥塞导致队列延迟。拥塞通常由带宽不匹配引起。例如,如果ATM交换机的电路从OC-12接口穿过DS3 ATM接口,则可能会遇到排队延迟。当信元到达OC-12接口的速度比DS3接口上的输出速度快时,就会发生这种情况。为流量整形配置的ATM边缘路由器限制其在接口上输出流量的速率。如果发往ATM VC的流量到达速率大于接口上的流量整形速率,则数据包/信元将在接口上排队。通常,通过排队延迟引入的延迟是导致性能问题的延迟。
解决方案:实施IP到ATM服务类别(CoS)功能,以实现差异化服务。利用基于类的加权公平队列(CBWFQ)和低延迟队列(LLQ)等功能来减少或消除任务关键型流量的排队延迟。增加虚电路的带宽以消除拥塞。
ATM PVC和SVC具有与每个电路关联的服务质量(QoS)参数。在ATM边缘设备和网络之间建立流量合同。使用PVC时,此合同在ATM网络(ATM交换机)中手动配置。 使用SVC时,ATM信令用于建立此合同。ATM边缘设备流量形状数据以符合指定的合同。ATM网络设备(ATM交换机)监控电路上的流量是否符合指定的合同和标记(标记)或丢弃(管制)不符合的流量。
如果ATM边缘设备的峰值信元速率(PCR)/SCR配置为高于网络中调配的速率,则很可能导致丢包。边缘设备上配置的流量整形速率应与通过网络配置的端到端速率相匹配。检验所有已配置设备的配置是否匹配。如果边缘设备向网络发送不符合在整个网络中调配的合同的信元,则通常会看到网络中丢弃的信元。这通常可以通过接收方尝试重组数据包时在远端收到CRC错误来检测。
具有PCR/SCR的ATM边缘设备配置为低于在网络中调配的速率,导致性能降低。在这种情况下,网络配置为提供比边缘设备发送的带宽更多的带宽。此情况可能导致边缘ATM路由器出口接口上出现额外的队列延迟甚至输出队列丢弃。
SVC在边缘设备上配置,但网络可能不会使用相同的流量参数建立SVC端到端。同样的概念和问题也适用于PVC的SVC。网络可能不会使用相同的QoS类和参数设置SVC端到端。此类问题通常由错误或互操作性问题引起。当发出SVC信号时,主叫方在前向和后向指定QoS流量整形参数。可能是被叫方没有使用正确的整形参数安装SVC。在路由器接口上配置严格流量整形可以防止SVC使用除已配置参数之外的整形参数进行设置。
用户必须跟踪SVC通过网络的路径,并验证是否使用始发设备上配置的QoS类和参数建立了该路径。
解决方案:消除流量整形/策略配置不匹配。如果使用SVC,请检验它们是否使用正确的整形/管制参数进行端到端设置。使用atm sig-traffic-shaping strict命令在ATM路由器接口上配置Strict Traffic Shaping。
为未指定比特率(UBR)配置的SVC可能通过非最佳路径进行设置。UBR VC的带宽限制为VC所经过链路的线速。因此,如果高速链路断开,通过该链路的VC可能会通过较慢的链路重新建立。即使恢复高速链路,VC也不会通过更快的链路断开和重新建立。这是因为较慢的路径满足所请求(未指定)的QoS参数。此问题在LANE网络中非常常见,因为LANE网络中有通过网络的备用路径。如果备用路径的链路速度相同,其中一个链路的故障会导致所有SVC都通过同一路径路由。由于网络的有效带宽减半,这种情况会严重影响网络的吞吐量和性能。
甚至可变比特率(VBR)和恒定比特率(CBR)SVC都可能通过非最佳路径进行路由。终端设备请求特定流量参数(PCR、SCR、最大突发大小{MBS})。 专用网络 — 网络接口(PNNI)和ATM信令的目标是提供满足请求QoS要求的路径。在CBR和VBR-rt呼叫中,这还包括最大信元传输延迟。路径可能满足请求方从带宽视点指定的要求,但不是最佳路径。当存在延迟较长的路径仍满足VBR和CBR VC的带宽要求时,此问题很常见。对于现在发现整个网络存在较大延迟特征的客户,这可能被视为性能问题。
解决方案:ATM网络中的SVC是按需建立的,通常不会在不同路径上断开和重新路由,除非SVC被断开(由于不活动或因其他原因释放)。 Cisco LightStream 1010和Catalyst 8500 ATM交换机提供软PVC路由优化功能。当有更好的路由可用时,此功能可以动态重新路由软PVC。不在ATM交换机上终止的SVC不提供类似的功能。
解决此问题的一个可能解决方案是在ATM边缘设备和连接的ATM交换机之间使用PVC。在ATM交换机之间配置了路由优化的软PVC能够在链路故障和后续恢复后从非最佳路径重新路由流量。
将SVC的空闲超时间隔配置为低,以便SVC断开并更频繁地重新建立。使用idle-timeout seconds [minimum-rate]命令更改导致SVC断开的时间和流量速率。由于VC必须处于非活动状态才能通过最佳路径重新路由,因此这可能不太有效。
如果所有其它路径都发生故障,请确保最佳路径已恢复为运行,然后退回与慢速冗余路径关联的一个ATM接口或终止SVC的一个路由器接口。
PA-A1 ATM端口适配器的架构和板载内存不足会导致性能下降。此问题可能在接口上的abort、overrun、ignores和CRC中表现出来。与带NPE-100/175/225/300的Cisco 7200路由器一起使用时,问题会更加严重。
有关其他信息,请参阅排除PA-A1 ATM端口适配器上的输入错误故障。
解决方案:用PA-A3(至少修订版2)或PA-A6 ATM端口适配器替换PA-A1 ATM端口适配器。
PA-A3硬件修订版1不会将单元重组为使用端口适配器上的板载静态RAM(SRAM)的数据包。适配器通过外围组件互连(PCI)总线将信元转发到通用接口处理器(VIP)或网络处理引擎(NPE)主机内存,在该内存中重组数据包。这会导致与PA-A1 ATM端口适配器类似的性能相关问题。
有关其他信息,请参阅PA-A3 ATM端口适配器上的输入和输出错误故障排除。
解决方案:将PA-A3硬件修订版1 ATM端口适配器更换为PA-A3(至少修订版2)或PA-A6 ATM端口适配器。
PA-A3-OC3SMM、PA-A3-OC3SMI和PA-A3-OC3SML旨在在单个VIP2-50中安装单端口适配器时提供最大交换性能。单个PA-A3-OC3SM、VIP2-50中的PA-A3-OC3SMI或PA-A3-OC3SML使用64字节数据包,在每个方向提供高达每秒85,000个数据包的交换容量。请注意,单个PA-A3-OC3SMM、PA-A3-OC3SMI或PA-A3-OC3SML可单独使用单个VIP2-50的整个交换容量。
对于需要最大端口密度或更低系统成本的应用,现在支持在同一VIP2-50中使用OC-3/STM-1版本PA-A3的双端口适配器配置。同一VIP2-50中的两个端口适配器使用64字节数据包在每个方向上共享大约95,000个数据包/秒的交换容量。
VIP-50根据端口适配器组合提供高达400兆位/秒(mbps)的聚合带宽。在大多数双端口适配器配置中,PA-A3-OC3SMM、PA-A3-OC3SMI或PA-A3-OC3SML,端口适配器的组合超过此聚合带宽容量。
因此,在同一VIP2-50中安装的两个端口适配器之间共享的性能受小数据包大小的聚合交换容量(95 kpps)和大数据包大小的聚合带宽(400 mbps)的限制。
当您使用PA-A3-OC3SMM、PA-A3-OC3SMI或PA-A3-OC3SML指定ATM网络时,必须考虑这些性能警告。根据设计,同一VIP2-50中双端口适配器的性能可能可接受,也可能不可接受。
有关其他信息,请参阅支持的PA-A1和PA-A3 VIP2配置。
单个LANE ELAN中终端系统数量过多会显着降低所有终端站的性能。ELAN代表广播域。ELAN内的所有工作站和服务器都会收到广播,可能还会收到来自ELAN内所有其他设备的组播流量。如果广播流量的级别相对于工作站的处理能力很高,则工作站的性能会受到影响。
解决方案:将单个ELAN中的终端站数限制为少于500个。监控网络是否存在可能对服务器/工作站性能造成不利影响的广播/组播风暴。
有关其他信息,请参阅LANE设计建议。
导致LANE网络性能差的其他问题是过多的LANE ARP(LE-ARP)活动和生成树拓扑更改。这些问题导致未解析的LE-ARP,这些LE-ARP导致通过总线发送的流量。这还可能导致网络中LEC的CPU使用率较高,这也可能导致性能相关问题。有关这些问题的详细信息,请参阅LANE生成树故障排除。
在连接LANE的以太网交换机的主机端口上配置生成树PortFast,以减少生成树拓扑更改。在为LANE配置的Catalyst 5000和6000交换机上配置本地LE-ARP重新验证,以减少LE-ARP流量。
使用LANE版本1,SVC设置为UBR服务类别。LANE第2版支持使用VBR-nrt等其他服务类别建立Data Direct SVC。一个第三方供应商的LANE客户端实施中存在一个漏洞,可能导致设置到Cisco设备的Data Direct SVC为VBR-nrt,SCR为4 Kbps。如果您的ATM主干由OC-3(155 Mbps)和OC-12(622 Mbps)中继链路组成,并且您在这些中继上设置了SVC,信元持续速率为4 Kbps,那么您的性能将受到影响。虽然此特定问题并不常见,但它指出了排除ATM电路性能问题时的重要需求。您必须跟踪SVC通过网络的路径,并确认VC已使用所需的服务类别和流量参数建立。
LANE数据直接虚电路是两个LAN仿真客户端(LEC)之间设置的双向点对点SVC,用于在这些客户端之间交换数据。LANE客户端发送LE-ARP请求以获取与MAC地址关联的ATM地址。然后,他们尝试设置到该ATM地址的Data Direct VC。在建立Data Direct VC之前,LANE客户端将未知单播数据包泛洪到广播和未知服务器(BUS)。LANE客户端可能无法建立到另一LEC的Data Direct VC,以便向其发送单播数据。如果发生这种情况,则可能导致性能下降。如果选择执行BUS服务的设备电源不足、供电不足或过载,则问题非常严重。此外,某些平台可能会限制转发到BUS的单播速率。Catalyst 2900XL LANE模块是一种限制发送到总线的单播流量的盒,而Catalyst 5000和Catalyst 6000则不限制。
Data Direct SVC可能因以下任何原因无法建立或使用:
LEC不会收到对LE-ARP请求的响应。
由于ATM路由或信令问题,无法创建SVC。
LANE刷新消息协议失败。建立Data Direct VC后,LEC在组播发送VC上发送刷新请求,以确保通过总线发送的所有数据帧都到达其目的地。当发送刷新请求的LEC收到回复响应时,它开始通过Data Direct VC发送数据。可以使用no lane client flush命令禁用刷新机制。
反向多路复用(IMA)接口上的UBR VC的PCR为1.5 Mbps,而不是IMA组中配置的所有上/上物理接口的总和。这种情况会降低性能,因为VC的流量整形速率低于IMA组中所有链路的总带宽。
最初,IMA组接口的带宽限制为使IMA接口保持运行所需的最小活动IMA链路数。用于定义此值的命令是IMA active-links-minimum。例如,如果四个物理ATM接口配置为IMA组0的成员,并且IMA active-links-minimum值设置为1,则带宽等于1 T1或1.5 Mbps,而不是6 Mbps。
Cisco Bug ID CSCdr12395(仅注册客户)更改此行为。PA-A3-8T1IMA适配器现在使用配置为IMA组成员的所有up/up ATM物理接口的带宽。
Cisco Bug ID CSCdt67354(仅注册客户)(CSCdv67523 (仅注册客户)是在接口从IMA组添加或移除、关闭/关闭时更新IMA组VC带宽的后续增强请求或因链路故障而退回,或在远程端更改。Cisco Bug IDCSCdr12395(仅限注册客户)中实施的更改仅在IMA组启动时将IMA组带宽配置为其成员链路的总带宽。初始启动状态后对IMA组的更改不会反映。
有关其他信息,请参阅7x00 IMA端口适配器上的ATM链路故障排除。
版本 | 发布日期 | 备注 |
---|---|---|
1.0 |
04-Aug-2004 |
初始版本 |