Committed Access Rate (CAR) 是一种速率限制功能,可用于提供分类和策略服务。CAR 可用于基于特定条件(如使用访问列表的 IP 地址和端口值)对数据包进行分类。可以定义符合速率限制值和超出该值的数据包操作。有关如何配置 CAR 的详细信息,请参阅配置承诺接入速率。
本文档说明当 conformed bps 值小于配置的承诺信息速率 (CIR) 时 show interface x/x rate-limit 命令的输出显示 non-zero exceeded bps 值的原因。
本文档没有任何特定的要求。
本文档不限于特定的软件和硬件版本。
有关文档规则的详细信息,请参阅 Cisco 技术提示规则。
三种情况下可以在此命令的输出中看到非零超出速率:
突发值设置得太低以致吞吐率不足。例如,请参阅Cisco Bug ID CSCdw42923(仅限注册客户)。
已解决 Cisco IOS® 软件中的双重记帐问题
Cisco IOS 中的软件 Bug
查看来自虚拟访问接口的示例输出。在此配置中,使用 RADIUS 对动态创建的虚拟访问接口指定速率限制。
AV Pair from Radius Cisco-AVPair = "lcp:interface-config#1=rate-limit input 256000 7500 7500 conform-action continue exceed-action drop", Cisco-AVPair = "lcp:interface-config#2=rate-limit output 512000 7500 7500 conform-action continue exceed-action drop",
使用 show interface x rate-limit 命令可监控 Cisco 旧监察器 CAR 的性能。在以下示例中,该命令的输出对为什么存在非零超出 bps 提供了说明。当前突发值为 7392 字节,而限制值指示的承诺突发 (Bc) 值设置为 7500 字节。
router#show interfaces virtual-access 26 rate-limit Virtual-Access26 Cable Customers Input matches: all traffic params: 256000 bps, 7500 limit, 7500 extended limit conformed 2248 packets, 257557 bytes; action: continue exceeded 35 packets, 22392 bytes; action: drop last packet: 156ms ago, current burst: 0 bytes last cleared 00:02:49 ago, conformed 12000 bps, exceeded 1000 bps Output matches: all traffic params: 512000 bps, 7500 limit, 7500 extended limit conformed 3338 packets, 4115194 bytes; action: continue exceeded 565 packets, 797648 bytes; action: drop last packet: 188ms ago, current burst: 7392 bytes last cleared 00:02:49 ago, conformed 194000 bps, exceeded 37000 bps
如果通过 Cisco 基于类的策略配置 CAR 或更新的监察器,则必须配置足够高的突发值,才能确保需要的吞吐量,以及确保监察器仅为了惩罚短期拥塞才丢弃数据包。
选择突发值时,务必适应队列大小的瞬时增加。不能简单地假定数据包在相同的时间到达和离开。您也不能假定队列从空状态转变为包含一个数据包,并且该队列基于一致的一进/一出到达时间保持包含一个数据包状态。如果典型流量非常具有突发性,则突发值也需要相应地提高,以便链路利用率保持在可接受的高水平。突发大小太低或最低阈值太低都会导致不可接受的低链路利用率。
突发流量可以简单地定义为一系列背靠背的 MTU 大小的帧,例如源自以太网的 1500 字节的帧。当此类突发帧到达输出接口时,可能会使输出缓冲区过载并瞬时超过令牌桶的配置深度。使用令牌计量系统时,监察器会做出有关到达的数据包是否符合、超过或违反配置的策略值的双值决策。出现突发流量(如 FTP 数据流)时,这些数据包的瞬时到达速率会超过配置的突发值并导致 CAR 丢包。
此外,拥塞时的总体吞吐量会随着监察器评估的流量类型不同而有所不同。如果 TCP 流量对拥塞做出响应,则其他流量不会响应。基于 UDP 的数据包和基于 ICMP 的数据包即是非响应流量。
TCP 基于对重新传输的肯定确认。TCP 使用滑动窗口作为其肯定确认机制的一部分。滑动窗口协议可以更好地利用网络带宽,原因是它们允许发送者在等待确认之前传输多个数据包。例如,在窗口大小为 8 的滑动窗口协议中,允许发送者在收到确认之前传输 8 个数据包。如果增加窗口大小,则会大大减少网络空闲时间。精心调整的滑动窗口协议可使网络中的数据包保持饱和状态并保持较高的吞吐量。
由于终点不知道网络的具体拥塞状态,作为一种协议的 TCP 设计为通过在发生拥塞时降低传输速率来对网络拥塞做出反应。具体来说,它使用两种方法:
技术 | 描述 |
---|---|
成倍降低速率避免拥塞 | 在发生数据段(等效为 TCP 数据包)丢失时,将拥塞窗口减小一半。拥塞窗口为秒值,或者是用于限制发送者在等待确认之前向网络中传送的数据包数量的窗口。 |
缓慢启动恢复 | 当通过新连接传送流量或在拥塞一段时间之后增加流量时,请按照单个数据段的大小启动拥塞窗口,并在每次确认到达时将拥塞窗口增加一个数据段。TCP 会将拥塞窗口初始化为 1,发送初始数据段,然后等待。当确认达到时,它会将拥塞窗口增加到 2,发送两个数据段,然后等待。有关更多详细信息,请参阅 RFC 2001。 |
当数据受到传输错误干扰,网络硬件出现故障,或者网络负载过大以致不能适应出现的负载时,数据包可能会丢失或被破坏。TCP 将假定以下情况下表示网络出现拥塞:数据包丢失或者由于极大延迟数据包未能在时间间隔内确认。
每次数据包到达时都将调用监察器的令牌桶计量系统。具体来说,将基于以下简单公式计算符合速率和超出速率:
(conformed bits since last clear counter)/(time in seconds elapsed since last clear counter)
由于该公式计算从上次清除计数器起一段时间内的速率,Cisco 建议清除计数器以便计算当前速率。如果未清除计数器,则先前的公式速率实际意味着 show command output 显示基于可能很长一段时间计算的平均值,并且该值对于确定当前速率可能没有意义。
平均吞吐量应与配置的一段时间内的承诺信息速率 (CIR) 匹配。突发大小使得可以在给定时间点保持一定的最大突发持续时间。如果没有流量或小于 CIR 的流量值并且令牌桶未填满,则较大的突发流量仍限制为基于正常突发流量和扩展突发流量计算的特定大小。
此机制导致的丢包率
记下当前时间。
使用自上次数据包到达时持续累计的令牌数更新令牌桶。
累计的令牌总数不能超过 maxtokens 值。丢弃多余的令牌。
检查数据包符合性。
通过策略也可以实现速率限制。以下是一个配置示例,用于对使用基于类的策略的以太网接口提供速率限制。
class-map match-all rtp1 match ip rtp 2000 10 ! policy-map p3b class rtp1 police 200000 6250 6250 conform-action transmit exceed-action drop violate-action drop policy-map p2 class rtp1 police 250000 7750 7750 conform-action transmit exceed-action drop violate-action drop ! interface Ethernet3/0 service-policy output p3b service-policy input p2
以下示例输出产生于 show policy-map interface 命令,说明针对提供的速率和丢包率以及符合速率和超过 bps 速率而正确计算和同步的值。
router#show policy-map interface ethernet 3/0 Ethernet3/0 Service-policy input: p2 Class-map: rtp1 (match-all) 88325 packets, 11040625 bytes 30 second offered rate 400000 bps, drop rate 150000 bps Match: ip rtp 2000 10 police: 250000 bps, 7750 limit, 7750 extended limit conformed 55204 packets, 6900500 bytes; action: transmit exceeded 33122 packets, 4140250 bytes; action: drop conformed 250000 bps, exceed 150000 bps violate 0 bps Service-policy : p3b Class-map: rtp1 (match-all) 88325 packets, 11040625 bytes 30 second offered rate 400000 bps, drop rate 50000 bps Match: ip rtp 2000 10 police: 200000 bps, 6250 limit, 6250 extended limit conformed 44163 packets, 5520375 bytes; action: transmit exceeded 11041 packets, 1380125 bytes; action: drop conformed 200000 bps, exceed 50000 bps violate 0 bps Class-map: class-default (match-any) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: any
下表列出了 show policy-map 或 show interface rate-limit 命令显示的计数器的已解决问题。已登录的注册客户可以在Bug搜索工具中查看Bug信息。
症状 | 已解决的 Bug ID 和解决方法 |
---|---|
低于预期的丢弃计数器 |
|
使预期的丢包率和吞吐量加倍 |
|
没有丢弃或零丢包率 | 一般来说,当应用基于类的 QoS 功能时,故障排除的第一步是确保 QoS 分类机制可正常工作。换句话说,请确保类映射的匹配语句中指定的数据包指向正确的类。 router#show policy-map interface ATM4/0.1 Service-policy input: drop-inbound-http-hacks (1061) Class-map: http-hacks (match-any) (1063/2) 149 packets, 18663 bytes 5 minute offered rate 2000 bps, drop rate 0 bps Match: protocol http url "*cmd.exe*" (1067) 145 packets, 18313 bytes 5 minute rate 2000 bps Match: protocol http url "*.ida*" (1071) 0 packets, 0 bytes 5 minute rate 0 bps Match: protocol http url "*root.exe*" (1075) 4 packets, 350 bytes 5 minute rate 0 bps Match: protocol http url "*readme.eml*" (1079) 0 packets, 0 bytes 5 minute rate 0 bps police: 1000000 bps, 31250 limit, 31250 extended limit conformed 0 packets, 0 bytes; action: drop exceeded 0 packets, 0 bytes; action: drop violated 0 packets, 0 bytes; action: drop conformed 0 bps, exceed 0 bps violate 0 bps
|
异常或不一致的丢包率 |
|
版本 | 发布日期 | 备注 |
---|---|---|
1.0 |
15-Feb-2019 |
初始版本 |