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
