Dotaz: GRE+IPSec - mala propustnost

[tomk]

Ahoj, snazim se zjistit pricinu male propustnosti tunelu GRE over IPSec v LTE modemu Conel SPECTRE v3. Na druhe strane je jak GRE, tak IPSec terminovan na malem Ciscu 871.

V modemu je dost osekany Linux (kernel 3.12.10) s busyboxem a minimem diagnostickych nastroju. Konfigurace je provedena prostrednictvim nastroju weboveho rozhrani modemu, ale ty v podastate pouzivaji standardni "ip" pro vytvoreni GRE tunnelu a pluto jako IKE daemona (ale jako implementaci IPSecu to pouziva kernelovy NETKEY). Aby to nebylo tak jednoduche, tak ma modem v ramci LTE dynamicky pridelovanou neverejnou IP adresu, takze se pouziva jeste NAT-T. Pro registraci GRE endpointu je pouzity OpenNHRP.

Za modemem na jedne strane a za Ciscem na druhe jsou dva pocitace, na nichz pouzivam iperf v UDP rezimu pro mereni propustnosti. Kdyz se posilaji data ze stany Cisca na stranu modemu, tak dosahnu cca 8Mbps, v opacnem smeru mi ale jede prenos pouze cca 500Kbps. Pri komunikaci v ramci Internetu (mimo IPSec tunnel) dosahuji pres modem rychlosti cca 22Mbps download a 17Mbps upload.

Co jsem se snazil vyloucit:

1. Vliv MTU - Jeste kdyz jsem delal pokusy jen pomoci TCP (scp), tak jsem zkousel zmensit primo MTU na rozhrani komunikujicich pocitacu - bez vlivu. Pro pokusy s iperf pouzivam parametr -l 1200, ktery generuje rovnou mensi datagramy.
2. Vliv vykonu CPU na modemu pro sifrovani. Standardne pouzivam AES-256/SHA1, zkousel jsem pouzit i AES-128/MD5 a DES/MD5, ale prakticky bez zmeny propustnosti. CPU je tam takoveto:

   processor	: 0
   model name	: ARMv7 Processor rev 2 (v7l)
   Features	: swp half fastmult vfp edsp neon vfpv3 tls vfpd32 
   CPU implementer	: 0x41
   CPU architecture: 7
   CPU variant	: 0x3
   CPU part	: 0xc08
   CPU revision	: 2
   
   Hardware	: Generic AM33XX (Flattened Device Tree)
   Revision	: 0000
   Serial		: 0000000000000000
   

   Vysledek "openssl speed aes-256-cbc" na modemu je navic radove srovnatelny s mym intel laptopem:

   # openssl speed aes-256-cbc
   Doing aes-256 cbc for 3s on 16 size blocks: 3019223 aes-256 cbc's in 2.98s
   Doing aes-256 cbc for 3s on 64 size blocks: 811793 aes-256 cbc's in 2.98s
   Doing aes-256 cbc for 3s on 256 size blocks: 210625 aes-256 cbc's in 2.98s
   Doing aes-256 cbc for 3s on 1024 size blocks: 53233 aes-256 cbc's in 2.98s
   Doing aes-256 cbc for 3s on 8192 size blocks: 6672 aes-256 cbc's in 2.99s
   OpenSSL 1.0.2h  3 May 2016
   built on: reproducible build, date unspecified
   options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) 
   compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
   The 'numbers' are in 1000s of bytes per second processed.
   type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
   aes-256 cbc      16210.59k    17434.48k    18093.96k    18292.14k    18279.94k
   

3. Vliv QoS v siti operatora (O2). Z PC za modemem jsem navazal IPSec VPN spojeni na VPN koncentrator v siti hned vedle Cisco routeru. Stejnou cestou a stejnym protokolem jsem dosahl rychlosti cca 12Mbps v obou smerech.
4. Spatne parametry ip stacku pro UDP - spis uz ze zoufalstvi jsem zkousel zvednout velikosti pro /proc/sys/net/ipv4/udp_* a pro /proc/sys/net/core/[rw]mem* ,ale nepozoroval jsem zadny efekt.
5. Problemy na strane Cisco routeru. Nainstaloval jsem si virtualni stroj s Fedorou, ve kterem jsem se pokusil replikovat setup z modemu - GRE+IPSec(NETKEY)+OpenNHRP. Z nej jsem dosahl rychlosti cca 10Mbps v obou smerech. Cisco v tu dobu narazi na svuj CPU limit.
6. Jen tak, mimo soutez, jsem zkousel propustnost samotneho GRE tunelu nba modemu. Nastavil jsem ho pouze mezi modemem a PC pripojenym po LAN. Propustnost byla cca 50Mbps.

Na modemu se mi zatim podarilo najit jediny indikator, ze je neco spatne. Pri uploadu pribyvaji na gre rozhrani dropnute ramce:

gre1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:xxx.xxx.xxx.xxx  P-t-P:xxx.xxx.xxx.xxx  Mask:255.255.255.255
          UP POINTOPOINT RUNNING  MTU:1472  Metric:1
          RX packets:45 errors:0 dropped:0 overruns:0 frame:0
          TX packets:704 errors:30 dropped:4547 overruns:0 carrier:30
          collisions:0 txqueuelen:0 
          RX bytes:6599 (6.4 KB)  TX bytes:768264 (750.2 KB)
usb0      Link encap:Ethernet  HWaddr DE:AD:BE:EF:00:00  
          inet addr:/modem_ip/  Bcast:100.255.255.255  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:401 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1121 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:176854 (172.7 KB)  TX bytes:897120 (876.0 KB)

Nedari se mi ale zjistit kde a proc se ty ramce ztraceji. Snazil jsem se chytat pomoci tcpdumpu ramce na gre rozhrani i na WAN/LTE(usb0) rozhrani. Prijde mi, ze na GRE vidim vsechny, ale ve streamu na WAN rozhrani jsou videt "diry" IPSecovych ESP sequence #:

No.     Time           Source                Destination           Protocol Length Info
    115 0.098272       /modem_ip/         /cisco_ip/          ESP      1326   ESP (SPI=0x1a975dd3)

Frame 115: 1326 bytes on wire (10608 bits), 300 bytes captured (2400 bits)
Ethernet II, Src: de:ad:be:ef:00:00 (de:ad:be:ef:00:00), Dst: 02:50:f3:00:00:00 (02:50:f3:00:00:00)
Internet Protocol Version 4, Src: /modem_ip/ (/modem_ip/), Dst: /cisco_ip/ (/cisco_ip/)
User Datagram Protocol, Src Port: ipsec-nat-t (4500), Dst Port: ipsec-nat-t (4500)
UDP Encapsulation of IPsec Packets
Encapsulating Security Payload
    ESP SPI: 0x1a975dd3 (446127571)
    ESP Sequence: 3807

No.     Time           Source                Destination           Protocol Length Info
    116 0.000393       /modem_ip/         /cisco_ip/          ESP      1326   ESP (SPI=0x1a975dd3)

Frame 116: 1326 bytes on wire (10608 bits), 300 bytes captured (2400 bits)
Ethernet II, Src: de:ad:be:ef:00:00 (de:ad:be:ef:00:00), Dst: 02:50:f3:00:00:00 (02:50:f3:00:00:00)
Internet Protocol Version 4, Src: /modem_ip/ (/modem_ip/), Dst: /cisco_ip/ (/cisco_ip/)
User Datagram Protocol, Src Port: ipsec-nat-t (4500), Dst Port: ipsec-nat-t (4500)
UDP Encapsulation of IPsec Packets
Encapsulating Security Payload
    ESP SPI: 0x1a975dd3 (446127571)
    ESP Sequence: 3808

No.     Time           Source                Destination           Protocol Length Info
    117 0.000181       /modem_ip/         /cisco_ip/          ESP      1326   ESP (SPI=0x1a975dd3)

Frame 117: 1326 bytes on wire (10608 bits), 300 bytes captured (2400 bits)
Ethernet II, Src: de:ad:be:ef:00:00 (de:ad:be:ef:00:00), Dst: 02:50:f3:00:00:00 (02:50:f3:00:00:00)
Internet Protocol Version 4, Src: /modem_ip/ (/modem_ip/), Dst: /cisco_ip/ (/cisco_ip/)
User Datagram Protocol, Src Port: ipsec-nat-t (4500), Dst Port: ipsec-nat-t (4500)
UDP Encapsulation of IPsec Packets
Encapsulating Security Payload
    ESP SPI: 0x1a975dd3 (446127571)
    ESP Sequence: 3899

No.     Time           Source                Destination           Protocol Length Info
    118 0.103109       /modem_ip/         /cisco_ip/          ESP      1326   ESP (SPI=0x1a975dd3)

Frame 118: 1326 bytes on wire (10608 bits), 300 bytes captured (2400 bits)
Ethernet II, Src: de:ad:be:ef:00:00 (de:ad:be:ef:00:00), Dst: 02:50:f3:00:00:00 (02:50:f3:00:00:00)
Internet Protocol Version 4, Src: /modem_ip/ (/modem_ip/), Dst: /cisco_ip/ (/cisco_ip/)
User Datagram Protocol, Src Port: ipsec-nat-t (4500), Dst Port: ipsec-nat-t (4500)
UDP Encapsulation of IPsec Packets
Encapsulating Security Payload
    ESP SPI: 0x1a975dd3 (446127571)
    ESP Sequence: 3905

Podle toho mi to pripada, jakoby se modemu podarilo nejak zasifrovat a pripravit data pro ESP packet, ale problem nastal az pri encapsulaci do UDP a data se mu nakonec nepodarilo odeslat. Nevim ale, kam se dal podivat, co proverit, pripadne nastavit.

Moje google-fu me zradilo, jedine podobne zoufale lidi jsem nasel u mikrotiku, jinak nic

Nemate s tim prosim nekdo zkusenost, nenapada vas neco?

Diky.

Odpovědi

[NN]

Jak se chova samotny IPSec tunel bez GRE jsi testoval?

[tomk]

Diky, vyzkousel jsem to ted. Download smer je stejny - cca 8Mbps, upload je 2x rychlejsi ~ 1Mbps. Neni to tedy merene primo proti tomu Ciscu, nemuzu tam tu konfiguraci rozbit, ale parametry IPSecu byly stejne. Bez GRE je to tedy o neco lepsi, ale stejne to neni uplne ono.

[tomk]

Nevim, jestli to neoveruju nejak divne. Zkousel jsem jeste chovani toho samotneho IPSecu v tunnel rezimu, bez GRE. Kdyz posilam ze strany modemu stream 5Mbps, tak na druhou stranu dorazi 20% - tedy ten 1Mbps, jak jsem psal vcera. Jenze kdyz generuju ze strany modemu stream 50Mbps, tak na druhou stranu dorazi zase zhruba 20%, tedy cca 9Mbps. Pri 80Mbps streamu zase 20% ~ 14Mbps. Vic jsem nezkousel. V kazdem pripade je ten sycak schopny tech 14Mbps vzit, zasifrovat, encapsulovat a po LTE poslat na druhou stranu.

Kdyz vratim konfiguraci s GRE, tak to tohle chovani kopiruje, jen s tim rozdilem, ze na druhou stranu dorazi jen 10%. Tedy pri streamu 5Mbps je to tech 500Kbps, pri 50Mbps streamu projde na druhou stranu 5Mbps.

Pricemz kdyz rikam, ze nedorazi na druhou stranu, tak ve skutecnosti ani neodejdou z modemu do LTE site.

[NN]

Ma to dve ETH sitovky? Neslo by to otestovat lokalne ie. sestavit tunel mezi eth1 a necim, vlozit mezi to switch a zmerit propustnost za tim boxem? Prepokladam, ze asi mas posledni firmware.

[tomk]

Ma to doknce 3 eth port, pricemz ten treti je sam o sobe jeste triportovy switch. Zkusil jsem nastavit IPSec v tunnel rezimu proti pocitaci na druhe strane ethernet kabelu. Je to o pidu rychlejsi, ale jinak se to chova stejne. Ciste po ethernetu, bez IPSecu to jelo cca 93Mbps - to mi ukazal iperf jak v TCP, tak i v UDP rezimu. Kdyz jsem ned tim spustil ten IPSec, tak mi to pri tom 50Mbps UDP streamu na druhe strane ukazalo cca 11Mbps (namisto 9 pri komunikaci pres LTE). Kdyz jsem tam zkusil poslat 95Mbps stream, tak se na druhou stranu dostalo 20Mbps. Kdyz jsem vyzkousel vykon tcp, na kolik se to rozjede, tak se to pohybovalo kolem 8Mbps.

[tomk]

Ano, firmware je tam 6.0.1 ze zacatku zari.

[NN]

Pokud je to mozne obratil bych se jeste na technickou podporu vyrobce.

[tomk]

Ano, diky, vyzkousim to. Prijde mi, ze honim nejake duchy kolem casovani, interruptu, nebo neceho podoneho a to jeste na certvijake architekture, na ktere je to postavene. Jen je mi divne, a jsem ze sebe zklamany, ze z zadneho cat /proc/* , ani z ip xfrm, ani whack cokoliv, ani z niceho podobneho nejsem schopny zjistit, kde se to v tom kernelu ztraci, co ma presne za problem. Ted, kdyz nepouzivam ani ten GRE tunnel, kde alespon naskakoval ten dropped counter, tak se tvari uplne vsechno jako v poradku, pritom zahazuje 80% packetu.

[Max]

Stále to tak nějak vypadá na to MTU. Zkus tu trasu cinknout pomocí tracepath :

tracepath -n IP_stroje_za_tunelem

A pak projistotu pingem :

ping -c 1 -M do -s 1400 IP_stroje_za_tunelem

Já totiž osobně nevím, jak se iperf chová, zda posílá DF (dont fragment), nebo ne. Když mi něco v síti straší, raději to zkontroluji více nástroji.
Zdar Max

[Max]

Jop, jinak mé google-fu mi vyplivlo toto : An IPSec mystery with dropped packets.
Zdar Max

[tomk]

... but this time I have a mystery instead of a solution ...

- jojo, presne moje situace!

[tomk]

tracepath dopadne takhle:

[root@server ~]# tracepath -n /za_modemem/
 1:  xxx.xxx.xxx.xxx   0.161ms pmtu 1500
 1:  xxx.xxx.xxx.xxx   0.866ms 
 1:  xxx.xxx.xxx.xxx   0.792ms 
 2:  xxx.xxx.xxx.xxx   5.250ms 
 3:  xxx.xxx.xxx.xxx   1.551ms 
 4:  xxx.xxx.xxx.xxx   1.620ms pmtu 1472
 4:  /modem/         268.024ms 
 5:  /za_modemem/     31.419ms reached
     Resume: pmtu 1472 hops 5 back 60 

[root@za_modemem ~]# tracepath -n /server/
 1?: [LOCALHOST]     pmtu 1500
 1:  /modem/           5.504ms 
 1:  /modem/           3.000ms 
 2:  /modem/           2.020ms pmtu 1414
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  /server/         40.301ms reached
     Resume: pmtu 1414 hops 11 back 5 

Ping projde:

[root@proxy ~]# ping -c 1 -M do -s 1400 /za_modemem/
PING /za_modemem/ (/za_modemem/) 1400(1428) bytes of data.
1408 bytes from /za_modemem/: icmp_seq=1 ttl=60 time=259 ms

--- /za_modemem/ ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 259ms
rtt min/avg/max/mdev = 259.837/259.837/259.837/0.000 ms

Pokud se tyka iperfu, tak alespon u tech UDP datagramu, se kterymi to zkousim, DF nenastavuje. Navic skutecne bere v potaz velikost zadanou parametrem -l na prikazove radce. Datagramy, ktere pak generuje, vypadaji takhle:

Frame 38: 1242 bytes on wire (9936 bits), 300 bytes captured (2400 bits)
Internet Protocol Version 4, Src: /za_modemem/ (/za_modemem/), Dst: /server/ (/server/)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 1228
    Identification: 0xc490 (50320)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0xd366 [validation disabled]
    Source: /za_modemem/ (/za_modemem/)
    Destination: /server/ (/server/)
User Datagram Protocol, Src Port: 62251 (62251), Dst Port: targus-getdata1 (5201)
Data (258 bytes)

Pral bych si, aby to byl problem s MTU. Sice bych si pripadal trapne, ze jsem na to neprisel, protoze to take byla prvni vec, co me napadla a kterou jsem se snazil vyloucit, ale i tak bych to bral

[arpanet]

  jaka verze IOSu je na 871 
  muzete ji zmenit ? 

#-----------------------------
neco podobneho mi delalo cisco<->cisco ... 
diry v ipsecu ... v tunelovacim modu 
pokud na lince nastal trochu jam v zavislosti na delce paketu
.... kdyz jsem to debugoval tak to bylo nekde okolo fragmentace 
.... ted verzi nevim .... 
ale v podstate po 2 dnech trapeni a loveni duchu
byla oprava nahranim posledni stable advipserv..
a rychle pryc ....
#-------------------------------------
ios na ozkouseni muzu poslat 
nebo to zaridit i legalne
ale 871 uz asi pod supportem 
nebude ta je end-off-vsechno
#--------------------------------

brandejs maelstrom vertix.cz

[tomk]

Diky, je pravda, ze je tam nejaka vykopavka s ios 12.4, ale to Cisco jsem myslim temi pokusy s PC routerem zapojenym primo na LAN vyloucil.

I v pripade, kdy jsem mel linuxovy router terminujici IPSec zapojeny na druhem rozhrani toho modemu, se to chovalo prakticky stejne.

Zkousel jsem ze strany modemu posilat stream udp datagramu velky 1200b a postupne jsem zvysoval datovy tok. Zacal jsem na 50Kbps, to prochazelo v poradku. Kdyz jsem se dostal na cca 200Kbps (a tedy asi 20pps), tak zacaly vypadavat prvni packety. Procento vypadnuvsich packetu se se vzrustajicim tokem postupne zvysovalo. Na tom by asi nebylo nic divneho (kdyby se to tedy cele neodehravalo pri tak malych tocich), jenze pri cca 5Mbps, kdy vypadavalo 80% packetu se zacala ztratovost drzet na stejne procentualni hodnote a celkova propustnost dale rostla. Pri 5Mbps tedy prosel cca 1Mbps, pri 50Mbps proslo 10Mbps a pri 80Mbps cca 16Mbps. Od 90Mbps se ztratovost zacala zase zvysovat, ale za to bych se na nej uz nezlobil .

[tomk]

Sorry, datagramy byly pochopitelne velke 1200B.

Jinak i kdyz jsem pak velikost datagramu zmensoval, az na nejakych 200B, tak k prvnim vypadkum zacinalo dochazet stale pri tech cca 20pps, tedy pri daleko nizsi prenosove rychlosti.