📝 История OSPF: как военные потеряли контроль над маршрутизацией

Сегодня разберём как академики отобрали у армии протокол который держит корпоративные сети до сих пор.

🟣Конец 80-х, ARPANET передаётся гражданским и старый RIP начинает трещать по швам. RIP считал маршруты в хопах и не знал о скорости каналов, при больших сетях сходился минутами и не умел в суммаризацию. IETF собрала рабочую группу и поставила задачу: написать link-state протокол который масштабируется, быстро сходится и работает в больших иерархических сетях.

🟣Джон Мой написал первую спецификацию OSPF в 1988 году практически в одиночку. Протокол строился на алгоритме Дейкстры - каждый роутер собирает полную карту зоны через LSA-пакеты и сам считает кратчайшие пути. Никакого доверия соседям, никаких слухов - только математика на основе полных данных о топологии.

🟣Иерархия зон решила проблему масштаба: backbone area 0 связывает все остальные зоны, внутри каждой зоны роутеры обмениваются детальной топологией, между зонами ходят только суммарные маршруты. Это позволило строить сети с тысячами роутеров без взрыва таблиц маршрутизации.

🟣Почему OSPF до сих пор везде: он появился в нужное время когда корпоративные сети резко выросли, был открытым стандартом в отличие от проприетарного EIGRP от Cisco, и решал реальные проблемы которые RIP не мог. Тридцать лет спустя практически любая корпоративная сеть крупнее пары роутеров работает на OSPF или IS-IS который решает ту же задачу тем же способом.

🟣Интересная деталь: Джон Мой позже публично рассказывал что писал первую версию спецификации страдая от депрессии и что работа над протоколом буквально спасла его в тот период. Человек, который держит корпоративный интернет - это история не про гениев в гараже, а про обычного инженера с дедлайном и личными проблемами.

Серверная Админа | Бункер Хакера | #OSPF

👋 Привет, сетевой друг!

Сегодня разберу протокол RSTP, который заменил STP и убрал самую бесучую его черту: ожидание по 30-50 секунд при любом изменении топологии.

🟣Зачем он: дефолтный STP сходится медленно, потому что ждёт таймеры - Forward Delay, Max Age. RSTP (Rapid Spanning Tree Protocol, 802.1w) убирает зависимость от таймеров и договаривается с соседями напрямую через механизм proposal/agreement. Сходимость падает с 30-50 секунд до 1-2.

🟣Как работает: вместо пассивного ожидания таймеров порт отправляет proposal соседу, тот немедленно отвечает agreement и порт переходит в forwarding.

🟣Роли портов изменились: в STP было два состояния, в RSTP три роли: Root Port (путь к корню), Designated Port (лучший порт на сегменте) и Alternate Port (резервный, аналог Blocking в STP). Alternate Port мгновенно становится Root Port при падении основного пути.

🟣Настройка на Cisco:

spanning-tree mode rapid-pvst

! Назначаем приоритет корневого свитча
spanning-tree vlan 10 priority 4096
spanning-tree vlan 20 priority 4096

! PortFast для портов к хостам - сразу в forwarding
interface GigabitEthernet0/1
 spanning-tree portfast
 spanning-tree bpduguard enable

🟣BPDU Guard на портах к хостам обязателен: если кто-то подключит свитч туда где должен быть только хост и начнёт слать BPDU - порт немедленно уйдёт в err-disabled:

! Глобально для всех portfast-портов
spanning-tree portfast bpduguard default

! Проверяем состояние
show spanning-tree vlan 10
show spanning-tree detail
show spanning-tree inconsistentports

🟣Диагностика когда что-то пошло не так:

debug spanning-tree events
show spanning-tree vlan 10 detail | include port|role|state|cost

Если видите TCN (Topology Change Notification) слишком часто - ищите нестабильный порт или петлю.

Серверная Админа | #RSTP

👨‍💻Серверная Админа | #мем

👋 Привет, сетевой друг!

Продолжим разбирать Primus - тул для обслуживания Windows который не стыдно запустить на рабочей машине. Покажу полезные команды для инструмента.

🟣Очистка временных файлов вручную через PowerShell:

# Пользовательские временные файлы
Remove-Item "$env:TEMP\*" -Recurse -Force -ErrorAction SilentlyContinue

# Системные временные файлы
Remove-Item "C:\Windows\Temp\*" -Recurse -Force -ErrorAction SilentlyContinue

# Кэш Windows Update
Stop-Service wuauserv -Force
Remove-Item "C:\Windows\SoftwareDistribution\Download\*" -Recurse -Force
Start-Service wuauserv

🟣Починка системных файлов - правильный порядок важен:

:: Сначала DISM восстанавливает образ
DISM /Online /Cleanup-Image /RestoreHealth

:: Потом SFC проверяет файлы по восстановленному образу
sfc /scannow

:: Результат SFC смотрим в логе
findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log | tail -50

🟣Сброс сети когда ничего не помогает:

netsh winsock reset
netsh int ip reset
netsh int tcp reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew

После этого обязательна перезагрузка - изменения применяются только после неё.

🟣Бэкап реестра перед любыми изменениями:

$date = Get-Date -Format "yyyy-MM-dd"
$path = "C:\RegBackup\$date"
New-Item -ItemType Directory -Force -Path $path

reg export HKLM\SYSTEM "$path\SYSTEM.reg"
reg export HKLM\SOFTWARE "$path\SOFTWARE.reg"
reg export HKLM\SAM "$path\SAM.reg"

🟣TRIM для SSD и дефрагментация для HDD - одной командой определяет тип диска:

$drives = Get-PhysicalDisk | Select MediaType, DeviceId
foreach ($drive in $drives) {
    if ($drive.MediaType -eq "SSD") {
        Optimize-Volume -DriveLetter C -ReTrim -Verbose
    } else {
        Optimize-Volume -DriveLetter C -Defrag -Verbose
    }
}

Серверная Админа | Zeroday | #Инструмент

👋 Привет, сетевой друг!

Давай расскажу про IP SLA с Object Tracking - как роутер сам принимает решения на основе качества канала, а не просто факта его наличия.

🟣Зачем это: стандартный floating static route переключается только когда интерфейс физически падает. Канал может быть поднят, но пакеты теряться на 40% - роутер об этом не знает. IP SLA меряет реальное качество и track реагирует на деградацию, а не на физическое падение.

🟣Настраиваем SLA который меряет jitter до провайдерского шлюза:

ip sla 1
 udp-jitter 8.8.8.8 5000 num-packets 20 interval 20
 frequency 30
 threshold 100

ip sla schedule 1 life forever start-time now

🟣Создаём track который реагирует на превышение threshold:

track 1 ip sla 1 reachability

track 2 ip sla 1 state
 delay down 10 up 30

delay down 10 up 30 - переключение происходит только если состояние не изменилось 10 секунд вниз или 30 секунд вверх. Убирает флаппинг при нестабильном канале.

🟣Привязываем маршруты к track:

ip route 0.0.0.0 0.0.0.0 10.0.0.1 track 1
ip route 0.0.0.0 0.0.0.0 10.0.0.2 10

Основной маршрут живёт пока track 1 зелёный. Резервный с distance 10 поднимается автоматически при деградации основного канала.

🟣Можно привязать track к интерфейсу напрямую - мастхэв, когда нужно гасить интерфейс при падении SLA:

interface GigabitEthernet0/1
 ip address 10.0.0.1 255.255.255.252
 shutdown track 1

🟣Смотрим состояние:

show ip sla statistics 1
show track 1
show track brief

show ip sla statistics покажет RTT, jitter, процент потерь и количество превышений threshold за последний период.

Серверная Админа | Zeroday | #IPSLA

👋 Привет, сетевой друг!

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

🟣В начале 70-х ARPANET заметно меняется по поведению. Изначально его задумывали как способ удалённого доступа к вычислительным ресурсам, но пользователи почти сразу начали делать другое - общаться. Вместо запуска задач на удалённых машинах сеть превратилась в канал сообщений. Это был первый сигнал: ценность сети, не в CPU, а в людях на концах соединений.

🟣Рэй Томлинсон в 1971 году фактически собрал современную почту из двух разных программ: локальной отправки сообщений и сетевой передачи файлов. И именно там появляется символ @ - простая идея, которая решает сложную проблему: как однозначно указать “пользователь + машина” в распределённой системе. До этого такого универсального адреса просто не существовало.

🟣Дальше происходит взрыв: Email становится главным приложением ARPANET буквально за несколько лет. И важно не то, что появилась почта, а то, что вокруг неё начали формироваться привычки: ответить, переслать, разложить входящие. Интерфейс ещё сырой, но поведение уже узнаваемое - сеть начинает “обрастать UX’ом”.

🟣Параллельно на Гавайях в ALOHAnet делают довольно дерзкую вещь: убирают контроль за средой передачи вообще. Устройства просто говорят в общий эфир, а если столкнулись - повторяют позже. Никаких сложных расписаний, только статистика и случайность. И внезапно это работает достаточно хорошо, чтобы стать основой для будущих моделей доступа к сети.

🟣В Xerox PARC Меткалф берёт эту идею и делает из неё инженерный продукт. Ethernet добавляет простое правило: перед отправкой слушай канал, и если он занят - подожди. Это уже не “хаотичный эфир”, а управляемая общая среда. И именно это превращает локальные сети в что-то стабильное и масштабируемое.

🟣Ирония в том, что Ethernet создавался вообще не как “основа мира сетей”, а как способ связать несколько рабочих станций и принтер. Но архитектура оказалась настолько удачной, что офисная сеть внезапно стала стандартом всей индустрии.

Серверная Админа | Бункер Хакера | #история

👋 Привет, сетевой друг!

Сегодня разберём ещё 5 полезных фишек для Cisco IOS, которые реально экономят время и нервы.

🟣ECN через tc на уровне интерфейса - тонкая настройка вместо глобального sysctl:

tc qdisc show dev eth0

# fq_codel с явным ECN
tc qdisc replace dev eth0 root fq_codel ecn

# Или fq для BBR
tc qdisc replace dev eth0 root fq flow_limit 200 ecn

# Статистика дропов и ECN-меток
tc -s qdisc show dev eth0

fq_codel меряет latency очереди и маркирует пакеты ECN до того как начинает дропать. В отличие от глобального tcp_ecn=1 работает на уровне конкретного интерфейса и не зависит от поддержки на промежуточном оборудовании.

🟣Receive Packet Steering - распределяем обработку входящих пакетов по CPU без аппаратного RSS:

nproc

# Включаем RPS на интерфейсе для всех CPU (4-core = f)
echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus

# RFS — направляем пакеты на тот CPU где живёт приложение
sysctl -w net.core.rps_sock_flow_entries=32768
echo 2048 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt

На однопоточном NIC без аппаратного multiqueue весь входящий трафик обрабатывается одним CPU. RPS разносит нагрузку программно.

🟣tcp_notsent_lowat - контролируем сколько данных накапливается в send buffer не отправленными:

sysctl -w net.ipv4.tcp_notsent_lowat=16384

Без этого при медленном получателе send buffer забивается и приложение блокируется на write() даже когда реально может отправить данные. Критично для HTTP/2 серверов с приоритизацией потоков.

🟣Отключаем GRO на интерфейсах где важна латентность:

ethtool -k eth0 | grep generic-receive

ethtool -K eth0 gro off
ethtool -K eth0 tso off gso off

GRO объединяет входящие пакеты в большие chunks перед передачей в стек - хорошо для throughput, плохо для латентности. На торговых системах и VoIP это принципиально.

🟣ip_local_reserved_ports - резервируем порты которые не должны занимать эфемерные соединения:

sysctl -w net.ipv4.ip_local_port_range="1024 65535"
sysctl -w net.ipv4.ip_local_reserved_ports="8080,8443,9090-9100"

Без резервирования при высоком RPS эфемерное соединение может занять порт на котором должен подняться сервис, и сервис не стартует с EADDRINUSE.

Серверная Админа | Zeroday | #Cisco

👋 Привет, сетевой друг!

Сегодня про OSV.dev - открытую базу уязвимостей и сервис, который проверяет зависимости проекта на известные security-проблемы в open-source.

🟣Что это: OSV (Open Source Vulnerabilities) - база, которая связывает уязвимости не просто с названиями пакетов, а с конкретными версиями. Это важно, потому что одна и та же библиотека может быть уязвима только в диапазоне версий, а не “всегда”.

🟣Как работает: сервис берет зависимости проекта (или контейнер/SBOM) и сопоставляет их с базой уязвимостей. В результате получается точный список: где проблема, в какой версии и что нужно обновить.

🟣Быстрый старт:

# установка
curl -sSfL https://raw.githubusercontent.com/google/osv-scanner/main/install.sh | sh

# проверка проекта
osv-scanner scan .



🟣Полезные сценарии:

# проверка Docker-образа
osv-scanner scan --docker nginx:latest

# проверка SBOM (CycloneDX / SPDX)
osv-scanner scan --sbom sbom.json

# быстрый просмотр конкретной уязвимости
osv-scanner query osv.dev/PYSEC-2023-15



🟣В современных системах 70–90% кода - это зависимости. И чаще всего взламывают не ваш код, а библиотеку, которую вы подключили “по умолчанию”. OSV закрывает именно этот слой риска и хорошо ложится в CI/CD или ручной аудит перед деплоем.

Серверная Админа | Zeroday | #Инструмент

📝 История Spanning Tree: как Ethernet перестал зацикливаться в петлях

Сегодня про базовую боль L2-сетей - петли, которые ломают сеть быстрее, чем любая “сложная” атака.

🟣Как сеть ломалась без STP: в L2 нет понятия “главного пути”. Свитчи просто пересылают кадры дальше, а broadcast вообще обязан уйти во все стороны. Как только появляется петля, один пакет начинает дублироваться и возвращаться обратно. Дальше это уже не трафик, а самовоспроизводящаяся лавина, которая забивает канал и ломает MAC-таблицы.

🟣Почему это не лечится “умнее пересылкой”: проблема не в маршруте, а в самой модели L2. Свитч не знает историю кадра и не отличает “новый” от “копии, пришедшей по кругу”. Поэтому никакая оптимизация пересылки не спасает - нужно убрать циклы как класс.

🟣Что сделал STP на практике: он не “настраивает сеть”, он принудительно убирает из неё часть физических связей, оставляя только структуру без циклов. Остальные линки остаются как резерв, но выключены на уровне пересылки.

🟣Как это выглядит в работе:
• сеть сначала ведёт себя как обычный граф
• потом выбирается точка опоры (root)
• из всех возможных путей остаётся один
• всё остальное “замораживается”, пока не случится обрыв

🟣Неочевидный эффект: резерв в Ethernet существует физически, но логически сеть всегда работает как будто у неё только одно дерево. Это сильно контрастирует с IP-миром, где резерв - это активная часть маршрутизации.

🟣Почему это до сих пор не убрали: потому что базовая модель Ethernet не изменилась. Пока есть L2-домены с широковещанием, петли остаются смертельной проблемой, а STP - самым простым способом не дать им убить сеть.

Серверная Админа | Zeroday | #Spannkingtree

👋 Привет, сетевой друг!

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

🟣Что такое API: ну если совсем грубо - это интерфейс для общения программ друг с другом. Вместо того чтобы инженер заходил в веб-интерфейс и нажимал кнопки вручную, приложение отправляет запрос и получает ответ в структурированном виде.

🟣Например, система мониторинга может сама запросить список интерфейсов у маршрутизатора или создать VLAN без участия человека.

🟣Как работает: чаще всего используется HTTP API. Клиент отправляет запрос на сервер, сервер обрабатывает его и возвращает ответ в формате JSON.

Пример запроса к устройству:

curl -X GET https://router/api/interfaces \
-H "Authorization: Bearer TOKEN"
Ответ:
{
  "interface": "Gi0/1",
  "status": "up",
  "traffic": "124 Mbps"
}



🟣Основные методы API:

GET     - получить данные
POST    - создать объект
PUT     - изменить объект
DELETE  - удалить объект



По такой схеме работают Cisco DNA Center, NetBox, Zabbix, Grafana, облачные платформы и сотни других систем.

🟣Зачем это сетевику: раньше для автоматизации приходилось парсить вывод CLI через Expect или SSH-скрипты. API позволяет получать данные в готовом виде без костылей и риска, что обновление прошивки сломает автоматизацию.

Пример создания VLAN через API:

curl -X POST https://switch/api/vlans \
-H "Authorization: Bearer TOKEN" \
-d '{"id":100,"name":"USERS"}'



🟣Что еще полезно знать для работы:

# Проверить доступность API
curl https://device/api

# Красиво вывести JSON
curl https://device/api/interfaces | jq

# Посмотреть HTTP-заголовки
curl -I https://device/api



Если сегодня сеть управляется кодом, то API - это тот самый язык, на котором разговаривают маршрутизаторы, контроллеры, системы мониторинга и автоматизация.

Серверная Админа | Zeroday | #API

👋 Привет, сетевой друг!

Расскажу еще о 3 способах прокачать защиту Mikrotik.

🟣Multicast IGMP Snooping для управления групповым трафиком: без него multicast флудит на все порты свитча как broadcast. С IGMP snooping коммутатор слушает IGMP-запросы и отправляет мультикаст только туда где есть подписчики:

/interface bridge
set bridge1 igmp-snooping=yes multicast-querier=yes

/interface bridge mdb
print

Особенно критично в сетях с IPTV или промышленными протоколами — без snooping мультикаст-поток на 20 Мбит/с убивает весь сегмент.

🟣Hairpin NAT для доступа к внутренним серверам по внешнему IP изнутри сети: классическая проблема когда сервер за NAT недоступен по публичному IP из той же локалки:

/ip firewall nat
add chain=srcnat \
  src-address=192.168.1.0/24 \
  dst-address=1.2.3.4 \
  protocol=tcp \
  dst-port=80 \
  action=masquerade \
  comment="Hairpin NAT"

add chain=dstnat \
  dst-address=1.2.3.4 \
  protocol=tcp \
  dst-port=80 \
  action=dst-nat \
  to-addresses=192.168.1.10 \
  comment="Forward to internal server"

Запрос изнутри на внешний IP роутер разворачивает на внутренний сервер и маскарадит источник - сервер отвечает правильно.

🟣Packet Sniffer с фильтрацией и отправкой на удалённый хост: встроенный снифер Mikrotik умеет стримить трафик на внешний Wireshark через TZSP без записи на флеш:

/tool sniffer
set filter-interface=ether1 \
  filter-ip-protocol=tcp \
  filter-port=80,443 \
  streaming-enabled=yes \
  streaming-server=192.168.1.100 \
  memory-limit=10

/tool sniffer start

На стороне Wireshark просто слушаем UDP 37008 - весь отфильтрованный трафик приходит в реальном времени. Флеш роутера не трогается, нагрузка минимальная.

Серверная Админа | Бункер Хакера | #Mikrotik

Факты

👨‍💻Серверная Админа | #мем

👋 Привет, сетевой друг!

Расскажу про универсальный тул для сетевой разведки и диагностики - Hawk

🟣Что это: Hawk объединяет сканирование сети, DNS-проверки, WHOIS, поиск поддоменов, анализ сервисов и базовые функции мониторинга. Нужен для быстрого первичного аудита или инвентаризации инфраструктуры.

🟣Если кратко, то внутри это набор обёрток над известными сетевыми техниками и инструментами. Можно искать активные хосты, проверять открытые порты, собирать баннеры сервисов и получать базовую информацию о доменах без постоянного переключения между утилитами.

🟣Стартуем:

git clone https://github.com/medpaf/hawk.git
cd hawk
sudo sh setup.sh

sudo python3 hawk.py



🟣А вот вам полезные команды:

# поиск устройств в локальной сети
-scanlan

# TCP/SYN-сканирование хоста
-scan -host 192.168.1.10

# определение версии сервиса
-grab -host 192.168.1.10 -p 22,80,443

# DNS-проверка
-ns example.com

# WHOIS
-whois example.com



🟣Есть и автоматизированный режим разведки:

-autoscan example.com



Он запускает несколько этапов сбора информации подряд и помогает быстро получить базовую картину по цели без ручного запуска каждого модуля.

🟣Но самая сильная сторона Hawk не в уникальных алгоритмах, а в том, что он собирает часто используемые сетевые операции в одном месте. Для быстрой диагностики, лабораторных стендов и учебных задач это бывает удобнее, чем держать в голове десятки отдельных команд.

Серверная Админа | Zeroday | #Инструмент

👋 Привет, сетевой друг!

Сегодня разберу QUIC, который фактически заменил связку TCP+TLS в современном вебе и убрал одну из самых неприятных проблем классического транспорта - блокировку потоков при потерях.

🟣Зачем он: классический TCP страдает от head-of-line blocking - если один пакет теряется, весь поток встаёт и ждёт восстановление. Плюс TLS поверх TCP добавляет отдельный handshake и ещё 1–2 RTT. QUIC (RFC 9000) убирает это, уходя в UDP и встраивая TLS 1.3 прямо в транспорт.

🟣Как работает: вместо одного общего потока QUIC создаёт connection с набором независимых streams. Потери влияют только на конкретный stream, остальные продолжают передавать данные без остановки. Шифрование встроено, поэтому транспортная логика и безопасность больше не разделены.

🟣Handshake:
обычное соединение (1-RTT)

client → Initial + crypto
server → Handshake + data
client → encrypted data
повторное соединение (0-RTT)
client → сразу encrypted request (если есть ключи сессии)

🟣Как выглядит в сети:

QUIC почти всегда UDP 443

tcpdump -i eth0 udp port 443 -nn

точечно по хосту

tcpdump -i eth0 host 1.1.1.1 -nn

🟣Проверка HTTP/3:

curl –http3 https://cloudflare.com

curl –http3 -I https://google.com

Если есть fallback - значит клиент/сервер не договорились о QUIC и ушли в HTTP/2.

🟣Проверка поддержки через TLS ALPN:

openssl s_client -alpn h3 -connect example.com:443

Если в ответе есть h3 - это HTTP/3 поверх QUIC.

🟣Что можно увидеть через Wireshark:

udp.port == 443
quic
tls && udp

Но важно: большая часть QUIC внутри зашифрована, включая транспортные метаданные, поэтому анализ становится гораздо более “слепым”, чем в TCP.

🟣Диагностика на хосте:

ss -u -a | grep 443
netstat -uapn | grep 443
lsof -i UDP:443

🟣В чем важность: привычная модель “SYN → SYN-ACK → ESTABLISHED” больше не работает. QUIC убирает наблюдаемость на уровне TCP и оставляет только косвенные сигналы - задержки, потери, джиттер и поведение потоков.

🟣Где уже используется: Google, YouTube, Cloudflare и большая часть мобильного трафика уже давно живут на QUIC/HTTP3. Это не эксперимент, а дефолтный транспорт современного веба.

Серверная Админа | Zeroday | #QUIC

👋 Привет, сетевой друг!

Сегодня поговорим о Ван Якобсоне - человеке который спас интернет от коллапса в конце 80-х.

🟣Кто такой Якобсон: исследователь в Lawrence Berkeley National Laboratory, позже работал в Cisco, Packet Design и Google. Не академик с кафедры — практик который чинил реальные проблемы реальной сети.

🟣Октябрь 1986 года: интернет падает. Пропускная способность между LBL и UC Berkeley вообще упала с 32 Кбит/с до 40 бит/с - в 800 раз. То же самое происходило по всей сети. Проблему назвали congestion collapse - сеть перегружалась, пакеты терялись, хосты ретрансмитили, это создавало ещё больше трафика и перегрузку усиливалась.

🟣За два года Якобсон разработал и внедрил четыре алгоритма которые до сих пор живут в каждом TCP-стеке: Slow Start, Congestion Avoidance, Fast Retransmit и Fast Recovery. Идея была простой - TCP должен сам определять пропускную способность канала и не перегружать сеть. Потеря пакета это сигнал что канал перегружен, нужно снизить скорость.

🟣В 1988 году вышла его статья Congestion Avoidance and Control - одна из самых цитируемых работ в истории компьютерных сетей. Алгоритмы внедрили в BSD Unix и они распространились по всему интернету за считанные месяцы.

🟣Позже Якобсон придумал tcpdump, pathchar для измерения характеристик каждого хопа в маршруте, и внёс вклад в разработку заголовков IPv6. В Google работал над Named Data Networking — концепцией где сеть маршрутизирует по именам контента а не по адресам.

🟣Без его работы интернет образца 1988 года просто лёг бы под собственным весом и не вырос в то что есть сейчас.

Серверная Админа | Zeroday | #история

👋 Привет, сетевой друг!

Разберём Flexible NetFlow - как собирать именно те метрики которые нужны, а не всё подряд.

🟣Чем отличается от обычного NetFlow: классический NetFlow v5/v9 пишет фиксированный набор полей. Flexible NetFlow позволяет самому определить что именно попадает в flow record - можно добавить DSCP, TTL, интерфейс, VLAN, BGP next-hop или любую комбинацию. Меньше мусора, точнее аналитика.

🟣Создаём кастомный flow record для анализа QoS-проблем:

flow record QOS_ANALYSIS
 match ipv4 source address
 match ipv4 destination address
 match ipv4 dscp
 match transport source-port
 match transport destination-port
 collect counter bytes
 collect counter packets
 collect transport tcp flags
 collect ipv4 ttl minimum
 collect ipv4 ttl maximum



TTL minimum и maximum в одном потоке - сразу видно асимметричную маршрутизацию когда пакеты туда и обратно идут разными путями.

🟣Экспортер и монитор:

flow exporter COLLECTOR
 destination 10.0.0.100
 transport udp 2055
 export-protocol netflow-v9
 template data timeout 60

flow monitor QOS_MONITOR
 record QOS_ANALYSIS
 exporter COLLECTOR
 cache timeout active 60
 cache timeout inactive 15

interface GigabitEthernet0/1
 ip flow monitor QOS_MONITOR input
 ip flow monitor QOS_MONITOR output



🟣Отдельный record для детекта сканирования - считаем количество уникальных dst-портов на один src-адрес:

flow record PORT_SCAN_DETECT
 match ipv4 source address
 match ipv4 destination address
 match transport destination-port
 collect counter packets
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last



Если один источник генерирует тысячи flow с разными dst-портами за короткое время - сканирование.

🟣Смотрим кэш прямо на роутере без коллектора:

show flow monitor QOS_MONITOR cache
show flow monitor QOS_MONITOR cache aggregate ipv4 source address
show flow monitor QOS_MONITOR statistics



aggregate позволяет группировать прямо в CLI - супер для быстрой диагностики без поднятия внешнего коллектора.

Серверная Админа | Zeroday | #Netflow