В Junos существуют различные типы Next-hop:

🟢broadcast (bcst)—Broadcast.
🟢deny—Deny.
🟢discard (dscd) —Discard.
🟢hold—Next hop is waiting to be resolved into a unicast or multicast type.
🟢indexed (idxd)—Indexed next hop.
🟢indirect (indr)—Indirect next hop.
🟢local (locl)—Local address on an interface.
🟢routed multicast (mcrt)—Regular multicast next hop.
🟢multicast (mcst)—Wire multicast next hop (limited to the LAN).
🟢multicast discard (mdsc)—Multicast discard.
🟢multicast group (mgrp)—Multicast group member.
🟢receive (recv)—Receive.
🟢reject (rjct)—Discard. An ICMP unreachable message was sent.
🟢resolve (rslv)—Resolving the next hop.
🟢unicast (ucst)—Unicast.
🟢unilist (ulst)—List of unicast next hops. A packet sent to this next hop goes to any next hop in the list.
🟢VxLAN Local—EVPN Type 5 route in kernel.

Также можно встретить тип dead.

Пример вывода команды:

show route forwarding-table vpn internet destination 42.119.54.0/24 extensive 
Routing table: internet.inet [Index 17] 
Internet:
    
Destination:  42.119.54.0/24
  Route type: user                  
  Route reference: 0                   Route interface-index: 0   
  Multicast RPF nh index: 0             
  P2mpidx: 0              
  Flags: sent to PFE, rt nh decoupled  
  Next-hop type: dead                  Index: 1102     Reference: 21

▎Инструкция чтобы увидеть dead своими глазами:

1. Необходим маршрутизатор Juniper MX.
2. Должен быть установлен софт 20.4R2.7. Да, он довольно старый.
3. Необходимо изменить MTU глобально на irb-интерфейсе: set interfaces irb mtu 9000.

Это приведет к флапу BGP-сессий и, как следствие, к неверно запрограммированным маршрутам на PFE с Next-hop "dead". Проблема воспроизводится 100%.

▎Что с этим делать:

1. Обновиться до более свежей версии, например, до 23.4R2-S3.9 - в этой версии проблема точно устранена.
2. Перед глобальным изменением MTU на irb-интерфейсе явно задать IP MTU для BGP-пиров, тогда также будет все в порядке.

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

Задача: на виртульной машине с Ubuntu 24 изолировать два сетевых интерфейса между собой.

Мы боролись с ассиметрией в виртуальной среде NSX-T, где distributed firewall к ней совсем нетерпим, необходимо было разнести маршруты 0/0 и 10/8 по разным интерфейсам, при это было важно, чтобы они не были в одной таблице маршрутизации.

И когда сетевик слышит, что нужно что-то «изолировать» - он идет натягивать VRF. По официальной документации netplan поддерживает VRF - то, что надо, берем.

Адаптируем под себя:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0: # -> vrf-mgmt
      addresses:
        - 10.10.8.101/23
      routes:
        - to: 10.0.0.0/8
          via: 10.10.8.1
      routing-policy:
        - from: 10.10.8.101/23
    eth1: # -> main
      addresses:
        - 10.11.8.3/29
      gateway4: 10.11.8.1
  vrfs:
    vrf-mgmt:
      table: 101
      interfaces: [eth0]

Интерфейсы разнесены по VRF, всё выглядит корректно:

# ip route
default via 10.11.8.1 dev eth1 proto static
10.11.8.0/29 dev eth1 proto kernel scope link src 10.11.8.3

# ip route show vrf vrf-mgmt
10.0.0.0/8 via 10.10.8.1 dev eth0 proto static
10.10.8.0/23 dev eth0 proto kernel scope link src 10.10.8.101

Проверяем доступ извне до IP-адреса внутри VRF - ping работает! А для сетевика полученный ICMP-ответ - это как документ с печатью, подтверждающий наличие доступа. Проверяем SSH, получаем «connection refused», перезагружаем VM(на всякий), доступа нет, интересно. Отключаем iptables(в любой непонятной ситуации), но и это не помогает. Любые дальнейшие эксперименты показывают, что и другие сервисы, привязанные к IP-адресу eth0 (который внутри VRF) также недоступны 🤷

Я не знал, что все сервисы работают в контексте VRF по умолчанию, т.е. процессы используют таблицу маршрутизации по умолчанию и имеют доступ к прослушиваемым IP-адресам только в этом дефолтном VRF, если не указано иное.

Если для ping внутри VRF мы можем использовать опцию -I, которая указывает src-интерфейс внутри VRF и ping начинает работать, то сервису SSH необходимо явно указать - используй контекст vrf-mgmt! Это будет касаться и других сервисов, которые должны работать с IP-адресами внутри VRF.

Решение для SSH: в systemd для юнита sshd изменить ExecStart с указанием использования VRF. Пока идет отладка изменим сразу /lib/systemd/system/ssh.service. (Напрямую лучше не изменять системные файлы, потому что любое обновление перезатрет изменения, нужно использовать override)

Было
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS

Стало
ExecStart=/bin/ip vrf exec vrf-mgmt /usr/sbin/sshd -D $SSHD_OPTS

Команда ip vrf exec запускает процесс sshd в контексте vrf-mgmt.

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

systemctl daemon-reload
systemctl restart ssh

Проверяем SSH извне на IP внутри VRF - доступ есть!

Если цель вынести только управление VM в отдельный VRF, то в принципе, на этом можно остановиться. Но в нашем случае были и другие сервисы, которым нужен доступ к VRF.

Идем дальше.

Есть решение, в котором все сервисы будут работать со всеми VRF в системе - L3 Master Device, известный как l3mdev:

Official reference
Enables child sockets to inherit the L3 master device index. Enabling this option allows a “global” listen socket to work across L3 master domains (e.g.,VRFs) with connected sockets derived from the listen socket to be bound to the L3 domain in which the packets originated. Only valid when the kernel was compiled with CONFIG_NET_L3_MASTER_DEV

Проверим наличие модуля CONFIG_NET_L3_MASTER_DEV в конфигурационном файле ядра:

grep CONFIG_NET_L3_MASTER_DEV /boot/config-$(uname -r)

Если видим CONFIG_NET_L3_MASTER_DEV=y, значит модуль встроен в ядро.

Включаем для tcp/udp:

sysctl -w net.ipv4.tcp_l3mdev_accept=1
sysctl -w net.ipv4.udp_l3mdev_accept=1

Проверяем, убеждаемся что все сервисы начинают работать внутри VRF. Успех 😮‍💨

По документации, l3mdev ухудшает производительность на 2-3%. Попробую разобраться как он работает.

#Задача

Поразбирался с l3mdev.
Продолжение предыдущего поста

L3mdev (Layer 3 Master Device) - это механизм в ядре Linux, который обеспечивает поддержку VRF, т.е. основное назначение l3mdev - это изоляция таблиц маршрутизации.

В контексте l3mdev есть два вида устройств(devices):

1️⃣ Master - это собственно и есть VRF. Пример: создаем VRF ip link add dev vrf-mgmt type vrf table 101, где vrf-mgmt и будет мастер устройством.

2️⃣ Slave - устройство, которое «подчинено» мастеру, т.е. сетевой интерфейс, привязанный к VRF. Пример: ip link set dev eth0 master vrf-mgmt, где eth0 - slave

У каждого сетевого интерфейса есть индекс, который можно посмотреть с помощью команды ip link show.

Вывод сокращен:

1: lo: <LOOPBACK,UP,LOWER_UP>

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> master vrf-mgmt state UP

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> state UP

4: vrf-mgmt: <NOARP,MASTER,UP,LOWER_UP> state UP

[1-4] - это индексы, при этом в зависимости от направления они могут быть:

🟢 iif - Input Interface Index, индекс сетевого устройства, на которое пришел пакет
🟢 oif - Output Interface Index, индекс сетевого устройства, через которое пакет будет отправлен

Задача l3mdev сводится к тому, чтобы перенаправить сетевые интерфейсы на L3 мастер-устройство для маршрутизации через правильную таблицу. То есть он меняет oif или iif со slave-устройства на master-устройство.

На примере нашего конфига netplan это работает так:
Пакет -> eth0(slave) -> 3lmdev делает update iif -> vrf-mgmt(master) -> table 101

Чтобы l3mdev мог заменять iif/oif на master (VRF), используется специальная таблица, которая создается автоматически при создании VRF - [l3mdev-table].

Команда для просмотра правил маршрутизации: ip rule show

Вывод:

0: from all lookup local
1000: from all lookup [l3mdev-table] <— вот она
32765: from 10.10.8.101/23 lookup main proto static
32766: from all lookup main
32767: from all lookup default

Числа слева - это приоритеты, возможный диапазон от 0 до 32767. Чем меньше число, тем выше приоритет. Задача l3mdev-table - динамически указывать на правильную таблицу VRF на основе сетевого интерфейса (iif или oif).

Как это работает:

Приходит пакет
↓
Приоритет 0: lookup local
↓
Приоритет 1000: lookup [l3mdev-table]
Вот тут начинает работать l3mdev
1. Определяет интерфейс (iif/oif) исходя из флоу трафика
2. Проверяет принадлежит ли интерфейс VRF
3. Определяет ID таблицы VRF и перенаправляет в нее
↓
Приоритет 32765: from 10.10.8.101/23 lookup main
↓
Приоритет 32766: lookup main
↓
Приоритет 32767: lookup default

И посмотрим, где l3mdev находится в сетевом стеке(упрощенно):

1️⃣ Пакет из сети попадает на сетевую карточку, далее в драйвер сетевой карты

2️⃣ Ядро создает skb (socket buffer), проверяет пакет на валидность, заголовки и тд.

3️⃣ Любой входящий трафик запускает хук Netfiler - NF_IP_PRE_ROUTING (обрабатывается до принятия решения о том, куда отправлять пакет). Про Netfilter и хуки можно почитать тут. Происходит первый поиск в RIB - проверяется принадлежит ли dst IP локальному интерфейсу.

4️⃣ Хук l3mdev_l3_rcv меняет skb->dev(eth0) на vrf-mgmt

5️⃣ На основе нового skb->dev происходит повторный поиск в RIB в VRF

6️⃣ И если пакет предназначен локальному хосту, вызывается хук NF_INET_LOCAL_IN и передается приложению.

Обработка исходящих пакетов по своей сути похожа, но будут вызываться разные хуки Netfiler и l3mdev.

Стоит отметить, что l3mdev никак не влияет на L2-трафик.

Из необычного, статистика по интерфейсу vrf-mgmt будет выглядеть так:

vrf-mgmt: flags=1217<UP,RUNNING,NOARP,MASTER> mtu 65575
ether 22:20:a7:a8:7f:f8 txqueuelen 1000 (Ethernet)
RX packets 36707747 bytes 26433447694 (26.4 GB)
TX packets 0 bytes 0 (0.0 B)

Счетчик TX на интерфейсе vrf-mgmt всегда равен 0.

Свою версию, почему так происходит, я напишу в следующем посте. Если у вас есть свои идеи или вы считаете, что в моих рассуждениях выше есть неточности, то можем обсудить в комментах.

——————————————
Документ с описанием: What is an L3 Master Device?
Нашел еще доклад + презу

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

Сегодня стартовала оффлайн часть ключевой отраслевой конференции по технологиям видео VideoTech 2025

СПб, 7-8 октября.

Отличная возможность обменяться опытом, рад буду пообщаться.

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

Продолжаем и заканчиваем историю про VRF в Linux.

Статистика по интерфейсу vrf-mgmt будет выглядеть так:

vrf-mgmt: flags=1217<UP,RUNNING,NOARP,MASTER> mtu 65575
ether 22:20:a7:a8:7f:f8 txqueuelen 1000 (Ethernet)
RX packets 36707747 bytes 26433447694 (26.4 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Необычно здесь то, что счетчик RX увеличивается, а TX - нет.
Сразу отметим, что в отличии от физических интерфейсов (eth0, eth1), интерфейс vrf-mgmt - виртуальный.

Почему так происходит.

▎Входящий трафик (RX)

1️⃣ Пакет приходит на интерфейс eth0, который привязан к VRF
2️⃣ Пакет попадает на интерфейс vrf-mgmt для маршрутизации
3️⃣ Увеличается счетчик RX, потому что пакет проходит через vrf-mgmt
4️⃣ Определяется получать и пакет отправляется приложению или другому хосту

▎Исходящий трафик (TX)

1️⃣ Приложение формирует пакет и отправляет его через VRF
2️⃣ FIB lookup в VRF - пакет должен уйти через eth0, при этом сам пакет VRF не обрабатывает (TX счетчик VRF не изменяется)
3️⃣ Пакет передается напрямую на eth0
4️⃣ И вот уже здесь TX счетчик eth0 увеличивается


Получается такая картина:

### Входящий трафик ###

[Сеть] → [eth0] → [VRF] → [Приложение]
                ↑
          RX счетчик увеличивается здесь

### Исходящий трафик ###

[Приложение] → [VRF] → [eth0] → [Сеть]
                         ↑
          TX счетчик увеличивается здесь

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

Задача: настроить коммутаторы Juniper QFX на отправку syslog over TLS

Такое потребовалось в одном изолированном контуре, где все должно быть максимально БЕЗОПАСНО 🔐

3 шага для настройки

🔑 Шаг 1: Установка сертификата

Тут два варианта.

1. Получить сертификат от вашего CA

Указываем URL для получения сертификата:

set security pki ca-profile tls-syslog enrollment url http://your-ca-server/certsrv

Получаем сертификат:

request security pki ca-certificate enroll ca-profile tls-syslog

Сертификат будет автоматически сохранён и использован.

2. Скачать уже готовый сертификат на устройство (например, через SCP)

Далее загружаем сертификат:

request security pki ca-certificate load ca-profile tls-syslog filename /var/tmp/cert_ca.pem

Проверяем, что сертификат был загружен:

show security pki ca-certificate

LSYS: root-logical-system
CA profile: tls-syslog
Certificate identifier: tls-syslog
Issued to: Okko CA Certificate, Issued by: C = RU, ST = Saint-Petersburg, O = Okko, OU = Technical Department, CN = Okko CA Certificate
Validity:
Not before: 09-11-2025 14:32 UTC
Not after: 09- 9-2035 14:32 UTC
Public key algorithm: ecdsaEncryption(384 bits)
Keypair Location: Keypair generated locally

🔑 Шаг 2: Создание ca-группы и ca-профиля

set security pki ca-profile tls-syslog ca-identity tls-syslog
set security pki ca-profile tls-syslog revocation-check disable
set security pki trusted-ca-group tlsdetails ca-profiles tls-syslog

🔑 Шаг 3: Настройка syslog с TLS

10.15.24.37 - Syslog-сервер

set system syslog host 10.15.24.37 any any
set system syslog host 10.15.24.37 interactive-commands any
set system syslog host 10.15.24.37 port 1515
set system syslog host 10.15.24.37 source-address 10.1.25.130
set system syslog host 10.15.24.37 transport tls
set system syslog host 10.15.24.37 tlsdetails trusted-ca-group tls-syslog ca-profiles tls-syslog
set system syslog host 10.15.24.37 structured-data
set system syslog file interactive-commands interactive-commands any
set system syslog file messages any any
set system syslog file messages authorization info
set system syslog source-address 10.15.25.130

Можно проверять логи на Syslog-сервере.

Документация Juniper: Syslog over TLS.

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