[原创]ADSL猫 一次断流故障的分析和思考 By Kangoo

kangoo

[这个贴子最后由kangoo在 2004/12/19 10:53pm 第 1 次编辑]

[watermark] ADSL猫 一次断流故障的分析和思考  by Kangoo (2004-10-27)
---------------------------------------------------------------------------------
1。引言
---------------------------------------------------------------------------------
我在3月份的时候遇到过ADSL频繁断线的情况，当时写的一篇《大面积ADSL出现死猫中场总结,分析及联想》（见：http://www.516600.com/cgi-bin/lb5000/topic.cgi?forum=59&topic=101&show=100）。
但当时基本没有遇到“断流”的情况，大部分都是“断线”。这次，我的ADSL猫出现了较严重的断流情况，通过分析、尝试，有了一点想法，也不知道对不对，就再写一篇吧，呵呵。
我这次碰到的可能是“断流”情况中的一种，可能“断流”并不是一种原因造成的。大家帮我看看思考的对不对，同时希望能抛砖引玉，大家一起来思考。

---------------------------------------------------------------------------------
2。问题的现象
---------------------------------------------------------------------------------
当然，我的ADSL是开启路由的，内网带了大约10台电脑。 出现断流时 有几种现象：
1。在内网一台电脑上PING ADSL的内网IP，时通时不通；
2。在内网一台电脑上PING 电信的网关，时通时不通；
3。登陆到ADSL猫上 PING 电信的网关，时通时不通；
4。以上3个，一个出现 不通的情况，其他2种也同时出现不通，即三者是同步的。
5。ADSL猫上无任何告警。
6。当断流发生时，网页打开经常无法打开，QQ/MSN 频繁上下线。

---------------------------------------------------------------------------------
3。可能的原因分析
---------------------------------------------------------------------------------
3.1 遭攻击的可能性
    和上次一样，首先怀疑是否受攻击，修改HTTP/TELNET端口，但发现效果不是很好，基本没有改善，断流还是随机不定时的出现。
3.2 流量过大的可能性
    还有就是流量过大的可能，是否流量过大，造成ADSL猫 过载而不响应 ICMP包。
    在ADSL猫和内网之间挂一个HUB，挂上sniffer pro，通过一段时间观察，发现断流出现时，并不是流量最大的时候，往往那时网络流量并不是很大。
3.3 Session限制的可能性
    排除了遭攻击以及 流量过大的可能，我发现了一些其他现象：
   a.当挂上BT时，断流出现的几率就开始增大了，但其实当时BT的下载速率很小（20KB/S左右，不可能造成拥塞）。
   b.还有一个有趣的现象就是：当我在内网一台电脑上PING ADSL猫的内网IP出现 Request time out 时，我登陆到ADSL猫的telnet一切正常，能正常敲命令，没有任何时延（按理此时我台式机到 ADSL猫的通信已经暂时中断了）。
除了流量造成的问题，那还有一种可能造成“断流”的，就是IP session的问题了。
$get nbsize
Max IP Session : 192            HTTP Port : 61580
Telnet Port    : 61581
    我的ADSL猫是 晨星的SR-DSL-AE，默认配置中，IP session 设定在192 条，即最大允许有192个IP session， 而且这个 IPsession 应该是包含所有的 session，如NAT的session 和主机到ADSL猫之间的 session。
    NAT的session 可以通过这个看到：
$get nat status
Active Translations : 175            Active Rules        : 1
FTP ALG Sess        : 0              SNMP ALG Sess       : 0
RA ALG Sess         : 0              RMCD ALG Sess       : 0
L2TP ALG Sess       : 0              MIRC ALG Sess       : 0
CUSEEME UDP ALG Sess: 0              CUSEEME TCP ALG Sess: 0
H323 Q931 ALG Sess  : 0              H323 RAS ALG Sess   : 0
H323 RTP ALG Sess   : 0              H323 245 ALG Sess   : 0
PPTP ALG Sess       : 0              RTSP ALG Sess       : 0
TIMBUKTU ALG Sess   : 0              T120 ALG Sess       : 0
或者这个：
$get nat rule status
RuleId         Active Translations
----------------------------------
2              177
3              0
5              0
8              0
（注：我主要用 RuleId =2来做NAT，另外几条是 RDR FTP服务器的，还有就是RDR TFTP/TELNET/HTTP 端口的。）
    可以看到的是，此时ADSL猫中NAT的Active Translations 已经达到 170多了（而且时刻在变化），而总共ADSL猫允许的总的IP session 是192条，如果 IP session 达到了 192条，那再有新的 TCP/UDP 连接请求到达ADSL猫，ADSL猫则无法再 应付了。 而这个原因，可以解释我前面遇到的几种现象。
现象1： 在ADSL猫和内网之间挂一个HUB，挂上sniffer pro，通过一段时间观察，发现断流出现时，并不是流量最大的时候，往往那时网络流量并不是很大。
    流量不是导致ADSL猫不接受新的IP连接的原因，原因是 IP session限制，即便此时流量不是很大，但是很多连接保持了，IP session 达到了最大数额，ADSL 也不能接受新的数据连接了。
现象2：当挂上BT时，断流出现的几率就开始增大了，但其实当时BT的下载速率很小（20KB/S左右，不可能造成拥塞）。
   BT的一个特点就是同时建立大量的连接，而这个，是IP session 达到限额的一个重要因素。
现象3：还有一个有趣的现象就是：当我在内网一台电脑上PING ADSL猫的内网IP出现 Request time out 时，我登陆到ADSL猫的telnet一切正常，能正常敲命令，没有任何时延（按理此时我台式机到 ADSL猫的通信已经暂时中断了）。
    这个就好解释了，TELNET 的连接已经建立好了，已经占上了 ADSL猫的一条IP session，当IP session 达到最大值时，新的请求ADSL 已无法应答了，但已经存在的 IP session ，ADSL还是照样服务的。  如果再IP session 达到最大值时，再去尝试TELNET ADSL猫，就很难说能不能登陆上了。

另外，桥接模式下，一般只有1台PC连接，一台PC的连接，很少达到192。 而如果开了路由，有多台电脑连接，连接的数额就成倍翻翻，如果再开了BT，如果要还有木马、病毒、蠕虫，他们也会建立一堆的 连接。 很容易就使 ADSL猫的 IP session 达到最大值。
下面是在我的主机上查看 我主机的连接，当时我只启动了 MSN/QQ/TELNET 以及Maxthon，还有就是有个Serv-U，就有如此多的连接。（netstat 的 /b参数是显示 连接对应的进程）
C:\Documents and Settings\Kangoo>netstat /b
Active Connections
  Proto  Local Address          Foreign Address        State           PID
  TCP    server:1074            localhost:XXXXX        ESTABLISHED     3784
  [ServUAdmin.exe]
  TCP    server:43958           localhost:XXXX         ESTABLISHED     876
  [SERVUD~1.EXE]
  TCP    server:1616            baym-cs303.msgr.hotmail.com:1863  ESTABLISHED
  3004
  [msnmsgr.exe]
  TCP    server:1828            192.168.1.1:XXXXX      ESTABLISHED     3176
  [telnet.exe]
  TCP    server:1883            218.18.XXX.XXX:http     ESTABLISHED     3940
  [QQ.exe]
  TCP    server:1912            61.XXX.XXX.XXX:http    ESTABLISHED     4044
  [Maxthon.exe]
  TCP    server:1913            61.XXX.XXX.XXX:http    ESTABLISHED     4044
  [Maxthon.exe]
  TCP    server:1914            61.XXX.XXX.XXX:http    ESTABLISHED     4044
  [Maxthon.exe]
  TCP    server:1915            61.XXX.XXX.XXX:http    ESTABLISHED     4044
  [Maxthon.exe]
  TCP    server:1916            61.XXX.XXX.XXX:http    ESTABLISHED     4044
  [Maxthon.exe]
  TCP    server:1917            61.XXX.XXX.XXX:http    ESTABLISHED     4044
  [Maxthon.exe]
  TCP    server:1918            61.XXX.XXX.XXX:http    ESTABLISHED     4044
  [Maxthon.exe]
  TCP    server:1919            61.XXX.XXX.XXX:http    ESTABLISHED     4044
  [Maxthon.exe]
  TCP    server:1920            61.XXX.XXX.XXX:http    ESTABLISHED     4044
  [Maxthon.exe]
  TCP    server:1921            61.XXX.XXX.XXX:http    ESTABLISHED     4044
  [Maxthon.exe]
  TCP    server:1922            61.XXX.XXX.XXX:http    ESTABLISHED     4044
  [Maxthon.exe]
  TCP    server:1923            61.XXX.XXX.XXX:http    ESTABLISHED     4044
  [Maxthon.exe]
  TCP    server:1924            61.XXX.XXX.XXX:http    ESTABLISHED     4044
  [Maxthon.exe]
  TCP    server:1925            61.XXX.XXX.XXX:http    ESTABLISHED     4044
  [Maxthon.exe]
  TCP    server:1930            61.XXX.XXX.XXX:http     ESTABLISHED     4044
  [Maxthon.exe]
  TCP    server:1708            rad.msn.com:http       CLOSE_WAIT      3004
  [msnmsgr.exe]
（注：IP地址我都用XXX替换真实地址，下文同）
---------------------------------------------------------------------------------
4。解决的思路
---------------------------------------------------------------------------------
   好了，如果是这个原因，怎么解决呢？
4.1 首先想到的是 修改 这个 max ip session，先改成250：
$modify nbsize ?
Parameter                         Description
---------                         -----------
[ maxipsess <decvalue> ]           Maximum IP Session
[ httpport <decvalue> ]            HTTP Port
[ telnetport <decvalue> ]          Telnet Port
&#36;modify nbsize maxipsess 250
Set Done
&#36;get nbsize
Max IP Session : 250            HTTP Port : 61580
Telnet Port    : 61581
&#36;commit
Set Done
&#36;reboot
（注意：调整数值请保持在合理范围内，以免影响ADSL猫的功能，如果不知道什么范围是合理范围，至少该知道那些是“离谱”的值，或者请尽量不要改动！）
  重启之后，所有的 IP session都被复位，从0开始，观察一段时间，发现单纯 NAT 的 translations 就很快飙升到了 200多，
&#36;get nat status
Active Translations : 217            Active Rules        : 1
FTP ALG Sess        : 2              SNMP ALG Sess       : 0
RA ALG Sess         : 0              RMCD ALG Sess       : 0
L2TP ALG Sess       : 0              MIRC ALG Sess       : 0
CUSEEME UDP ALG Sess: 0              CUSEEME TCP ALG Sess: 0
H323 Q931 ALG Sess  : 0              H323 RAS ALG Sess   : 0
H323 RTP ALG Sess   : 0              H323 245 ALG Sess   : 0
PPTP ALG Sess       : 0              RTSP ALG Sess       : 0
TIMBUKTU ALG Sess   : 0              T120 ALG Sess       : 0
   此时， 我再次尝试 PING 猫、网关、DNS服务器，各种测试都有正常反映，没有之前频繁出现的 request time out。 好像一切都解决了？
C:\Documents and Settings\Kangoo>ping 61.XXX.XXX.XXX
Pinging 61.XXX.XXX.XXX with 32 bytes of data:
Reply from 61.XXX.XXX.XXX: bytes=32 time=10ms TTL=126
Reply from 61.XXX.XXX.XXX: bytes=32 time=11ms TTL=126
Reply from 61.XXX.XXX.XXX: bytes=32 time=10ms TTL=126
Reply from 61.XXX.XXX.XXX: bytes=32 time=9ms TTL=126
Ping statistics for 61.XXX.XXX.XXX:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 9ms, Maximum = 11ms, Average = 10ms
   不过，再过一段时间，我发现，再 session 熟高的情况下，如果流量再稍微高一点，网络的反应会比较慢，PING DNS 每次都有回复，没有出现request time out ，但时延明显增大，且不稳定：
C:\Documents and Settings\Kangoo>ping 61.XXX.XXX.XXX
Pinging 61.XXX.XXX.XXX with 32 bytes of data:
Reply from 61.XXX.XXX.XXX: bytes=32 time=290ms TTL=126
Reply from 61.XXX.XXX.XXX: bytes=32 time=177ms TTL=126
Reply from 61.XXX.XXX.XXX: bytes=32 time=318ms TTL=126
Reply from 61.XXX.XXX.XXX: bytes=32 time=71ms TTL=126
Ping statistics for 61.XXX.XXX.XXX:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 71ms, Maximum = 318ms, Average = 214ms
    同时，内网主机上网时打开新的页面时变的慢的很多，但不管如何最终都能打开，但反应明显慢了许多。 这个，估计是 ADSL猫中CPU 已经超负荷工作了，造成的时延增大。
    所以，原来 这个max ip session 值设定在192 是有它道理的，如果要修改，只能小幅度的增加，具体增加到多少，就要不断的试验才行了。其实是应该按照 实际的流量、CPU的负荷来动态的调节，那是最好的了。可是 这猫比较傻。
    现在我的ADSL猫虽然在 大流量时，还是存在反映慢的问题，但至少，之前“断流”的问题缓解了。 我最后将 IP session 设定在 240左右，慢慢尝试吧，根据需要调整。

4.2 其他改善方法的思考
那其他还有什么方法可以改善这个情况呢？我找了半天，觉得以下几个地方都是可以改善的，但具体修改的数值，还在尝试当中。
（再次注意：下文数值的调整我也在尝试之中，各位如果想调整请保持在合理范围内，以免影响ADSL猫的功能，如果不知道什么范围是合理范围，至少该知道那些是“离谱”的值，或者请尽量不要改动！本人不对后果付责，汗 -_-&#35;&#35;&#35;&#35;）
&#36;get nat ?
Command        Description
-------        -----------
global         NAT Global Info
rule           NAT Rule Commands
stats          NAT Statistics Info
status         NAT Status Info
translation    NAT Translation Table
&#36;get nat global
TCP Idle Timeout(sec): 86400           TCP Close Wait(sec)  : 60
TCP Def Timeout(sec) : 60              UDP Timeout(sec)     : 300
ICMP Timeout(sec)    : 5               GRE Timeout(sec)     : 300
Default Nat Age(sec) : 240             NAPT Port Start      : 50000
NAPT Port End        : 51023           Admin Status         : Enable
&#36;modify nat global ?
Parameter                         Description
---------                         -----------
[ tcpidletimeout <decvalue> ]      Tcp idle timeout(sec)
[ tcpclosewait <decvalue> ]        Wait time after which conn is closed(sec)
[ tcptimeout <decvalue> ]          Def tcp timeout incase of errors(sec)
[ udptimeout <decvalue> ]          Udp timeout(sec)
[ icmptimeout <decvalue> ]         Icmp timeout(sec)
[ gretimeout <decvalue> ]          Gre timeout(sec)
[ defnatage <decvalue> ]           Default nat timeout(sec)
[ portstart <decvalue> ]           Starting value of port range
[ portend <decvalue> ]             Last value of port range
[ enable | disable ]               Admin status
  这个在WEB设置中也有，如下图：

spareM

不错呀，又长知识了，thanks

音乐虫子

NAPT Port Start      : 50000
NAPT Port End        : 51023
这两个我也想改,大家应该注意到,拨号后第一个登陆上去的QQ,端口是50000,第二个是50001,依此类推,最多支持1023个QQ同时登陆?

BOYMZJ

写的很好。受教。还有几个概念请楼主解释一下
TCP IDLE TIME OUT
Default Nat Age(sec)

kangoo

[这个贴子最后由kangoo在 2004/10/28 11:50am 第 3 次编辑]

>NAPT Port Start      : 50000
>NAPT Port End        : 51023
>这两个我也想改,大家应该注意到,拨号后第一个登陆上去的QQ,端口是50000,第二个是50001,依此类推,最多支持1023个QQ同时登陆?
这个应该是猫在执行NAT功能 在 outside 侧所使用的 端口范围，这个范围，限制了最多的 ip session。 端口从50000到 51023，可以理解成 同时值支持1024 个 QQ登陆（假定 QQ 登陆只使用1个 NAT session的话），不过我上文中也说了，这里有个1024的限制，另外，NAT规则上还有另外的一个限制，而那个默认是192，比这个1024 小多了，也就只有最多最多192个QQ登陆。（实际不可能的）
如下图：
假定你的QQ 要登陆，我们假定内网IP 是使用192.168.1.X网段，你ADSL猫拨号得到了202.101.202.101这个IP，而QQ服务器 是61.61.61.61的IP。
（为方便说明，我以QQ 用TCP方式登陆举例，UDP方式类似，另外我假定 QQ服务器的端口是6666，主机发出请求是从 4000发出的。只是举例说明，并不代表真实情况）
                   <---inside | outside --->
+----+
|    |--------------------->[ADSL]--------------[ Internet]  QQ 服务器
+----+
192.168.1.2     192.168.1.1       202.101.202.101             61.61.61.61
4000端口                          50001端口                   6666端口
1。主机192.168.1.2 上QQ登陆，主机向内网发送一个TCP 请求连接(SYN)，源IP地址是 192.168.1.2，源TCP端口4000，目的地址是 61.61.61.61:端口6666。由于这个目的地址并不在我内网网段内，所以 主机会将这个包发送到 ADSL的内网口上（即网关上），即发出的数据包的目的MAC地址是 ADSL内网端口地址。
网络层：192.168.1.2:4000 -> 61.61.61.61:6666
数据链路层： 主机MAC     -> ADSL 猫内网口MAC
2。ADSL收到这个 TCP请求连接的IP数据包，识别目的IP是位于WAN侧的，则执行NAT，使用ADSL所取得公网IP来替换掉IP包中的源IP地址，并且在WAN侧，寻找一个空闲的NAT端口（即50000～51023之间），比如端口50001空闲，则此IP包将转发到WAN上，并且把这条转换作为一个临时的NAT规则记下来，此时地址变成：
202.101.202.101:50001 -> 61.61.61.61:6666
3。此时，ADSL猫的NAT功能相当于 在 inside 的 192.168.1.2:4000 和 outside 侧的 202.101.202.101:50001之间建立了一条临时管道。
192.168.1.2:4000===202.101.202.101:50001 <->  61.61.61.61:6666
   WAN侧的QQ服务器如果有QQ登陆的回复发回来，他会送到 202.101.202.101:50001 上，ADSL猫会记得那个临时NAT规则还在，和这个匹配，那它会继续按照这个规则把包转发，ADSL猫把这个数据包转到内网上，但这个IP数据包的目的IP地址和端口替换为 192.168.1.2:4000。
   内网192.168.1.2主机 的QQ如果有数据从4000端口继续发送到 61.61.61.61:6666 上，ADSL猫会记得那个临时NAT规则还在，和这个匹配，那它会继续按照这个规则把包转发，ADSL 即把这个数据包转到WAN侧，但这个IP数据包的源IP地址和端口替换为 202.101.202.101:50001。

   好了， 这样，对于内网主机来说，他好像在和WAN侧的QQ服务器 做无障碍的通信； 而WAN侧QQ服务器 只知道在和一台202.101.202.101 的“主机”进行通信， ADSL猫对于他们2者来说是透明的。其实，ADSL在中间做了2传手，骗骗双方，以为他们在无障碍通信，其实都是ADSL在中间做NAT的功劳。
BTW：不过我想QQ服务器如果聪明一点的话，它会奇怪这台名叫 202.101.202.101 的“主机”上的QQ为什么那么怪异，他发出的QQ连接并不是从4000发出的，而是从50001发出的，因为QQ软件默认都是从4000端口来连接服务器的。这个我们可以从上面的例子中看出来，其实 内网主机上的QQ确实是从4000端口发起登陆的，但是因为经过了NAT，所以转到了50001端口上去了。
    所以，现在显IP的QQ上面，如果你看到某个人的IP地址后面的端口是4000，就说明他是拨号、ADSL桥接等方式上网的（他的电脑是具有公网IP的，他也是暴露在公网下的，可以当肉鸡），如果他的端口并不是4000，而且其他的，就知道他肯定是经过了NAT来上网的。进一步，可以从他的端口号来看出他用的什么猫（各种猫端口范围是不一样的），当然，他如果是从专门的路由器上过来的，那就难猜了，哈哈，题外话，扯远了。

    我们可以看出来，WAN侧的那些50000到 51023的端口是个资源，他是有限的，每一个去向 WAN的 NAT连接都会占用一个 端口，使用完毕后，等待超时就拆除这个NAT，释放那个端口。而超时，就使用下面这个问题中的“定时器”。

>写的很好。受教。还有几个概念请楼主解释一下
>TCP IDLE TIME OUT
>Default Nat Age(sec)
这个我还没有完全猜明白，因为没有资料，我只能从字面去理解它。
TCP IDLE TIME OUT：默认68400秒，24小时，也就是 一个TCP的NAT，在没有数据包传送，空闲了24小时后，才拆除。 但我还不确认，如果TCP连接双方主动发动FIN来中止TCP连接，ADSL猫是否能识别？
Default Nat Age(sec)： 默认的NAT寿命，默认值为300秒，即默认情况下，一个NAT5分钟后超时拆除，这个和上面定义有点重叠，也不算太明白，不过从我观察上来看，主要是 UDP的NAT寿命，UDP经常是发几个包就没下文的，所以即便就发了一个UDP包，ADSL猫也会建立一个NAT，而且这个NAT会在5分钟才拆除。

freelancer

谢谢楼主，我前几天刚开的路由，没开的时候BT、EM什么一起上也没事，最多PING升得高一点，开了后，PING还只有几十的时候就狂断了。。。就猜可能是这种连接数太多的问题，正好看到这篇文章，回去试试

BOYMZJ

非常佩服楼主。讲解的非常详细。谢谢

goingchan

Default Nat Age没跟前面的定义重叠，这个是指除了TCP、UDP、ICMP、GRE、ESP外的所有NAT session，IP协议簇里可不是只有前边那几个玩儿的

hgyuo

顶,好文章.