Умный на лестнице - это выражение, которое иногда встречается в художественной литературе [1]. Оно используется в отношении человека, который нашёл удачный ответ уже после того, как диалог был закончен, то есть буквально оказавшись за порогом на лестнице. Имеет саркастическую интонацию. Может употребляться в отношении самого себя.

Есть такая функция логирования, при которой для аутентификации берется имя пользователя и пароль от входа в Windows. Если компьютер в домене, то и доменное имя будет приставлено к логину в формате "DOMAIN_NAME\user_name". Если используется протокол 802.1x, то это имя (именно в таком формате) будет перенаправлено на сервер. Возникает вопрос: если сервер аутентификации ничего не знает о домене, то может ли iMaster NCE "отсечь" доменное имя и корректно обработать такой запрос, не создавая лишней головной боли? Оказалось, что может, но есть в этом решении какая-то костыльность, и головная боль вместе с ней.

Недавно обратился заказчик, который эксплуатирует стек из S5720-52X-PWR-SI и дюжину IP телефонов Avaya и Grandstream. С Avaya проблем не было, а вот Grandstream периодически отключались, при этом отключались спонтанно и выборочно. Зависимостей не было обнаружено: в отдельные дни могло быть до 30 отключений, в другие 1-2. Некоторые аппараты отключались чаще, другие – реже. C PoE и с кабельной трассой проблем не было. Больше подозрений вызвала именно конфигурация портов в режиме hybrid...

NetFlow и Netstream - это инструменты для мониторинга, сбора статистики о трафике, и задачи они имеют одни и те же, но реализации имеют разные. Недавно мы рассматривали кейс, когда после интеграции нескольких железок Huawei в существующую сеть Cisco, на Huawei был настроен Netstream аналогично конфигурации NetFlow на Cisco, но трафик c Huawei считался в сто раз меньше того количества, которое ему отправлял Cisco:

----router Cisco --->100 пакетов ---> router Huawei AR6280 --->1 пакет----

Очередной случай, когда нам говорили, что "все хорошо", но в итоге ничего не работало. На этот раз речь о VPLS между роутером Huawei 40E и Nokia XRS 7950.

С двумя проблемами обычно обращаются клиенты, когда берутся за конфигурирование SSL VPN на фаерволах USG Huawei (SSL VPN = защищенный доступ к внутренним ресурсам фаервола через Интернет). Первая проблема: не проходит аутентификация при попытки залогиниться через web-браузер смартфона. Вторая: не удается ограничить доступ для определенных пользователей (полисер не распознает username). Это не вина клиентов, или программых недоработок продукта, скорее это недостаточная ясность документации.

Недавно обратилось несколько клиентов с идентичной проблемой. Клиенты развертывали leaf коммутаторы Huawei в ЦОДе. Коммутаторы функционировали как L3 шлюзы для СХД (сценарий VXLAN распределенного шлюза). Каждая пара leaf коммутаторов объединялась в стек или M-LAG группу. Задача была простая: чтобы ноды имели сетевую доступность до шлюзов. Клиент успешно развернул большую часть коммутаторов, но проблема возникла на последней паре: шлюз (vbdif интерфейс) был недоступен с ноды, сетевой связности не было, хотя ARP до ноды доходил. Конфигурация на всех коммутаторах была стандартной, единственным отличием этой последней пары коммутаторов было то, что они были другой модели - CE8850EI. Эта модель и ряд других имеют функциональную особенность.

Недавно обратился клиент, который жаловался на низкую скорость download-загрузки на сети 802.11ac. В качестве доказательства он представил Speedtest скрин, на котором upload был равен 200mbps, а download 15-20mbps. Но в ходе траблшутинга с помощью iPerf мы заметили, что низкий показатель download продолжается только первые 10 секунд теста...

Недавно к нам обратился клиент из страны бывшего СССР. Он организовал свободный доступ к Wi-Fi на городском пляже. Были выполнены изыскания, обследована местность, смонтировано оборудование и торжественно перерезана красная ленточка, но качество сервиса оказалось неудовлетворительным: частые обрывы соединения, низкая скорость и недостаточная зона покрытия. В ходе разбирательства выяснилось, что никаких обследований местности ни до развертывания, ни после не производилось, реализация проекта основывалась только на моделировании RSSI, а все работы по факту выполнял подрядчик.

Недавно обратился клиент с проблемой на 802.11 сети: с мобильных телефонов часто не удавалось подключиться к SSID на фазе аутентификации. Со стационарных устройств таких проблем замечено не было - но именно с мобильных, как сообщал заказчик. Мы попросили клиента сообщить происходит ли это во время удаления пользователя от точки доступа или нет, но клиент не смог сообщить, так как сам не знал где физически располагаются точки доступа.

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

Нередко заказчики обращаются с проблемой, когда с исправными и верно установленными трансиверами оптический линк 100G не поднимается. Как правило, происходит это во время миграции/модернизации с одновендорных решений типа "Вендор А - Вендор А" на сеть типа "Вендор А - HUAWEI". В недавнем кейсе заказчик проделал путь из СПБ в Великий Новгород, чтобы провести ночные работы по замене коммутатора Вендора А на коммутатор HUAWEI. На другой стороне был пакетный брокер Profitap XX-3200. Ребята планировали быстро выполнить работы и вернуться в СПБ к утру, но линк не поднялся.

Недавно обратился клиент с вопросом почему у него при трассировке появляются звездочки. Трассировка проходила через IPsec тоннель, поэтому коротким ответом было: потому что IPsec не возвращает ICMP reply. Но у клиента также была проблема с маршрутизацией, причину которой он связывал со "звездочками". И все это происходило на фаерволе USG Huawei, с которым клиент имел дело впервые. Иными словами, коротким ответом он не удовлетворился.

Недавно заказчик сообщил, что не может сделать ни автоматический, ни ручной бэкап конфигурации коммутатора Huawei серии S5700. Пройдясь по шагам траблшутинга, было замечено, что конфигурации нет, точнее значение строки "Startup saved-configuration file" в display startup равно NULL:

Обратился клиент с жалобой на то, что суммарный OSPFv2 маршрут (LSA Type 3) не аннонсировался между непосредственно подключенным соседями: от роутера A к роутеру B. Особенностью этой топологии было то, что на роутере B был прописан vpn-instance (VRF).

Недавно расследовали кейс, когда при казалось бы исправной конфигурации все попытки залогиниться на маршрутизатор Huawei NE40E-X8A (V800R021C00SPC100) были неуспешны в течение около двадцати минут, при этом все линии VTY SSH линии были свободны, никто не логинился на устройство несколько дней. Кто или что занимало свободные линии?

Мы уже разобрали в прошлых частях как накатить на сетевые устройства Huawei список команд из внешнего файла. И это работает, если у нас сеть состоит из одинаковых устройств. Конечно, в реальной практике такое встречается редко. В этой работе мы рассмотрим как использовать разные конфигурационные файлы для разных устройств Huawei, при этом не выходя за рамки одного скрипта. То есть у нас будет все тот же скрипт на основе Netmiko, но в зависимости от версии устройства, конфиг будет накатываться разный: один конфиг для коммутатора CloudEngine Huawei, другой конфиг для роутера AR3200 Huawei.

Как обычно, полный скрипт приведу в конце статьи, видеодемонстрация доступа по ссылке на Форуме Huawei ICT Club.

Обычно мы можем встретить три проблемы при попытке запустить Python-скрипт на сети Huawei (впрочем, и на любой другой): это отсутствие L3 связности с устройством, это неверные имя пользователя или пароль, и это SSH-неполадки. Можно заметить, что любая из этих проблем остановит накат скрипта и сгенерирует один и тот же лог, большая часть из которого сложна для восприятия. В этой статье я постарался рассказать о небольшом улучшении предыдущего кода, которое сообщит о конкретной ошибке на устройстве, и продолжит накат скрипта до конца.

Весь код приведу в конце статьи, а его запуск можно посмотреть на видео демонстрации.

Продолжаю ковырять автоматизацию рутины на сети из Huawei коммутаторов. На этот раз изыскания, которые позволили сократить код в 3 раза, а именно: хосты и команды перенесены в отдельные файлы, пароль и имя пользователя больше не хранятся в открытом тексте. Есть демонстрация запуска скрипта. Детальное описание за кнопкой «Читать далее».

Ansible с костыльком может автоматизировать сеть и non-CloudEngine коммутаторов Huawei, как недавно было доказано на нашем Enterprise форуме. Однако в сети, в которой работают разные модели коммутаторов, Ansible не представляется эффективным инструментом на данный момент. И несмотря на бесспорное улучшение качество кода Python для Telnet, данный скрипт также не подходил по ряду причин. 

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

На помощь пришел Netmiko. О том как это было, читайте в этом посте. Готовый скрипт приводится в конце.