Я пытаюсь поймать и обработать (в стороннем аналитическом приложении) пакеты DHCP из сеанса ERSPAN, но не могу этого сделать. Есть интерфейс PHY, который получает трафик ERSPAN, и интерфейс типа erspan для получения декапсулированных пакетов (ip link add inspan type erspan seq key 10 local 10.171.165.65 erspan_ver 1)
Я использую nftables для сопоставления и обработки и самое простое правило:
table netdev inspan {
chain catch {
type filter hook ingress device "inspan" priority filter ; policy accept;
iifname "inspan" udp dport 67 counter meta nftrace set 1 accept
}
}
показывает ТОЛЬКО широковещательные пакеты (ip daddr 255.255.255.255):
# nft monitor trace
trace id 6fd1132b inet filter input packet: iif "inspan" ether saddr 00:1a:64:33:8d:fa ether daddr ff:ff:ff:ff:ff:ff ip saddr 0.0.0.0 ip daddr 255.255.255.255 ip dscp cs0 ip ecn not-ect ip ttl 128 ip id 20986 ip protocol udp ip length 328 udp sport 68 udp dport 67 udp length 308 @th,64,96 0x1010600d5d272d200000000
trace id 6fd1132b inet filter input rule iifname "inspan" udp dport 67 counter packets 0 bytes 0 meta nftrace set 1 accept (verdict accept)
в то время как ВСЕ одноадресные пакеты (присутствующие в инкапсулированном трафике ERSPAN на PHY) отсутствуют в этой трассировке, как будто они были потреблены (и потеряны) где-то между PHY и inspan.
Обратите внимание, что ВСЕ ОСТАЛЬНОЕ отображается в inspan (при просмотре с помощью tcpdump) - любой другой TCP, UDP и т. д., КРОМЕ DHCP uincast, и это не зависит от настроек promisc всех интерфейсов в цепочке.
Система выглядит чистой. Это Ubuntu 22.04, но без DHCP-сервера, DHCP-клиентов, netplan, ifupdown и других связанных с DHCP вещей; systemd-networkd полностью отключен (для целей тестирования я настраиваю сеть вручную).
Есть идеи, где теряются одноадресные пакеты DHCP? Мне кажется, что-то в ядре ловит эти пакеты и отбрасывает их, поскольку они не предназначены для этого хоста.
Спасибо.