预览加载中,请您耐心等待几秒...
1/10
2/10
3/10
4/10
5/10
6/10
7/10
8/10
9/10
10/10

亲,该文档总共40页,到这已经超出免费预览范围,如果喜欢就直接下载吧~

如果您无法下载资料,请参考说明:

1、部分资料下载需要金币,请确保您的账户上有足够的金币

2、已购买过的文档,再次下载不重复扣费

3、资料包下载后请先用软件解压,在使用对应软件打开

提升端到端业务质量的措施和手段云南内容简介三、网络层面端到端研究三、网络层面端到端研究——(一)两手段1、完善的资源记录及更新——资源信息资源信息内容:1、完善的资源记录及更新——行为记录2、自主开发的“IP承载网智能维护系统”功能介绍及应用场景—数据采集本系统主要功能包括数据采集、配置检查、数据分析、IP地址管理、设备信息查询、ping测;1、CRC增长分析:该项工作需要统计所有物理端口信息,分别采集两次设备端口信息,即可判断CRC增长情况。1、IP地址查询:如果输入的IP不带掩码,则取缺省值32,这里查询到的IP为与全网中IP地址存在包含或被包含或相等的地址(说明一下,任意两段IP地址段只存在包含、被包含和相等关系,不存在交集),同时可以输出该段IP地址剩余可用的IP地址。已用地址和可用地址是不存在冲突的,可以用“冲突检测功能”进行检测。以信令地址(10.30.249.0/25)为例,可查询到在现网中已被用的地址和剩余可用的IP地址。1、ping测试是对链路质量检测最简单且可靠的方法,根据采集到的配置,生产自动ping测表格(手动生成一方面不完整,其次网络频繁变更,不可能每次都手动生成),形成ping测命令,登陆到设备上,执ping测行指令,实现自动ping测。以CE-AR测试为例:1、CE面板信息查询:选择相应CE后,即显示出CE局址、可用的vrid(virtualrouterid)和设备面板信息,包括端口信息、IP地址信息等端口参数。三、网络层面端到端研究——(二)业务接入CE资源申请流程三、网络层面端到端研究——(三)流量模型分析方法故障案例一——曲靖CE-AR间传输带宽配置缺失引起的流量拥塞问题(1) 过程中对该链路进行持续ping测试,发现该链路在流量小于5%以后直到无流量承载情况下,链路不再丢包,从而证明曲靖AR2-曲靖CE2整条传输链路上无故障点,链路质量正常。此时曲靖CE1-AR1承载了曲靖的所有GB流量,利用率为42%左右,即曲靖忙时正常流量应为400M以上,与之前双平面承载时总流量为270M左右相比,流量立即上涨了130M以上,该原因即为曲靖进行部分BSC调整后整体PS流量上升30%的原因。 但之后再将该链路cost值改回10后,流量倒回AR2-CE2链路并到一定值时又开始丢包,并且最大流量值只能到达15%(即130M左右)后无法上涨(曲靖忙时正常流量应为400M以上,而丢包时双平面相加只有200多M流量被传送,流量丢失严重)。至此,我们推断,该问题点在于曲靖AR2-CE2间实际配置的传输带宽可能仅为155M左右(因为流量最高只能到15%,即150M左右),未达到最初网络规划建设时需求的带宽1GE。故当该链路流量未达到155M瓶颈时我们无法发现该问题,在2012年曲靖PS域数据业务发展过程中该链路上流量超过155M带宽限制时出现拥塞及严重丢包,进而影响了用户手机上网体验。 【问题解决】 找到了问题症结点为曲靖CE2-AR2间传输带宽配置问题,经核实,因CE2与AR2为异局址,中间经过了曲靖本地网传输SDH系统,在CE入网之初,本地传输并未按规划需求配置为1GE带宽,而只配置了一个VC4,即155M,进而留下了隐患。曲靖本地网重新对AR2-CE2间调度配置新的传输OTNGE电路,解决了流量受限问题。经后续流量倒回测试,此时AR2-CE2间流量达到28%以上。故障案例二——诺西Flexi-BSCGb上下行流量路径不一致时闪断问题(1)【故障处理】 业务应急恢复:通过修改CE上配置的VRRP协议优先级的方式,将SGSN(主用上行到偶数平面)对应的玉溪、红河、曲靖三个地市15台flexi型号BSC的上行主用也调整到偶数CE,形成图3-14流量模式,暂时规避GB-link闪断问题。分析得知:Gb上行流量通过BSC内连接CE1的SWU2流出(如下图4中黄色虚线),下行流量通过与CE2连接的SWU3流入。SWU2、SWU3均为BSC内嵌的二层交换机ESB24,且部署了广播抑制功能,其学习PCU的MAC地址表aging-time为5分钟,而CE的MAC地址aging-time为20分钟(一般路由器的默认值,各厂家一致)。 由上述,在上下行路径非对称模型下,flexiBSC内ESB24间mac地址表存在5分钟更新时间到而删除的情况,且因为BSC内部署了广播抑制功能,故此时ESB24上mac地址表消失。当CE2在20分钟更新时间到后发一次ARP请求(mac地址请求)报文到BSC内PCU时,SWU3才回送一个Arpreply报文到CE2,所以SWU3的MAC地址表每20分钟才更新一次。期间存在一段时间内无mac地址表的情况,导致下行流量流入SWU3后因查询不到mac地址表而丢包,进而引起Gb业务闪断。解决思路: 对于上