Маршрутизаторы “заточенные” под оператора. Роутер nag llc


Немного рекомендаций относительно Wive-NG | Wi-CAT LLC

Эта тема навеяна многочисленными инструкциями по настройке роутеров. И касается далеко не только Wive.

Немного рекомендаций относительно Wive-NG

YOUR MUST READ THIS !!!

Начнём с радио:1) при настройке никогда не меняйте непонятные вам параметры2) если у вас нет B only устройств, используйте режим G/N, или же чистый N, если все ваши устройства поддерживают 802.11N (не включайте поддержку 802.11B без нужды, за последние 8 лет я лишь один раз видел устройство, поддерживающее только 802.11B и это был древний телефон на WinMobile6)3) всегда используйте только чистые WPA2+AES режимы шифрования, смешанные WPA1/2 и TKIPAES режимы следует использовать только если у вас есть устройства, не поддерживающие WPA2AES4) не используйте автовыбор канала (см. тему рядом) или используйте автовыбор в режиме “по уровню шума”.5) Выбирая канал в 5ГГц диапазоне всегда проверяйте, что все ваши устройства могут работать, и работают корректно на выбранной частоте. К сожалению очень часто устройства имеют старые региональные ограничения в составе драйверов wi-fi, что может приводить к разнообразным проблемам, в т.ч. устройство может вообще не видеть точку доступа работающую на том или ином канале6) Контролируйте реальную эффективную скорость работы на том или ином канале (например с помощью iperf). Не редко эффективная скорость передачи и стабильность соединения будет выше на занятых каналах. О природе этого явления постараюсь доступно рассказать в будущих публикациях. Пока стоит запомнить, что единственное доступное пользователю средство проверки, это не сканер эфира, а тест реальной пропускной способности7) при использовании Dual Band устройств (таких как MD1/ME1), старайтесь использовать разные SSID для разных диапазонов, это убережет вас от всевозможных подземных стуков вызванных разнородностью реализации выбора диапазона клиентскими устройствами. Подробнее о проблематике можно прочесть в статье

Сеть:1) настраивайте только то, что действительно требуется для полноценной работы с вашим оператором2) не включайте поддержку IPv6, если ваш оператор не предоставляет такую услугу, либо вам она не нужна (то же самое касается и всего остального, не следует включать то, что ваш оператор не поддерживает)3) если у вас на доступе туннель PPPOE/PPTP/L2TP, то в настройках Port forward (проброс портов) следует выбирать интерфейс VPN, а не WAN, если вы желаете протянуть порты в Internet, а не в локальную сеть.4) если ваш оператор использует на доступе PPPOE без DHCP (например, Ростелеком или Эр-Телеком) , в настройках VPN необходимо включить Pure PPPoE.

По сервисам:1) никогда не включайте непонятные вам сервисы2) никогда не разрешайте без нужды доступ к сервисам роутера из WAN (например, разрешив updxy принимать соединения с WAN интерфейса, очень скоро вы попадёте в списки халявных IP-TV прокси, ещё быстрее всю вашу полосу в интернет выгребут халявщики, смотрящие через вас IPTV).

USB:1) не питайте от USB роутера всевозможный хлам типа USB нагревателей кофе или вентиляторов, светильников и прочего2) крайне желательно использовать HDD с отдельным сетевым питанием, некоторые HDD потребляют просто неразумно много, и штатный БП роутера может запросто не вытянуть такой нагрузки, как результат – проблемы со стабильностью самого роутера, выход из строя БП или даже порча данных на HDD3) использование USB3 устройств может заметно влиять на качество и дальность обслуживания клиентов в 2.4ГГц диапазоне из-за интерференции (подробности https://www.intel.com/content/www/us/en/io/universal-serial-bus/usb3-frequency-interference-paper.html)4) используйте только качественные USB кабели небольшой длины5) если используете роутер как файл-сервер, крайне рекомендуется использовать ext4 как FS

Обновление:1) старайтесь использовать свежую версию ПО, доступную по адресу https://sourceforge.net/projects/wive-ng/files/wive-ng-mt/ т.к. кроме исправлений ошибок, влияющих на стабильность, периодически также правятся и проблемы безопасности в тех или иных компонентах (например, в dropbear).2) правильно выбирайте образ для обновления, ориентируясь на Firmware Version в Administration->Status3) не заливайте в устройство стороннее ПО или версии для других устройств SNR (например, в устройство без 5ГГц модуля – ПО с его поддержкой, в лучшем случае получите полуработающий WebUI и кашу в калибровках, что ведёт к разнообразным глюкам, в худшем – устройство может выйти из строя аппаратно, а заливка стороннего ПО запросто повредит индивидуальные калибровки радио и, как результат, приведёт к проблемам работы по радиоканалу)4) после обновления с заводской версии (а лучше и при переходе с любой достаточно старой ветки) желательно выполнить сброс кнопкой reset на корпусе устройства, удерживая её около 10сек с последующей настройкой через WebUI (не заливкой назад backup`а)5) по мотивам http://help.powernet.com.ru/157-nastroyka-marshrutizatora-snr-cpe-md1.html Галка сброса RWFS НЕ ПРИВОДИТ К СБРОСУ НАСТРОЕК , за исключением настройки xupnpd и ещё пары демонов, которые имеют собственный интерфейс конфигурации. Снимать эту галку при обновлении ПО крайне не рекомендуется, т.к. не будут обновлены init скрипты. Снимать галку следует только если вы чётко понимаете, что делаете, и что после этого не возникнет проблем с логикой инита (определить можно только самостоятельно отследив все изменения в git на эту тему).

Общие рекомендации:1) Первым делом смените пароль (а лучше имя пользователя и пароль) на вход. Иначе имеете все шансы стать участником бот-сети (несмотря на то, что в прошивке я старался минимизировать такие шансы, даже если устройство скомпрометировали)2) Всегда используйте хотя бы номинально криптостойкие пароли (не менее 8 символов в разном регистре + 4-6 цифр).3) Для настройки используйте браузеры, поддерживающие рекомендации W3C (Firefox/Chrome/и т.д.), Internet Explorer в зависимости от версии может вести себя непредсказуемо, в силу подхода MS к его разработке в частности и поддержки стандартов вообще.4) Также, крайне полезно будет добавить адрес роутера в исключения антивирусов, контент-фильтров и баннерорезалок, ибо эти заразы частенько дропают часть JS или даже соединения до встроенного web-сервера, отсюда тормоза и глюки web-интерфейса.5) При зависании устройства наглухо (т.е. не перезагрузка устройства, а именно зависание, когда устройство перестаёт отзываться по сети как по проводу, так и по радио) первым делом проверяем БП. Если после замены на заведомо исправный БП проблема не прошла – отправляем в сервис. Глухой вис по вине ПО в Wive-NG практически исключён, так как даже если ещё ничего страшного не произошло, но был замечен какой-то сбой на уровне ядра, это приведёт к панике ядра и моментальной перезагрузке устройства во избежание, например, его компрометации. Т.е., далеко задолго до того, как устройство потенциально могло бы зависнуть, логика его перезагрузит при первом же подозрении , что что-то пошло не так. Также, можно включить аппаратный ватчдог (находиться в MISC), который перезагрузит устройство даже если сбой произошёл из-за проблем с питанием, т.е. не программная часть привела к зависанию, а какая-то внешняя сущность типа перегрева или скачка напряжения.

Проблемы совместимости, на которые мы повлиять не можем т.к. проблема на клиентской стороне:1) Некоторые устройства не могут корректно работать с каналами выше 11-го в 2.4ГГц диапазоне, или могут не работать с какими-то (одному вендору их известно какими именно) каналами в 5ГГц, поэтому если устройство не может соединиться или вовсе не видит AP (точку доступа), следует попробовать первым делом сменить канал.

По этим же причинам не стоит пытаться использовать автовыбор канала в 5ГГц, т.к. даже если при загрузке устройство выбрало канал из нижнего диапазона, не факт, что в будущем (с увеличением загруженности эфира) роутер не выберет канал из чистого поддиапазона выше 64-го канала, а ваше устройство запросто может не уметь работать в этом поддиапазоне.

Бардак устаканится только тогда, когда вендоры обновят таблицы региональных ограничений на клиентских устройствах.

2) Также, у некоторых мобильных устройств наблюдаются проблемы с 80МГц полосой в 802.11ac режиме. Например, Smasung Galaxy S5 (поправлено в последних официальных прошивках самсунга), часть яблочной продукции (iphone 6 и macbook air 2012-2013г выпуска). Всех их объединяет использование в качестве радио BCM4345x от Broadcom вкупе с драйвером версии, выпущенной до КРОС 2.0-17 (конец мая 2017) ;)

Выглядит это как отсутствие передачи данных при живом подключении или очень низкая скорость. От AP это не зависит. Решение – отключить поддержку 80МГц полосы для 802.11ac (естественно, у всех устройств, которые корректно работали с 80МГц полосой, реальная скорость передачи упадёт примерно вдвое).

Братья по несчастью живут тут:a) https://discussions.apple.com/thread/6687368b) https://discussions.apple.com/message/27134380#27134380c) https://tinkertry.com/if-youre-using-a-802-11ac-wifi-device-you-may-want-to-avoid-80mhz-channel-width и тут http://forums.macrumors.com/threads/wi-fi-is-super-slow-on-80mhz.1861397/

Данная проблема не является проблемой роутера!Ошибка кроется в драйвере BCM на клиентской стороне (см. ссылки выше по ровно тем же проблемам с роутерами других вендоров на абсолютно разных чипах).

В бяке замечена почти исключительно техника Apple. И несмотря на то, что проблема старая и яблоки могли бы её решить уже очень давно, заблокировав 80МГц полосу на клиентской стороне или просто обновив драйвер BCM для этих устройств (достоверно известно, что текущий драйвер для новых чипов, используемых в Iphone7, и более новых, не имеет этой проблемы и поддерживает чип, установленный в Iphone6) яблоки попросту забили на это. Видимо, с целью стимуляции пользователя к покупке новых устройств.Впрочем, это не единственный метод – например, на старых девайсах можно принудительно уронить производительность (пруф: https://lenta.ru/news/2017/12/21/apple/). На мой взгляд, это называется кидалово. Но тут дело каждого. =)

Начиная с версии 6.1.5 был добавлен воркэрануд : устройства Iphone6, huawei honor P8/P9 на тех же радио-чипах, что и iphone 6, и ряд других устройств , на которых проявляется проблема, будут автоматически лимитированы 40МГц полосой. Это меньшее из зол (позволяет не отключать 80МГц и позволить клиентам без данной ошибки использовать преимущество широких каналов).

Если у вас наблюдается подобная проблема – скиньте название устройства, год выпуска, MAC адрес (что бы выделить OUI, т.к. именно по нему определяется, для кого включать лимит) и детальное описание включая лог и Stalist с AP мне в приват.

Какие именно OUI включены в workaround, можно узнать из Changlog`а прошивки https://sourceforge.net/p/wive-ng/wive-ng-mt/ci/master/tree/History или в коде драйверов https://sourceforge.net/p/wive-ng/wive-ng-mt/ci/master/tree/linux-3.4.x/drivers/net/wireless/ralink/mt7610/common/vht.c#l274К сожалению, у того же Apple только для модели Iphone6 уже выявлено 6 разных OUI, и не факт, что это всё (видимо, зависит от страны, в которую устройство продавалось, или от какого-то иного признака).

3) У части устройств (например, Samsung J100F, на текущий момент самсунг устранил проблему с очередным обновлением) наблюдается ошибка реализации FastRoaming: они пытаются всегда использовать короткую процедуру при включенном FT на AP, хотя первое соединение обязано проходить по полной схеме. В итоге, не могут подключиться и просто пишут “сохранено”. Выход – отключить Fast Transition 802.11R (да и вообще не следует включать роуминговые расширения при использовании одной AP).

Как уже говорилось, не следует менять настройки, если вам они не понятны. Не стоит включать или выключать всё подряд и т.д. и т.п. Нужно чётко осознавать, что вы делаете и зачем. Иначе лучше обратиться к специалисту, который ознакомится с матчастью и прочитает соответствующие материалы, перед тем как начинать настройку.

P.S. Огромная просьба ко всем пользователям Apple. Прежде чем писать нам о ваших проблемах, проверьте, нет ли сходных проблем с роутерами других вендоров, работающих в тех же режимах. Почти все проблемы wifi в apple лежат на стороне Apple. Увы и ах. И именно у вас есть полное право долбить Apple до победного пока они не исправят свои косяки. Вы заплатили им денег за эксклюзивную игрушку – пусть отрабатывают. Иначе, получается так, что Apple косячит, а остальные вынуждены подстраиваться и городить воркэраунды, в простонародье обзываемые костылями, или ограничивать возможности радио, что неминуемо сказывается на производительности радиосегмента с нормальными клиентами.

wi-cat.ru

Маршрутизаторы “заточенные” под оператора / Блог компании НАГ / Хабр

image В нашем магазине полным ходом идет распродажа первых представителей маршрутизаторов под маркой SNR. Маршрутизатор SNR-CPE-W4N (аналог DIR-615) завоевал популярность среди наших клиентов и широко применялся провайдерами связи. Невысокая цена вкупе с функциональностью сделали свое дело. Подробнее о SNR-CPE-W4N можно прочесть в нашем обзоре. Под катом хотелось бы рассказать о коробочках, что пришли ему на смену. Начнем представление тех кто пришел на смену SNR-CPE-W4N с его ближайшего “родственника” с аналогичным названием. Однако новая версия маршрутизатора SNR-CPE-W4N разительно отличается от предшественника, как внешним видом, так начинкой.image Компактный корпус устройства (173х118х175 мм) не доставит неудобств в размещении, как дома, так и при строительстве офисной сети. Верхняя крышка корпуса выполнена из белого пластика с лакированным покрытием. На корпусе не остается следов пальцев и царапин, а загрязнения легко стираются. Посередине красуется логотип SNR.

SNR-CPE-W4N оснащен двумя внешними антеннами с усилением 5dBi благодаря чему обеспечивается достаточно большая зона покрытия Wi-Fi сигнала со стабильной передачей данных внутри неё. Роутер поддерживает стандарт IEEE 802.11b/g/n и технологию MIMO2x2. Это позволяет достигать передачи данных на скорости в 300 Мбит/с. Начинка устройства выполнена на базе чипсета MT7620N, применяемого во многих современных Wi-Fi-роутерах.

image Маршрутизатор отлично подходит для абонентов подключенных к услуге IPTV. Поддерживает Multicast, IGMP Snooping, а также Multicast-to-Unicast. Изоляция мультикаст/бродкаст трафика позволяет достигать качественной работы IP-телевидения даже на Wi-Fi клиентах. На случай если устройство, подключаемое к IPTV не поддерживает Multicast, в программное обеспечение роутера добавлен DLNA-сервер xupnpd, позволяющий загружать плейлист провайдера непосредственно на роутер и использовать его в качестве медиасервера.

Основные особенности:

— Чип Mediatek MT7620N — Wi-FI: 802.11b/g/n 2T2R — 8МБ Flash / 64МБ RAM — Поддержка IPv6 — Встроенный xupnpd (DLNA) — ПО WIve-NG-mt — Русифицированный web-интерфейс

image

Ближайший собрат SNR-CPE-W4N в линейке маршрутизаторов под нашей маркой — это его двухдиапазонная версия SNR-CPE-MD1.

image

Здесь возможностей гораздо больше, так как роутер может работать в в двух частотных диапазонах 2,4ГГц и 5ГГц одновременно на максимально высоких скоростях — до 733 Мбит/с. Такие возможности обеспечиваются благодаря поддержки роутером стандарта IEEE 802.11b/g/n и технологии MIMO 2x2, а также 802.11a/ac.

image

Габариты устройства 187 х 143 х 35 мм позволяют разместить его без ущерба для пространства офиса или дома. Большая зона покрытия и стабильная работа сигнала обеспечивается наличием двух антенн 5dBi.

Поддержка двух диапазонов позволяет не только использовать более свободную частоту 5ГГц для передачи данных, но и реализовать схему, в которой wifi роутер выступает одновременно в качестве беспроводного клиента (режим APCli) на одной частоте (например, 5ГГц), и точки доступа для конечных устройств на другой (например, 2.4ГГц). Работа с мультимедийными сервисами здесь осуществляется, как и у “пациента” выше.

Основные особенности:

— Чип Mediatek MT7620A — Чип Mediatek MT7610NE — Wi-Fi: 802.11b/g/n 2T2R — Wi-Fi: 802.11a/ac 1T1R — 8МБ Flash / 64МБ RAM — Поддержка IPv6 — Встроенный xupnpd (DLNA) — ПО WIve-NG-mt — Оригинальный либо русифицированный web-интерфейс

image

В обоих маршрутизаторах реализована поддержка IPv6, в том числе native dual stack over IPOE/PPPOE с dhcp+ra, режим 6to4; сервисы radvd и dhcp6s и тд.

image

Программное обеспечение

Прошивка обоих роутеров основана на ПО Wive-NG-MT. Это дальнейшее развитие ПО для маршрутизаторов нового бюджетного чипа от Ralink/Mediatek MT7620. Wive-NG-MT — встраиваемая операционная система, разработанная специально по заказу NAG.

image

image

image

Кастомизация

Специально для операторов связи разработано гибкий набор предложений кастомизации. Любой маршрутизатор можно “заточить” под конкретного оператора. Изменения можно произвести как с внешним видом устройства. Например подготовить собственную коробку с расцветкой оператора.

image

Как и сменить логотип на корпусе устройства

image

image

Программное обеспечение Wive-NG-mt позволяет самостоятельно изменять init без пересборки прошивки, посредством rwfs. Это позволяет адаптировать маршрутизатор под особенности сети оператора и облегчить для пользователя настройку роутера.

Для корпоративных сетей доступен функционал шейпера, гибко конфигурируемый роуминг между точками, не требующий внешнего контроллера, а также работа в режиме Hotspot.

image

geektimes.com

Коммуникации последнего метра: кастомизируй это!

Когда мне предложили обозреть это устройство от широко известного бренда SNR, я согласился не раздумывая. Во-первых, потому что я постоянный автор ресурса уже три года (или даже больше), и было бы странно не поинтересоваться. Во-вторых, всегда интересно взять и поковырять коробочку, причем не любопытства ради, но пользы для. И вот -  коробочка получена, а затем разобрана...

В коробке оказался домашний  wi-fi маршрутизатор SNR-CPE-W4N, о двух антеннах, четырех портах и с самой незамысловатой внешностью:

Характеристики "железа", как следует из описания с сайта, тоже не самые навороченные и выдающиеся:

  • Чипсет Ralink 3052 (RT3052)
  • Тип WiFI: 2T2R
  • Память SDRam: 32MB
  • Память Flash: 4MB

Тайваньская компания Ralink Technology, Corp со штаб-квартирой в Купертино, штат Калифорния, чипы серии RT3050/52 выпускает уже так давно, что кажется должны были заполонить половину обитаемой суши. Кстати, буквально в январе 2013 года было объявлено, что Ralink сливается с другим тайваньским производителем микросхем - компанией MediaTek. И будучи человеком, довольно далеким (похоже, до недавнего времени) от шекспировских страстей на рынке тайваньской (да и вообще) микроэлектроники, я и не подозревал, что корпорация MediaTek вполне успешно конкурирует с монстрами типа NVidia и Qualcomm. Между тем, отчет по продажам за январь 2013 (!!! - вот это скорость публикации!) говорит, что компания выручила за месяц ни много, ни мало - 8,453 миллиарда долларов. Так-то!

Datasheet по RT3050/52, обнаруженный первым в поиске, датирован 14 августа 2008 года. Впрочем, длительность выпуска такого довольно специфичного чипсета свидетельствует лишь об удачности решения и ни о чем более. Официально, производитель микросхемы (на самом деле фактически однокристальной системе)  заявляется по следующим параметрам и фичам:

  • Single frequency band: 2.4GHz~2.497GHz - стандартные частоты стандарта 802.11.
  • 2T2R 300Mbps PHY data rate - это означает, что схема имеет два передающих и два приемных блока, что позволяет достичь скорости обмена данными 300 Мбит/с. (младшая  RT3050 имеет один приемник и один передатчик - схема 1T1R).
  • MIPS 24KEc 320MHz with 32KB I-cache/16KB D cache - процессорные ядра, позволившие реализовать функции широкополосной маршрутизации, работу моста “Ethernet-Wi-Fi”, поддержку VoIP и других приложений. Не удивлюсь, если на базе эдакого девайса некто сделает "мини-компьютер с блек-джеком монитором и usb-портами".
  • Embedded a 7-port Ethernet switch and a 5-port 10/100 Mbps PHY - функции точки доступа и маршрутизатора 802.11n объединены с коммутатором и интерфейсом физического уровня на указанных скоростях. При этом реализован 7-портовый коммутатор Ethernet и 5-портовый 10/100 Ethernet.
  • Support 5 10/100 UTP ports and one RGMII/MII port - чипсет поддерживает, как уже говорилось, пять портов 10/100 UTP и один порт RGMII/MII.
  • Hardware NAT, QoS, TCP/UDP/IP checksum offloading - все, что нужно домашнему маршрутизатору, чтобы запустить в Сеть несколько пользователей.
  • Operating systems: Linux - прошивку можно менять, но об этом чуть позже.
  • QoS - WMM, WMM Power Save - обеспечивает основные возможности QoS для сетей IEEE 802.11. Отдавая приоритет VoIP-трафику над процессами, менее чувствительными к скорости передачи данных, можно добиться уменьшения флуктуации интервалов между пакетами при их прохождении по сети. Использование QoS является простым и недорогим решением для серьезного улучшения качества VoIP-звонков. А еще банановый с энергосбережением.
  • WEP64/128, WPA, WPA2 engines - хардверная реализация почти всех распространенных технологий безопасности (криптографии) Wi-Fi.
  • USB2.0 OTG x 1 - может поддерживать один USB-порт для каких-нибудь целей.

 

Кстати, есть модель с поддержкой USB-порта (у меня был без оной) - SNR-CPE-W4N-3G. У меня как раз (хвастаюсь) есть давно маршрутизатор с такой фичей. И я даже купил как-то по оказии CDMA-модем от SkyLink. И даже настроил его. Но за три года эксплуатации мне он ни разу не потребовался. Потом на счету кончились деньги, а модем так и висит одиноко на шнурке и ничем не доставляет. По моему разумению, лучше использовать сей порт для подключения убер-девайса класса USB-накопитель и натравить роутер на разные торренты - так было гораздо полезнее.

Еще Ралинковская микросхема может обслуживать до 256 клиентов по радио, и организовывать до восьми BSSID (Basic Service Set Identifiers) или попросту - отдельных сетей Wi-Fi. В качестве внешнего оформления выбран корпус типа TFBGA-289 размерами 14 х 14 мм. и конфигурация однокристальных систем может включать до 64 МБ 16/32-разрядной памяти SDR SDRAM.

В общем, железо вполне себе а) достойное б) проверенное временем.

Крупным планом со стороны портов, прибор выглядит так:

… а если сдвинуть ножки-резинки и вывернуть четыре самореза, то прибор распадается на четыре части (антенны не считаются):

Главное, разумеется, плата. Но корпус о трех деталях выглядит намного аккуратнее, чем некоторые образцы военно-промышленного комплекса Советского Союза, с которыми я имел дело лет *дцать назад - все аккуратненько, облоя нет, толщина пластикового слоя однородна по всем измерениям, посторонних включений и "ракушек" не обнаружено. :)

На плате мы имеем какие-то детальки собственно ту самую "однокристальную ЭВМ", закрытую радиатором, с необходимой периферией, радиотрактом и одним коннектором для консольного подключения. Плата также не производит отталкивающего впечатления - плата, как плата. Разве что радиатор на "самую главную" деталь как-то неаккуратно нахлобучен - видны подтеки клея-термопасты, а сам радиатор, если его посильнее нажать, елозит. Но не отваливается. Кстати, с радиатором есть некая история, связанная с китайской культурой кустарного производства (это я где-то в форумах поддержки прочитал, пока разбирался с балалайкой) - радиатор, разумеется, удорожает конструкцию, но он необходим, поскольку микросхема таки при работе нагревается. А хитрые и мастеровитые китайцы в некоторых устройствах радиатор ставить "забывали" с целью экономии. Устройства, что характерно, все же работали. Но недолго. Посему некоторые завсегдатаи Алибабы очень придирчиво смотрят на наличие радиатора, который, в конечном итоге (напомню, устройства подобные данному, выпускаются уже минимум четыре года), стал неким показателем качества.

Итак, в  конкретной модели радиатор на однокристальном маршрутизаторе присутствует:

И на этом описание железки можно прекратить, ибо прибор весьма не редкий - только на Алибабе я обнаружил  не менее 350 устройств аналогичных данному (что и не удивительно совсем). В некоторых случаях - аналогичных вплоть до корпуса, цвета и устройства коробочки. На Яндекс.Маркете я отыскал порядка двух сотен очень похожих устройств (по характеристикам, доступным в поиске). А вот список устройств, на которых есть возможность установить ПО WR-NL (прошивка, рекомендуемая нашим поставщиком) с комментариями разработчика:

  1. D-Link DIR-300 B1-B4 (NRU),
  2. D-Link DIR-412 A1,
  3. D-Link DIR-600 B1/B2,
  4. D-Link DIR- 615 E1(Only USA version),
  5. D-Link DIR-615 Hw:D1,
  6. D-Link DIR-620
  7. Asus RT-N13U,
  8. Asus RT-N13U Rev.B1,
  9. Asus RTG-32 rev.B1/C1,
  10. Asus RT-N10+ (на RTG-32B1 работа не гарантирована в связи с малым объёмом ОЗУ)
  11. Tenda W306R,
  12. Tenda W307R
  13. No-Name CVNK-K53
  14. FONERA 2.0n
  15. CANYON CNP-WF514N1
  16. Asmax br615n
  17. Buffalo WHR-G300N
  18. Winstar 300Mbit router
  19. Opticum NXR-500
  20. Edimax 3G-6200n
  21. ZyXEL Keenetic,
  22. ZyXEL Keenetic lite,
  23. ZyXEL Keenetic 4G,
  24. ZyXEL NBG-419N
  25. BL-WA02 11N 300M Wireless Router
  26. SL-R7202, SL-R7205 300M Wireless Router
  27. Getnet GR-124W
  28. Conceptronic C300BRS4A_V2 (tenda W306R clone)
  29. SNR-CPE-W4N,
  30. MT-WR751N-B, MT-WR850N-A
  31. 7Links Mini-WLAN-Router WRP-310
  32. WR3G01 (клон SL-R7205)
  33. TopLink RT-300BK (клон SL-R7202)

Список, как видно, вполне немаленький. Обозреваемое устройство входит. Кстати, я, как обладатель весьма похожего устройства ZyXEL Keenetic 4G уже два или три года. Более точно вспомнить не могу, поскольку банально забыл о его существовании - работает и работает. Не перегружается, не шумит. Но цена у него в два раза больше, чем у SNR.

Данный материал в серии КПМ уже третья (кстати, намерен продолжать) официальная или четвертая, если посчитать прошлогодне-новогоднюю "Святочные гадания на Wi-Fi". Во всех статьях я утверждал, что использование Wi-Fi, так или иначе, затронет всех провайдеров, независимо от личного отношения инженеров к данной технологии.

Позволю себе еще раз напомнить, почему так произойдет:

  1. Проникновение планшетов и смартфонов растет рекордными темпами, о чем рассказывают все аналитические агентства. Трудно себе представить планшет, прикованный проводом - он по определению должен быть беспроводным.
  2. Радиочастотный ресурс суть есть ограниченный. Почти единственные частоты, разрешенные для широкого использования без лицензий и общения с ГКРЧ (внутри помещений) это wi-fi (ниже специально картинка-пояснение для тех, кто тут "случайно")
  3. Стоимость абонентского устройства для подключения к сети фактически равняется нулю - любой ноутбук, смарт и планшетный компьютер может не иметь поддержки сотовой связи, но почти всегда есть связь по Wi-Fi. Это практически не позволяет другим технологиям конкурировать. Пока.
  4. Использование Wi-Fi  уже привычно и естественно. Учить пользоваться и/или агитировать за Советскую Власть технологии никого не нужно.

Разумеется, есть и проблемы. Особенно в городах. Особенно в крупных.

Однако обещанная картина с частотными присвоениями, показывает, что по сравнению с Россией, дозволенный диапазон, например во Франции, несколько уже:

…что абсолютно не мешает сети Fon покрыть территорию всей страны оранжевыми точками, плотнее, чем большая тройка покрывает Московскую область:

Так что любые возражения от техноперфекционистов разбиваются о деньги клиентов, которым нужно "вафлю". И ее нужно дать, иначе клиенты пойдут в другое место.

О различных способах монетизации технологии тоже можно спорить, поелику их достаточное количество и это было рассмотрено в первой части "КПМ". Во второй части  рассматривался частный случай с рекламными моделями.

А сегодня мы рассматриваем более приземленную и естественную модель применения данной технологии - оконечивание ethernet и установление коммуникации именно, что "последнего метра". Для злостных хейтеров Wi-Fi я еще раз подчеркну - последнего метра. Что абсолютно не эквивалентно покрытию города-миллионника или обслуживанию сотен абонентов в вагоне метрополитена. В ближайшем будущем (да уже и в настоящем) провайдер без возможности установки беспроводного роутера будет считаться не клиентоориентированным и не заслуживающим внимания со стороны вдумчивого абонента.

Разумеется, любой пользователь может самостоятельно купить (про Яндекс.Маркет уже упомянуто) и установить маршрутизатор у себя в квартире. Но это должен быть относительно продвинутый пользователь. Пользователь же "обычный" (а именно за него сейчас будут развертываться основные маркетинговые войны) пойдет к тому оператору, который сделает "красиво".

И вот тут SNR и поможет.

Гибкое и проверенное решение дозволяется брендировать и имеется возможность "затачивать" маршрутизаторы под конкретного оператора, причем, за весьма невеликие деньги, сравнимые с одним ARPU. А это настолько мало, что маршрутизаторы принципиально можно раздавать и бесплатно в рамках акций типа "первый месяц бесплатно", только вместо "месяца" отдавать красивые "коробочки с интернетом", и рассказывать, что "у нас вовсе не нужно тянуть провода по плинтусу".

Сделать собственный маршрутизатор не просто. А очень просто.

Для начала - внешний вид. SNR позволяет (думаю, при соответствующих объемах - из-за пары десятков устройств можно угореть хотя бы на полиграфии, уточняйте у менеджеров) подготовить собственную коробку, раскрашенную в корпоративные цвета оператора:

… простым изменением Corel-файла по подготовленной развертке. С этим легко справится отдел маркетинга. Вот готовые примеры брендирования:

… или вот:

Видно, что коллеги не ограничились коробкой, но еще сделали нанесение логотипов на собственно устройство, что абсолютно верно, ибо коробки, как правило, выбрасывают или складывают в местах хранения хлама.

Я бы еще телефон техподдержки обязательно и КРУПНО написал. Потому что так же кастомизируемый стикер находится на обратной стороне устройства:

… которое не так заметно  и не так очевидно, что "в случае неисправности - выдернуть шнур перевернуть маршрутизатор и набрать телефон". Писать адрес сайта на лицевой стороне устройства -  идея нормальная, но если у пользователя "не работает интернет", то на сайт он никак попасть не сможет.

На самом деле, кастомизировать можно любую коробочку, конечно же. Идем на Митинский/Савеловский рынок (они живы еще?) или на Алибабу, заказываем нехилую партию роутеров "со скидками" и самостоятельно обклеиваем их собственными стикерами, которые тут же печатаем на самоклейке. Но, согласитесь, что времена кустарщины давно прошли. Да еще и не факт, что эдакие коммЭрческие упражнения приведут к экономии. Наклейки, время, транспорт - все стоит некоторых денежных сумм. А еще имеется риск получить глючную железку...

Но самое интересное, конечно же, заключается в ПО, которое так же можно "заточить" под собственные нужды. Как уже говорилось выше, чипсет работает на спецверсии Linux, а это означает открытый исходный код и массу вариантов firmware для устройства. Из коробки маршрутизаторы оборудованы гибчайшей прошивкой класса DD-WRT. Но специалисты SNR предлагают более интересное решение – Wive_WR, статус-экран которой выглядит так:

… который легко (при вмешательстве специально обученных специалистов) может стать таким:

То есть, кастомизации поддается не только коробочка и стикеры на роутере, но и внешний вид, и логическое устройство настроечных меню.

В идеале, для совершенно неподготовленных пользователей я бы оставил буквально два пункта:

Авторизацию клиента у провайдера:

… которая доступна при любом раскладе, если пользователь пытается подключиться к Сети, но роутер еще "не знает" реквизитов клиентской авторизации.

И ввод пароля для домашней Wi-Fi сети:

… последний скриншот я бы назвал сложным - пользователю совершенно нет практической необходимости знать статический у него адрес, или динамический.

Ввел пароль провайдерской авторизации, придумал название домашней сети и ввел пароль для нее. Ну, может еще выбор канала для wi-fi. Все это должно сопровождаться исчерпывающей справкой в текстовом виде, написанной для "тех, кто служил на бронепоезде".

По моему разумению, первая страница, доступная при включении новенького роутера, должна выглядеть так:

… я всего лишь попробовал смоделировать в wireframe, как должен выглядеть пользовательский интерфейс. Однако для продвинутых пользователей стоит оставить и расширенные настройки - мало ли. Может пользователи захотят организовать какой-нибудь SAN внутри своей сети, или еще какую "сложную штуку". Мешать им не надо и где-нибудь в уголке оставить ссылку на "расширенные настройки", при переходе на которые должно быть крупно написано: "Расширенные настройки предназначены для специально обученных людей. Если вы не такой, то любое изменение настроек может привести к поломке интернетов". Как-то так.

А еще, можно, например, добавить массу фич, о которых стоит подумать. Например (то, что приходит в голову, но решительно не исчерпывающее):

  1. Удаленное администрирование маршрутизатора. Возможно, совмещенное с функцией мониторинга. Очень полезная штука, за которую служба техподдержки скажет спасибо. Но пользователя нужно предупредить, что это принципиально возможно и разрешить ему запретить удаленное подключение. Во избежание недоразумений.
  2. Возможность организации второй "гостевой" сети. Может быть, даже и открытой. Почему нет? С изоляцией от домашней сети и  ограничением скорости, например, в 1Мб/сек, или даже меньше. Смартфоном зайти, прочитать почту - пожалуйста. А при современных скоростях в  десятки мегабит, пользователь "потери" даже и не обнаружит.
  3. Возможность организации третьей сети со скрытым SSID с целью организации бэкхолла до следующего маршрутизатора. Что-то типа mesh-сети. А может и "не типа", а самой настоящей mesh-сети. Математика доступна.
  4. Всенепременно поддержку торрентов, натравленных на USB-хранилище. Но это вкусовщина и политика оператора.
  5. IP-TV вкупе с мультикастом, предварительно настроенные под конкретного оператора. От пользователя можно скрыть за "расширенными настройками".

На этом моя фантазия почему-то исчерпалась. Для подготовленного пользователя, повторюсь, можно нужно оставить "профессиональные" настройки, предварительно предупредив, что эксперименты, конечно, приветствуются, но техподдержка не знает, как “пробить” железные двери и железобетонные перекрытия. Ну и всего разнообразия домашнего оборудования SAN/NAS, медиапроигрывателей и торрентограбилок техподдержка знать не в состоянии. Хотя...

В завершении, еще раз напоминаю, что я с удовольствием пообщаюсь с разработчиками и поставщиками интересных телеком-решений на предмет обозрения их на страницах Наг.ру. Ключевое слово - интересных. Yet another "ай-пи ти-ви" или "вот тут у нас офигенная фигня, только мы не придумали, кому она нужна" обозревать скучно, грустно и не интересно. Пишите, звоните - я всегда доступен для диалога.

От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству.

Ссылка на материал, для размещения на сторонних ресурсах

nag.ru

Такие разные проблемы

Чем крупнее сеть, тем более разношёрстнее оборудование там стоит, тем сильнее различается уровень компетенции обслуживающего персонала, тем больше проблем у них возникает.

Хочу представить вам подборку разноплановых аварий на сетях, доставивших немало часов увлекательной отладки.

Имеем вот такую сеть.

На доступе кольца коммутаторов младшей линейки, защищённые MSTP. Кольца агрегируются на вышестоящем коммутаторе, который напрямую подключен к BRAS'у. Кольца разорваны посередине, чтобы уравновесить нагрузку на разные порты агрегаторов.

Помимо базового доступа в Интернет предоставляется услуга IPTV.

Симптомы проблемы: Периодически наблюдается повышенная загрузка CPU сразу огромного количества коммутаторов по всему L2-домену, и в такие моменты они становятся недоступными для управления на несколько секунд. Сервисы при этом не страдают.

Анализ и решение

Раз сразу несколько коммутаторов страдают в одно время, надо начинать поиски с внешних факторов. Начинаем, как обычно, с проверки логов.

В них встречаются такие сообщения:

2013-09-16 20:46:37 The CPU is overloaded, and the tasks with top three CPU occupancy are frag_add(16%), SNPG(15%), FTS(13%). (CpuUsage=95%, Threshold=95%)

Frag_add отвечает за изучение MAC-адресов и заполнение ARP-таблицы, FTS - за отправку и получение пакетов, а SNPG - за обработку мультикаста.

Учитывая некую периодичность появления таких сообщений, предполагаем, что есть какое-то внешнее событие, которое запускает механизмы коммутатора. А обновление таблицы MAC'ов и ARP обычно происходит сразу после получения TC-пакета процессом STP. Это делается для того, чтобы сразу отреагировать на изменения топологии.

Не пришлось долго искать такие сообщения в логах:

2013-09-16 20:09:14 MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet0/0/1.

То же самое показывает и статистка полученных TC:

Этим объясняется процесс frag-add. Частично этим объясняется и активность FTS (получение и отправка пакетов) - первое время каждый принятый кадр нужно обработать на CPU и загнать MAC-адреса в таблицу. Но это событие не из ряда вон выходящее, и если каждое отключение порта приводило бы к повышению CPU, жить такому вендору было бы сложно.

Есть ещё процесс SNPG, отвечающий за мультикаст. Что не так с ним?

Дело в том, что в конфигурации присутствует команда igmp-snooping send-query enable. Она отвечает за отправку IGMP General Query во все свои порты при получении STP TC. Сделано это для того, чтобы быстро перестроить таблицу мультикастовой коммутации, когда изменилась топология. Таким образом, коммутатор быстро узнаёт, где появились клиенты, которые прежде получали трафик по другому пути. По умолчанию GQ отправляется на адрес 192.168.0.1. Естественно, он уходит и в тот порт, который выполнял роль Router Port, потому что при перестроении кольца он мог поменяться, и там могли появиться клиенты. В общем, не хилая такая работа для коммутатора младшей линейки - обработать весь поток Report'ов такого большого L2-домена.

Далее опытным путём подтвердили предположение: после удаления этой команды загрузка CPU оставалась в пределах нормы во время перестроения кольца. Кроме того, обратили внимание, что об обрыве в одном кольце уведомляются коммутаторы во всех других (рассылаются TC BPDU). Это следствие того, что на весь немаленький L2-домен натянут один MSTP процесс. По этой причине страдало так много коммутаторов. Вот казалось бы и распутали клубок - удалить команду и желательно разнести разные кольца по разным MSTP Instance или даже процессам, чтобы не было такого острого взаимовлияния. Но вот оказия: как только удалили эту команду, после изменения топологии прекращает работать мультикаст. А через несколько минут восстанавливается сам по себе. Повторяемость 100%. Найти ответ в лоб не удаётся. Что происходит, совершенно непонятно.

Остаётся только дампить трафик.

Вот результаты:

То есть дёрнули порт и непонятно почему, коммутатор отправил три пакета IGMP General Query с адресом отправителя 0.0.0.0. Что это такое, откуда, зачем? На вопрос отвечает Максим Поташёв RFC4541.

The 0.0.0.0 address represents a special case where the switch is proxying IGMP Queries for faster network convergence, but is not itself the Querier. The switch does not use its own IP address (even if it has one), because this would cause the Queries to be seen as coming from a newly elected Querier. The 0.0.0.0 address is used to indicate that the Query packets are NOT from a multicast router.

Иными словами, это специальный Query, который позволяет ускорить сходимость. Адрес 0.0.0.0 означает, что запрос не от мультикастового маршрутизатора, и не нужно производить перевыборы Querier. И тут картина начинает складываться. BRAS просто складывал с себя обязанности Querier после получения 0.0.0.0 (он же меньше текущего). Заблокировали отправку IGMP Querier с агрегирующего коммутатора на BRAS - никаких проблем больше нет. Потрачено много времени на отладку, а всё потому, что кто-то не придерживается RFC. Кстати, вышла в свет новая статья из цикла Сети Для Самых Маленьких. Она посвящена кокрастыке мультикасту и поможет вам разобраться в деталях.

Список продолжает проблема с широковещательными штормами. Пожалуй, это настоящий бич сетей MetroEthernet. Огромная часть запросов первого уровня открывается именно по штормам: петли физические, петли логические, петли в MPLS L2VPN. И в то время, как все стремятся уменьшить радиус широковещательного домена до локальной сети, некоторые расширяют его до масштабов города.

Имеем вот такую сеть

Есть один центральный узел-контроллер. К сети MetroEthernet подключаются станции, которые хотят взаимодействовать с контроллером, причём не просто взаимодействовать, а именно так, словно они подключены непосредственно друг к другу безо всяких маршрутизаторов.

Для этого на сети MetroEthernet поднята услуга MPLS L2VPN. Все станции являются членами одного широковещательного домена. В кольцах доступа существует чистый IP/Ethernet, а внутри агрегации уже MPLS.

Кольцо защищено RRPP - проприетарным протоколом Huawei для кольцевых топологий. Пакеты RRPP - это BPDU, чтобы они проходили через сеть MetroEthernet, создан специальный VSI исключительно для RRPP. То есть пакеты RRPP Hello прозрачно проходят через маршрутизатор благодаря L2VPN.

Внутри сети между маршрутизаторами Full-Mesh с помощью MPLS TE туннелей для передачи данных L2VPN. В качестве IGP выступает ISIS (хочу напомнить, что он активируется на интерфейсах, в отличие от OSPFv2).

В какой-то момент на одном из магистральных интерфейсов сети MetroEthernet начал расти счётчик CRC-ошибок. Естественно, это сразу сказалось на сервисах. Интерфейс выключили, ошибки кончились, но кольцо MetroEthernet оказалось разомкнутым, что как бы страшно.

Но, разумеется, всё продолжает работать, туннель между двумя маршрутизаторами перестроился на резервный путь по кольцу.

RRPP тоже работает, потому что Hello-пакеты проходят успешно.

То есть сейчас, если два устройства в одном кольце захотят пообщаться друг с другом, они пойдут по длинному пути.

Но долго без резервирования жить нельзя - сеть не Украина - отделить кусочек нельзя. Инженеры решили провести тест линии. Для этого они выбрали время наименьшей нагрузки, взяли с собой запасные SFP и платы и поехали на узел.

Чтобы не проводить операции на живой сети, решили изменить настройки IP на интерфейсе - взять адреса из какого-нибудь неиспользуемого в сети диапазона - они же ведь в этом случае ни с кем не пересекутся.

Поменяли IP, включили интерфейсы, запустили пинг. Наблюдают ошибки на портах, потери в пинге - проблема на лицо. Наблюдают какое-то время ещё перед тем, как менять линию, не обращая пока внимания, что терминал начал подтормаживать. Через несколько минут звонок от центра мониторинга - "недоступна большая часть станций".

Глядь, а там загрузка интерфейсов под 100%, CPU тоже перегружен - как есть шторм.

Разорвали проблемный линк, подождали минут 5 - ничего не изменилось - шторм прогрессирует. Начали рвать все имеющиеся кольца - помогло.

Два вопроса: почему случился шторм, ведь предприняли, казалось бы, меры и почему отключение проблемной линии не помогло?

Легче оказалось ответить на второй вопрос. В силу особенностей дизайна сети широковещательный шторм распространился очень быстро. И к моменту, когда инженеры узнали о шторме, он уже вовсю царствовал на коммутаторах других колец. Процессоры были заняты обработкой всяческих ARP'ов и других широковещательных пакетов и начали отбрасывать пакеты RRPP Hello. RRPP Master, не получая Hello, разблокировали свои резервные порты, считая, что кольцо разорвано. А на самом-то деле кольцо было целым и продолжало передавать трафик.

В итоге даже после разрыва линка между R1 и R2 петли продолжали плодить шторм и в других кольцах.

Но что же пошло не так с самого начала?

Несложно догадаться, что корень проблемы именно в CRC-ошибках. Результаты работы чёрного ящика показали, что в буфере чипа линейной платы произошёл сбой, который, грубо говоря, инвертировал бит, записанный в него, тем самым повреждая данные. Ирония заключается в том, что мутировали именно пакеты RRPP Hello, другие данные были затронуты в меньшей степени. RRPP Master не понимал, чего от него хотят, не обрабатывал Hello и снимал блокировку со своего резервного порта, смыкая тем самым петлю, в то время, как все другие данные ходили вполне нормально, и сразу после этого начали размножаться.

"Но мы же... поменяли IP-адрес - не должно было ничего подняться", "таблица маршрутизации не знает" - говорили они, "MPLS TE-туннели должны идти по нормальному пути" - говорили они.

Развязка

Концами TE-туннелей являются адреса Loopback-интерфейсов. RSVP строит LSP по кратчайшему пути. Да, пока линк был в дауне, путь лежал через всё кольцо MetroEthernet, но потом его подняли. И... на интерфейсе не был выключен ISIS, который не посмотрел, что IP-адреса какие-то левые, а просто изучил, что через них доступны Loopback'и других маршрутизаторов, туннели легли через этот путь, данные начали корёжиться.

Штормы это всё-таки один из самых сложных типов проблем - устранить сравнительно легко и сделать это надо очень быстро, а разбираться потом, когда уже всё кончилось, где там, что коротнуло.

Интереснейшая проблема, которую, слава Лейбницу, решал не я. Копий было сломано много, война была затяжной.

Очень простая сеть

Всё работает, базовые станции успешно общаются с RNC, трафик ходит. Далее происходит плановое обновление ПО на маршрутизаторах, и после него на RNC вываливается авария о том, что потеряна синхронизация с БС - сервисы разваливаются. Откат - всё работает. Ещё один тест для подтверждения - ситуация повторяется.

Важно понять, как происходит синхронизация. Существует не так уж много известных механизмов для этого: NTP, TOP, SynchroEthernet, 1588v2 (он же PTP).

Заказчик с полной уверенностью утверждает, что для синхронизации используется NTP. Хоть мы такого и не встречали никогда, но ладно - радиооборудование другого вендора, мало ли что он там накрутил. Ответственный инженер и целая команда разработчиков, проглядела все глаза, пытаясь найти хоть какие-то различия в NTP-пакетах до и после обновления. R&D поклялись Китайской Великой Стеной, что не вносили никаких изменений в алгоритм обработки NTP-сообщений. Сравнивали до байта данные в пакете.

И тут закралось первое подозрение, а что если не по NTP? Заказчик продолжал спорить, вендор радиооборудования молчал, как рыбой об лёд, потому что с ним не было контракта на техподдержку.

Мы же практически с завязанными глазами должны были угадать, что идёт не так в многомегабитном потоке данных. Пытались найти следы других механизмов синхронизации - ноль по вдоль.

В итоге чёрный ящик крутился, крутился и через несколько дней выплюнул - VSS Monitoring (кажется, так Wireshark определял эти пакеты). Пакеты этого типа ходили между RNC и BS. Мы до сих пор не уверены в том, что именно в них ходила синхра (возможно, внимательный читатель прояснит эту ситуацию), но именно в них обнаружили кардинальное отличие между различными версиями.

Это оказались пакеты сравнительно маленького размера - несколько байтов полезной нагрузки. Но, как известно, Ethernet не приемлет радикального минимализма - ему подавай как минимум 64 байта. Понятное дело, что даже заголовки MPLS+L2VPN+Ethernet+VLAN (4+4+18+4=32 байта) не всегда добьют до нужного, поэтому есть специальный механизм - Padding. Он дополняет размер Ethernet-кадра до минимального - до 64 байтов.

И как обычно, дьявол в мелочах. Заполняться, согласно стандарту, должно нулями, мол проще и легче определить, где кончаются полезные данные, где начинается padding. Но этого стандарта почему-то не принято строго придерживаться. Часто оказывается эффективнее заполнить тем, что уже есть в буфере, а отделение зёрен от плевел переложить на вышестоящий протокол.

Так вот оказалось, что в старой версии всё работало согласно стандарту, а вот в новой было решено оптимизировать механизм Padding, и кадр дополнялся не нулями, а куском из этого же самого кадра. Учитывая, что это не исключительное нарушение стандарта, подавляющее большинство протоколов с этим как-то справляется, а кто-то не справился, скорее всего, приняв всё заполнение за полезную нагрузку. Тут остаётся только гадать.

В кратчайшие сроки был выпущен временный патч, возвращающий назад режим работы - проблема решилась. Это пример очень сложного запроса и показатель хардкорности инженеров техподдержки. Даже со связанными руками, закрытыми глазами, кляпом во рту и работающим рядом отбойным молотком эти ребята способны решать сложнейшие запросы.

Проблемы первого уровня называются также критическими, но довольно таки часто на деле они являются скорее истерическими. Это ситуации когда заказчик хочет открыть запрос первого уровня, но в действительности ничего страшного не случилось, либо случилось, но сервисы уже восстановлены.

Вот вам пьеса в трёх действиях:

Саботажник

У инженерного состава паника - уже несколько раз они наблюдали падение линка между ядром сети и агрегацией. Пять минут лежит, потом само поднимается. Падает сервис всего города. Во внутренней системе заявок идут ожесточённые дискуссии на эту тему, считают, сколько пользователей страдает, смотрят логи со всех узлов, статистику. Я в этом участия не принимаю и могу с чувством, с толком, с расстановкой изучать логи.

Кстати, надо тут заметить, что в Hi-End маршрутизаторах Huawei два хранилища для логов - просто буфер, который выводится по команде display logbuffer, и файл подробнейших логов на карте памяти (cfcard2:/log/log.log).

В последний сохраняются все события и все действия инженеров на коммутаторе. Вот его я и начал смотреть. Догадаетесь, что я там увидел?

Торопыга

А вот случай совсем недавно. Инженер жалуется, что после команды undo mpls на интерфейсе упали все LSP, LDP-сессии, туннели на устройстве - восстановилось после ребута. Полный предвкушения, что будет что-то интересное, я полез в логи. Печенька не заставила себя долго ждать:

 

System-view - режим конфигурации sysname - команда для смены имени устройства.

Мазохист

Проблема: не работает команда по добавлению статического Router port в IGMP - после настройки клиенты перестают получать мультикастовый трафик.

На канальном уровне для мультикаста есть много плюшек для управления. Одна из них - статическая настройка порта в сторону маршрутизатора.

Вообще Router port изучается коммутатором благодаря IGMP-Snooping после получения IGMP General Query от маршрутизатора. Когда на коммутатор приходят Report от клиентов, он отправляет их именно в Router port. Бывают ситуации, когда маршрутизатор по какой-то причине не посылает General Query, но посылать Report'ы на него по-прежнему нужно. Либо вы хотите чётко определить, что отправлять Report нужно именно в этот интерфейс.

Делается это в режиме настройки интерфейса командой igmp-snooping static-router-port vlan X.

Есть дополнительная команда для выключения изучения того, где находится маршрутизатор вообще: undo igmp-snooping router-learning. В этом случае он просто начинает игнорировать Query с этого порта.

Вместе эти две настройки позволяют жёстко зафиксировать порт, куда следует отправлять Report, и соответственно откуда получать трафик.

Как же можно здесь навредить себе? А всё довольно просто - достаточно включить IGMP-Snooping Proxy.

Ведь на оборудовании Хуавэй у него три базовых правила работы:

  1. Если коммутатор получил Query от вышестоящего маршрутизатора, он отправляет ему ответный Report, не опрашивая клиентов - просто сообщает, какие группы ему нужны.
  2. Если коммутатор получил самый первый Report для данной группы, он отправляет его наверх. Все другие Report он учитывает, но не отправляет
  3. Если коммутатор получил самый последний Leave (от последнего клиента группы), он отправляет его наверх. Все другие Leave учитывает, но не отправляет.

И что же это получается, если настроить все команды разом? Первый клиент подключается, посылает Report. Это первый Report для группы, поэтому коммутатор отправляет его в Router port. Трафик начинает литься и клиент его получает.

Далее маршрутизатор тщетно отправляет GQ на в интерфейс, но коммутатор их отбрасывает, потому что настроено undo igmp-snooping router-learning.

Сам по себе клиент, как правило, не отправляет Report периодически.

По прошествии трёх минут маршрутизатор прекращает свои потуги, не получая Report, и удаляет интерфейс из списка OIL. Все следующие клиенты уже были не первыми и их Report'ы погибали на коммутаторе.

Что объединяет все описанные ситуации? Человеческий фактор, расхлябанное отношение, невнимательность.

Решение сетевых проблем часто сравнивают с работой врача. Пациент жалуется на боль, а мы с помощью наводящих вопросов и анализов находим болезнь. Разница лишь в том, что цена нашей ошибки - деньги и репутация, а не человеческие жизни. У нас есть право на ошибку, но не нужно им злоупотреблять.

Пожалуй, из ряда выбивается только проблема с паддингом - всё-таки разработчики действовали из лучших побуждений - они хотели оптимизировать работу и в общем-то не их вина, что стандартом не достаточно чётко это прописано. И не вина другого вендора, что он не предусмотрел такую возможность и не адаптировал к ней свои механизмы.

Ещё более глубокая проблема - широковещательные штормы. Понятны причины, по которым на L2 существует принцип широковещания, можно понять и причины, по которым нет поля TTL в кадрах Ethernet, понятно даже то, почему изначально разработчики не задумывались о таких проблемах - в конце концов, эта технология задумывалась для LAN, а не для сети провайдера или уж тем более MAN. Однако эта недальновидность дорого теперь обходится операторам. Но это уже совсем другая история.

Ссылка на материал, для размещения на сторонних ресурсах

nag.ru


Смотрите также