国际专线电路调试案例分析

一、案例背景

XX集团是XX公司的重要合作伙伴，也是重庆分公司的重点保障对象。近期，其连续申请了到日本、英国和意大利的3条国际MSTP专线电路，我们在电路开通调试初期碰到以下几个问题：

1. 日本电路：

重庆XX采用华为Metro 1000传输设备EFS单板接入以太网专线业务，对端采用思科15454传输设备，两端业务开通后，测试无法ping通。

1. 英国电路和意大利电路：

                            （XX至英国电路网络图）

 

                             （XX至英国电路简图）

问题一：在9月下旬，由于E段传输路由器还没有调通，协调通过IPSEC隧道临时解决，而调试IPSEC过程中无法调通隧道。

问题二：在12月9日调通E段传输路由后，进行全程联调，ping65500字节的大包有3%丢包；用MSTP仪表打环测试能够达到10M带宽，但两端使用单台电脑下载达不到10M带宽（平均速度不到3M带宽），英国POP点架设FTP服务器端，重庆使用FTP客户端进行下载测试，平均速率是300KB/S，造成用户感知不好。意大利电路也有同样带宽不能达10M的情况

二、案例分析

     下面对这3条电路的开通、调试过程详细分析如下：

1. 日本电路

1）、检查网元告警，Metro 1000设备EFS单板有LP_TIM_VC12、LP_SLM_VC12、LP_RDI_VC12告警，说明端设备J2、V5字节设置不一致。

2）、由于对端设备查询这两个字节比较困难，华为默认的

J2字节为HuaWei SBS，V5字节为异步，因此对J2、V5字节尝试更改，当J2字节修改为“00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00”（16进制方式16个0）后，LP_TIM-V12告警消失。V5字节从0X01至0X0D依次修改，发现对端设备采用GFP_F封装协议时，V5字节为0X0D(GFP映射)，当对端设备采用HDLC封装协议时，V5字节为0X08（其它映射（测试使用）），设置和对端一直后，LP_SLM_VC12、LP_RDI_VC12告警消失。

3）、封装与映射中需要配置的包括映射协议、扰码方式、校验字段长度、FCS计算位序、扩展头选项，而对端设备只能看到映射协议和校验字段长度两项。在映射协议上，华为EFS单板支持GFP、HDLC、LAPS三种封装协议， GFP协议包括GFP-F和GFP-T协议，华为的EFS单板支持的是GFP_F协议；对端选择GFP-F协议，本端选择GFP协议，校验字段长度上，对端选择CRC32，本端选择FCS32。其它三项扰码方式、FCS计算位序与扩展头选项只能通过设置不同的选项来测试，最终选择扰码方式为“X43+1”， FCS计算位序为“Big endian”，扩展头选项为“没有”。

4）、端口内外部属性设置，进入华为以太网端口的数据如果不带VLAN，则需要将外部端口属性设置为ACCESS，同时在入端口后打上默认的VLAN ID（具体VLAN ID可以修改），如果进入以太网端口的数据带VLAN，则需要将端口属性设置为Tag Aware，对数据进行透传。之前了解到对端设备为VLAN为7的数据，需要将端口属性设置为Tag Aware，来透传数据。后来与日本XX联系，了解到对端设备不带VLAN，因此将内外部端口属性都设置为ACCESS，默认VLAN设置为1。

5）、以上设置完成后，通过电脑测ping，能够ping通，但是用户反应有丢包。此时再与客户确认接入EFS单板设备的端口工作模式，重庆用户路由器FE端口设置的是100M全双工，因此将传输设备EFS单板端口工作模式设置为100M全双工，同时双方路由器也经过相应参数更改后，丢包问题解决。

1. 英国电路

问题一的处理过程：

其IPSEC方式组网如下图：

在重庆路由器配置如下：

R1(config)#int f0/0
R1(config-if)#ip add 172.29.0.145 255.255.255.252
R1(config-if)#no sh
R1(config-if)#int f1/0
R1(config-if)#ip add 217.34.42.89 255.255.255.252
R1(config-if)#no sh
R1(config-if)#end　　

R1#conf t
R1(config)#aaa new-model
R1(config)#aaa authorization network vpn-client-user local

R1(config)#ip local pool VPNDHCP 192.168.0.100 192.168.0.150

R1(config)#crypto isakmp client configuration group vpn-client-user
R1(config-isakmp-group)#key norvel.com.cn
R1(config-isakmp-group)#pool VPNDHCP
R1(config-isakmp-group)#dns 10.0.14.14
R1(config-isakmp-group)#domain norvel.com.cn
R1(config-isakmp-group)#exit
R1(config)#

R1(config)#crypto isakmp policy 10
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#encryption 3des
R1(config-isakmp)#group 2
R1(config-isakmp)#hash sha
R1(config-isakmp)#exit
R1(config)#end
R1#conf  t
R1(config)#crypto ipsec transform-set R1 esp-sha-hmac esp-3des
R1(cfg-crypto-trans)#exit
R1(config)#crypto dynamic-map dyvpn 10
R1(config-crypto-map)#set transform-set R1

R1(config-crypto-map)#reverse-route　　　　　　
R1(config-crypto-map)#exit

R1(config)#crypto map dyvpn isakmp authorization list vpn-client-user
R1(config)#crypto map dyvpn client configuration address respond
R1(config)#crypto map dyvpn 1 ipsec-isakmp dynamic dyvpn
R1(config)#int e1/0
R1(config-if)#crypto map dyvpn

R1(config)#ip route 0.0.0.0 0.0.0.0 217.34.42.90

测试能使用IPSEC正常连接；同样在英国伦敦也能IPSEC正常连接。

但在伯明翰使用如上方式不能正常连接。

经检查，在伦敦POP点是通过家庭网关拨号连接的，获得的IP只有一个：217.34.42.89。因此在重庆路由器上的217.34.42.89这个IP在外网是不可见的。因此在伯明翰连接217.34.42.89这个IP时，其实是连接至英国伦敦POP点的家庭网关这台设备上的，因此不能正常连接。

此时考虑两个方案解决该问题：

方案一、在英国伦敦POP点的家庭网关配置映射，将217.34.42.89所有应用（包括IPSEC协议：Authentication Header（AH）协议和Encapsulating Security Payload（ESP）协议分别对应IP协议号 " 51"和" 50"）映射至重庆的路由器FA1/0口192.168.1.254这个IP上。

方案二、将IPSEC路由器从重庆移至英国伦敦POP点，在路由器上添加ADSL卡直接拨号获取217.34.42.89这个公网IP。

通过web方式登录英国伦敦POP点的家庭网关，在DMZ区将217.34.42.89所有应用映射至私网192.168.1.254，测试IPSEC仍不能正常连接。后咨询相关厂家说是该家庭网关设备性能太弱，不能将IPSEC的IP协议号50和51做映射。设备上的映射其实只是所有tcp和UDP端口的映射。无果！

通过第二个方案来解决时，发现英国伦敦POP点的家庭网关配置是PPPOA拨号，在cisco路由器上需要配置ATM卡的拨号方式，而这种卡一时无法找到。无果！

由于设备的瓶颈，需要更改整个IPSEC方案，在VPN的几个协议中，考虑L2TP没有IP协议号，只需映射L2TP端口（1701）做映射。于是在英国伦敦POP点的家庭网关将217.34.42.89端口1701映射至192.168.1.254这个IP的1701端口上。

在重庆路由器主要配置如下：

aaa new-model

aaa authentication login default local

aaa authentication login cisco local

aaa authentication ppp default local

aaa authorization network vpn-client-user local

aaa session-id common

ip cef

ip auth-proxy max-nodata-conns 3

ip admission max-nodata-conns 3

vpdn enable

vpdn-group VPN-SERVER

! Default L2TP VPDN group

 accept-dialin

  protocol l2tp

  virtual-template 1

 no l2tp tunnel authentication

pool VPNDHCP

interface FastEthernet0/0

 description to-neiwang

 ip address 172.29.0.145 255.255.255.252

 duplex auto

 speed auto

interface FastEthernet0/1

 ip address 192.168.1.253 255.255.255.0

 duplex auto

 speed auto

 crypto map dyvpn

interface Virtual-Template1

 ip address 10.21.252.254 255.255.255.0

 peer default ip address pool VPDNPOOL-1

 ppp mtu adaptive

 ppp authentication ms-chap-v2 ms-chap chap pap

 ppp ipcp dns 10.0.14.14 10.0.14.15

ip local pool VPNDHCP 192.168.0.100 192.168.0.150

ip local pool VPDNPOOL-1 10.21.252.1 10.21.252.253

ip forward-protocol nd

ip route 0.0.0.0 0.0.0.0 192.168.1.254

ip route 10.0.168.0 255.255.255.0 172.29.0.146

ip route 10.17.5.0 255.255.255.0 172.29.0.146

通过外网测试L2TP，能正常拨号。至此解决了XX公司英国的临时电路问题。

问题二的处理过程：

1）、分别在英国POP点与重庆长途落地机房SDH设备上配置以太网落地，重庆XX采用Metro 3000设备EFS单板接入以太网专线业务，对端采用思科15454设备。
    2）、英国POP点架设FTP服务器端，重庆使用FTP客户端进行下载测试；最高下载速度为525KB/S，平均保持在300KB/S。经检查英国POP点传输设备端口为强制10M全双工， FTP服务器端口为自适应，将该FTP服务器端口修改为强制10M全双工，再进行FTP下载测试，网速稍有好转，平均下载速度保持在360KB/S。英国POP点发现传输设备(思科)有异常：伦敦向重庆侧FTP时端口的PM，检测到思科传输设备端口上ifInErrors计数值增加的比较多。检查重庆端传输设备无异常。在重庆段的PC机使用wireshark抓包工具进行抓包，截图如下：

 

 

发现许多“TCP segment of a reassembled PDU”，且报文长度均为1248字节。“TCP segment of a reassembled PDU”指TCP层收到上层大块报文后分解成段后发出去。其实这个是由TCP的MSS(Maximum Segment Size，最大报文段长度)决定的，TCP在发起连接的第一个报文的TCP头里通过MSS这个可选项告知对方本端能够接收的最大报文（当然，这个大小是TCP净荷的大小）。其实主机响应一个FTP命令时如果要回应很多数据（信息）而这些数据超出了TCP的最大MSS时，主机会通过发送多个数据包来传送这些数据（注意：这些包并未被分片）。对wireshark来说这些对相应同一个FTP命令的数据包被标记了“TCP segment of a reassembled PDU”。也就是说在伦敦POP点的一个FTP报文净值按照TCP的MSS值被分成多段，在重庆客户端接受多段又需要重装成一个报文。在分段和重装过程中影响了传送效率，使得带宽不能充分利用。而要使得一个报文不被分段和重装，可以调整全程线路上的MTU值至最大，或者将PC机TCP MSS值调整小点。

    3）、出于以上的分析，检查MTU值。英国POP点告知思科设备无法修改MTU值，且无法找到该值在何处。由于华为设备默认为1522，华为重庆端直接将MTU值由1522修改为9600，再次测试该电路，传输速率保持在1.17MB/S，问题得到解决。后英国POP点也找到思科设备MTU值在何处查看，经查看思科设备MTU值默认为9600，且无法修改，至此，为以后XX公司等国际长途电路提供了经验，当远端采用思科传输设备时，由于默认MTU值是9600，故本端华为传输设备MTU值都用9600。

 

4）、将整个电路放通。由重庆XXPC机至英国XXPC机直接进行测试，Ping 65500的包有严重丢包现象，使用飞秋传送文件速度最高为30KB/S。该测试表明用户使用为非正常状态。

5）、抛开重庆XX及英国XX两端路由器进行测试。测试方法：因XX英国方无FTP服务器，故只使用“飞秋”进行文件传输测试。

测试发现，“飞秋”传输速度只有500-600KB/S。该结果也为非正常数值。经检查重庆XX端PC机（②端口）网卡端口模式为100M半双工，经协商同时将双方PC机网卡端口模式同时改为100M全双工，修改后英国XX端PC机（⑨端口）闪断（飞秋可以登陆然后就断掉，之后端口无法启用），并发现英国XX端只能使用10M全双工模式。双方又同时将PC机端口模式修改为10M全双工，使用“飞秋”传送文件发现“飞秋”传输速度只有250-300KB/S，仍为非正常状态。重庆XX端PC机（②端口）将网卡模式修改为100M全双工，与英国XXPC机（⑨端口，此时仍为10M全双工模式）重新进行测试，测试结果：Ping 65500 的包，无丢包现象，“飞秋”文件传输速度为891KB/S，英国伦敦POP点查看端口流量使用率为80%。在传送文件同时进行65500的大包Ping测，共计Ping 包495个，丢包0个，丢包率为0%。

意大利也按照同时方式更改设置，测试亦正常。至此，测试已能说明XX公司到英国和意大利国际电路是符合合同中所约定的带宽（10M）。

三、案例总结

总结上述三条国际电路的开通过程，调测时需要注意以下几点：

1. 在无公网IP的路由器上如果要建立VPN隧道，建议使用L2TP方式，因为无IP协议号的映射。
2. 封装协议采用华为设置GFP协议，思科设置GFP-F协议，校验字段长度华为设置FCS32，思科设置CRC32，华为扰码方式设置“X43+1”， FCS计算位序设置“Big endian”、扩展头选项设置为“没有”，思科无此三项；
3. J2字节设置为16进制的16个00，V5字节设置为0X0D（GFP映射）；
4. 内外部端口属性设置，根据FE口对接设备来选择，本案例内外部端口都设置为ACCESS；

5、 传输设备MTU需要匹配成最大值（思科设备默认为9600，华为设备默认为1522），故以后碰到类似电路开通时，建议本端华为传输设备MTU值都用9600；

6、 用户端路由器配置存在问题，本次路由器相应端口模式应该和传输设备的端口模式一致。