Тайни на тестване на Ethernet канали

Добър ден скъпи приятели. В продължение на няколко години тя работи като системен администратор в редица корпоративни и домашни доставчици в Санкт Петербург и до днес често се сблъсквам с факта, че при закупуване на оборудване операторите гледат повече на цената и описанието на функциите, отколкото на реалните показатели, доставчиците обикновено не пишат нищо за тях, в резултат на което вместо един ключ трябва да инсталирате все повече и повече, а качеството на комуникацията може да не се подобри. Не всички оператори са наясно със съществуването на концепцията за SLA (споразумение за ниво на обслужване), поради което събрах надеждна информация за тестване на мрежи и оборудване и съм готов да ви я предоставя на вашето внимание.

Ethernet трябва да бъде тестван!

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

Какво точно и защо трябва да тествате?

Наети или наети от вас комуникационни канали;
Доставка и приемане на комуникационни канали, изградени от вас или за вас;
Предоставени комуникационни услуги, особено ако в договора има неустойка;
Оборудване, което искате да купите, но те искат да ви го продадат и да ви кажат, че е супер готино и евтино.

Това са малка шепа примери за това, което клиентите и превозвачите са изложени на риск днес.

Меки помощни програми за тестване на "Интернет"

Пълноценното тестване на канала не може да бъде ехо заявки, ping и mtr никога няма да ви кажат каква е честотната лента на канала. Iperf и други софтуерни помощни програми няма да могат да кажат за това, тъй като с едновременното използване на мрежата и тестването, софтуерните помощни програми не знаят количеството потребителски данни, които са в канала в момента, също и по време на тестване на софтуера, възможни са редица неточности поради наличието на заглавки на пакети, в зависимост от размера на кадъра, заглавията остават със стандартната дължина, а тялото с данните се увеличава или намалява, софтуерните помощни програми определят честотната лента на канала, без да се вземат предвид размера на хедърите, което при различни размери на пакетите внася известно объркване в такова тестване.

Няма да можете да оцените качеството на наетия vlan, като разгледате графика за зареждане на канала или изтеглите големи файлове от интернет. Защо speedtest.net не е доказателство за скоростта на предоставения канал, вероятно не си струва да се уточнява? В края на краищата веднага става ясно, че не е известно кои канали и през кои мрежи отиват до най-бързите сървъри, както и не е известно колко е зает каналът по време на теста и много други параметри на теста и дали има са толкова много неизвестни в теста, тогава резултатите от него не могат да бъдат точни. Резултатът от теста за скорост е по-скоро определена делта от някои показатели, отколкото реални числа.

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

Ethernet техники и анализатори

Днес има две основни техники за тестване на пропускателната способност: старата, RFC-2544, и малко по-младата, Y.1564. Методологията ITU-T Y.1564 - по-актуална днес, има описания за тестване на съвременни високоскоростни комуникационни канали със съвременни концепции на SLA (Service Layer Agreement).

Тъй като качеството на Ethernet канала е комбинация от много фактори, следователно правилното тестване трябва да обхване всички тези комбинации, доколкото е възможно. Има много аспекти, които трябва да се вземат предвид при тестване и би било полезно да имате разширени функции като BER тест, джитър на пакети, поддръжка на MPLS, QoS, тестване на натоварване на протоколи от приложен слой (http, ftp и др.).

За да тествате канали от 1G до 10G и по-високи, е доста трудно да се правят стрес тестове с помощта на неспециализиран хардуер; процесорите често не са в състояние да генерират достатъчно количество трафик, за разлика от специализираните тестери-анализатори. Такива устройства могат да се поставят в стелаж, шкаф, дори в чекмедже на тавана и да се провеждат тестове от разстояние, или можете да правите автоматични измервания на различни интервали от време. Всички преносими анализатори няма да се влошат в тежките условия на канализацията, тъй като те се подлагат на строги тестове за якост.

Доставка и приемане на комуникационни канали.

Най-добре е да имате тестер-анализатор в стандартния арсенал за доставка или приемане на изградените линии и магистрали, за да работите по високи стандарти, въпреки че можете да намерите фирми, специализирани в полеви тестове в Интернет. По някаква причина се смята, че закупуването на тестер-анализатор е много скъпо.

Методологията RFC-2544 препоръчва измерване на различни размери на кадрите: за Ethernet трафик кадрите са 64, 128, 256, 512, 1024, 1280, 1518 октета; за всеки размер на кадрите се изисква отделен сериен тест. Ако е необходимо, можете също да тествате за рамката Jumbo (кадри от 4096 или 9000 октета). За да се симулират различни видове трафик са необходими различни размери на кадрите.

Първоначално техниката е разработена директно за тестване на мрежови устройства, например при разработване на комутатори, но наборът от функции е адаптиран за измерване на качеството на връзките. Техниката е одобрена през 1999 г. от ISOC.

Техниката предлага набор от 6 теста, ще опиша по-подробно как се провежда тестването, за яснота на възприятието:

((брой предадени кадри - брой получени кадри) * 100)/брой предадени кадри

Първото изпращане се извършва при максимално възможната скорост, след това скоростта на изпращане се намалява с максимална стъпка от 10%, според метода, намаляването на стъпката% ще даде най-точните резултати. Намаляването на скоростта трябва да продължи, докато последните две изпращания са без грешки, а именно, ние откриваме максималната скорост на трансфер на данни, при която скоростта на загуба на кадрите става 0.

Какво се е променило с неотдавнашната методология Y.1564?

Новите препоръки бяха разгледани и одобрени през 2011 г. от ITU. Джитърът на пакети (трептене) се добавя към препоръките, вече очертани в RFC 2544, а именно способността да се изчислява разликата във времето при получаване на брой последователни пакети данни, свързани с един и същ поток, в идеалния свят не би трябвало да съществува, но в проблемните мрежи там могат да бъдат нарушени, което може да повлияе на скоростта на обработка на данните. RFC2544 ви позволява да извършвате проверки изключително при максималната скорост на канала, при която няма да има загуба на пакети, която обикновено е по-висока от скоростта на CIR (Committed Information Rate). Y.1564 е създаден специално за SLA, като оценява скоростта и качеството на предоставения канал според ключови показатели за ефективност (KPI) и ви позволява да проверите предоставения канал в съответствие с договора.

Y.1564 ви позволява да проверите гарантираната честотна лента, максимално допустимата, както и да дадете товар, надвишаващ честотната лента, например, за да проверите настройките на формуляра.

Има още няколко разлики между методите, RFC2544 не проверява коректността на конфигурацията на услугата (съответствие с посочените KPI и скоростта, ограничаваща над EIR (Excess Information Rate), за да се избегне претоварване на мрежата). Оригиналната версия на RFC2544 не измерва трептене. Според RFC2544, всеки тест се задейства от отделна нишка, която не позволява измерване на качеството на услугите, предоставени в съвкупността и увеличава времето за тестване, друг недостатък на RFC2544 е, че няма възможност за профилиране за тестване на различни видове трафик в един канал, например, ако мрежата използва QoS, Y.1564 взема предвид недостатъци и леко разширена функционалност.

Можете да тествате само нови канали или вече работещи?

Трябва да тествате както новите канали, така и още повече старите. Можете да разберете предварително за предстоящи проблеми, без да призовавате клиентите на обаждане за поддръжка. Съвременните тестери-анализатори могат да извършват проверки в работеща мрежа, да проверяват канали както на 10/100/1000Mbit, така и на 10/40/100G. Има едно НО, много е важно да разберете какво и как правите, важно е да не подложите случайно канала на тест.

Режими на тестване - In/Out of service.

Към днешна дата мрежовото тестване се стреми към пълна систематизация и постоянен контрол на каналите, по-ранните версии на методологията RFC2544 са създадени за тестване на канали/оборудване в режим OutOfService и са били използвани главно за тестване на оборудване, но днес всички производители на тестови устройства преминават към по-нови стандарти за тестване, позволяващи непрекъснато наблюдение на мрежата в режим InService. Такова тестване ви позволява да проверите скоростта на честотната лента, без да прекъсвате връзката с клиентите, което е важно за телекомуникационните оператори.

Другари, както казва един мой приятел, нека да се бием заедно с „ко-кекери“ и да започнем да тестваме какво изграждаме и какво експлоатираме.