Re: [LARTC] htb and fw problems
Hello, On Wednesday 04 August 2004 11:00, Ing Isianto Istiadi wrote: > I'm using the kernel 2.6.6, iproute2-2.4.7.20020116, iptables v1.2.9, and > gentoo. I have a leased-line 64 kbps. > I can see the counter works in iptables, but in the htb, it doesn't go to > the right class (it always go to the default class). > > Any help will be appreciated > > > here's my htb conf > #!/bin/bash > > tc qdisc del dev eth1 root > > tc qdisc add dev eth1 root handle 1: htb default 80 > tc class add dev eth1 parent 1: classid 1:1 htb rate 65kbps ceil 65kbps > tc class add dev eth1 parent 1:1 classid 1:10 htb rate 20kbps ceil 35kbps > prio 3 tc class add dev eth1 parent 1:1 classid 1:20 htb rate 5kbps ceil > 10kbps prio 0 tc class add dev eth1 parent 1:1 classid 1:30 htb rate 8kbps > ceil 11kbps prio 2 tc class add dev eth1 parent 1:1 classid 1:40 htb rate > 23kbps ceil 40kbps prio 1 tc class add dev eth1 parent 1:1 classid 1:80 htb > rate 8kbps ceil 10kbps prio 4 Well, it's just a wild guess, but do you really have a 64 k-byte/second leased line or could it be a 64 k-bit/second line? If it's the latter you should try: tc class add dev eth1 parent 1: classid 1:1 htb rate 64kbit ceil 64kbit and see if that works out. I'd also highly recommend reading http://www.docum.org/docum.org/faq/cache/74.html rgds, Arno ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multiple tc filter rules
Hi Jonathan, On Tue, 16 Mar 2004 11:09:31 + Jonathan Naylor <[EMAIL PROTECTED]> wrote: > I am in the position of needing to filter on two parameters, I need to filter > on IP address and I also need to filter on the value of a connection mark. I > understand the syntax of the tc filter command for each, but how can I > combine them ? Is it possible to put the two tc filter commands in series or > is there some syntax to do it in one tc filter command ? Well, I think it's easiest include the IP-Filtering into iptables like this: iptables -t mangle -A -[d|s] -j MARK --set-mark 1 and then set up a filter with tc that directs the traffic to the right class. Regards, Arno. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Incorrect source address in ARP request. Anyone seen
> requests with src 17.70.0.1? Linux ARP follows the routing and will
> reply in this case (when used in place of the router).
Yes that's true. Unfortunately it seems that Linux is one of the few
who implement this behaviour. Others seem to hold the view that
ARP is a link-level protocol and as such only has any relevance for
the scope defined on the interface itself.
So even though it's technically possible and legal to do so according
to the RFC, it's unfortunately not often used in practice..
> to handle such case. The problem comes only if "router decides not
> to accept ARP from valid source IP from valid input device".
Which seems to cover almost all dedicated routers (eg. Cisco) and probably
quite a few other OS'es too.
> Take a look at arp_solicit()
Saw that.. I'll mangle it a bit so it will only send out the
link address. That way it's compatible with what other devices expect.
Thanx for the help! At least I know I hadn't screwed up something.
Bye, Arno.
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Incorrect source address in ARP request. Anyone seen this?
I'm using iproute2-ss010824 and a 2.4.20 kernel. Quite a subtle issue here, so I can imagine it has not been spotted before. The setup: I have set up a machine as a gateway. The 'external' interface uses a dummy IP address (eg. 10.0.0.2) and the internal side is a normal address. (it's more complex in real life using Zebra and such, but this is the basic setup that shows the problem) To make sure I can start connections to the outside world from this machine I must make sure that the source address of the packets is from the internal interface with the 'real' address range, or otherwise packets won't come back as they would originate from the 10.0.0.x range. I could not use iptables to translate/NAT the source address (other issues there), but the 'scope' option in iproute2 seemed the best answer and indeed it seems to work fine. I have now set up the internal interface with a 'global' scope and the external with a 'link' scope: 1: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 02:02:05:62:00:23 brd ff:ff:ff:ff:ff:ff inet 17.70.0.1/28 brd 17.70.0.15 scope global eth0 2: eth1: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:30:48:27:25:15 brd ff:ff:ff:ff:ff:ff inet 10.0.0.2/24 brd brd 10.0.0.255 scope link eth1 So according to the docs now it should select the 10.0.0.2 address for directy connected machines and use the 17.70.0.1 address for 'remote' destinations. This basically works fine. When I connect to a directly-connected 10.0.0.xxx address it indeed chooses the 10.0.0.2 source address (link-address), but when connecting to a remote host (via a GW learned by Zebra) it uses the 17.70.0.1 source address. Great! Problem solved! Well.. Almost.. There seems to be one snag: Incorrect ARP source address. If there is no ARP entry for the gateway yet (no traffic has gone out, routes learned from another BGP peer) and I try to reach a remote address immediately then the ARP request that goes out on the 10.0.0.0 network for the correct gateway does *not* contain the 10.0.0.2 source address, but instead 17.70.0.1. Well.. That obviously does not work as this IP address does not occur on this LAN and as a reasult most other routers will (correctly) ignore this. If I try to connect to the correct gateway on a 10.0.0.x adress directly then it does work as it will use the correct 10.0.0.2 source for it's ARP request. It seems that the ARP code also chooses the 'global' scope address for the ARP request, while it should really always choose the 'link' address of this interface as the source of the broadcast. I have now temporarily fixed this by either adding some static ARP entries or ARP-table filtering using iptables, but I feel that's only a temporary measure. Have I overlooked something in my setup or should I start poking in the kernel ARP code? Thanx! Bye, Arno. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
