click
click copied to clipboard
expensive Packet::push; have 0 wanted 14
Hello everyone, I have the following IPSec configuration script:
in::FromDevice(enp4s0f1)
-> IPPrint("I took the packet")
-> Strip(14)
-> CheckIPHeader()
-> GetIPAddress(16)
-> ipsec_rt::RadixIPsecLookup( 10.10.1.1/32 0,
192.168.2.0/24 10.10.2.1 1 111 1111111111111111 1111111111111111 1 0 ,
0.0.0.0/0 2
);
ipsec_rt[0]
// Receive
-> Discard;
ipsec_rt[1]
-> IPsecESPEncap()
-> IPsecAuthHMACSHA1(0)
-> IPsecAES(1)
-> UDPIPEncap(10.10.1.1 , 4500 , 192.168.2.5 , 4500)
-> EtherEncap(0x800,3c:fd:fe:04:ad:40,3c:fd:fe:04:c1:e2 )
-> IPPrint("Hello this is an IPSec packet")
-> Queue
-> ToDevice(enp4s0f0);
ipsec_rt[2]
// Default
-> Discard;
When traffic(from FastUDPSource element) inserts in the click configuration I took the following warning but I don't know what does it really means.

I m kindly asking you for some input,
https://pdos.csail.mit.edu/pipermail/click/2007-April/005780.html
It means there was not enough headroom (available space) to insert the headers. The default headroom is 28 bytes, which is probably being used by the UDPIPencap so when the EtherEncap wants to add another header in front of the packet, there is no free space.
I have not tried this, but you could try recompiling click after changing the default headroom to say 48 bytes in 'include/click/packet.hh'
I imagined that such a thing would be the cause.
Does this affects the IPSec functionality? And by this I mean, does this affects the throughput at the sink?
This does not affect the functionality but certainly kills the throughput.
You can use the HEADROOM argument of FromDevice to allocate more headroom to incoming packets.
Alternatively, DPDK packets come with 128 bytes of Headroom and it will be much faster too.
Thank you @tbarbette.
May I ask you a question, is it wrong for IPSec functionality if i don't use the UDPIPEncap and EtherEncap and have something like this?
ipsec_rt[1]
-> IPsecESPEncap()
-> IPsecAuthHMACSHA1(0)
-> IPsecAES(1)
-> Queue
-> ToDevice(enp4s0f0);
Never used IPsec, sorry.
The HEADROOM argument seems to be working. The warning stop.