Как создать бесконечно длинный AS_PATH в BGP: инструкция, которой лучше не следовать.

Описан сценарий, показывающий, как комбинация функций BGP confederations и AS override может привести к нештатному поведению протокола, в частности к петле, а в случае автора еще и к падению процесса BGP.

А можно сразу к выводам:

The main lessons from this tale are:

• never use BGP confederations under any circumstances, and
• be cautious of features that weaken BGP routing loop detection.

Статья свежая, 2024 г, но кто-нибудь видел в проде BGP confederations или это все-таки только в учебниках?

🎤 Будни сетевика 😊

Интересное чтиво о высокоуровневом проектировании систем масштаба Netflix и др

• Designing Netflix
• Designing WhatsApp
• Designing Uber
• Designing Tinder
• Designing Instagram


🎤 Будни сетевика 😊

Задача: сохранить данные в Zabbix при переходе на новые маршрутизаторы

Проводили работы по замене маршрутизатора Juniper mx10003 на mx304, конфиг переносился 1 в 1 и по всем системам все было хорошо, но в zabbix новый маршрутизатор был недоступен. Удалять старый хост не хотелось - нужна была история. Отмечу, что мы уже довольно давно перешли на SNMPv3.

Ошибка в Zabbix: «Timeout while connecting», при этом с Zabbix-сервера mx304 были доступны по ICMP и SNMPv3 (проверяли snmwalk). Пробовали пересоздать snmpv3 пользователей, проверили алгоритмы шифрования и ключи, синхронизацию времени - бесполезно.

Смотрим tcpdump на Zabbix, видим ошибки:

usmStatsUnknownEngineID
usmStatsNotInTimeWindows

EngineID - это уникальный идентификатор snmp-агента в сети. Зачастую данный идентификатор генерируется сетевым устройством самостоятельно на основании mac или IP-адреса интерфейса управления.

Проверяем EngineID на mx304:

mx304> show snmp v3 general

Local engine ID: 80 00 0a 4c 01 0a 4d 25 a2
Engine boots: 2
Engine time: 47160 seconds

Проверяем EngineID на mx10003:

mx10003> show snmp v3 general

Local engine ID: 80 00 0a 4c 01 0a 4d 25 a2
Engine boots: 13
Engine time: 29049080 seconds

Cтарый и новый маршрутизаторы имеют одинаковые EngineID. Cтранно, изучаем дальше.

Выясняем, что EngineID используется не только как уникальный идентификатор агента в сети, но и участвует в следующих процессах:

1. Генерация ключей - используется в процедуре key localization для создания уникальных ключей аутентификации для каждого устройства.

2. Механизм защиты от replay-атак - EngineID является ключом кеша, где хранятся параметры времени (EngineBoots, EngineTime).

Перед тем как Zabbix сможет выполнять запросы, он должен узнать у агента(mx304) значения EngineID, EngineBoots, EngineTime и делает он это в две транзакции. В первой узнается EngineID, во второй EngineBoots, EngineTime. В первой транзакции Zabbix формирует snmpv3 пакет, где в msgAuthoritativeEngineID указывает EngineID агента = 0(либо ничего не указывает). Агент получает такой пакет, где EngineID отличен от локального и отбрасывает его. В ответ он формирует пакет, где указывает свой корректный EngineID. Во второй транзакции аналогично узнаются параметры EngineBoots и Time. Процесс проверки агентом значений EngineBoots, EngineTime со своими локальными значениями является частью процесса аутентификации. Сперва проверяется EngineBoots, если значение отлично от локального, то пакет отбрасывается и агент генерирует ответ с корректным значением. Далее проверяется EngineTime. Если разница больше или меньше 150 секунд, то пакет отбрасывается.

Полученные значения EngineID/Boots/Time Zabbix сохраняет в свой кэш. Ключом для поиска по этому кэшу используется как раз EngineID. В нашем случае Zabbix по ключу "80 00 0a 4c 01 0a 4d 25 a2" получает из кэша значения EngineBoots = 13, EngineTime = 29049080 (значения от старого mx10003) и отправляет их mx304, который понимает, что полученные значения не его и процесс аутентификации заканчивается ошибкой, mx304 отправляет сообщение usmStatsNotInTimeWindows. Zabbix начинает процедуру обнаружения, но не может перезаписать в свой кеш новые значения EngineBoots и Time, полученные от mx304 т.к. они отличаются(2 у mx304 и 13 у mx10003). Возникает циклическая зависимость: для успешной работы нужны верные параметры из кэша, но чтобы их туда положить, нужно успешно завершить сессию, которая зависит от этих параметров 🤷

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

RFC на все это дело.

Решение:

1. Задать явно значение EngineID:
set snmp engine-id local <id>

2. Использовать EngineID на основе mac:
set snmp engine-id use-mac-address

Почему совпал EngineID:

The Juniper default SNMP engine ID is the device's default IP address

А конфиг мы перенесли 1 в 1 🙂

🎤 Будни сетевика 😊 #Задача

Ранее для того, чтобы пользователь мог просматривать логи в Junos, достаточно было выдать разрешение на команду show log messages, но в последних версиях Juniper изменили логику доступа к логам:

Latest Junos version have been changed to allow only root user or maintenance permission users to view the log files. Other permission categories will not be able to see them.

Изменилось тут:

Junos syslog privilege change after applying the fix of PR1702241

В какой точно версии это появилось я не нашел (ставлю на 23), могу только сказать что в 20.2R1.10 еще работало, в 23.4R2-S3.9 уже нет.

4 опции, что с этим можно сделать.

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

🎤 Будни сетевика 😊