On 18.7.2021. 20:39, Hrvoje Popovski wrote:
> On 18.7.2021. 20:11, Alexander Bluhm wrote:
>> On Sat, Jul 17, 2021 at 06:32:59PM +0200, Hrvoje Popovski wrote:
>>> with this diff i'm getting very stable traffic over tunnel and it's
>>> little faster.
>>
>> This is expected.  Too much queueing creates oscilating behavior
>> and suboptimal throughput.
>>
>>> Even with your last diff on tech@
>>> https://marc.info/?l=openbsd-tech&m=162645141414262&w=2
>>> i'm seeing traffic drops, less frequent, but i'm seeing it...
>>
>> There is another reason for traffic drops.  iked(8) is not clever
>> when rekeying.  The idea is to have SAs with old key and new key
>> simultaneously.  After both machines have new SA, the old should
>> be removed.  But currently we have a window when sender uses new
>> SA, but receiver only has old SA and cannot decrypt the packets.
>> This is a temproray problem, I see drops for a short time.  tobhe@
>> wants to fix this.
>>
>> I think you use isakmpd(8), I don't know how rekeying works there.
> 
> Yes, I'm using isakmpd, but I can test iked and isakmpd, no problem ...
> 
> 
>>> Do you want me to test this diff combined with your ipsec diff
>>> on tech@ ?
>>
>> I have commited the replay diff.  This fixes permanent packet drop.
>> Do you see permanent traffic stalls with current?
> 
> With isakmpd yes, iked haven't tested, but i will now ..
> But with your diff from bugs@ everything seems smooth and stable without
> drops and panics even with isakmpd :)

I've setup isakmpd and iked tunnels and tested both daemons with or
without replay diff from tech@ and they behave very similar.

I have 2 same boxes with 6 x E5-2643 v2 @ 3.50GHz, 3600.44 MHz, 06-3e-04
and sending traffic (1000 byte UDP) through tunnel between them.

ipsec.conf
ike active esp from 192.168.232.0/24 to 192.168.123.0/24 \
        local 192.168.42.1 peer 192.168.42.111 \
        main auth hmac-sha1 enc aes group modp1024 \
        quick enc aes-128-gcm group modp1024 \
        psk "123"

iked.conf
ikev2 active esp from 192.168.232.0/24 to 192.168.123.0/24 \
        local 192.168.42.1 peer 192.168.42.111 \
        ikesa enc aes-128-gcm group modp1024 prf hmac-sha1 \
        childsa enc aes-128-gcm group modp1024 \
        psk "123"

In this config with these boxes if i send up to 150Kpps through iked or
ipsec tunnel, tunnel is stable with or without diff. If I send 200Kpps
traffic through ipsec tunnel, traffic drops and won't come back, iked
tunnel would come back, but after few minutes it stops forwarding
traffic completely.
If i send 250Kpps or more, with or without replay diff ipsec or iked
tunnel stops forwarding traffic after few seconds ...

So I think that reply diff only prolong permanent stalls of traffic

Interesting is that when traffic completely stops i need to do ifconfig
ix1 down && ifconfig ix1 up, ix1 is the interface where my generator is
connected, to make traffic flow through tunnel. Stopping the generator
and run it again didn't help, only down/up of ix1 interface.
When traffic stops mcl2k2 Fail counter increases..

r620-1# vmstat -m | egrep "Fail|mcl"
Name        Size Requests Fail    InUse Pgreq Pgrel Npage Hiwat Minpg
Maxpg Idle
mcl2k       2048     1225 3957        0     3     0     3     3     0
  8    0
mcl2k2      2112 285844285 198      183 58658     1 58657 58657     0
  8    0
mcl4k       4096      112 1327        0     1     0     1     1     0
  8    0
mcl8k       8192      406  302        0     1     0     1     1     0
  8    0




With queuing diff that you sent here on bugs@, iked behaves the same as
before, i just need to send about 600Kpps or more through tunnel and i'm
not seeing and mcl Fails when traffic stops.
On other hand, isakmpd is stable at 150Kpps even if sending 12Mpps
through tunnel ...


I'm sorry if this mail is not clear enough, I'm testing, repeating
tests, and writing here what I'm seeing



Reply via email to