abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 19:55 | Nová verze

Po dvou letech od vydání verze 3.0 byla vydána nová major verze 4.0 nástrojů LXC, LXD a LXCFS pro kontejnerovou virtualizaci LXC (LinuX Containers). Jedná se o verzi s dlouhodobou podporou (LTS). Ta končí v červnu 2025. Přehled novinek v jednotlivých oznámeních o vydání: LXC, LXD a LXCFS.

Ladislav Hagara | Komentářů: 2
včera 16:11 | Humor

Řada firem své letošní již připravené aprílové žertíky kvůli SARS-CoV-2 a COVID-19 nezveřejnila. Přehled zveřejněných například na April Fools' Day On The Web. Na CoinMarketCapu byla přidána nová kryptoměna: toaleťáky. Ve hře World of Tanks jsou vylepšené tanky, v PUBG nový herní mód Fantasy Battle Royale, …

Ladislav Hagara | Komentářů: 3
včera 15:22 | Zajímavý projekt

Komunity KDE a GNOME, které doposud vyvíjely příslušná desktopová prostředí, se rozhodly přestat tříštit síly a představují společný projekt KNOME, který nabídne konfigurovatelnost GNOME a jednoduchost KDE v jednom balíčku. Staví na technologiích QTK3 a Kutter.

Fluttershy, yay! | Komentářů: 22
včera 14:11 | Nová verze

Tradičně na apríla byla vydána nová stabilní verze OpenTTD (Wikipedie), tj. open source klonu hry Transport Tycoon Deluxe. Přehled novinek v nejnovější verzi 1.10.0 v seznamu změn. Starší verzi OpenTTD lze vyzkoušet také v prohlížeči.

Ladislav Hagara | Komentářů: 0
včera 06:00 | Nová verze

Po čtyřech a půl měsících vývoje od vydání verze 5.3 byla vydána nová verze 5.4 svobodného open source redakčního systému WordPress. Kódové označení Adderley bylo vybráno na počest amerického jazzového trumpetisty Nata Adderleyho.

Ladislav Hagara | Komentářů: 0
31.3. 23:44 | IT novinky

Association for Computing Machinery vzhledem k probíhající pandemii COVID-19 nabízí bezplatný přístup do databáze publikací ACM Digital Library, a to do 30. června 2020.

Fluttershy, yay! | Komentářů: 2
31.3. 23:11 | IT novinky

Humble Bundle nabízí balík her (některých multiplatformních a/nebo bez DRM), knih, komiksů,… za cenu alespoň €28. Akce Humble Conquer COVID-19 Bundle probíhá do 7. dubna. Výtěžek bude věnován humanitárním/charitativním organizacím Lékaři bez hranic, Direct Relief, International Rescue Committee a Partners In Health.

Fluttershy, yay! | Komentářů: 7
31.3. 18:44 | Komunita

Český LibreOffice tým vydává překlad příručky LibreOffice Online. Příručka vznikla překladem anglického originálu, který byl vytvořen v rámci projektu Google Season of Docs 2019. Příručka je ke stažení na českých stránkách LibreOffice. Český tým pokračuje s překladem příručky Začínáme s LibreOffice a hledá další dobrovolníky pro překlad z angličtiny a revize přeloženého textu.

Zdeněk Crhonek | Komentářů: 0
31.3. 17:55 | Nová verze

Theia je nové modulární vývojové prostředí (IDE) určené k běhu jako webová aplikace a modifikovatelné pomocí doplňků kompatibilních s MS Visual Studio Code. Vývoj zaštiťuje Eclipse Foundation. Více v oznámení vydání verze 1.0.

Fluttershy, yay! | Komentářů: 1
31.3. 17:44 | Upozornění

V souvislosti s nedávnými kybernetickými útoky na nemocniční zařízení v České republice nabídl Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) ve spolupráci se sdružením CZ.NIC, správcem české národní domény a provozovatelem Národního bezpečnostního týmu CSIRT.CZ, pomoc klíčovým zdravotnickým subjektům, na které se vztahuje reaktivní opatření NÚKIB.

Ladislav Hagara | Komentářů: 2
Chodíte do práce?
 (14%)
 (0%)
 (7%)
 (0%)
 (59%)
 (21%)
 (0%)
Celkem 29 hlasů
 Komentářů: 2, poslední dnes 00:16
Rozcestník

www.AutoDoc.Cz

Dotaz: GRE+IPSec - mala propustnost

24.9.2016 20:41 tomk
GRE+IPSec - mala propustnost
Přečteno: 583×

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

24.9.2016 21:18 NN
Rozbalit Rozbalit vše Re: GRE+IPSec - mala propustnost
Jak se chova samotny IPSec tunel bez GRE jsi testoval?
24.9.2016 22:57 tomk
Rozbalit Rozbalit vše Re: GRE+IPSec - mala propustnost
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.
25.9.2016 11:41 tomk
Rozbalit Rozbalit vše Re: GRE+IPSec - mala propustnost

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.

25.9.2016 12:10 NN
Rozbalit Rozbalit vše Re: GRE+IPSec - mala propustnost
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.
25.9.2016 15:53 tomk
Rozbalit Rozbalit vše Re: GRE+IPSec - mala propustnost

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.

25.9.2016 15:55 tomk
Rozbalit Rozbalit vše Re: GRE+IPSec - mala propustnost

Ano, firmware je tam 6.0.1 ze zacatku zari.

26.9.2016 08:22 NN
Rozbalit Rozbalit vše Re: GRE+IPSec - mala propustnost
Pokud je to mozne obratil bych se jeste na technickou podporu vyrobce.
26.9.2016 11:46 tomk
Rozbalit Rozbalit vše Re: GRE+IPSec - mala propustnost

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 avatar 24.9.2016 22:09 Max | skóre: 68 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: GRE+IPSec - mala propustnost
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
Měl jsem sen ... :(
Max avatar 24.9.2016 22:15 Max | skóre: 68 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: GRE+IPSec - mala propustnost
Jop, jinak mé google-fu mi vyplivlo toto : An IPSec mystery with dropped packets.
Zdar Max
Měl jsem sen ... :(
25.9.2016 00:17 tomk
Rozbalit Rozbalit vše Re: GRE+IPSec - mala propustnost
... but this time I have a mystery instead of a solution ...
- jojo, presne moje situace! :-)
25.9.2016 00:04 tomk
Rozbalit Rozbalit vše Re: GRE+IPSec - mala propustnost

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 ;-)

26.9.2016 08:46 arpanet | skóre: 1
Rozbalit Rozbalit vše Re: GRE+IPSec - mala propustnost
  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
26.9.2016 11:31 tomk
Rozbalit Rozbalit vše Re: GRE+IPSec - mala propustnost

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 ;-).

26.9.2016 11:58 tomk
Rozbalit Rozbalit vše Re: GRE+IPSec - mala propustnost

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.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.