Hello Jonathan, The scenario works perfectly well on a NAT router. See, you drop excess of bits on the interface where the packets arrive. Which is before nating. Maybe we speak about different scenarios here? What I describe limits the maximum upload speed for ip in the LAN. Let me know the packet flow with the interfaces and IP addresses. Cheers, -Nikolay p.s. I am also CCing the lartc mailing list in case someone else can help. Jonathan Gazeley wrote: > Hi Nikolay, > > Thanks for this. I tried using the code below, but it did not work for > me. Is your server running tc also a NAT box? The reason I think my code > isn't working is because NAT and tc are on the same server, meaning that > the source IP of an outgoing packet is rewritten _before_ it gets to tc > -- meaning that it is not possible to match packets by source IP. > > Cheers, > Jonathan > > Nikolay Kichukov wrote: >> Hello, >> The policer is not 1: but ffff:, not engress(root) but ingress. >> >> Let me give you an example: >> >> tc qdisc add dev eth0 ingress handle ffff: >> TC_FILTER="tc filter add dev eth0 parent ffff: protocol ip" >> $TC_FILTER prio 2 u32 match ip src 192.168.0.6/32 police rate 32kbit >> burst 16kb drop flowid ffff: >> $TC_FILTER prio 2 u32 match ip src 192.168.0.4/32 police rate 128kbit >> burst 32kb drop flowid ffff: >> $TC_FILTER prio 2 u32 match ip src 192.168.0.2/32 police rate 128kbit >> burst 32kb drop flowid ffff: >> $TC_FILTER prio 2 u32 match ip src 192.168.0.5/32 police rate 128kbit >> burst 32kb drop flowid ffff: >> >> >> eth0 is the LAN interface which the 192.168.0.0/24 IPs are connected to. >> >> The rest is self explanatory. >> >> Let me know if I can help you with anything else. >> >> Cheers, >> -Nik >> >> >> >> Jonathan Gazeley wrote: >> >>> Hi Nikolay, >>> >>> How might this be implemented? I have used a shell script that loops >>> around with a new IP address each time, and then my police line looks >>> like this: >>> >>> tc filter add dev $LAN parent 1: protocol ip prio 50 u32 match ip src >>> 137.222.$j.$i police rate ${UPLINK}kbit burst 10k drop flowid :1 >>> >>> However my clients still have unlimited uplink. The other day, someone >>> told me that then the tc box is also NATing, the source IP is rewritten >>> before the police filter is applied - meaning that you cannot match on >>> source IP. How did you overcome this problem? >>> >>> Thanks for your help, >>> Jonathan >>> >>> >>> Nikolay Kichukov wrote: >>> >>>> Hello Jonathan, >>>> Indeed. I have tested with limited number of IPs though. Not sure how >>>> that scheme will behave if you apply it to a huge network. >>>> >>>> Cheers, >>>> -Nikolay >>>> >>>> Jonathan Gazeley wrote: >>>> >>>> >>>>> Hi Nikolay, >>>>> >>>>> Thanks for your help - this looks useful. Is it possible to apply a >>>>> police filter invidiually to each IP behind the NAT? >>>>> >>>>> Thanks, >>>>> Jonathan >>>>> >>>>> Nikolay Kichukov wrote: >>>>> >>>>>> Hello, >>>>>> You need to recompile your kernel and include the appropriate modules >>>>>> for htb to work. >>>>>> >>>>>> The other idea I have is to use policer to filter how much traffic >>>>>> PCs >>>>>> in the LAN upload. This is done on the LAN interface. Eliminates the >>>>>> need to mark packets, etc. >>>>>> >>>>>> You just drop all the packets that are coming in too fast. And >>>>>> presumably your LAN can do at least 100mbps, so the delay of packet >>>>>> retransmission can be neglected. >>>>>> >>>>>> HTH, >>>>>> -Nikolay >>>>>> >>>>>> Martin Milata wrote: >>>>>> >>>>>> >>>>>>> On Mon, Jul 30, 2007 at 02:58:00PM +0100, Jonathan Gazeley wrote: >>>>>>> [...] >>>>>>> >>>>>>>> 137.222.235.125 >>>>>>>> RTNETLINK answers: No such file or directory >>>>>>>> RTNETLINK answers: Invalid argument >>>>>>>> We have an error talking to the kernel >>>>>>>> RTNETLINK answers: No such file or directory >>>>>>>> RTNETLINK answers: Invalid argument >>>>>>>> We have an error talking to the kernel >>>>>>>> >>>>>>> [...] >>>>>>> >>>>>>> Hint: If you run your script as "bash -x script_name" (or use >>>>>>> #!/bin/sh -x >>>>>>> as shabang), you will be able to see which exact command caused the >>>>>>> error >>>>>>> message. >>>>>>> >>>>>>> Regards, >>>>>>> -MM >>>>>>> _______________________________________________ >>>>>>> LARTC mailing list >>>>>>> LARTC@xxxxxxxxxxxxxxx >>>>>>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >>>>>>> >>>>>> _______________________________________________ >>>>>> LARTC mailing list >>>>>> LARTC@xxxxxxxxxxxxxxx >>>>>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >>>>>> > _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc