[LARTC] Why does this script noet work (bandwidth, tc en u32)
Hi, Can anyone point me out where the script below is wrong? All I want is that host 172.31.1.1 can only use 10 megabit. If I run this script on the in-between router nothing happens (the host uses still the full 100 mbit, tested with iperf) , so i assume that something must be wrong #!/bin/sh # LAN1 NIC tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit # my machine tc class add dev eth0 parent 1:1 classid 1:2 htb rate 1mbit ceil 10mbit # filter tc filter add dev eth0 parent 1:1 protocol ip prio 1 u32 match ip dst 172.31.1.1 flowid 1:2 # LAN2 NIC tc qdisc del dev eth1 root tc qdisc add dev eth1 root handle 1: htb tc class add dev eth1 parent 1: classid 1:1 htb rate 100mbit # my machine tc class add dev eth1 parent 1:1 classid 1:2 htb rate 1mbit ceil 10mbit # filter tc filter add dev eth1 parent 1:1 protocol ip prio 1 u32 match ip src 172.31.1.1 flowid 1:2 TIA -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 web: www.askesis.nl ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Routing cache and the missing redirect flag
Hello, Should route -C show the RTCF_REDIRECTED flag ? (0x0004). I had searched in the code and it seems that it should show this flag by r. However, I could not show this flag by route -c even that it should have been there. I have the following scenario where I have this flag set. I see it in cat /proc/net/rt_cache but **not** in route -C. (BTW, ip route show table cache does not show flags at all). Here is what I do: We have machine A with ip 192.168.0.121. We have machine B with ip 192.168.0.10. On a machine A (192.168.0.121) I ran: route add -net 192.168.0.10 netmask 255.255.255.255 gw 192.168.0.189 The 192.168.0.189 machine, has forwarding and send_redirect set to 1. machine A (192.168.0.121) has accept_redirects set to 1. Now I run ping 192.168.0.10. I get a redirect: (as should indded be the case under these circumstances): PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data. 64 bytes from 192.168.0.10: icmp_seq=1 ttl=64 time=0.194 ms From 192.168.0.189: icmp_seq=2 Redirect Host(New nexthop: 192.168.0.10 Now , as far as I understand from the kernel code, this sets the RTCF_REDIRECTED in the route cache. And indeed, cat /proc/net/rt_cache | grep 0A00A8C0 shows: eth00A00A8C00A00A8C0 40 1 0 7900A8C0 1500 0 0 00 -1 0 7900A8C0 (0A00A8C0 is 192.168.0.10 in HEX.) We see here the fourth field, which is 4 (RTCF_REDIRECTED). **But**, route -Cn | grep 192.168.0.10 shows: 192.168.0.121 192.168.0.10192.168.0.189 0 02 eth0 192.168.0.10192.168.0.121 192.168.0.121 l 0 01 lo We don't see here the RTCF_REDIRECTED flag ! (the l is for RTCF_LOCAL). I had looked in the sources for route command ; route belongs to the net-tools package ; and parsing of flags is done in lib/netinet_gr.c, in the rprint_cache() method; According to the code there, this flag shoulf have been r: ... ... if (iflags RTCF_DOREDIRECT) strcat(flags, r); ... ... Any ideas? Regards, Ian ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Why does this script noet work (bandwidth, tc en u32)
On Tue, 2007-06-19 at 13:47 +0200, Joost Kraaijeveld wrote: Hi, Can anyone point me out where the script below is wrong? Maybee, I'm new to this stuff and having trouble getting some things to work myself. :S All I want is that host 172.31.1.1 can only use 10 megabit. If I run this script on the in-between router nothing happens (the host uses still the full 100 mbit, tested with iperf) , so i assume that something must be wrong #!/bin/sh # LAN1 NIC tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit # my machine tc class add dev eth0 parent 1:1 classid 1:2 htb rate 1mbit ceil 10mbit One thing I find useful (especially when debugging) is to replace the default fifo qdisc on the leaf with one that _does_ maintain statistics - which you can see with 'tc -s qdisc show dev ...'. Makes it a bit easier to see where your traffic is going, and if that matches your expectations/intentions. # filter tc filter add dev eth0 parent 1:1 protocol ip prio 1 u32 match ip dst 172.31.1.1 flowid 1:2 Try attaching the filter to the root qdisc (parent 1:0). What I think might be happening is that the root qdisc had no idea what to do with the packets - there are no filters there, and you did not specify a default class. So it just sends the packets directly to the interface. Or you could try adding default 1 to the root htb qdisc. From there your filter should do the rest. Only I don't know if default can point to a non-leaf class, if you try let me know if it works or not. HTH, Mark. # LAN2 NIC tc qdisc del dev eth1 root tc qdisc add dev eth1 root handle 1: htb tc class add dev eth1 parent 1: classid 1:1 htb rate 100mbit # my machine tc class add dev eth1 parent 1:1 classid 1:2 htb rate 1mbit ceil 10mbit # filter tc filter add dev eth1 parent 1:1 protocol ip prio 1 u32 match ip src 172.31.1.1 flowid 1:2 TIA ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Why does this script noet work (bandwidth, tc en u32)
Hi Mark, After changing the script in this way it seems to work (MI think that this is what you mend with attaching the filter to the root qdisk): # downlink tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit tc class add dev eth0 parent 1:1 classid 1:2 htb rate 1mbit ceil 10mbit tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst 172.31.1.1 flowid 1:2 # uplink tc qdisc del dev eth1 root tc qdisc add dev eth1 root handle 1: htb tc class add dev eth1 parent 1: classid 1:1 htb rate 100mbit tc class add dev eth1 parent 1:1 classid 1:2 htb rate 1mbit ceil 10mbit tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src 172.31.1.1 flowid 1:2 One thing I find useful (especially when debugging) is to replace the default fifo qdisc on the leaf with one that _does_ maintain statistics - which you can see with 'tc -s qdisc show dev ...'. Makes it a bit easier to see where your traffic is going, and if that matches your expectations/intentions. Could you elaborate on this? Which other fifo qdisc that maintains statistics? Any hints on the right syntax? TIA -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 web: www.askesis.nl ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Why does this script noet work (bandwidth, tc en u32)
Hey, # uplink tc qdisc del dev eth1 root tc qdisc add dev eth1 root handle 1: htb tc class add dev eth1 parent 1: classid 1:1 htb rate 100mbit tc class add dev eth1 parent 1:1 classid 1:2 htb rate 1mbit ceil 10mbit tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src 172.31.1.1 flowid 1:2 Could you elaborate on this? Which other fifo qdisc that maintains statistics? Any hints on the right syntax? i guess he is talking of e.g. sfq: tc qdisc add dev eth1 parent 1:2 handle 2: sfq perturb 10 -- Frank Remetter http://www.remetter.de/ GPG-FP: 2B07 B7D8 5C27 AB94 7A37 8B0B DEBE DD89 D68B 7BE6 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Fwd: police burst is mandatory?
Stas Oskin wrote:
Hi.
I'm using the following filter from lartc ultimate PPP example:
tc filter add dev $DEV parent : protocol ip prio 50 u32 match ip src \
0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
It works fine, but when I remove the burst 10k, I receive the following
error:
burst requires rate.
Illegal police
AFAIK, burst is how many bytes can be transferred over rate up to ceil
and is an optional parameter, but here it is mandatory? Also, shouldn't the
ceil parameter absence make this parameter useless?
You are thinking of htb - for policer burst/buffer is required.
policers don't delay/shape/queue packets, they just drop overrate
packets (when used with the drop param).
The burst is the length of a virtual buffer used to decide when to drop
a packet, when it's full everything else gets dropped till enough time
has passed for it to have enough room for the next packet, how much time
depends on the rate.
It needs to be at least MTU (MTU+14 on eth) or the policer won't pass
full size packets at all. If you make it too small, like making a real
buffer too small - it won't be nice for tcp throughput.
Andy.
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Re: PQ questions
Tim Enos wrote: Cool, Thanks Christian! I'm wishing that all of those same params showed up in the output without having to run anything. No problem. Should it matter that I'm using an emulated interface? Quite possibly - using prio on real devices still can appear not to work until you have filled up any buffer the driver uses. On my 100meg eth it would take 5/6 unscaled tcp connections to fill enough for prio to do anything. You can use prio as a child of hfsc/htb so that they set the rate. It may be nicer to use htb's own prio though, if you need a slow rate and care about latency. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Linux bridging and cascaded switches
On Tue, Jun 19, 2007 at 05:54:46PM -0500, Greg Scott wrote: Hi - Still plugging away at my Linux bridge/firewall and thinking through the consequences. In a normal firewall situation, the Internet is on one side, the internal LAN on the other. Duh! But now, with a Linux bridge in the middle, the whole thing becomes one big messy LAN. So we have a scenario that looks like this: Internal---User---Core-Firewall---Internet---Internet router Servers switch switch (Bridged)switch (and default GW for internal servers) out of curiosity why would you want to bridge at the firewall. is this meant to be a drop in-line firewall appliance The scenario is a little more complex than I drew above because the internal side has more than one LAN segment participating in the bridge. I'm working on a way to simulate all this here - before going into production - but I have a big question; That firewall/bridge is no longer a router - it's a bridge. Well, a bridge that also does a bunch of stateful IP layer 3 filtering. So now, it will participate in a spanning tree setup with all those switches, on both sides of it - right? I'm guessing I want to turn off STP in this case. Am I on the right track? if there is only 1 way to connect from the corporate (private LAN) to the public (internet) then I don't think you will need STP - it was meant to stop loops in ethernet segments. If you have multiple paths you might still need it Thanks - Greg Scott ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc signature.asc Description: Digital signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Linux bridging and cascaded switches
On Tue, Jun 19, 2007 at 06:35:46PM -0500, Greg Scott wrote: out of curiosity why would you want to bridge at the firewall. is this meant to be a drop in-line firewall appliance Long story but yes, it is essentially a drop in-line system. It's a mess. So will that Internet router really see 4 switches - a switch, a bridge, and 2 switches - between it and the internal servers? I don't remember all my LAN rules but that feels way too deep to me. I think that was the old 5-4-3 or was it 4-3-2 ... I think that was more in the days of repeater and broadcast hubs. Modern day switch I believe allow for a lot more. - Greg signature.asc Description: Digital signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
