[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 (192.168.48.0/24 and
192.168.49.0/24) bound to the same NIC (eth0), with traffic being routed
between the two subnets by the machine containing the TC system
(192.168.48.251;192.168.49.251). 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@192.168.48.250]$ $ ping -R 192.168.49.253

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

{clip}

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

	--- 192.168.49.253 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
ICMP_REDIRECT. I.e.:
	[kb1@192.168.48.250]$ $ ping -R 192.168.49.253
which makes the ICMP_REDIRECTS occur, followed by:
	[kb1@192.168.48.250]$ /sbin/route -Cn
	Kernel IP routing cache
	Source          Destination     Gateway         Flags Metric Ref
Use Iface
{clip}
	192.168.48.250  192.168.49.253  192.168.48.251        0      0
10 teql0
	192.168.49.253  192.168.48.250  192.168.48.250  l     0      0
8 lo

Still shows the router (192.168.48.251;192.168.49.251) 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@192.168.48.251 kb1]# /sbin/route -Cn 
	Kernel IP routing cache
	Source          Destination     Gateway         Flags Metric Ref
Use Iface
{clip}
	192.168.48.250  192.168.49.253  192.168.49.253  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:

{clip}
	RR:     192.168.48.250
	        192.168.49.251
	        192.168.49.253
	        192.168.48.250
{clip}


I've double checked for other machines that might be routing between the
subnets, or have misconfigured netmasks (ie. 255.255.254.0) 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
router.

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

k.