Completely DROP for UDP packets.

Completely DROP for UDP packets.

[msn]

Hi, I'm trying to dropping all UDP packets from specific address
but it still has higher CPU usages. anyone has ideas for this
issues ? here's example

A   --+--->  F
B   --+
C   --+

A/B/C sending massive UDP packets to F, also it has address dropping
rules fro A/B/C. Yes, it is works fine. But if i see the CPU usages
of 'F' some of cases it is using more than 20-30% when its(A/B/C)
sending 100M to F. is there any best way to decreasing the CPU usage
of the 'F' ? thanks in advance.

Cheers.

P.S :
1. INPUT filter dropping very higher CPU usages
2. TARPIT and prestate PREROUTING dropping less higher but not satisfied.

Re: Completely DROP for UDP packets.

[Martijn Lievaart]

msn wrote:
> Hi, I'm trying to dropping all UDP packets from specific address
> but it still has higher CPU usages. anyone has ideas for this
> issues ? here's example
>
> A   --+--->  F
> B   --+
> C   --+
>
> A/B/C sending massive UDP packets to F, also it has address dropping
> rules fro A/B/C. Yes, it is works fine. But if i see the CPU usages
> of 'F' some of cases it is using more than 20-30% when its(A/B/C)
> sending 100M to F. is there any best way to decreasing the CPU usage
> of the 'F' ? thanks in advance.
>
> Cheers.
>
> P.S :
> 1. INPUT filter dropping very higher CPU usages
> 2. TARPIT and prestate PREROUTING dropping less higher but not satisfied.
>
>   

TARPITTING does not work on UDP, it's for TCP only. Just DROP in the raw 
table.

HTH,
M4

Re: Completely DROP for UDP packets.

[msn]

So, it is NO

> msn wrote:
>> Hi, I'm trying to dropping all UDP packets from specific address but
>> it still has higher CPU usages. anyone has ideas for this
>> issues ? here's example
>>
>> A   --+--->  F
>> B   --+
>> C   --+
>>
>> A/B/C sending massive UDP packets to F, also it has address dropping
>> rules fro A/B/C. Yes, it is works fine. But if i see the CPU usages of
>> 'F' some of cases it is using more than 20-30% when its(A/B/C) sending
>> 100M to F. is there any best way to decreasing the CPU usage of the
>> 'F' ? thanks in advance.
>>
>> Cheers.
>>
>> P.S :
>> 1. INPUT filter dropping very higher CPU usages
>> 2. TARPIT and prestate PREROUTING dropping less higher but not
>> satisfied.
>>
>>
>
> TARPITTING does not work on UDP, it's for TCP only. Just DROP in the raw
>  table.
>
> HTH,
> M4

Re: Completely DROP for UDP packets.

[msn]

ignoring previous message. sorry...

So, it is NOT possible to decreasing the CPU usage of the massive UDP
handling in the linux kernel ? any comments would be nice to me. thanks in
advance.

Cheers.



> msn wrote:
>> Hi, I'm trying to dropping all UDP packets from specific address but
>> it still has higher CPU usages. anyone has ideas for this
>> issues ? here's example
>>
>> A   --+--->  F
>> B   --+
>> C   --+
>>
>> A/B/C sending massive UDP packets to F, also it has address dropping
>> rules fro A/B/C. Yes, it is works fine. But if i see the CPU usages of
>> 'F' some of cases it is using more than 20-30% when its(A/B/C) sending
>> 100M to F. is there any best way to decreasing the CPU usage of the
>> 'F' ? thanks in advance.
>>
>> Cheers.
>>
>> P.S :
>> 1. INPUT filter dropping very higher CPU usages
>> 2. TARPIT and prestate PREROUTING dropping less higher but not
>> satisfied.
>>
>>
>
> TARPITTING does not work on UDP, it's for TCP only. Just DROP in the raw
>  table.
>
> HTH,
> M4

Re: Completely DROP for UDP packets.

[Pascal Hambourg]

Hello,

msn a écrit :
> 
> So, it is NOT possible to decreasing the CPU usage of the massive UDP
> handling in the linux kernel ? any comments would be nice to me.

You cannot decrease the packet processing load in the network interface 
driver, unless you use a more "efficient" network card or driver. As 
Martijn wrote, the best you can do at iptables level is drop the packets 
as soon as possible, in the PREROUTING chain of the 'raw' table even 
though this is not the primary purpose of the 'raw' table. This will 
save CPU usage for the traversal of subsequent iptables chains, the 
connection tracking if it is enabled (as opposed to filtering in the 
PREROUTING chain of the 'mangle' table), the input routing decision and 
the fragment reassembly (as opposed to filtering in the INPUT chain of 
any table).

The path is as follows :

interface -> raw/PREROUTING -> conntrack & fragment reassembly -> 
mangle/PREROUTING -> nat/PREROUTING -> routing decision -> fragment 
reassembly -> mangle/INPUT -> filter/INPUT -> local delivery