• 文章搜索:
  • 目录

        • 分享到...

        • 新浪微博
        • 腾讯微博
        • 推荐到豆瓣 豆瓣空间
        • 分享到搜狐微博 搜狐微博
        • 分享到QQ空间 QQ空间
        • 分享到腾讯朋友 腾讯朋友
        • 网易微博分享 网易微博
        • 添加到百度搜藏 百度搜藏
        • 转贴到开心网 开心网
        • 转发好友 告诉聊友
    • 推荐
    • 打印
    • 收藏

    H3C广域网智能流控设计与应用

    作者:  |  上传时间:2011-04-22  |  关键字:网络大爬虫4-QoS专题

    文/尹建华

    1. 智能流控概述

    1.1. 广域流量调度的挑战

    流量调度是网络基础设计之一,其重要性就如同开车上路,除了关注怎样到目的地之外,还要关注路况,比如道路是否畅通、路面是否湿滑等等。流量调度就是信息高速公路上的路况设计和调度管理,它与链路性质和带宽、路由设计、QoS策略实施、流量和质量监管等这些因素密切相关。

    随着企业信息业务的不断丰富,数据大集中已经成为IT建设的趋势,在广域网带宽紧张、成本昂贵的情况下,如何解决带宽与业务之间的矛盾,打造快速、稳定、高质量的广域网络,进行良好的流量调度设计就显得尤为重要。

    传统的流量调度设计,主要存在这三方面的问题和挑战:

     业务质量:采用一般的QoS队列调度,链路拥塞时,由于报文排队的原因,业务会出现十几、甚至几十倍的延迟和抖动。这就是为什么采用了QoS设计却仍然出现质量明显下降的问题所在。如何让业务流量始终平滑是所有QoS设计的关键所在。

     链路效率:随着企业广域网络的发展,双链路承载已经成为高可靠设计和带宽扩容的不二选择。而传统基于单接口、单链路的QoS设计,往往造成主链路业务繁忙,而备链路利用不足的严重带宽浪费现象。

     带宽公平:多数企业都有分支机构或远程接入点,在这些分支机构内,由于某个员工收email附件或者BT下载导致的其他人员上网慢,甚至业务中断的现象屡见不鲜。如何保证重要业务的质量和公平的给每个员工分配上网带宽,而且能在员工不上网时释放带宽给其他人用,这也是传统广域流量调度存在的一大难题。

    本文广域网智能流量调度将针对以上三大挑战进行优化设计。

    1.2. 智能流控的价值理念

    智能流控,旨在通过流量调度和管理的技术创新,实现动态、精确的流量控制,从而提升业务质量和链路资源利用效率。

    智能流控的价值理念:更高效、更精确、更方便。

    智能流控,智在哪里,有何创新?

     高效的调度技术:对令牌机制创新的分层CAR技术,实现了PQ、CQ、CBQ等传统的调度策略,不仅简化了QoS调度设计,还几倍、十几倍的降低了业务流的时延和抖动,显著提升了业务传输质量水平。

     虚拟的带宽资源:入接口分层CAR部署,配合策略路由动作,创新实现了多端口或链路的流量统一调度设计,虚拟化了链路资源,是对单链路QoS的一个飞跃。

     SDHIP的特质:入接口分层CAR和出接口共享带宽限制设计,为企业提供了在多部门间带宽预留和共享的方案。该方案不仅继承了IP承载的带宽共享特征,保证了带宽利用效率,又体现了SDH传输的带宽独占的可靠承载要求。

     动态令牌桶技术:基于在线流量检测的动态令牌桶,结合分层CAR,支持500个以上在线IP终端的带宽公平分配和保证。这是QoS队列所无法做到的。

    1.3. 如何在广域网中应用

    广域网应用场景

    智能流控关键技术

    分层

    CAR

    动态

    CAR

    负载分担

    低时延抖动调度设计

    双链路统一调度设计

    园区出口公平带宽设计

    多部门带宽独占和共享

    专线双出口负载分担

    可选

    智能流控设计与关键技术

    智能流量调度设计和技术,可以应用于广域网基本QoS设计、双链路流量调度设计、广域网园区或分支出口流量调度设计、广域多部分带宽独占和共享需求设计、精细化QoS设计等常见广域网络和业务应用场景中。

    2. 智能流控技术

    2.1. 分层CAR:

    普通CAR技术:CAR作为流量监管的技术,就是对流量进行控制,通过监督进入网络的流量速率,对超出部分的流量进行“惩罚”,使进入的流量被限制在一个合理的范围之内,以保护网络资源和用户的利益。

    CAR技术原理:采用令牌桶控制流量,当令牌桶中存有令牌时,可以允许报文取令牌进行传输;当令牌桶中没有令牌时,报文必须等到桶中生成了新的令牌后才可以继续发送。这就限制了报文的流量不能大于令牌生成的速度,达到了限制流量,同时允许突发流量通过的目的。例如可以限制HTTP报文不能占用超过50%的网络带宽。如果发现某个连接的流量超标,流量监管可以选择丢弃报文,或重新配置报文的优先级。

    分层CAR技术:相比单层CAR,分层CAR是一种更灵活的流量监管策略,用户可以在为每个流单独配置单层CAR动作的基础上,再通过分层CAR(第二次CAR)对多个业务的流量总和进行限制,实现带宽的二次分配。那么,分层CAR对已经做过普通CAR的各业务流是如何处理的呢?

    首先,分层CAR的处理对象是:普通CAR处理后的,且动作选择为continue的报文。因为只有经过了普通CAR处理后,报文才有红绿颜色之分;并且只有选择了continue,而不是pass或者discard,因为这两个都做就直接对报文转发走了,或者丢弃了,没有机会进入分层CAR的二次令牌发放过程。

    其次,分层CAR的令牌发放遵循两个原则:第一、先给绿色报文发放,后给红色报文发放;第二,在第一原则基础上,对红绿报文,均按照各业务普通CAR的配置顺序进行发放,直到发完为止。

    注意事项:分层CAR是对已经着色的流量进行处理,如果在CAR的处理流量中只是未着色流量,那么该CAR就按照普通CAR进行处理。但如果CAR处理的流量对象既有着色后的流量,也有未经过CAR处理后的未着色流量,那么CAR会同时对绿色流量和未着色流量进行优先处理,然后对红色流量进行令牌分配(如果令牌富余的话),会导致分层CAR的处理混乱,无法按照预先的设计进行绿色流量的准确调度控制,因为中间混合了未着色流量。所以分层CAR的处理对象,务必确保都是已经完全着色,也就是经过至少一次CAR处理后的流量。

    分层CAR令牌发放顺序

    业务ABC绿色报文、业务ABC红色报文

    举例:

    1.配置示意:

    qos car acl3000 cir 1024Kbps green continue red discard

    qos car acl3001 cir 2048Kbps green continue red continue

    qos car acl3002 cir 3072Kbps green continue red continue

    qos car acl3003 cir 6144Kbps green pass red discard

    2.业务说明:

    acl3000为业务A,acl3001为业务B,acl3002为业务C,acl3003为业务A+B+C。因为acl3003包含了ABC三种业务,且前面三种业务都有流量选择了continue动作,因此实际上最后一条car对前面continue的流量操作就是分层car的处理。分层car是一种内部处理机制,命令字与普通car是相同的。

    3.转发情况:

    业务瞬间进入流量

    实际转发的流量

    业务A

    业务B

    业务C

    业务A

    业务B

    业务C

    1M

    2M

    3M

    1M

    2M

    3M

    0.5M

    2.5M

    3M

    0.5M

    2.5M

    3M

    0M

    2.5M

    3.5M

    0M

    2.5M

    3.5M

    1.5M

    1.5M

    5M

    1M

    1.5M

    3.5M

    1M

    5M

    3M

    1M

    2M

    3M

    从上面表格中可以看出,分层CAR对令牌的发放顺序对各个业务之间的带宽分配(通过令牌分发)起到了关键作用。正因为分层CAR这种令牌发放原则,使得其成为了QoS队列的一种替代设计。在本例中,ABC业务的普通CAR实际上是一种按比例分配带宽的CQ机制,而ABC的分层CAR则体现了在CQ机制上的,超出流量的优先抢占的PQ关系。

    2.2. 动态CAR:

    动态CAR是对预先指定的IP地址范围,进行流量的动态检测,如果有该IP范围内新的IP地址的流量产生,系统会动态产生一个基于该IP的令牌桶(CAR),并对其限速;当该IP地址不再产生流量后,该令牌桶自动消失,从而减少对系统令牌桶资源的占用。

    另外,动态CAR可以和分层CAR进行结合,实现同一IP地址范围内的在线IP流量之间的公平带宽分配和抢占。

    下面举例说明:

    举例1:IP地址带宽限制

    1.配置示意:

    [Sysname] qos carl 1 source-ip-address subnet 1.1.1.0 24 per-address

    [Sysname] interface ethernet1/1

    [Sysname-Ethernet1/1] qos car outbound carl 1 cir 100 cbs 6250 ebs 0

    2.业务说明:

    在接口Ethernet1/1的出方向上应用CARL规则1。CARL规则1是对源地址属于子网1.1.1.0/24内每台PC限速100kbps,网段内各IP地址的流量不共享剩余带宽。

    举例2:IP地址带宽公平分配

    1.配置示意:

    [Sysname] qos carl 2 source-ip-address range 1.1.2.100 to 1.1.2.199 per-address shared-bandwidth

    [Sysname] interface ethernet1/1

    [Sysname-Ethernet1/1] qos car outbound carl 2 cir 5000 cbs 3125 ebs 31250

    2.业务说明:

    在接口Ethernet1/1的出方向上应用CARL规则2。CARL规则2是对源地址属于IP地址段1.1.2.100~1.1.2.199内所有PC限速5Mbps,网段内各IP地址的流量共享剩余带宽。比如,初始只有1.1.2.100这台PC上线,网速可以达到5Mbps;接着,1.1.2.199这台PC也上线了,如果后上线这台PC有2.5M以上的流速需求,那么,通过系统内部动态CAR+分层CAR机制,这两台PC流速都会变成2.5Mbps;同样,第三台上线后,每台PC的流量为5Mbps/3=1.67Mbps。如果有一台PC下线了,那么其他的PC流速就会提升上来,达到5Mbps/n,n为实际在线PC数量,而不是配置的IP地址范围的数量。

    动态CAR机制是通过CARL的per-address参数体现出来的。而动态CAR结合分层CAR实现带宽公平分配,则还要通过设置shared-bandwidth参数来实现。

    2.3. 负载分担:

    负载分担的实现方式有以下几种:

     基于流的负载分担:使能了快速转发功能后只能进行基于流的负载分担。例如,当前设备上存在两条等价路由,如果有一条数据流经过,那么将从其中一条路由上转发;如果有两条数据流经过,那么这两条等价路由分别转发这两条数据流。

     基于报文的负载分担:关闭了快速转发功能后进行基于报文负载分担,即将待发送报文均匀分配到两条等价路由上。

     基于带宽的负载分担:关闭了快速转发功能后,报文按接口物理带宽进行负载分担(即基于报文的负载分担);当用户为接口配置了指定的负载带宽后,设备将按用户指定的接口带宽进行负载分担,即根据各接口物理带宽比例关系进行分配。

     基于用户的负载分担:设备上存在多条等价路由时,可以根据报文中的用户信息(源IP地址)对流量进行负载分担。

    对于广域网双链路,采用基于流的负载分担,或采用基于带宽的非平衡负载分担(多用于双专线带宽不相等的情况)对提升广域链路利用率有很大意义。但需要注意的是,基于带宽的负载分担不适合Internet出口做NAT情况下的分担,因为基于带宽的负载分担只能基于报文,会出现同一个流采用不同的公网源地址转发的情况。

    3. 应用实践设计

    3.1. 低时延低抖动QoS设计

    3.1.1. 设计描述:

    本设计为采用分层CAR技术实现的QoS队列调度设计,同时与传统CBQ队列调度技术进行实测性能比较,旨在为用户提供一种全新、简单、具有性能优势的QoS设计方案。

    3.1.2. 设计组网:

    单台SR66的单一物理接口(5*E1线路,10M)进行验证。

    3.1.3. 关键配置:

    基本业务流定义:

    acl number 3511 //video

    rule 10 permit ip source 172.16.2.11 0.0.0.7

    acl number 3521 //produce

    rule 10 permit ip source 172.16.2.21 0.0.0.7

    acl number 3531 //others

    rule 10 permit ip source 172.16.2.31 0.0.0.7

    acl number 3550 //all, include video/produce/others

    rule 10 permit ip source 172.16.2.11 0.0.0.7

    rule 20 permit ip source 172.16.2.21 0.0.0.7

    rule 30 permit ip source 172.16.2.31 0.0.0.7

    对比方案一:入接口分层CAR设计:

    interface Pos4/1/0

    link-protocol ppp

    ip address 100.1.7.2 255.255.255.0

    qos car inbound acl 3511 cir 4096 green continue red discard

    qos car inbound acl 3521 cir 4096 green continue red continue

    qos car inbound acl 3531 cir 512 green continue red continue

    qos car inbound acl 3550 cir 8704 green pass red discard

    对比方案二:出接口CBQ设计:

    traffic classifier video

    if-match acl 3511

    traffic classifier produce

    if-match acl 3521

    traffic behavior video

    queue ef bandwidth 4096 cbs 102400

    traffic behavior produce

    queue af bandwidth 4096

    qos policy flow-assign

    classifier produce behavior produce

    classifier video behavior video

    interface Mp-group4/0/0

    qos reserved-bandwidth pct 100

    qos apply policy flow-assign outbound

    3.1.4. 设计效果:

    视频流丢包率对比结果:

    Video

    (Mbps)

    Produce

    (Mbps)

    Others

    (Mbps)

    Video Packet Loss Ratio

    分层CAR结果

    CBQ结果

    1.67

    6

    4

    0%

    0%

    2.50

    6

    4

    0%

    0%

    3.33

    6

    4

    0%

    0%

    4.17

    6

    4

    1.75%

    4.59%

    5.00

    6

    4

    19.36%

    20.59%

    生产流丢包率对比结果:

    Produce

    (Mbps)

    Video

    (Mbps)

    Others

    (Mbps)

    Produce Packet Loss Ratio

    分层CAR结果

    CBQ结果

    1.67

    6

    4

    0%

    0%

    2.50

    6

    4

    0%

    0%

    3.33

    6

    4

    0%

    0%

    4.17

    6

    4

    3.05%

    2.57%

    5.00

    6

    4

    20.46%

    18.82%

    丢包率分析:从以上结果看,分层CAR和CBQ设计,对报文的丢包率都比较接近。

    视频流时延对比结果:

    Video

    (Mbps)

    Produce

    (Mbps)

    Others

    (Mbps)

    Video Packet Latencyms

    分层CAR

    CBQ

    1.67

    6

    4

    1.74

    6.43

    2.50

    6

    4

    1.83

    6.57

    3.33

    6

    4

    2.08

    6.74

    4.17

    6

    4

    4.86

    6.93

    5.00

    6

    4

    6.38

    6.94

    生产流时延对比结果:

    Produce

    (Mbps)

    Video

    (Mbps)

    Others

    (Mbps)

    Produce Packet Latencyms

    分层CAR

    CBQ

    1.67

    6

    4

    9.05

    7.81

    2.50

    6

    4

    6.42

    8.00

    3.33

    6

    4

    4.02

    8.58

    4.17

    6

    4

    3.99

    18.98

    5.00

    6

    4

    5.77

    33.50

    时延和抖动分析:视频业务,分层CAR比CBQ的EF加速转发的调度时延偏小,但EF队列的平均时延比较稳定。生产业务,分层CAR相比CBQ AF确保转发的调度,时延和抖动都要明显小得多,尤其当生产业务流量超出AF确保带宽4M后,其时延明显放大,而分层CAR设计时延没有明显变化。

    从对比结果看:分层CAR作为新型的流量调度技术,拥有与传统队列调度技术相似的调度效果,而且时延和抖动控制方面,尤其相对AF确保转发调度,具有明显的优势。在配置方面,分层CAR设计则更为简单、灵活。

    3.2. 带宽预留和共享下的QoS设计

    SDH和IP技术在带宽分配方面,前者适合对不同业务分配通道和带宽进行隔离,但各业务之间无法同时做到带宽共享;而IP技术则正相反,业务之间可以共享带宽,但很难实现带宽预留,而不让其他业务占用。对于某些企业的广域网建设,往往既需要各部门都拥有一定的预留带宽,用以保证本部门重要业务,任何时刻不能被其他部门占用;也需要部门之间能够对大部分带宽进行共享,保证总体的带宽利用效率;在此带宽预留和共享的设计之上,如果还要对部门内的不同业务进行良好的QoS设计,一般的IP QoS设计是难以做到的。我们通过下面这个分层CAR的设计来实现上述需求。

    3.2.1. 设计描述:

    在地区A、B的核心路由器之间的155M链路上,流量调度设计要求如下:

     为部门1、部门2重要业务预留一定带宽各为40M,超出40M的数据走75M共享数据队列进行共有带宽抢占;

     各部门视频预留10M并优先转发,超出10M的部分进行丢弃;

     为保证视频质量的稳定,要求10M视频流占用部门预留带宽,而绝对不能走共享带宽;

     在部门预留带宽内,视频流量实时变化时,预留带宽内的数据流量可以自动随之调整带宽,使得实时视频流量+预留带宽内的数据流之和保持在40M(除非数据+视频总流量小于40M),而超出总带宽40M的数据流则进入两个部门的共享数据带宽,参与共享带宽的部门间抢占。

    3.2.2. 设计组网:

    多部门间共用广域物理线路

    单接口部门间带宽独占和共享设计

    3.2.3. 关键配置:

    业务标记说明:通过入接口MPLS报文的优先级标签EXP5代表部门1的视频业务,EXP2代表部门1的数据业务;EXP4代表部门2的视频业务,EXP1代表部门2的数据业务。

    流量调度说明:在汇聚路由器的针对部门1和部门2的两个入接口分别进行部门内流量分层CAR调度。实现视频业务优先占用部门预留带宽,富余的预留带宽给本部门数据业务,预留带宽内的视频业务和数据业务均标记为EXP2,而超出预留带宽的数据业务标记为EXP0。在汇聚路由器的155M POS出接口上,对两个部门超出预留带宽的数据业务进行总带宽限制为75M(155M-40M*2),这样就实现了部门的预留带宽,同时保证了预留带宽优先分配给视频业务,其余预留带宽给数据业务的设计。也就是说,带宽预留和共享设计,是通过入口CAR和出口GTS限流配合实现,而预留带宽优先分配给视频,其余带宽给数据的设计是通过分层CAR实现的。

    3.2.4. 设计效果:

    在实现企业部门之间带宽预留和共享,实现带宽独立和带宽利用率双重需求的同时,又保证了部门内视频业务的带宽和服务质量,避免了视频业务走共享数据队列所带来的带宽抢占和丢包风险。

    3.3. 广域双链路流量调度设计

    传统QoS的设计,都是基于单接口或链路的,当总业务流量超出该接口带宽后,就要进行业务间QoS调度,并对低优先级和超出承诺带宽的业务进行丢包处理。这种传统QoS技术针对双链路和多链路情况,却没有更好的方案进行跨链路的流量统一QoS调度,而只能做基本的业务分流承载,各自做QoS保障。其结果就是,一条链路可能严重拥塞,而另外一条链路却空闲的很,带宽资源严重浪费。

    下面这个设计,就是针对这一现象进行双链路统一QoS流量调度设计,采用的分层CAR技术结合策略路由设计实现。

    3.3.1. 设计描述:

    业务说明:包括生产、办公和视频业务。一般情况下,通过路由设计,生产业务走主链路,办公和视频业务走备用链路。生产业务虽然平时流量不大,但最为重要,业务不能中断,因此需要尽力保证生产业务不丢包;办公业务重要程度在生产之后,流量较大,需要充分利用双链路空闲带宽;而视频业务偶尔会有,但需要保证带宽并优先转发,链路故障时不对视频业务进行链路切换。

    业务流向:全部生产和主要办公业务为骨干各级到园区核心的大集中业务,园区存放服务器。视频业务任何跨层之间都有通信要求。同级各组之间不进行横向业务交流。因此,整体流量主要为纵向流量访问模型。

    超负荷流量调度和优先级保证:主链路上,当生产业务下行方向超出10M后,多出10M的流量横向引流到同级备链路路由器,并参与该设备下行方向的QoS调度,进行超负荷流量调度;同样,备链路办公和视频业务总流量超出10M后,仅对办公业务超负荷流量向主链路路由器进行分担,并参与主链路路由器下行出口的QoS调度,而视频业务始终限制在2M之内,为保证视频质量的稳定性,不参与备链路的过载分担。

    3.3.2. 设计组网:

    双链路流量过载调度设计

    测试组网说明:

    1. 该组网方式模拟行业用户中常见的广域网建设方式,分为核心园区网、分支园区网络和骨干网络。

    2. 核心园区网络内是三层网络,网关是SR88,三层设备包括SR66和S75E的三层交换机,在SR66和S75E之间部署防火墙;

    3. 在分支园区网络中是二层网络,里面是二层交换机;

    4. 骨干网络由各个层级园区网络的网关设备组成,骨干链路采用CPOS;

    5. 园区网络和骨干网络采用双链路上行,既保证了链路的可靠性,同时也达到了扩充链路资源的目的。

    本设计以双链路分流承载和骨干汇聚层SR66下行方向过载分担设计为主要进行介绍。

    3.3.3. 关键配置:

    分流设计配置—骨干汇聚层主链路SR66

    # 配置两个OSPF实例,上行和横向接口属于OSPF 100,下行接口属于OSPF 200,就是说核心网络属于OSPF 100,而分支网络属于OSPF 200。

    ospf 100

    area 0.0.0.0

    network 100.1.5.0 0.0.0.255

    network 100.1.6.0 0.0.0.255

    ospf 200

    area 0.0.0.0

    network 100.1.3.0 0.0.0.255

    # 配置前缀列表,分别匹配分支的生产业务、办公业务和视频业务网段

    ip ip-prefix branch-produce index 10 permit 172.20.0.0 16 less-equal 32

    ip ip-prefix branch-office index 10 permit 172.25.0.0 16 less-equal 32

    ip ip-prefix branch-video index 10 permit 172.30.0.0 16 less-equal 32

    # 配置路由策略,匹配生产业务的路由,cost设定为10,匹配办公和视频业务的路由,cost设定为10000,当OSPF 100引入OSPF 200路由的时候,应用该路由策略。

    route-policy branch-to-core permit node 1

    if-match ip-prefix branch-produce

    apply cost 10

    apply cost-type type-1

    route-policy branch-to-core permit node 5

    if-match ip-prefix branch-office

    apply cost 10000

    apply cost-type type-1

    route-policy branch-to-core permit node 10

    if-match ip-prefix branch-video

    apply cost 10000

    apply cost-type type-1

    ospf 100

    import-route ospf 200 route-policy branch-to-core

    # 配置前缀列表,分别匹配分支的生产业务、办公业务和视频业务网段

    ip ip-prefix core-produce index 10 permit 172.16.20.0 24

    ip ip-prefix core-office index 10 permit 172.16.25.0 24

    ip ip-prefix core-video index 10 permit 172.16.30.0 24

    # 配置路由策略,匹配生产业务的路由,cost设定为10,匹配办公和视频业务的路由,cost设定为10000,当OSPF 100引入OSPF 200路由的时候,应用该路由策略。

    route-policy core-to-branch permit node 1

    if-match ip-prefix core-produce

    apply cost 10

    apply cost-type type-1

    route-policy core-to-branch permit node 5

    if-match ip-prefix core-office

    apply cost 10000

    apply cost-type type-1

    route-policy core-to-branch permit node 10

    if-match ip-prefix core-video

    apply cost 10000

    apply cost-type type-1

    ospf 200

    import-route ospf 100 route-policy core-to-branch

    分流设计配置—骨干汇聚层备链路SR66

    配置基本同主链路SR66,只是在两个OSPF相互引入路由的时候,匹配生产业务路由的cost值为10000,而匹配视频和办公业务的cost的值为10。这样保证了生产业务走左边主链路,而视频和办公业务走右边备份链路。

    过载分担设计配置—骨干汇聚层主链路SR66

    # 匹配生产业务的ACL

    acl number 3100

    rule 10 permit ip source 172.16.20.0 0.0.0.255 dest 172.20.1.0 0.0.0.255

    # 匹配af11(过载流量标记为af11)的ACL

    acl number 3200

    rule 0 permit ip dscp af11

    # 配置策略路由,如果是过载流量,将走到R4横向链路

    policy-based-route exceed permit node 1

    if-match acl 3200

    apply ip-address next-hop 100.1.5.2

    # 接口下配置qos car,承诺速率为9M,超过9M的流量标记为af11,通过策略路由,走横向链路。这里设置为9M而不是10M,主要考虑链路其他流量的存在对下行10M接口的影响,比如路由协议和控制流量,因此当生产业务超过9M时,就需要进行过载分担了。

    interface pos 2/1/0

    qos car inbound acl 3100 cir 9000 green pass red remark-dscp-continue af11

    ip policy-based-route exceed

    过载分担设计配置—骨干汇聚层备链路SR66

    # 匹配办公业务的ACL

    acl number 3025

    rule 10 permit ip source 172.16.25.0 0.0.0.255 dest 172.25.1.0 0.0.0.255

    # 匹配视频业务的ACL

    acl number 3030

    rule 10 permit ip source 172.16.30.0 0.0.0.255 dest 172.30.1.0 0.0.0.255

    # 办公和视频业务业务都匹配的ACL

    acl number 3035

    rule 10 permit ip source 172.16.25.0 0.0.0.255 dest 172.25.1.0 0.0.0.255

    rule 20 permit ip source 172.16.30.0 0.0.0.255 dest 172.30.1.0 0.0.0.255

    # 匹配af12(过载流量标记为af12)的ACL

    acl number 3200

    rule 0 permit ip dscp af12

    # 过载流量走到主链路SR66路由器的横向链路

    policy-based-route exceed permit node 1

    if-match acl 3200

    apply ip-address next-hop 100.1.5.1

    # 下行方向入接口配置QOS,如果视频流量超过设定值,直接丢弃;如果办公业务超过设定值,如果视频业务有富余带宽,可以占用。如果视频和生产业务总流量超过设定,通过策略路由,走横向链路到主链路SR66进行转发

    interface Pos4/1/0

    qos car inbound acl 3030 cir 4096 green continue red discard

    qos car inbound acl 3025 cir 4096 green continue red continue

    qos car inbound acl 3035 cir 8192 green pass red remark-dscp-continue af12

    ip policy-based-route exceed

    : 以上配置针对一个分支,多个分支的情况下,需要为每个分支配置匹配生产业务的ACL,接口下为每个分支配置qos car

    下行出口QoS队列调度配置—骨干汇聚层主链路SR66

    # 配置QOS策略,使得生产业务占用AF队列,60%的带宽,办公业务也是AF队列,占用20%的带宽。

    traffic classifier produce

    if-match acl 3100

    traffic behavior produce

    queue af bandwidth pct 60

    traffic classifier office

    if-match acl 3025

    traffic behavior office

    queue af bandwidth pct 20

    qos policy flow-assign

    classifier produce behavior produce

    classifier office behavior office

    # 将QOS策略应用在下行出口

    interface Mp-group2/0/0

    qos reserved-bandwidth pct 100

    qos apply policy flow-assign outbound

    下行出口QoS队列调度配置—骨干汇聚层备链路SR66

    # 配置QOS策略,视频业务进入ef队列,占用带宽的20%,生产和办公业务占用af队列,分别占用20%和40%的带宽。

    traffic classifier produce

    if-match acl 3020

    traffic behavior produce

    queue af bandwidth pct 20

    traffic classifier office

    if-match acl 3025

    traffic behavior office

    queue af bandwidth pct 40

    traffic classifier video

    if-match acl 3030

    traffic behavior video

    queue ef bandwidth pct 20

    qos policy flow-assign

    classifier produce behavior produce

    classifier office behavior office

    classifier video behavior video

    # 将qos策略应用在下行出口

    interface Mp-group2/0/0

    qos reserved-bandwidth pct 100

    qos apply policy flow-assign outbound

    3.3.4. 设计效果:

    双链路统一QoS流量调度,需要统一考虑主备链路过载分担时,对哪些业务进行横向调度,同时也要考虑过载分担过来的流量与本链路原有流量的统一QoS调度设计,避免过载流量对本链路流量进行较大的冲击。

    过载分流设计,相比于传统单链路QoS和基本业务分流的组合方案,在带宽利用率方面和QoS带宽保证和优先级设计方面都有比较好的提升。而相对于传统的负载分担设计,最大的优势是尽量保持按设计链路转发,减少转发环节,而且可以做精细的QoS保证设计,比如本设计中的视频业务优先,而不做过载分担这些细节。

    3.4. 广域出口终端带宽控制

    企业园区或分支的广域出口带宽相对有限,而园区或企业分支内的终端用户一般都在几十、成百上千的规模,传统的QoS队列设计根本无法做到针对每一个终端进行精确的带宽控制。这样就会出现由于某个人下载大附件导致其他人上网速度慢的情况出现,也有可能影响到其他的重要业务,比如视频会议。通过基于在线IP的动态令牌桶技术,与分层CAR结合,则可以实现上述理想:做到基于终端IP的带宽公平分配和共享,同时对重要业务进行带宽保证和优先转发。

    3.4.1. 设计描述:

    小型园区广域接入,需要考虑园区内的用户和业务分组,及组内/组间的带宽分配。

    园区内对业务进行分组:视频业务和数据业务类。其中数据类业务又分为市场/用服/行政三组人员。

    在园区出口的入方向(下行流量)进行带宽保证设计,各组内按单用户IP地址进行带宽保证;

    当视频不用带宽时,可以留给数据业务组使用。即使数据业务存在富余带宽的时候,视频业务也不能占用。数据业务中,当某个组有富余带宽的时候,可以留给其他部门使用。

    3.4.2. 设计组网:

    广域出口终端带宽控制

    一个小型园区内,按业务分,包括视频业务和数据业务,其中数据业务的终端用户有200人左右,按照部分划分,包括市场、用服和行政三组人员,各组人员各64人。

    3.4.3. 关键配置:

    SR66广域接口的下行方向进行带宽控制配置:

    # 配置car list,指定视频地址范围

    qos carl 2 destination-ip-address range 192.170.1.1 to 192.170.1.63

    # 配置car list,指定市场组的地址范围,每个在线IP平均分配带宽,并进行富余带宽共享

    qos carl 4 destination-ip-address range 192.170.1.64 to 192.170.1.127 per-address shared-bandwidth

    # 配置car list,指定用服组的地址范围,每个在线IP平均分配带宽,并进行富余带宽共享

    qos carl 6 destination-ip-address range 192.170.1.128 to 192.170.1.191 per-address shared-bandwidth

    # 配置car list,指定行政组的地址范围,每个在线IP平均分配带宽,并进行富余带宽共享

    qos carl 8 destination-ip-address range 192.170.1.192 to 192.170.1.254 per-address shared-bandwidth

    # 配置car list,包括所有的地址范围

    qos carl 10 destination-ip-address range 192.170.1.1 to 192.170.1.254

    # 在接口下配置分层CAR,在配置第一层CAR的时候,因为视频业务中超过cir的流量直接discard,因此即使企业业务由富余带宽,也不会抢占。而市场、用服、行政超过cir的流量动作是continue,通过第二层CAR,会进行二次处理,这样当其它业务有富余带宽的时候,会占用。

    interface Mp-group4/0/0

    qos car inbound carl 2 cir 3000 green continue red discard // 视频

    qos car inbound carl 4 cir 2000 green continue red continue // 市场

    qos car inbound carl 6 cir 2000 green continue red continue // 用服

    qos car inbound carl 8 cir 2000 green continue red continue // 行政

    qos car inbound carl 10 cir 9000 green pass red discard // 所有:视频和人员数据

    本配置中是通过CARL命令字以及关键参数per-address和shared-bandwidth进行体现的,采用在线动态令牌桶生成技术与分层CAR结合的技术方案。

    3.4.4. 设计效果:

    上述设计中,当视频流量在3M以内,视频业务会得到优先带宽保证;而其余带宽则按照每组人员共2M,对内在在线用户进行带宽公平分配,比如市场人员某一时刻在线人员为10人,那么每一个市场人员都可以得到200Kbps的带宽。而另一时刻,市场人员有20人在线,则每个人可以得到的带宽则为100Kbps。其他组人员带宽分配方案与市场人员相同。

    如果视频业务流量低于3M,比如为0时,那么视频业务的3M带宽就会被市场、用服和行政人员进行公平分配,而不会有带宽浪费现象出现。

    需要注意的是,由于广域网带宽往往由电信运营商进行限定,比如这里限定为10M,流量的丢包控制往往在运营商侧。因此在园区入口进行该方案设计时,总体带宽建议少于运营商给定带宽的5%~10%左右,这样就为内部的带宽分配提供了控制空间,通过对超额定带宽的业务流进行丢包,达到TCP自动降速或UDP承载的应用层自动降速的目的,实现带宽的公平分配;否则按10M设计,由于进来的流量肯定在10M以内,业务流的丢包控制完全放在了运营商侧,以上设计就会失效。当然,园区上行流量设计则不需要注意该问题。

    3.5. 广域专线出口负载分担

    对于拥有广域双出口的分支或园区,为达到广域链路资源的充分利用,往往采用负载分担技术。当由于广域网链路带宽可能存在的非对称性,即两条链路带宽不一样时,传统的负载分担技术则存在困难。下面介绍一种基于双出口带宽比例的非对称负载分担设计,则可以帮助企业自由的实现各种比例的负载分担效果。

    3.5.1. 设计描述:

    下图MSR50同时拥有4M和10M的双上行链路。设计上行流量基于链路带宽按包进行负载分担。

    3.5.2. 设计组网:

    广域出口方向负载分担

    3.5.3. 关键配置:

    # 配置默认路由,两个出接口是等价路由

    ip route-static 0.0.0.0 0.0.0.0 100.1.1.1

    ip route-static 0.0.0.0 0.0.0.0 100.1.2.1

    # 在两个出接口下关闭快转

    interface Mp-group0

    undo ip fast-forwarding outbound

    interface Serial5/0

    undo ip fast-forwarding outbound

    # 配置基于端口带宽的负载分担

    bandwidth-based-sharing

    3.5.4. 设计效果:

    上行流量按双出口带宽比例进行逐包负载分担发送。但这种逐包负载分担设计,不适合双Internent经过NAT处理的出口,因为双出口意味着不同的Internet公网地址,而逐包则会导致同一个会话用不同的公网地址转发出去,会话不能维持。

    4. 最佳实践总结

    企业广域网链路资源的相对稀缺,以及业务集中承载的趋势,对广域网的业务流量调度和QoS保证提出了更为严格的挑战。本文基于H3C在广域网流量调度领域的创新性设计,对企业广域网的一些典型场景和环节进行了详细阐述。这些场景已经在政府、金融、电力和大企业等各个行业落地,且都是一些行业特色需求,比如带宽预留、超负载分担、数据业务为视频会议让路、统一带宽管理、办事处员工外网带宽保证等要求。