Ingress NGINX Retirement: What You Need to Know

In March 2026, Ingress NGINX maintenance will be halted, and the project will be retired. After that time, there will be no further releases, no bugfixes, and no updates to resolve any security vulnerabilities that may be discovered. The GitHub repositories will be made read-only and left available for reference.

Existing deployments of Ingress NGINX will not be broken. Existing project artifacts such as Helm charts and container images will remain available.

UPD: В комментах подсказали, что есть два Nginx Ingress:

1. От самого Kubernetes - https://github.com/kubernetes/ingress-nginx/
2. От F5/Nginx - https://github.com/nginx/kubernetes-ingress/

Речь в статье про первый.

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

Дефолтный ARP-полисер на Juniper MX

Несколько лет назад мы в течение довольно долгого времени пытались найти причину флапов BFD на маршрутизаторах Juniper MX. Проблема была плавающая и ни с чем не коррелировала, возникала на обоих маршрутизаторах в паре в двух разных дата-центрах. В какой-то момент уже дошли до диагностики QSFP-модулей, потому что как раз в это время начали использовать новые модули от другого поставщика 😅

В итоге, все оказалось гораздо проще. У Juniper есть дефолтный ARP-полисер, который ограничен в 150 kb/s.

Вот он «красавчик», показывает дропы:

jun_mx> show policer default_arp_policer
Policers:
Name Bytes Packets
default_arp_policer 22695791183 493445894

Этот полисер применяется по умолчанию ко ВСЕМ интерфейсам:

Logical interface irb.50
Policer: Input: __default_arp_policer__
Logical interface irb.51
Policer: Input: __default_arp_policer__
Logical interface irb.100
Policer: Input: __default_arp_policer__
Logical interface irb.777
Policer: Input: __default_arp_policer__
Logical interface irb.778
Policer: Input: __default_arp_policer__
…
и тд

Решением было создать кастомный ARP-полисер:

set firewall policer okko_arp_policer if-exceeding bandwidth-limit 2m

set firewall policer okko_arp_policer if-exceeding burst-size-limit 1m

set firewall policer okko_arp_policer then discard

И применить его на все интерфейсы:

set interfaces irb unit 50 family inet policer arp okko_arp_policer

set interfaces irb unit 51 family inet policer arp okko_arp_policer

set interfaces irb unit 100 family inet policer arp okko_arp_policer

set interfaces irb unit 777 family inet policer arp okko_arp_policer

set interfaces irb unit 778 family inet policer arp okko_arp_policer
…
и тд

После этого на каждом интерфейсе будет использоваться СВОЙ ARP-полисер, а не общий дефолтный:

jun_mx> show policer
Policers:
Name Bytes Packets
__default_arp_policer__ 0 0
okko_arp_policer-irb.50-inet-arp 0 0
okko_arp_policer-irb.51-inet-arp 0 0
okko_arp_policer-irb.100-inet-arp 0 0
okko_arp_policer-irb.777-inet-arp 0 0
okko_arp_policer-irb.778-inet-arp 0 0

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

Задача: Запустить goBGP в Docker-контейнере без прав суперпользователя и установить BGP-сессию с реальным сетевым оборудованием.

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

Определимся с терминологией:

Хост - сервер или виртуальная машина, на которой работает контейнер.

Контейнер - изолированное окружение для приложения, работающее поверх хоста, т.е. использует ядро ОС хоста, но может иметь свои процессы и сетевые доступы.

BGP использует 179-й порт, который является привилегированным (менее 1024), и для его использования без прав суперпользователя не обойтись. Но у нас нет необходимости принимать соединения на 179-м порту, достаточно, чтобы goBGP сам мог инициировать сессию. В goBGP есть параметр для этого:

ListenPort: -1, // не слушать tcp:179

Для установления BGP-сессии будет использоваться динамический порт, который нужно как-то передать на хост из контейнера. Самый простой вариант - запустить контейнер с network_mode: host, что позволяет контейнеру напрямую использовать сетевой стек хоста. В режиме host сетевой стек контейнера не изолирован от хоста, т.е. если контейнер привязывается к какому-либо порту (в нашем случае к порту, с которого устанавливается BGP-сессия), то этот же порт будет открыт на хосте. EXPOSE в Dockerfile делать не нужно.

Настраиваем пиров и проверяем, что BGP-сессия установилась!

Проверяем, что внутри контейнера нет открытого порта 179:

# netstat -lntup | grep $(docker inspect 4c39c56c2f7e --format='{{.State.Pid}}')

tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 2497377/service
tcp 0 0 0.0.0.0:7854 0.0.0.0:* LISTEN 2497377/service
udp 0 0 0.0.0.0:2055 0.0.0.0:* 2497377/service

Проверяем на хосте:

# netstat -lntup | grep 179
#

Порт 179 никто не слушает - так и должно быть. Без прав root не получится занять порт ниже 1024.

Посмотрим все соединения в системе на хосте, связанные с портом 179:

# lsof -i :179
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
service-na 2497377 user 14u IPv4 100373363 0t0 TCP service_name:48155->_gateway:bgp (ESTABLISHED)

В выводе видно, что процесс с PID 2497377 установил исходящее соединение на порт 179, а локально он использует случайный порт 48155, то есть goBGP выступает в роли BGP-клиента.

Если по каким-то причинам нужно внутри контейнера (без прав root) слушать 179-й порт и принимать входящие соединения, придется использовать Linux capabilities:

RUN setcap 'cap_net_bind_service=+ep' /путь_к_приложению

CAP_NET_BIND_SERVICE позволяет процессу использовать привилегированные порты (<1024).

Но это актуально только если используется опция no-new-privileges:true. У нас она обязательна к применению по требованию ИБ. По умолчанию, NET_BIND_SERVICE разрешен, полный список разрешенных capibilities тут.

Можно еще попробовать запустить goBGP на нестандартном порту (например 1179) и с помощью iptables на хостовой машине пробросить трафик с 179 на 1179. При этом убрать network_mode: host.

И примерно так пробросить на хосте:

iptables -t nat -A PREROUTING -p tcp --dport 179 -j DNAT --to-destination <container_ip>:1179

P.S. Если есть дополнения или я где-то ошибаюсь, буду рад комментариям.

UPD: Спасибо за исправления @maxnrm

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

⚡️ YADRO×SPRINT OFFER: оффер для Network Engineer in Test за 3 дня!

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

Мы в поиске специалистов в команду KORNFELD, которая занимается тестированием коммутаторов различных типов и сетевого оборудования YADRO. Инженеры анализируют поведение систем, актуализируют требования, создают сценарии и подходы к тестированию — от функционального до надёжности и отказоустойчивости, а также помогают совершенствовать архитектуру продуктов и пользовательский опыт.

💡 Как всё проходит:
1️⃣ Оставьте заявку до 30 ноября, пройдите HR-скрининг и технический скрининг.
2️⃣ Пройдите техническое и менеджерское интервью.
3️⃣ Получите оффер всего за 3 дня.

🚀 Основные задачи:
• Анализ продуктовых требований и подготовка use cases.
• Проведение E2E- и failover-тестирования.
• Разработка тест-кейсов и тест-планов для нового и уже существующего функционала.
• Участие в совместных испытаниях и взаимодействие с командами разработки, L3 и сервиса.

🔥 Для нас важны:
• Опыт работы с сетевым оборудованием (Cisco, Huawei, Juniper и др).
• Глубокие знания протоколов, применяемых в ЦОДах (BGP, OSPF, VxLAN, VRRP и др.).
• Навыки тестирования и траблшутинга.
• Внимательность, системность и интерес к сетевым технологиям.

💙 Оставляйте заявку до 30 ноября, присоединяйтесь к инженерному сообществу YADRO и вносите вклад в развитие сетевых технологий будущего!

Как создать бесконечно длинный 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 опции, что с этим можно сделать.

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

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