Re: lug-bg: Tunnel iziskvania

[Vesselin Kolev <vlk@xxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


| Колев Правил ли си тестове машините да са със SCSI дискове а не с
| IDE? На Celleron 366 MHz мисля че около 10% от процесорното време се
| изразходва за управление на IDE диск(овете). Май ако в компютъра има
| и осакатена (жълта) мрежова карта и тя товари допълнително, в случая
| не говора за 3COM и INTEL. Общо казано, зависи какво е "желязато"...
|
Момент, аз говорих за рутери, а не за файлови сървъри. Поне аз на
софтуерен рутер не ползвам SCSI. Що се касае до IDE диковете, в
един рутер, като моите, те почти не се използват. А и жълти карти
не ползвам.

Има обаче един такъв номер, който малко се прилага и разбира. Пак
се връщам на QoS схемата. Не можеш да пускаш сесиите да договарят
скоростта вътре в тунела. Това трябва да става вън от него. Иначе
генерираш колизии и допълнителен товар. Т.е. QoS става преди
тунела.

След това, нужно е да се знае, че трябва да се задели "extra
bandwith" за тунела. Трафик 10 Mbps генериран в тунел не е 10 Mbps
в преносната среда, а е на 10-15% повече. Причината е, че част от
трафика се заделя за капсулация и контрол на параметрите в тунела.

Ако се спазят посочените по-горе изисквания, всичко вече зависи от
натоварването на процесора и качеството на хардуера. Т.е. след като се
изпълнят горните съвети ще може да се прави какъвто и да е извод
за качеството на конфигурацията и прилагането и за тунелно решение.

Специално за IPsec схемата на натоварване е следната. При "вдигане"
на тунела имаш "handshake" процес, който наистина вдига много товара
на системата, но пък пакети още не минават така, че тук няма как да
говорим още за загуби на пакети. След ръкостискането стартираш
кодиране със симетричен криптоалгоритъм, което далеч не е толкова
натоварващо. Например, аз използвам BlowFish и CAST. Не обичам
потоковите алгоритми като RCx. Все пак, ако се говори за натоварването
при изпълнение на симетричния алгоритъм, то можем да разгледаме
два случая: запълване на канал 10 Mbps с малки пакети и запълване на
канал 10 Mbps с пакети равни на каналния MTU. При първия случай
(малки пакети) натоварването ще е по-голямо в сравнение с втория.

При мен тунелни решения има от 2 години и то става въпрос за VPN
връзки за канали от порядъка на 10 Mbps. При всички случаи, в които
съм имал проблеми, след анализ става ясно, че вина за загубите на
пакети носи неправилното QoS планиране. От 2 месеца за нуждите на
един проект (OpenIntegra) правя изпитания с високоскоростно трасе
(80 Mbps) реализирано вътре в IPsec тунел. Следим броят колизии
при макисмални натоварвания. Машините, които реализират трасето са
със следните параметри:

OS: Linux (RedHat 9 - kernel 2.4.20-20.9)
CPU: Athlon 900 MHz
RAM: 256 MB (DDR)
HDD: Seagate SATA 80 GB (7200)
LAN: 2xIntel 82557 (модул eepro100.o)


Демони:

sendmail - сдвоена структура (2 демона с различно предназначение)
извършващи TLS сесии.

sshd - използва се и за реализация на файлов сървър (шел scponly
и chroot на демона и потребителите)

httpd - използва се за обмен на файлове в SSL режим (достъп до
файлови хранилища след удостоверяване чрез валиден X.509) също в
chroot

named - в рекурсивен режим и в chroot, използва TSIG и rndc

stunnel - достъп до POP3 и IMAP4 след удостоверяване с валиден X.509

proftpd - файлов сървър, пуснат в режим на TLS логин и пренос


QoS: чрез tc (от iproute2)

Преди да направим QoS схемата имахме загуби на пакети дори без
голям товар от страна на демоните. След това нямахме загуби дори
при 97% запълване на канала. При голямо натоварване от страна на
демоните има забавяне на отговорите на пакетите. Един единствен
път имаше загуби на пакети при усилен пинг на broadcast вътре в
тунела.

~  Поздрави
~    Весо
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/oN/X+48lZPXaa+MRAuu/AKCVlGMMrOrKKd55Qud8imJ+imZaXwCgzXaT
n8EwWhpcuUnbGpPrhQpBOPo=
=bE01
-----END PGP SIGNATURE-----


============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================