[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Rate problems with both CBQ and TBF partially resolved

 So... It looks like I was wrong. All the TC components were functioning
correctly. The problem lay in getting packets into the filters. If I'd
been using my eyes, I would have realised earlier that the byte counter
for the filter was a mere 300k. I was transferring a 12Mb file. Only the
ACK packets from the FTP client were going through the filters, thus all
the business of halving the filter limit halving the transfer rate.

 The current question is why only half of the traffic is making it to
the filters. The problem seems to be to do with the kernel routing code
in Linux. You'll recall I have two subnets ( and bound to the same NIC (eth0), with traffic being routed
between the two subnets by the machine containing the TC system
(; Running a monitor on the network during
a transfer reveals that the kernel on the router machine is generating
ICMP_REDIRECT messages (presumably because the traffic is arriving and
leaving by the same card). This is backed up by running:

	[kb1@]$ $ ping -R

	PING ( from :
56(124) bytes of data.
	From Redirect Host(New nexthop:
	64 bytes from icmp_seq=0 ttl=128 time=5.7 ms NOP


	From Redirect Host(New nexthop:
	64 bytes from icmp_seq=3 ttl=128 time=3.3 ms
	NOP     (same route)

	--- ping statistics ---
	4 packets transmitted, 4 packets received, 0% packet loss
	round-trip min/avg/max = 3.2/3.9/5.7 ms

 I've gone into /proc/sys/net/ipv4/conf/eth0 and disabled send_redirects
(echo 0 > send_redirects) with no effect. I noticed an old message on
the kernel mailing lists about IN_DEV_TX_REDIRECTS not being referenced
correctly in route.c; ip_rt_send_redirect() but that has supposedly been
fixed in my kernel (2.2.12-20). For the life of me I can't work out why
redirects are being generated in the first place. The machines on either
end seem to be treating the routing correctly locally, even after the
	[kb1@]$ $ ping -R
which makes the ICMP_REDIRECTS occur, followed by:
	[kb1@]$ /sbin/route -Cn
	Kernel IP routing cache
	Source          Destination     Gateway         Flags Metric Ref
Use Iface
{clip}        0      0
10 teql0  l     0      0
8 lo

Still shows the router (; as the Gateway...
However, doing the same route cache dump on the router only shows the
active route from .48.250 -> .49.253 and not the route back! i.e.:

	[kb1@ kb1]# /sbin/route -Cn 
	Kernel IP routing cache
	Source          Destination     Gateway         Flags Metric Ref
Use Iface
{clip}  ri    0      0
133 eth0

I also find it strange that the RECORD_ROUTE option in the ECHO_REQUEST
generated by ping shows the router on the outbound frame, but not the
returned frame. I.e:


I've double checked for other machines that might be routing between the
subnets, or have misconfigured netmasks (ie. that might
be acting as bridges but I can't find anything. I can even see both the
ICMP_ECHO and the ICMP_REPLY packets if I run iptraf on eth0 on the

I'm grateful for any suggestions anyone might have... including a more
appropriate list to post routing questions to ;-)