bpftool prog profile: кто съедает CPU внутри BPFBPF-программы могут работать в сетевом пути тысячи и миллионы раз в секунду.
Поэтому проблема иногда выглядит странно:
CPU → 100%
приложение → почти не грузит
network traffic → высокий
Смотреть только на процессы в
top здесь недостаточно.У
bpftool есть режим профилирования конкретной BPF-программы:bpftool prog show
Находим нужную программу и получаем её ID:
123: xdp name firewall
После этого:
bpftool prog profile id 123
Можно получить статистику выполнения программы и понять, сколько процессорного времени она реально потребляет.
Почему это полезно?
Допустим, на сервере стоит XDP-фильтр. Он должен быстро отбрасывать мусорный трафик, но внутри программы появилась сложная логика: несколько map lookup, дополнительные проверки и работа с большим количеством пакетов.
При небольшом трафике это незаметно.
А при 5 млн PPS:
5 000 000 packets/sec
×
несколько дополнительных операций
↓
существенная нагрузка CPU
И в итоге администратор видит просто высокий
softirq/CPU usage, хотя источник нагрузки находится внутри BPF-программы.Это особенно интересно тем, что BPF выполняется не как отдельный процесс, который можно найти в
top.То есть искать:
top
ps aux
в этом случае недостаточно.
Логика диагностики получается другой:
CPU ↑
↓
network/softirq ↑
↓
BPF подозрителен
↓
bpftool prog show
↓
bpftool prog profile
И это уже позволяет искать не «какой процесс грузит CPU», а какая программа внутри kernel datapath тратит процессорное время.
N.A.
👍3❤2
RD и RT - почему это не одно и то же
В MPLS L3VPN есть две сущности, которые часто смешивают:
RD (Route Distinguisher) и RT (Route Target).
Обе выглядят как что-то вроде:
Но делают они совершенно разные вещи.
Представим двух клиентов:
Для обычного BGP это один и тот же IPv4-префикс.
RD добавляет к нему уникальность:
У второго клиента:
Теперь PE-маршрутизатор может хранить оба маршрута, несмотря на одинаковый IPv4 prefix.
Но RD не решает, кому этот маршрут можно импортировать.
Для этого используется RT.
Например:
А у другой VRF:
Получается:
То есть логика примерно такая:
И здесь есть важный момент.
Одинаковый RD не означает, что VRF должны видеть маршруты друг друга.
И наоборот: одинаковый RT не означает, что маршруты имеют одинаковый RD.
Их можно даже специально сделать разными:
Маршруты будут различаться в VPN control plane благодаря RD, а политика распространения между VRF будет определяться RT.
Поэтому RD и RT лучше запомнить не как «две похожие цифры», а как две разные функции:
RD - идентичность VPN-маршрута. RT - политика его распространения.
N.A.
В MPLS L3VPN есть две сущности, которые часто смешивают:
RD (Route Distinguisher) и RT (Route Target).
Обе выглядят как что-то вроде:
65000:100
Но делают они совершенно разные вещи.
Представим двух клиентов:
Customer A
10.10.10.0/24
Customer B
10.10.10.0/24
Для обычного BGP это один и тот же IPv4-префикс.
RD добавляет к нему уникальность:
RD 65000:100 + 10.10.10.0/24
↓
65000:100:10.10.10.0/24
У второго клиента:
65000:200:10.10.10.0/24
Теперь PE-маршрутизатор может хранить оба маршрута, несмотря на одинаковый IPv4 prefix.
Но RD не решает, кому этот маршрут можно импортировать.
Для этого используется RT.
Например:
VRF-A
export RT 65000:100
import RT 65000:200
А у другой VRF:
VRF-B
export RT 65000:200
import RT 65000:100
Получается:
VRF-A
│
│ export RT 65000:100
↓
MP-BGP
↓
│ import RT 65000:100
↓
VRF-B
То есть логика примерно такая:
RD → «Как сделать этот маршрут уникальным?»
RT → «В какие VRF этот маршрут можно импортировать?»
И здесь есть важный момент.
Одинаковый RD не означает, что VRF должны видеть маршруты друг друга.
И наоборот: одинаковый RT не означает, что маршруты имеют одинаковый RD.
Их можно даже специально сделать разными:
VRF-A
RD: 65000:101
RT export: 65000:100
VRF-B
RD: 65000:202
RT import: 65000:100
Маршруты будут различаться в VPN control plane благодаря RD, а политика распространения между VRF будет определяться RT.
Поэтому RD и RT лучше запомнить не как «две похожие цифры», а как две разные функции:
RD - идентичность VPN-маршрута. RT - политика его распространения.
N.A.
👍7❤2
show spanning-tree: почему STP блокирует порт
В Cisco-подобных коммутаторах команда:
показывает не просто «какой порт заблокирован». Она позволяет понять, почему именно этот порт проиграл выбор пути.
Например:
На первый взгляд кажется:
Gi1/0/2 - резервный линк, всё нормально.
Но STP выбирает не «основной и резервный кабель». Каждый switch сравнивает BPDU и стоимость пути до Root Bridge.
Если два пути имеют одинаковый cost, в дело идут дополнительные tie-breaker:
Поэтому после замены коммутатора или изменения priority один и тот же физический линк вполне может внезапно стать
Особенно полезно смотреть:
Там можно увидеть изменения topology и понять, почему STP пересчитал дерево, а не просто констатировать, что порт заблокирован.
N.A.
В Cisco-подобных коммутаторах команда:
show spanning-treeпоказывает не просто «какой порт заблокирован». Она позволяет понять, почему именно этот порт проиграл выбор пути.
Например:
VLAN 10
Root ID Priority 24586
Address 0011.2233.4455
Interface Role Sts Cost
Gi1/0/1 Root FWD 4
Gi1/0/2 Altn BLK 4
На первый взгляд кажется:
Gi1/0/2 - резервный линк, всё нормально.
Но STP выбирает не «основной и резервный кабель». Каждый switch сравнивает BPDU и стоимость пути до Root Bridge.
Если два пути имеют одинаковый cost, в дело идут дополнительные tie-breaker:
Root Bridge
↓
Root Path Cost
↓
Sender Bridge ID
↓
Sender Port ID
Поэтому после замены коммутатора или изменения priority один и тот же физический линк вполне может внезапно стать
BLK.Особенно полезно смотреть:
show spanning-tree vlan 10 detail
Там можно увидеть изменения topology и понять, почему STP пересчитал дерево, а не просто констатировать, что порт заблокирован.
N.A.
👍5
TI-LFA: fast reroute без SPF
Обычный IGP при отказе линка должен сначала понять, что топология изменилась, затем пересчитать SPF и установить новый маршрут.
Это занимает время.
TI-LFA работает иначе: резервный путь вычисляется заранее.
Допустим, основной путь:
R1 знает, что если линк
При отказе R2 не ждёт полноценного SPF для восстановления forwarding. Он использует заранее рассчитанный backup path.
В SR-сетях этот путь можно выразить через Segment List:
И пакет сразу получает альтернативный forwarding path.
Получается:
Самая интересная часть здесь в том, что TI-LFA не пытается быстрее пересчитать всю сеть.
Он старается сделать так, чтобы при отказе маршрутизатору вообще не пришлось ждать этого пересчёта для уже идущего трафика.
Поэтому TI-LFA особенно полезен в сетях, где несколько десятков миллисекунд уже имеют значение: транспорт, датацентры, backbone и другие чувствительные к потере трафика сервисы.
N.A.
Обычный IGP при отказе линка должен сначала понять, что топология изменилась, затем пересчитать SPF и установить новый маршрут.
Это занимает время.
TI-LFA работает иначе: резервный путь вычисляется заранее.
Допустим, основной путь:
R1 ── R2 ── R4
│
X
│
R3 ── R4
R1 знает, что если линк
R2-R4 пропадёт, трафик можно отправить через R3.При отказе R2 не ждёт полноценного SPF для восстановления forwarding. Он использует заранее рассчитанный backup path.
В SR-сетях этот путь можно выразить через Segment List:
R1 → [SID R3] → R4
И пакет сразу получает альтернативный forwarding path.
Получается:
обычный convergence:
link down
↓
LSA/LSP
↓
SPF
↓
новый маршрут
↓
FIB update
↓
forwarding
TI-LFA:
link down
↓
локальная защита
↓
backup path
↓
forwarding
Самая интересная часть здесь в том, что TI-LFA не пытается быстрее пересчитать всю сеть.
Он старается сделать так, чтобы при отказе маршрутизатору вообще не пришлось ждать этого пересчёта для уже идущего трафика.
Поэтому TI-LFA особенно полезен в сетях, где несколько десятков миллисекунд уже имеют значение: транспорт, датацентры, backbone и другие чувствительные к потере трафика сервисы.
N.A.
👍2❤1
SRv6 uSID: зачем нужны короткие SID
В обычном SRv6 маршрут можно описать последовательностью Segment ID:
Каждый SID занимает IPv6-адрес, поэтому длинный путь быстро раздувает SRH.
Например:
Чем больше сегментов, тем больше служебных данных приходится тащить вместе с пакетом.
uSID (micro-SID) решает эту проблему другим способом.
Вместо того чтобы использовать полноценный 128-битный SID для каждого шага, несколько коротких инструкций помещаются внутрь одного IPv6-адреса:
Условно:
Когда пакет проходит через очередной SRv6 node, текущий uSID обрабатывается, а следующий становится активным.
В результате тот же логический путь:
можно закодировать компактнее, чем последовательностью отдельных 128-битных SID.
Зачем это вообще нужно?
Потому что SRv6 использует IPv6-адреса для инструкций. Если построить длинный traffic-engineered path и записать каждый шаг отдельным SID, служебная часть пакета начинает заметно расти.
uSID позволяет уплотнить несколько инструкций в один SID-контейнер, сохраняя модель SRv6.
Условно:
То есть uSID - это не новый routing protocol и не «более быстрый IPv6».
Это способ сделать SRv6-путь компактнее, когда количество инструкций становится большим.
N.A.
В обычном SRv6 маршрут можно описать последовательностью Segment ID:
R1 → R5 → R8 → R12
Каждый SID занимает IPv6-адрес, поэтому длинный путь быстро раздувает SRH.
Например:
SID 1
SID 2
SID 3
SID 4
SID 5
...
Чем больше сегментов, тем больше служебных данных приходится тащить вместе с пакетом.
uSID (micro-SID) решает эту проблему другим способом.
Вместо того чтобы использовать полноценный 128-битный SID для каждого шага, несколько коротких инструкций помещаются внутрь одного IPv6-адреса:
IPv6 address
┌──────────────┬───────────────────────────────┐
│ locator │ uSID │ uSID │ uSID │ uSID │
└──────────────┴───────────────────────────────┘
Условно:
LOC:R1 | R5 | R8 | R12
Когда пакет проходит через очередной SRv6 node, текущий uSID обрабатывается, а следующий становится активным.
В результате тот же логический путь:
R1 → R5 → R8 → R12
можно закодировать компактнее, чем последовательностью отдельных 128-битных SID.
Зачем это вообще нужно?
Потому что SRv6 использует IPv6-адреса для инструкций. Если построить длинный traffic-engineered path и записать каждый шаг отдельным SID, служебная часть пакета начинает заметно расти.
uSID позволяет уплотнить несколько инструкций в один SID-контейнер, сохраняя модель SRv6.
Условно:
обычный SRv6:[SID][SID][SID][SID][SID]
uSID:[Locator | uSID | uSID | uSID | uSID]
То есть uSID - это не новый routing protocol и не «более быстрый IPv6».
Это способ сделать SRv6-путь компактнее, когда количество инструкций становится большим.
N.A.
👍3❤1
gNMI vs SNMP polling
Представим сеть из сотни коммутаторов. Нужно следить за загрузкой интерфейсов.
Классический вариант - SNMP polling:
Сервер сам регулярно опрашивает устройства.
Например, раз в 60 секунд.
Проблема появляется, когда нужны более частые данные.
При интервале 60 секунд вы можете не увидеть короткий всплеск:
Через минуту SNMP получит уже совершенно нормальное значение.
gNMI может работать иначе - через streaming telemetry.
Устройство устанавливает долгоживущую сессию с collector’ом и само отправляет изменения или значения с заданным интервалом:
Например, можно подписаться на конкретный путь:
И получать обновления без постоянного
Главное отличие:
Но gNMI не означает автоматически «данные всегда быстрее и лучше».
Если настроить telemetry слишком агрессивно, сотни устройств начнут постоянно отправлять большое количество данных. Collector, сеть и сами устройства тоже получают нагрузку.
Поэтому инженерная задача здесь не просто заменить SNMP на gNMI, а выбрать правильную модель:
SNMP отлично подходит для классического мониторинга и огромного количества уже существующей инфраструктуры.
gNMI интереснее там, где нужно получать более детальное состояние сети практически в реальном времени, особенно при автоматизации и работе с YANG-моделями.
N.A.
Представим сеть из сотни коммутаторов. Нужно следить за загрузкой интерфейсов.
Классический вариант - SNMP polling:
NMS ──→ switch
"дай counters"
NMS ──→ switch
"дай counters"
NMS ──→ switch
"дай counters"
Сервер сам регулярно опрашивает устройства.
Например, раз в 60 секунд.
Проблема появляется, когда нужны более частые данные.
При интервале 60 секунд вы можете не увидеть короткий всплеск:
60 sec ──────────────────────────
↑
burst
Через минуту SNMP получит уже совершенно нормальное значение.
gNMI может работать иначе - через streaming telemetry.
Устройство устанавливает долгоживущую сессию с collector’ом и само отправляет изменения или значения с заданным интервалом:
switch
│
├── update
├── update
├── update
└── update
↓
collector
Например, можно подписаться на конкретный путь:
/interfaces/interface[name=Ethernet1]/state/counters
И получать обновления без постоянного
GET со стороны collector.Главное отличие:
SNMP polling
NMS → GET → device
NMS → GET → device
NMS → GET → device
gNMI telemetry
device ─────────→ collector
device ─────────→ collector
device ─────────→ collector
Но gNMI не означает автоматически «данные всегда быстрее и лучше».
Если настроить telemetry слишком агрессивно, сотни устройств начнут постоянно отправлять большое количество данных. Collector, сеть и сами устройства тоже получают нагрузку.
Поэтому инженерная задача здесь не просто заменить SNMP на gNMI, а выбрать правильную модель:
редкие counters
↓
polling может быть достаточен
частые изменения состояния
↓
streaming telemetry
критические события
↓
ON_CHANGE / event-driven
SNMP отлично подходит для классического мониторинга и огромного количества уже существующей инфраструктуры.
gNMI интереснее там, где нужно получать более детальное состояние сети практически в реальном времени, особенно при автоматизации и работе с YANG-моделями.
N.A.
👍4
RIB vs FIB divergence в high-end роутерах
В routing table (RIB) маршрут отображается корректно: next-hop есть, метрики нормальные, протокол сходится.
Но data-plane не использует этот маршрут - пакеты не уходят, и кажется, что сеть «работает частично».
Причины чаще всего связаны с ограничениями ASIC, рекурсивным разрешением next-hop или проблемами с adjacency.
Для диагностики сначала проверяем, как маршрут запрограммирован в FIB/CEF:
Если next-hop не разрешается через adjacency, пакеты не будут пересылаться:
На high-end платформах полезно проверить hardware table и возможные дропы:
Решение обычно включает корректировку рекурсивного next-hop, перераспределение нагрузки по ASIC, а иногда - оптимизацию L3 adjacency и проверку максимального количества маршрутов/entry в FIB для high-end маршрутизаторов.
N.A.
В routing table (RIB) маршрут отображается корректно: next-hop есть, метрики нормальные, протокол сходится.
Но data-plane не использует этот маршрут - пакеты не уходят, и кажется, что сеть «работает частично».
Причины чаще всего связаны с ограничениями ASIC, рекурсивным разрешением next-hop или проблемами с adjacency.
Для диагностики сначала проверяем, как маршрут запрограммирован в FIB/CEF:
show ip cef <prefix> detail
Если next-hop не разрешается через adjacency, пакеты не будут пересылаться:
show adjacency detail
show ip arp <next-hop>
На high-end платформах полезно проверить hardware table и возможные дропы:
show platform hardware qfp active feature cef drop
Решение обычно включает корректировку рекурсивного next-hop, перераспределение нагрузки по ASIC, а иногда - оптимизацию L3 adjacency и проверку максимального количества маршрутов/entry в FIB для high-end маршрутизаторов.
N.A.
👍4
MAB: когда MAC заменяет 802.1X
802.1X предполагает, что устройство умеет пройти аутентификацию через EAP.
Но что делать с устройством вроде принтера, IP-телефона или камеры, где полноценного 802.1X может не быть?
Для этого используют MAB - MAC Authentication Bypass.
Схема выглядит примерно так:
Switch узнаёт MAC устройства и отправляет его на RADIUS как идентификатор:
RADIUS проверяет MAC по своей базе и может вернуть, например, VLAN:
После этого порт получает доступ в соответствующий VLAN.
Но MAB - это не полноценная замена 802.1X по уровню безопасности.
MAC-адрес не является секретом. Его можно узнать и подменить.
Поэтому типичная политика выглядит так:
Например:
Поэтому MAB обычно используют как fallback для устройств, которые физически не могут пройти 802.1X, а не как более простой способ аутентификации всех клиентов.
🔥 И важный момент: MAB не означает, что switch «доверяет MAC». Он лишь использует MAC как идентификатор, который передаётся AAA-системе для принятия решения о доступе.
N.A.
802.1X предполагает, что устройство умеет пройти аутентификацию через EAP.
Но что делать с устройством вроде принтера, IP-телефона или камеры, где полноценного 802.1X может не быть?
Для этого используют MAB - MAC Authentication Bypass.
Схема выглядит примерно так:
Устройство
│
│ MAC
↓
Access Switch
│
│ RADIUS
↓
AAA
Switch узнаёт MAC устройства и отправляет его на RADIUS как идентификатор:
Calling-Station-Id = AA:BB:CC:DD:EE:FF
RADIUS проверяет MAC по своей базе и может вернуть, например, VLAN:
Access-Accept
↓
VLAN 30
После этого порт получает доступ в соответствующий VLAN.
Но MAB - это не полноценная замена 802.1X по уровню безопасности.
MAC-адрес не является секретом. Его можно узнать и подменить.
Поэтому типичная политика выглядит так:
802.1X
↓
если устройство умеет → нормальная аутентификация
нет ответа 802.1X
↓
MAB
↓
проверка MAC
Например:
Ноутбук
↓
802.1X → пользователь/сертификат → VLAN 20
IP-телефон
↓
802.1X не поддерживает
↓
MAB → MAC известен RADIUS → VLAN 30
Неизвестное устройство
↓
MAB → Access-Reject
Поэтому MAB обычно используют как fallback для устройств, которые физически не могут пройти 802.1X, а не как более простой способ аутентификации всех клиентов.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Loop Guard vs Root Guard: в чем разница
Оба механизма относятся к STP, но защищают от совершенно разных аварий.
Loop Guard нужен, когда порт перестал получать BPDU, хотя раньше получал их.
Например, между двумя коммутаторами есть STP-линк:
SW2 должен получать BPDU и держать порт в blocking/discarding. Если BPDU внезапно перестали доходить из-за односторонней проблемы линка, SW2 может решить, что путь свободен, и перевести порт в forwarding.
Получается L2-петля.
Loop Guard обнаруживает потерю ожидаемых BPDU и не дает порту перейти в forwarding:
Root Guard решает другую проблему.
Допустим, ваш коммутатор уже является Root Bridge:
Кто-то подключает новый коммутатор с более низким Bridge ID:
SW4 начинает отправлять superior BPDU. Без защиты STP может перестроить дерево и выбрать SW4 корневым.
Root Guard на порту SW2 не позволяет этому случиться. При получении superior BPDU порт уходит в root-inconsistent и не становится путем к новому Root Bridge.
То есть запомнить можно так:
И ещё важный момент: BPDU Guard - это третий сценарий.
Он обычно ставится на access/edge-портах. Если туда вообще приходит BPDU, порт блокируется, потому что за ним не должен находиться STP-коммутатор.
Получается:
Разница не в том, что один «сильнее» другого. Они реагируют на три разные аномалии STP.
N.A.
Оба механизма относятся к STP, но защищают от совершенно разных аварий.
Loop Guard нужен, когда порт перестал получать BPDU, хотя раньше получал их.
Например, между двумя коммутаторами есть STP-линк:
SW1 ───────── SW2
BPDU →
SW2 должен получать BPDU и держать порт в blocking/discarding. Если BPDU внезапно перестали доходить из-за односторонней проблемы линка, SW2 может решить, что путь свободен, и перевести порт в forwarding.
Получается L2-петля.
Loop Guard обнаруживает потерю ожидаемых BPDU и не дает порту перейти в forwarding:
BPDU пропали
↓
Loop Guard
↓
порт остаётся в loop-inconsistent
Root Guard решает другую проблему.
Допустим, ваш коммутатор уже является Root Bridge:
ROOT
SW1
/ \
SW2 SW3
Кто-то подключает новый коммутатор с более низким Bridge ID:
SW1 ─── SW2 ─── SW4
↑
новый Root претендент
SW4 начинает отправлять superior BPDU. Без защиты STP может перестроить дерево и выбрать SW4 корневым.
Root Guard на порту SW2 не позволяет этому случиться. При получении superior BPDU порт уходит в root-inconsistent и не становится путем к новому Root Bridge.
То есть запомнить можно так:
Loop Guard
→ BPDU неожиданно исчезли
→ защищает от L2-петли
Root Guard
→ пришёл superior BPDU
→ защищает позицию Root Bridge
И ещё важный момент: BPDU Guard - это третий сценарий.
Он обычно ставится на access/edge-портах. Если туда вообще приходит BPDU, порт блокируется, потому что за ним не должен находиться STP-коммутатор.
Получается:
BPDU пришёл туда, где его быть не должно
→ BPDU Guard
BPDU перестал приходить туда, где он должен быть
→ Loop Guard
Пришёл superior BPDU и пытается изменить Root
→ Root Guard
Разница не в том, что один «сильнее» другого. Они реагируют на три разные аномалии STP.
N.A.
👍7
9 октября в Москве пройдет СисАдмин 2026 — большая конференция для системных администраторов, ИТ-менеджеров, инженеров и специалистов по поддержке инфраструктуры.
📍 Москва, кластер «Ломоносов»
📅 9 октября 2026
🗣 Офлайн-формат, один день
Участие бесплатное, нужно только зарегистрироваться на https://tglink.io/bf34972f25c2f4?erid=2W5zFHae1UD.
О чем конференция
✔️ Управление рабочими местами на Windows, Linux, macOS;
✔️ MDM/UEM/EMM;
✔️ Администрирование техники Apple;
✔️ Управление ИТ-инфраструктурой и мониторинг;
✔️ Информационная безопасность для системных администраторов;
✔️ Миграция на Linux;
✔️ Организация работы ИТ-отдела и поддержки и многое другое.
📌 СисАдмин 2026 — это более 700 участников, ИТ-выставка, насыщенная программа, неформальное общение и квиз с призами.
Вы можете не только прийти как гость, но и бесплатно выступить с докладом. Для этого оставьте заявку на сайте.
До встречи на СисАдмин 🙌
#реклама
О рекламодателе
📍 Москва, кластер «Ломоносов»
📅 9 октября 2026
🗣 Офлайн-формат, один день
Участие бесплатное, нужно только зарегистрироваться на https://tglink.io/bf34972f25c2f4?erid=2W5zFHae1UD.
О чем конференция
✔️ Управление рабочими местами на Windows, Linux, macOS;
✔️ MDM/UEM/EMM;
✔️ Администрирование техники Apple;
✔️ Управление ИТ-инфраструктурой и мониторинг;
✔️ Информационная безопасность для системных администраторов;
✔️ Миграция на Linux;
✔️ Организация работы ИТ-отдела и поддержки и многое другое.
📌 СисАдмин 2026 — это более 700 участников, ИТ-выставка, насыщенная программа, неформальное общение и квиз с призами.
Вы можете не только прийти как гость, но и бесплатно выступить с докладом. Для этого оставьте заявку на сайте.
До встречи на СисАдмин 🙌
#реклама
О рекламодателе
👍2👎1
MPLS PHP: зачем предпоследний LSR снимает label
В MPLS пакет обычно идет через несколько LSR:
PE1 добавляет label:
На P1 и P2 не нужно заглядывать в IP-заголовок. Они работают по label: смотрят в LFIB, меняют label и отправляют пакет дальше.
Но возникает вопрос: зачем заставлять последний P-router делать ещё одну операцию?
Для этого используется PHP - Penultimate Hop Popping.
P2, то есть предпоследний LSR, заранее знает, что следующий hop — PE2. Вместо обычного swap:
он снимает label полностью:
PE2 получает уже обычный IP-пакет и не тратит ресурсы на удаление последнего MPLS label перед дальнейшей обработкой.
Обычно для этого используется специальный Implicit Null label. Он фактически означает: «на следующем hop label уже не нужен».
Получается такая цепочка:
Почему именно предпоследний, а не последний?
Потому что если последний PE всё равно должен обработать пакет дальше как IP, нет особого смысла сначала передавать ему MPLS label, чтобы он тут же его снял.
PHP переносит эту работу на предыдущий LSR и оставляет PE уже готовый к обычной обработке пакета.
В итоге путь выглядит так:
Именно поэтому в MPLS часто можно увидеть: на предпоследнем LSR label уже исчез, хотя пакет ещё не дошёл до конечного PE.
N.A.
В MPLS пакет обычно идет через несколько LSR:
PE1 → P1 → P2 → PE2
PE1 добавляет label:
IP → [Label 100] → P1 → P2 → PE2
На P1 и P2 не нужно заглядывать в IP-заголовок. Они работают по label: смотрят в LFIB, меняют label и отправляют пакет дальше.
Но возникает вопрос: зачем заставлять последний P-router делать ещё одну операцию?
Для этого используется PHP - Penultimate Hop Popping.
P2, то есть предпоследний LSR, заранее знает, что следующий hop — PE2. Вместо обычного swap:
[Label 100]
↓
[Label 200]
он снимает label полностью:
[Label 100]
↓
IP packet
↓
PE2
PE2 получает уже обычный IP-пакет и не тратит ресурсы на удаление последнего MPLS label перед дальнейшей обработкой.
Обычно для этого используется специальный Implicit Null label. Он фактически означает: «на следующем hop label уже не нужен».
Получается такая цепочка:
PE1 P1 P2 PE2
│ │ │ │
│ Label 100 │ Label 200 │ │
├───────────►├──────────►├───────────►│
│ │ │ IP │
│ │ │ без label │
Почему именно предпоследний, а не последний?
Потому что если последний PE всё равно должен обработать пакет дальше как IP, нет особого смысла сначала передавать ему MPLS label, чтобы он тут же его снял.
PHP переносит эту работу на предыдущий LSR и оставляет PE уже готовый к обычной обработке пакета.
В итоге путь выглядит так:
Ingress PE → Label switching → PHP → Egress PE
Именно поэтому в MPLS часто можно увидеть: на предпоследнем LSR label уже исчез, хотя пакет ещё не дошёл до конечного PE.
N.A.
❤2👍2
DSCP remarking: где пакет может потерять свой приоритет
DSCP хранится прямо в IP-заголовке и используется устройствами сети для выбора очереди и политики обработки.
Например, приложение отправило пакет с:
На первом маршрутизаторе он попал в priority queue.
Но дальше значение может измениться:
Это называется DSCP remarking - устройство переписывает значение DSCP.
Причин может быть несколько.
Например, на границе сети оператор разрешает клиенту использовать только определённые классы:
Или коммутатор доверяет DSCP только на uplink, а на access-портах переписывает его:
Ещё вариант - политика QoS на WAN. Перед отправкой трафика в другой сегмент сеть может изменить маркировку, чтобы она соответствовала локальной QoS-модели.
Важно: изменение DSCP не меняет сам пакет или приложение. Меняется только поле, по которому следующие устройства принимают решения о QoS.
Поэтому при проблемах с приоритетным трафиком недостаточно посмотреть DSCP на сервере:
Это ещё не означает, что приложение отправляло DSCP 0.
Он мог быть изменён где-то по пути:
Если QoS внезапно перестал работать, полезно проверять DSCP на разных участках пути и искать место, где:
Именно там находится политика, которая изменила классификацию пакета.
N.A.
DSCP хранится прямо в IP-заголовке и используется устройствами сети для выбора очереди и политики обработки.
Например, приложение отправило пакет с:
DSCP = EF (46)
На первом маршрутизаторе он попал в priority queue.
Но дальше значение может измениться:
Host
↓
Router 1 DSCP 46
↓
Router 2 DSCP 8
↓
Router 3 DSCP 8
↓
Server
Это называется DSCP remarking - устройство переписывает значение DSCP.
Причин может быть несколько.
Например, на границе сети оператор разрешает клиенту использовать только определённые классы:
DSCP 46 → DSCP 10
DSCP 34 → DSCP 8
остальные → DSCP 0
Или коммутатор доверяет DSCP только на uplink, а на access-портах переписывает его:
PC → Switch
DSCP 46
↓
policy-map
↓
DSCP 0
Ещё вариант - политика QoS на WAN. Перед отправкой трафика в другой сегмент сеть может изменить маркировку, чтобы она соответствовала локальной QoS-модели.
Важно: изменение DSCP не меняет сам пакет или приложение. Меняется только поле, по которому следующие устройства принимают решения о QoS.
Поэтому при проблемах с приоритетным трафиком недостаточно посмотреть DSCP на сервере:
tcpdump → DSCP 0
Это ещё не означает, что приложение отправляло DSCP 0.
Он мог быть изменён где-то по пути:
Host
↓
Access switch
↓
Distribution
↓
WAN router
↓
Provider
↓
Server
Если QoS внезапно перестал работать, полезно проверять DSCP на разных участках пути и искать место, где:
46 → 46 → 46 → 0
↑
remarking
Именно там находится политика, которая изменила классификацию пакета.
N.A.
👍3