免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 10476 | 回复: 6

[网络管理] iptables网关机ping提示No buffer space available [复制链接]

论坛徽章:
0
发表于 2005-08-18 22:15 |显示全部楼层
用户反映很慢,登上一看,

[root@fc3 ~]# ping 61.139.2.69
connect: No buffer space available

是什么问题???在google上查,都说得不清不楚

论坛徽章:
0
发表于 2005-08-18 22:57 |显示全部楼层

iptables网关机ping提示No buffer space available

你加大/proc/sys/net/ipv4/ip_conntrack_max里的值试试

论坛徽章:
0
发表于 2005-08-18 23:36 |显示全部楼层

iptables网关机ping提示No buffer space available

晕,二楼的,这种办法你也想得出?
那是对付table full的办法,我早就
echo "32768" >; /proc/sys/net/ipv4/netfilter/ip_conntrack_max
了,
在2.4内核中不要中间的netfilter,不知怎么2.6多了,也没人告诉我;((((只是我自己看在ipv4下没这个文件.但是,如果改了netfilter下文件,似乎会自动在ipv4下也生成 这个文件.


因为连接都不容易成功,所以我实在想不出办法,只好重启(
启动后,发觉arp在不断增加,里面有55开头的ip,
mac全为0,
55和我的ip开头一样,但后3节不一样,我可记得我的掩码是24位的呀怎么这也认得(
竟然来自公网,我晕,难道上级路由器出错???

眼看arp就3xx条了,一会儿又降下来了,最小只有180,其实真实用户很少的.
想修改参数,查了半天,
原来默认arp表最大1024条,
echo "10000" >; /proc/sys/net/ipv4/neigh/default/gc_thresh3
改大点吧.

暂时只有这样,但是:
1.幸好这会一直只有3xx条,如果继续增加,那再大的设置可能也不够.
2.在重启前我用了arp的,但是里面都是真实arp信息.~~~~~~~~~实在想不通((

论坛徽章:
0
发表于 2005-08-18 23:52 |显示全部楼层

iptables网关机ping提示No buffer space available

嘿嘿,这可以google上鬼佬说的,不是俺的主意

另外,message上应该有neighbor table full的信息,不知道有没有

论坛徽章:
0
发表于 2005-08-19 00:07 |显示全部楼层

iptables网关机ping提示No buffer space available

http://bbs.chinaunix.net/forum/viewtopic.php?t=568721&show_type=&postdays=0&postorder=asc&start=10


另外,再检查一下lo interface起来了没有,不过这个只针对很旧的发行版

论坛徽章:
0
发表于 2005-08-19 00:58 |显示全部楼层

iptables网关机ping提示No buffer space available

竟然查不到neighbor table full的消息
Aug 18 16:10:33 fc3 kernel: printk: 2 messages suppressed.
Aug 18 16:13:44 fc3 kernel: printk: 1 messages suppressed.
Aug 18 17:35:53 fc3 kernel: dst cache overflow
Aug 18 17:43:49 fc3 last message repeated 7 times
Aug 18 17:43:56 fc3 last message repeated 10 times
Aug 18 17:44:02 fc3 kernel: printk: 12 messages suppressed.
Aug 18 17:44:02 fc3 kernel: dst cache overflow
Aug 18 17:44:04 fc3 kernel: printk: 14 messages suppressed.
Aug 18 17:44:04 fc3 kernel: dst cache overflow
Aug 18 17:44:09 fc3 kernel: printk: 13 messages suppressed.
Aug 18 17:44:09 fc3 kernel: dst cache overflow
Aug 18 17:44:16 fc3 kernel: printk: 31 messages suppressed.
Aug 18 17:44:16 fc3 kernel: dst cache overflow
Aug 18 17:45:28 fc3 kernel: printk: 15 messages suppressed

再后来就
Aug 18 20:45:32 fc3 kernel: dst cache overflow
Aug 18 20:45:37 fc3 kernel: printk: 367 messages suppressed.
Aug 18 20:45:37 fc3 kernel: dst cache overflow
Aug 18 20:45:42 fc3 kernel: printk: 298 messages suppressed.
Aug 18 20:45:42 fc3 kernel: dst cache overflow
Aug 18 20:45:47 fc3 kernel: printk: 280 messages suppressed.
Aug 18 20:45:47 fc3 kernel: dst cache overflow
Aug 18 20:45:52 fc3 kernel: printk: 239 messages suppressed.
Aug 18 20:45:52 fc3 kernel: dst cache overflow
Aug 18 20:45:57 fc3 kernel: printk: 322 messages suppressed.
Aug 18 20:45:57 fc3 kernel: dst cache overflow

其实查日志8.1左右就出现了dst cache overflow,这是什么东东???

再看CU的帖,
有人说改了这,好了几分钟,
                                                                                       默认大小
echo 120 >; /proc/sys/net/ipv4/neigh/default/gc_stale_time              60
echo 512 >; /proc/sys/net/ipv4/neigh/default/gc_thresh1                256
echo 2048 >; /proc/sys/net/ipv4/neigh/default/gc_thresh2               512
echo 4096 >; /proc/sys/net/ipv4/neigh/default/gc_thresh3              1024   ”

又说,对内网接口eth1进行跟踪:
# tcpdump -i eth1 arp
发现十几台机器不停地向linux询问不存在的ip地址的MAC,是它们造成arp表出现严重的抖动现象。
12:55:41.900194 arp who-has 172.19.0.157 tell 172.19.201.70
12:55:42.086023 arp who-has 172.19.215.219 tell 172.19.201.70
12:55:42.556482 arp who-has 172.19.124.232 tell 172.19.201.70
12:55:42.990155 arp who-has 172.19.85.122 tell 172.19.201.70
12:55:43.322160 arp who-has 172.19.88.217 tell 172.19.201.70
12:55:43.580866 arp who-has 172.19.51.85 tell 172.19.201.70

在天网防火墙中同时发现这十几台电脑不停在向外发包,主要是445端口,这些电脑有病毒。
我和网管停了这十几台电脑,“Neighbour table overflow”的信息终于消失。



我再来看我的,原来外网网卡是设的255.0.0.0的掩码,
也抓包看看
tcpdump -n -i eth0 arp
不得了,
[root@fc3 ~]# tcpdump -n -i eth0 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
00:56:16.247417 arp who-has 55.97.43.108 tell 55.66.66.6
00:56:16.336311 arp who-has 55.137.139.164 tell 55.66.66.6
00:56:16.370306 arp who-has 55.27.144.187 tell 55.66.66.6
00:56:16.409293 arp who-has 55.74.41.47 tell 55.66.66.6
00:56:16.409336 arp who-has 55.51.146.120 tell 55.66.66.6

原来这包是我发的?被黑了?
再看看内网网卡,
[root@fc3 ~]# tcpdump -n -i eth1 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
00:57:56.058315 arp who-has 192.168.0.223 tell 192.168.0.50
00:57:56.120764 arp who-has 192.168.0.187 tell 192.168.0.50
00:57:56.216952 arp who-has 192.168.0.182 tell 192.168.0.50
00:57:56.459455 arp who-has 192.168.0.160 tell 192.168.0.50
00:57:56.756649 arp who-has 192.168.0.158 tell 192.168.0.50
00:57:56.961031 arp who-has 192.168.0.170 tell 192.168.0.50
00:57:57.000000 arp who-has 192.168.0.123 tell 192.168.0.254
00:57:57.000263 arp reply 192.168.0.123 is-at 00:14:2a:23:be:bf
00:57:57.145870 arp who-has 192.168.0.126 tell 192.168.0.50
00:57:57.260960 arp who-has 192.168.0.107 tell 192.168.0.254
00:57:57.261238 arp reply 192.168.0.107 is-at 00:0d:87:49:e0:a4
00:57:57.408693 arp who-has 192.168.0.218 tell 192.168.0.50

原来192.168.0.50不对头,再看看在ip_conntrack中是怎么样的,
[root@fc3 ~]# cat /proc/net/ip_conntrack|grep 192.168.0.50|wc -l
701
[root@fc3 ~]# cat /proc/net/ip_conntrack
tcp      6 42 SYN_SENT src=192.168.0.50 dst=55.34.170.37 sport=3314 dport=445 packets=2 bytes=128 [UNREPLIED] src=55.34.170.37 dst=55.66.66.6 sport=445 dport=3314 packets=0 bytes=0 use=1
tcp      6 28 SYN_SENT src=192.168.0.50 dst=55.43.157.185 sport=3036 dport=445 packets=2 bytes=128 [UNREPLIED] src=55.43.157.185 dst=55.66.66.6 sport=445 dport=3036 packets=0 bytes=0 use=1
tcp      6 41 SYN_SENT src=192.168.0.50 dst=55.25.136.167 sport=3279 dport=445 packets=2 bytes=128 [UNREPLIED] src=55.25.136.167 dst=55.66.66.6 sport=445 dport=3279 packets=0 bytes=0 use=1
tcp      6 63 SYN_SENT src=192.168.0.50 dst=55.80.235.244 sport=3701 dport=445 packets=2 bytes=128 [UNREPLIED] src=55.80.235.244 dst=55.66.66.6 sport=445 dport=3701 packets=0 bytes=0 use=1

原来是中了病毒.
iptables -A FORWARD -i eth1 -p tcp --dport 445 -j DROP
这样就好了,arp正常了.


倒,这次怎么忘了封445了((((((((((((((((((

论坛徽章:
0
发表于 2005-08-19 01:02 |显示全部楼层

iptables网关机ping提示No buffer space available

dst cache overflow也找到了,还是这个原因引起的,


https://www.redhat.com/archives/fedora-list/2004-December/msg02529.html

我的机子上
[root@fc3 rc.d]# route -Cn
Kernel IP routing cache
Source          Destination     Gateway         Flags Metric Ref    Use Iface
192.168.0.50  55.251.180.95   55.251.180.95   i     0      0        0 eth0
218.17.224.180  192.168.123.186 192.168.123.186       0      0        2 eth1
219.133.49.16   192.168.123.150 192.168.123.150       0      0        0 eth1
192.168.0.50  55.139.132.17   55.139.132.17   i     0      0        0 eth0
192.168.0.50  55.197.180.131  55.197.180.131  i     0      0        0 eth0
61.129.55.176   192.168.123.107 192.168.123.107       0      0       24 eth1
192.168.0.50  55.138.81.114   55.138.81.114   i     0      0        0 eth0
192.168.0.50  55.155.152.2    55.155.152.2    i     0      0        0 eth0
192.168.123.18  202.96.170.163  55.66.66.5      i     0      0        0 eth0
192.168.123.123 219.133.211.40  55.66.66.5      i     0      0       26 eth0

如果按redhat上帖子来分析,应该直接修改
/proc/sys/net/ipv4/route/max_size
我的机子现在是
[root@fc rc.d]# cat /proc/sys/net/ipv4/route/max_size
2048

不过既然病毒没了,可能够用?还是去参考下coyotelinux,结果里面是8192,那马上
echo 32768 >; /proc/sys/net/ipv4/route/max_size

后来继续在coyotelinux中看,发觉一件让人吃惊的事,
coyote# pwd
/proc/sys/net/ipv4/netfilter
竟然有这个目录???我明明记得这是2.6才有的
coyote# uname -a
Linux coyote 2.4.29 #4 Thu Mar 17 13:30:56 EST 2005 i686 unknown

难道我记错了???
那就上redhat9去看,
[root@localhost root]# ls -l |grep ^d.*$
drwx------    2 root     root         4096  5▒▒  4 18:41 multifix
[root@localhost root]# cd /proc/sys/net/ipv4/
[root@localhost ipv4]# pwd
/proc/sys/net/ipv4
[root@localhost ipv4]# ls -l |grep ^d.*$
dr-xr-xr-x    8 root     root            0  8▒▒ 19 01:26 conf
dr-xr-xr-x    7 root     root            0  8▒▒ 19 01:26 neigh
dr-xr-xr-x    2 root     root            0  8▒▒ 19 01:26 route


想不通,为什么2.4有两种组织方式
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP