dst cache overflow的解决(from fedoraforum.org)

 原贴:http://forums.fedoraforum.org/archive/index.php/t-69855.html

Hello.
I have a router running FC 2 with kernel 2.6.10-1.770_FC2.

Yesterday my network went down and a lot of "dst cache overflow"
appeared in my console. I then increased
my /proc/sys/net/ipv4/route/max_size from 8192 to 16384 and my network
started to work again...

The problem is that dst_cache keeps increasing:
[root@saf113 root]# cat /proc/slabinfo |grep ip_dst_ca
ip_dst_cache 9210 9210 256 15 1 : tunables 120 60 0 : slabdata 614 614 0

This way the problem will repeat itself... Is there a solution to this?
Is this a known bug?

Thanks for the help.
Andr=E9


--=20
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list

---

Alexander Dalloz

2005-08-05, 02:27 AM CDT

Am Mi, den 06.07.2005 schrieb André Cruz um 15:21:

> I have a router running FC 2 with kernel 2.6.10-1.770_FC2.

That kernel has security issues.

> Yesterday my network went down and a lot of "dst cache overflow"
> appeared in my console. I then increased
> my /proc/sys/net/ipv4/route/max_size from 8192 to 16384 and my network
> started to work again...
>
> The problem is that dst_cache keeps increasing:
> [root@saf113 root]# cat /proc/slabinfo |grep ip_dst_ca
> ip_dst_cache 9210 9210 256 15 1 : tunables 120 60 0 : slabdata 614 614 0
>
> This way the problem will repeat itself... Is there a solution to this?
> Is this a known bug?

> André

I don't understand why your proc value is that small.

$ cat /proc/sys/net/ipv4/route/max_size
131072

This is on my unmodified FC2 with the rebuild FC3 kernel 2.6.11-1.35.

Do you constantly run P2P filesharing? That is a typical reason too for
stopping SOHO hardware router to work as they have limited NAT
capacities.

Alexander


--
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.35_FC2smp
Serendipity 16:33:29 up 10 days, 23:25, load average: 0.13, 0.13, 0.06

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCy+yhEEG6lbNmp3MRAseLAJwLK3zAGz4koYp6YxPme+ sMOeUd7wCgoj3d
NQAo4LHlfuj1HtgyKrSa5Wc=
=q/PO
-----END PGP SIGNATURE-----

---

Alexander Dalloz

2005-08-05, 02:27 AM CDT

Am Mi, den 06.07.2005 schrieb André Cruz um 15:21:

> I have a router running FC 2 with kernel 2.6.10-1.770_FC2.

That kernel has security issues.

> Yesterday my network went down and a lot of "dst cache overflow"
> appeared in my console. I then increased
> my /proc/sys/net/ipv4/route/max_size from 8192 to 16384 and my network
> started to work again...
>
> The problem is that dst_cache keeps increasing:
> [root@saf113 root]# cat /proc/slabinfo |grep ip_dst_ca
> ip_dst_cache 9210 9210 256 15 1 : tunables 120 60 0 : slabdata 614 614 0
>
> This way the problem will repeat itself... Is there a solution to this?
> Is this a known bug?

> André

I don't understand why your proc value is that small.

$ cat /proc/sys/net/ipv4/route/max_size
131072

This is on my unmodified FC2 with the rebuild FC3 kernel 2.6.11-1.35.

Do you constantly run P2P filesharing? That is a typical reason too for
stopping SOHO hardware router to work as they have limited NAT
capacities.

Alexander


--
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.35_FC2smp
Serendipity 16:33:29 up 10 days, 23:25, load average: 0.13, 0.13, 0.06

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCy+yhEEG6lbNmp3MRAseLAJwLK3zAGz4koYp6YxPme+ sMOeUd7wCgoj3d
NQAo4LHlfuj1HtgyKrSa5Wc=
=q/PO
-----END PGP SIGNATURE-----

---

Kimmo Koivisto

2005-08-05, 02:28 AM CDT

On Wednesday 06 July 2005 16:21, Andr=E9 Cruz wrote:
> Hello.
> I have a router running FC 2 with kernel 2.6.10-1.770_FC2.
>
> Yesterday my network went down and a lot of "dst cache overflow"
> appeared in my console. I then increased
> my /proc/sys/net/ipv4/route/max_size from 8192 to 16384 and my network
> started to work again...
>
> The problem is that dst_cache keeps increasing:
> [root@saf113 root]# cat /proc/slabinfo |grep ip_dst_ca
> ip_dst_cache 9210 9210 256 15 1 : tunables 120 60 0 : slabdata 614 614 =
0
>
> This way the problem will repeat itself... Is there a solution to this?
> Is this a known bug?

Yes it is a known bug, see=20
http://oss.sgi.com/archives/netdev/2005-01/msg01367.html
http://lists.linuxcoding.com/rhl/2005/msg21777.html

The bug is fixed for vanilla 2.6.11 and AFAIK 2.6.11-1.7_FC3 was the firs=
t=20
FC3-kernel that had it fixed.

Flushing did not help for me, I had to monitor dst cache and reboot when =
cache=20
was full.=20

I had lots of udp fragments because of the IPsec VPN's, and for me those =
udp=20
fragments were the reason (I think).

Regards
Kimmo Koivisto
>
> Thanks for the help.
> Andr=E9

--=20
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list

---

Kimmo Koivisto

2005-08-05, 02:28 AM CDT

On Wednesday 06 July 2005 16:21, Andr=E9 Cruz wrote:
> Hello.
> I have a router running FC 2 with kernel 2.6.10-1.770_FC2.
>
> Yesterday my network went down and a lot of "dst cache overflow"
> appeared in my console. I then increased
> my /proc/sys/net/ipv4/route/max_size from 8192 to 16384 and my network
> started to work again...
>
> The problem is that dst_cache keeps increasing:
> [root@saf113 root]# cat /proc/slabinfo |grep ip_dst_ca
> ip_dst_cache 9210 9210 256 15 1 : tunables 120 60 0 : slabdata 614 614 =
0
>
> This way the problem will repeat itself... Is there a solution to this?
> Is this a known bug?

Yes it is a known bug, see=20
http://oss.sgi.com/archives/netdev/2005-01/msg01367.html
http://lists.linuxcoding.com/rhl/2005/msg21777.html

The bug is fixed for vanilla 2.6.11 and AFAIK 2.6.11-1.7_FC3 was the firs=
t=20
FC3-kernel that had it fixed.

Flushing did not help for me, I had to monitor dst cache and reboot when =
cache=20
was full.=20

I had lots of udp fragments because of the IPsec VPN's, and for me those =
udp=20
fragments were the reason (I think).

Regards
Kimmo Koivisto
>
> Thanks for the help.
> Andr=E9

--=20
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list