• 全部
  • 经验案例
  • 典型配置
  • 技术公告
  • FAQ
  • 漏洞说明
  • 全部
  • 全部
  • 大数据引擎
  • 知了引擎
产品线
搜索
取消
案例类型
发布者
是否解决
是否官方
时间
搜索引擎
匹配模式
高级搜索

某局点SecPath F1000-AK135(V7) 多条pppoe拨号线路配置了负载均衡丢包经验案例分析

  • 0关注
  • 1收藏 3736浏览
李聪 四段
粉丝:1人 关注:0人

组网及说明

问题描述

   客户现场有四条固定地址线路,两条pppoe线路 。按照客户要求,将四条固定地址线路以及两条pppoe线路进行了outbound链路负载均衡的配置。配置成功之后发现客户上网有丢包的情况出现,接下来进行分析原因。本次涉及防火墙的型号以及版本: F1000-AK135   Version 7.1.064, Release 9323P16

过程分析

首先我们对现场反馈的线路质量测试、链路组状态进行分析。

1. 分析链路质量测试

为了排除是不是pppoe线路质量的问题,我们让现场将pppoe线路直接连接在电脑测试发现没丢包。抛开我们防火墙测试pppoe线路也是正常的,没有发现丢包。

2. 分析链路组、虚服务是否正常

现场工程师通过display loadbalance link brief查看设备的链路组状态如下:

[H3C]dis loadbalance link brief

Link            Router IP            State        VPN instance  Link group

link1           115.236.48.233            Active                   link-group  

link2           115.236.175.9             Active                   link-group  

link3           218.75.34.97             Active               link-group  

link4           115.236.62.81             Active                   link-group  

pppoe0             10.1.0.1             Active                   link-group  

pppoe1             10.1.10.1                Active               link-group 

通过查看虚服务也是正常开启的,通过查看display loadbalance link statistics或者web页面查看链路带宽统计信息也是发现pppoe线路是有流量增长的,说明负载到pppoe线路没有问题。

3. 分析原因,确认故障

经检查配置发现现场配置了pppoe链路的最大带宽,同时在虚服务使能了带宽繁忙比。

链路配置是:

#

loadbalance link pppoe0

 router ip 10.1.0.1

 link-group link-group

 max-bandwidth 100000  //配置了链路带宽为100M

 success-criteria at-least 1

 probe pppoe0

#

loadbalance link pppoe1

 router ip 10.1.10.1

 link-group link-group

 max-bandwidth 100000 //配置了链路带宽为100M

 success-criteria at-least 1

 probe pppoe1

#

从上面看出链路配了最大带宽。

虚服务使能了链路繁忙:

#

virtual-server ##defaultvsforllbipv4##%%autocreatedbyweb%% type link-ip

 virtual ip address 0.0.0.0 0

 lb-policy ##defaultpolicyforllbipv4##%%autocreatedbyweb%%

 default link-group link-group

 service enable

 sticky-sync enable

 bandwidth busy-protection enable  //带宽繁忙比配置。

 bandwidth interface statistics enable  //调用链路接口带宽作为统计依据。

但是防火墙缺省情况下,dialer口的带宽是64k

[F1070]dis int Dialer 1

Dialer1

Current state: UP

Line protocol state: UP(spoofing)

Description: Dialer1 Interface

Bandwidth: 64 kbps   //pppoe拨号的dialer接口带宽为64K

Maximum transmission unit: 1500

Hold timer: 10 seconds, retry times: 5

Internet protocol processing: Disabled

Link layer protocol: PPP

经过分析确认,防火墙pppoe拨号之后dialer接口的带宽系统默认为64K,并且现场配置了带宽繁忙比,并且以接口带宽作为参考。这个时候需要手动修改一下pppoedialer接口的带宽为运营商的实际带宽,否则会出现带宽不足导致的丢包情况发生。因此现场修改了下dialer口带宽为100M,卡顿的现象就没了。



解决方法

   通过以上的分析,可以确认故障原因为防火墙pppoe拨号之后dialer接口的带宽系统默认为64K,这个时候如果在虚服务开启以接口带宽作为参考的链路繁忙比功能,我们需要将dialer接口的带宽改为运营商实际带宽值,否则会出现带宽不够用丢包情况。因此建议后续防火墙pppoe拨号,dialer接口下面的带宽值改为运营商实际带宽值。

该案例对您是否有帮助:

您的评价:1

若您有关于案例的建议,请反馈:

作者在2019-06-12对此案例进行了修订
0 个评论

该案例暂时没有网友评论

编辑评论

举报

×

侵犯我的权益 >
对根叔知了社区有害的内容 >
辱骂、歧视、挑衅等(不友善)

侵犯我的权益

×

泄露了我的隐私 >
侵犯了我企业的权益 >
抄袭了我的内容 >
诽谤我 >
辱骂、歧视、挑衅等(不友善)
骚扰我

泄露了我的隐私

×

您好,当您发现根叔知了上有泄漏您隐私的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您认为哪些内容泄露了您的隐私?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)

侵犯了我企业的权益

×

您好,当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 zhiliao@h3c.com 邮箱,我们会在审核后尽快给您答复。
  • 1. 您举报的内容是什么?(请在邮件中列出您举报的内容和链接地址)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
  • 3. 是哪家企业?(营业执照,单位登记证明等证件)
  • 4. 您与该企业的关系是?(您是企业法人或被授权人,需提供企业委托授权书)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

抄袭了我的内容

×

原文链接或出处

诽谤我

×

您好,当您发现根叔知了上有诽谤您的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您举报的内容以及侵犯了您什么权益?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔知了社区有害的内容

×

垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载 >
辱骂、歧视、挑衅等(不友善)
骚扰我
诱导投票

不规范转载

×

举报说明

提出建议

    +

亲~登录后才可以操作哦!

确定

亲~检测到您登陆的账号未在http://hclhub.h3c.com进行注册

注册后可访问此模块

跳转hclhub

你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作