Re: [LARTC] Re: tc n00b

[Nikolay Kichukov <hijacker@oldum.net>]

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@mailman.ds9a.nl
>>>>>>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>>>>>>>                         
>>>>>> _______________________________________________
>>>>>> LARTC mailing list
>>>>>> LARTC@mailman.ds9a.nl
>>>>>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>>>>>>                   
> 
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc