Как разделить management и пользовательский трафик

Смешивание management и пользовательского трафика кажется удобным «пока всё работает», но при перегрузке сети вы можете потерять доступ к оборудованию именно тогда, когда оно нужно для исправления проблем.

Отдельный management VLAN или VRF обеспечивает изоляцию и предсказуемость управления.

⏺Симптомы смешанного трафика: Когда management трафик идёт по тем же линкам, что и пользовательский, перегрузка, storm или широковещательные пакеты могут блокировать управление.

В такой ситуации коммутатор или сервер могут быть видны по IP, но команды не проходят, а ping и telnet/SSH зависают.

⏺Как настроить отдельный VLAN для управления на Cisco:

vlan 99
name MANAGEMENT

interface Vlan99
ip address 10.99.0.10 255.255.255.0
no shutdown

Привязка access-портов для управления:

interface GigabitEthernet1/0/1
switchport mode access
switchport access vlan 99

Транковые порты - только с нужными VLAN:

interface GigabitEthernet1/0/24
switchport mode trunk
switchport trunk allowed vlan 10,20,99

Дополнительно: изоляция через VRF:

vrf definition MGMT
rd 65000:99

interface Vlan99
vrf forwarding MGMT
ip address 10.99.0.10 255.255.255.0

Проверка и диагностика:

show vlan brief
show ip route vrf MGMT
ping vrf MGMT 10.99.0.10

N.A.

Читать полностью…

5 команд для продвинутой диагностики QoS на L3 интерфейсе

Интерфейс зелёный, линк up, а приложения всё равно жалуются на задержки или потерю пакетов? Скорее всего, виноват QoS.

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

1️⃣Какая политика висит на интерфейсе:

show policy-map interface GigabitEthernet1/0/1

Видно, какая политика output/input применена, какие классы трафика и сколько байт прошло через каждый.

2️⃣Статистика конкретного класса трафика:

show policy-map interface GigabitEthernet1/0/1 class CRITICAL

Сразу видно, сколько пакетов получили приоритет, сколько queued и сколько дропнуто.

3️⃣Очереди и шейпинг:

show queueing interface GigabitEthernet1/0/1

Глубина очередей, dropped packets, tail-drop и backlog - всё, что может создавать jitter и задержки.

4️⃣Состояние интерфейса и счётчики:

show interfaces GigabitEthernet1/0/1 counters

Ошибки, CRC, collisions, overruns - иногда именно они маскируются под проблемы QoS.

5️⃣Детальная статистика по всей политике:

show policy-map interface GigabitEthernet1/0/1 statistics

Смотрим dropped packets, conform/exceed rates по каждому классу - удобно для fine-tuning под high-load.

N.A.

Читать полностью…

ARP / ND cache exhaustion

В больших сетях таблицы ARP (IPv4) и Neighbor Discovery (IPv6) могут переполняться. 

Это создаёт «невидимые» проблемы: линк вроде работает, а трафик теряется или идёт нестабильно, и обычные ping/traceroute иногда ничего не покажут.

Симптомы переполнения ARP/ND:
⏺Периодическая недоступность отдельных хостов даже при рабочем линке.
⏺Нестабильная маршрутизация L3: соседние коммутаторы видят один и тот же MAC на разных портах.
⏺Err-disable порты из-за excessive ARP/ND traffic (особенно на access-коммутаторах).
⏺CPU spike на коммутаторе при попытках обработать множество ARP/ND записей.
⏺Flapping sessions на stateful devices (firewall, NAT), когда таблица маршрутов перестаёт корректно обновляться.

Продвинутая диагностика:

show arp detail vrf MGMT
show ip arp | include incomplete
show ipv6 neighbors detail
show mac address-table dynamic | include <MAC>
show processes cpu sorted | include ARP
show platform tcam utilization
show logging | include ARP

Углублённая проверка паттернов:

debug arp
debug ipv6 nd
show interface Gi0/1 counters errors
show ip route vrf MGMT

И да, важно, что даже если линк физически up, проблемы ARP/ND могут разлагать L3-связь и stateful приложения. Это особенно критично для сегментов с VMs, IoT или high-density access.

N.A.

Читать полностью…

Jumbo Frames и MTU mismatch

Jumbo Frames позволяют передавать большие пакеты (обычно до 9000 байт) и ускоряют трафик для storage, VM migration и high-throughput приложений.

Проблема возникает, если на пути хотя бы один интерфейс с меньшим MTU: пакеты падают silently или фрагментируются, что приводит к замедлению и нестабильности приложений.

Признаки проблемы:
⏺TCP-сессии медленно открываются или «висят» без packet loss по ping обычного размера
⏺VM migration или storage replication тормозят
⏺traceroute показывает неожиданное поведение или «packet too big» ICMP

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

Настройка MTU на интерфейсе:

interface Gi0/1
 mtu 9216

Проверка MTU по пути:

ping 10.0.0.2 size 9000 df-bit
show interfaces Gi0/1

На Linux для проверки MTU и отправки jumbo-пакетов:

ip link set dev eth0 mtu 9000
ping -M do -s 8972 10.0.0.2

N.A.

Читать полностью…

TTL Security / GTSM для BGP

TTL Security (или GTSM - Generalized TTL Security Mechanism) ограничивает BGP-сессии так, чтобы соседний роутер мог «достучаться» только с ожидаемого количества хопов.

Любой пакет с меньшим TTL считается подозрительным и отбрасывается. Это защищает control-plane от spoofed BGP-пакетов и DoS через подмену source IP.

⏺Часто понять отсутствие GTSM можно так: BGP-сессии рвутся при случайных ICMP или сканировании, или сосед получает пакеты с «чужим TTL», что создаёт flapping.

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

router bgp 65001
 neighbor 10.0.0.2 remote-as 65002
 neighbor 10.0.0.2 ttl-security hops 2

Проверка состояния BGP-сессии с GTSM:

show bgp neighbors 10.0.0.2
show bgp summary

N.A.

Читать полностью…

Давно планировал выучить Go, но не хотел тонуть в теории?

Курс «Golang-разработчик» в Слёрме стартует 30 января. Мы создали его для бэкенд-разработчиков и DevOps-инженеров, которые хотят сменить стек или научиться писать инфраструктурные инструменты на Go.

Важно: курс не для новичков.

Почему этот курс дает результат:
• 80% обучения — это практика. Вместо скучных лекций вы получите 53 часа прикладной работы.
• Спикер-практик. Обучение ведет Виталий Лихачев, SRE в Booking.com.
• Реальный проект в портфолио. Ты с нуля спроектируешь отказоустойчивый сервис на выбор: онлайн-банк, мессенджер или файловое хранилище.

Попробуй продукт бесплатно: мы открываем демо-доступ на 3 дня. Ты сможешь оценить платформу, подачу материала и решить, подходит ли тебе темп обучения, прежде чем платить.

👉 Занять место или получить демо-доступ
👉 Проверь свои знания и получи полезные материалы от экспертов рынка.

Читать полностью…

Control Plane Policing (CoPP)

Control Plane Policing ограничивает трафик, направленный к самому устройству.

Data plane может быть в порядке, но перегруженный control plane приводит к флапу протоколов и потере управления.

Типичный симптом: линк up, маршруты есть, но SSH лагает, BGP рвётся, SNMP не отвечает. Причина - CPU занят обработкой control-plane трафика.

CoPP позволяет явно задать, какой трафик и с каким rate допустим для CPU.

Классификация control-plane трафика:

class-map match-any CP-CRITICAL
 match protocol bgp
 match protocol ospf
 match protocol ssh

class-map match-any CP-MGMT
 match protocol snmp
 match protocol icmp

Политика с rate-limit:

policy-map CP-POLICY
 class CP-CRITICAL
  police 1000000 conform-action transmit exceed-action drop
 class CP-MGMT
  police 500000 conform-action transmit exceed-action drop
 class class-default
  police 200000 conform-action transmit exceed-action drop

Применение политики к control plane:

control-plane
 service-policy input CP-POLICY

Проверка состояния и нагрузки:

show policy-map control-plane
show processes cpu sorted

CoPP не влияет на throughput, но защищает control plane и делает поведение устройства стабильным при перегрузках и аномальном трафике.

N.A.

Читать полностью…

BFD для быстрого детекта линка

BFD (Bidirectional Forwarding Detection) позволяет обнаруживать падение линка за миллисекунды вместо секунд.

Это критично для OSPF, BGP и MPLS, где быстрый failover снижает влияние на приложения и сервисы. 

BFD работает поверх протоколов маршрутизации, отправляя маленькие heartbeat-пакеты и мгновенно фиксируя потерю связи.

Пример настройки на Cisco для OSPF:

interface Gi0/1
 ip ospf bfd

Для BGP:

router bgp 65001
 neighbor 10.0.0.2 remote-as 65002
 neighbor 10.0.0.2 fall-over bfd

Проверка состояния BFD:

show bfd neighbors
show bfd sessions
show bfd summary

Дополнительные команды для диагностики OSPF с BFD:

show ip ospf neighbor
show ip ospf interface
debug bfd

Для MPLS LSP с BFD:

mpls traffic-eng tunnels
mpls traffic-eng bfd
show mpls traffic-eng tunnels
show mpls traffic-eng bfd

N.A.

Читать полностью…

Проверка резервных маршрутов

Redundant link может быть физически поднят, но маршрутизация или ACL могут блокировать трафик.

Иногда резервный линк выглядит активным, но пакеты по нему не идут. Проверка резервных маршрутов заранее позволяет убедиться, что failover сработает корректно, и экономит время при инцидентах.

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

Проверка reachability через резервный путь:

ping 10.0.0.2 source 10.0.0.1

Просмотр таблицы маршрутизации и состояния маршрутов:

show ip route

Можно дополнительно использовать traceroute, чтобы убедиться, что трафик идёт по нужному резервному пути:

traceroute 10.0.0.2

N.A.

Читать полностью…

Почему стоит проверять качество кабельной разводки

Даже идеально настроенный коммутатор или роутер не спасёт сеть от проблем с плохими кабелями. 

Ошибки CRC, флапы линков, intermittent packet loss - чаще всего именно из-за физики.

Проверка кабельной разводки помогает заранее выявить:
⏺повреждённые или плохо обжатые коннекторы
⏺перекрещенные пары или неправильную разводку
⏺длинные сегменты без экранирования, которые влияют на скорость и стабильность

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

Проверка состояния интерфейсов:

show interfaces status
show interfaces counters errors

Диагностика физического уровня:

test cable-diagnostics tdr interface Gi0/1
show cable-diagnostics tdr interface Gi0/1

N.A.

Читать полностью…

Static route vs Dynamic route

Выбор между static и dynamic напрямую влияет на стабильность и управляемость сети.

⏺Static route - предсказуемая, простая и ломается редко. Отлично подходит для небольших сегментов или point-to-point линков, где топология почти не меняется. Минус - при изменениях сети маршруты нужно менять вручную. Static маршруты полезны как backup для критичных сегментов, потому что они всегда доступны и не зависят от состояния соседних устройств.

⏺Dynamic route - гибкая, адаптируется к изменениям топологии. Подходит для больших сетей с frequent changes, когда ручное управление стало бы слишком сложным. Минус - может флапать и создавать нестабильность при ошибках конфигурации, фильтрах или нестабильных соседях. Dynamic маршруты удобны для основного трафика, где нужно быстро подстраиваться под изменения.

Примеры на Cisco:

Static route:

ip route 10.0.0.0 255.255.255.0 192.168.1.1
ip route 0.0.0.0 0.0.0.0 192.168.1.254

Dynamic route (OSPF):

router ospf 1
 network 10.0.0.0 0.0.0.255 area 0
 network 192.168.1.0 0.0.0.255 area 0

N.A.

Читать полностью…

Почему стоит проверять резервные пути и failover

Redundant link сам по себе не гарантирует стабильность сети.

Даже если линк поднят и маршруты выглядят корректно, приложения могут страдать: маршрутизация не пересчиталась, firewall блокирует новый путь, ECMP разбил сессии неправильно.

Пример практики на Cisco:

show ip route
show ip cef
ping 10.0.0.2 source 10.0.0.1

⏺Лучше заранее имитировать отказ: поднять резервный линк, отключить основной и проверить, что трафик корректно уходит по backup. Так вы увидите реальные слабые места, которые не проявляются при просто «up» интерфейсе.

Failover стоит проверять регулярно - после изменений в конфигурации, апгрейда прошивки или добавления новых VLAN. Это снижает риск, что в момент инцидента резерв не сработает.

N.A.

Читать полностью…

Почему SNMP community «public» опасен

По умолчанию на многих устройствах есть SNMP community public. 

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

Правильная практика - создать уникальный community и ограничить доступ по IP.

Пример на Cisco:

snmp-server community MySecret RO 10
snmp-server community MySecret RW 192.168.10.0 255.255.255.0

Так вы контролируете, кто может читать и менять данные SNMP, и снижаете риск случайного или злого вмешательства.

N.A.

Читать полностью…

Когда стоит настраивать ECMP, а когда он только мешает

ECMP выглядит как очевидное улучшение: несколько равных путей, больше пропускная способность, меньше перегрузок.

Для stateless-трафика и большого количества потоков это действительно работает хорошо.

⏺Проблемы начинаются там, где появляются stateful-сессии. ECMP распределяет трафик по хешу. Если хеш считается только по IP, разные TCP-сессии могут пойти по разным путям. А если по пути стоит stateful firewall, NAT или load balancer, ответы начинают возвращаться не тем маршрутом, где была создана сессия.

Типичный симптом: часть соединений работает, часть рвётся. Повторные попытки иногда проходят, иногда нет. Ping и traceroute выглядят нормально, а приложение ведёт себя нестабильно.

ECMP хорошо подходит для spine-leaf, DC-трафика, east-west потоков, где много коротких сессий и нет жёсткой привязки состояния к одному пути. Там он действительно даёт масштабирование.

А вот на edge, перед firewall или VPN, ECMP часто создаёт больше проблем, чем пользы. В таких местах один предсказуемый маршрут надёжнее двух «умных», которые могут внезапно поменять путь для части трафика.

⚡️Перед включением ECMP важно понимать, по каким полям считается хеш и кто дальше по цепочке хранит состояние.

N.A.

Читать полностью…

Почему лучше явно задавать STP root, а не оставлять «по умолчанию»

Когда STP root не задан, сеть выбирает его сама - по наименьшему BID. Пока топология не меняется, всё выглядит стабильно и «работает». Проблемы начинаются в момент изменений.

Типичная ситуация: заменили коммутатор, обновили прошивку или просто перезагрузили часть сети.

⏺У нового устройства оказался ниже BID - и root bridge тихо переехал. STP пересчитался, часть портов ушла в blocking, а трафик пошёл по менее удачному пути.

Снаружи это выглядит как деградация сервисов. Увеличились задержки, появились таймауты, где-то просел throughput. Маршруты есть, линков хватает, но сеть стала «чуть медленнее», и искать начинают в приложениях.

Явно заданный root фиксирует логику сети. Вы заранее решаете, где должна сходиться L2-топология и через какие устройства идти основной трафик. Любые изменения в сети тогда либо не влияют на STP, либо сразу заметны.

Пример на Cisco:

spanning-tree vlan 10,20 priority 4096

Или проще:

spanning-tree vlan 10,20 root primary

Проверка:

show spanning-tree vlan 10

N.A.

Читать полностью…

Как проверить и исправить скорость и дуплекс на коммутаторах и серверах

Даже если линк выглядит «зелёным», многие проблемы с TCP, VoIP и storage на самом деле происходят из-за mismatch speed/duplex между коммутатором и сервером.

Правильная настройка ускоряет трафик и устраняет нестабильность.

⏺Симптомы бывает такие:

Если скорость или дуплекс не совпадают на двух сторонах линка, вы увидите случайные packet loss, CRC errors, TCP-сессии, которые тормозят или зависают, а голосовой и видео трафик начинает «скакать» с jitter.

Часто throughput ниже ожидаемого, особенно на storage или VM трафике, и все это может происходить при видимо «зелёном» интерфейсе.

⏺Как проверить на коммутаторе Cisco:

show interfaces Gi0/1 status
! Показывает статус, скорость и дуплекс порта
show interfaces Gi0/1
! Детальная информация: errors, duplex, speed, auto-negotiation
show interfaces counters errors
! Подсчёт CRC, collisions, overruns
show interfaces status | include Gi0/1
! Быстрая проверка состояния конкретного порта

⏺Как исправить mismatch:

1️⃣Вручную задать скорость и дуплекс на коммутаторе:

interface Gi0/1
speed 1000
duplex full
no shutdown

2️⃣На серверах - настроить NIC на фиксированную скорость и full duplex или включить auto-negotiation, если коммутатор тоже auto.

Проверка после исправления:

show interfaces Gi0/1 status
show interfaces Gi0/1
ping <сервер-IP> repeat 100

Если CRC и collisions исчезли, TCP стабилен, jitter пропал - линк настроен корректно.

N.A.

Читать полностью…

Зачем явно задавать root bridge в STP

Если root bridge не назначен вручную, роль root получает коммутатор с наименьшим BID.

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

В результате появляются неожиданные задержки в L2-сети, flapping портов, частые перестройки STP, а пользователи жалуются на «скачки» сети и потерю соединений.

Иногда трафик может попасть в suboptimal path, а диагностировать причину сложнее, чем кажется на первый взгляд.

Команды для проверки и диагностики на Cisco:

show spanning-tree
show spanning-tree vlan 1 detail
show spanning-tree vlan 10 detail
show spanning-tree root
show spanning-tree summary
show spanning-tree interface Gi0/1 detail
show log | include STP
debug spanning-tree events

Настройка явного root bridge:

spanning-tree vlan 1 root primary
spanning-tree vlan 10 root secondary
spanning-tree vlan 1 priority 24576
spanning-tree vlan 10 priority 28672

N.A.

Читать полностью…

ECMP pitfalls

На бумаге ECMP - мечта: несколько равных путей, балансировка, более высокая пропускная способность.

На деле же для stateful трафика это как «разбросанные дорожки»: пакеты одного соединения идут разными путями, и соединение начинает вести себя странно. 

VPN рвётся, firewall теряет сессии, TCP-флоу скачут.

5 типичных проблем с ECMP:
1️⃣Stateful NAT или firewall - сессии рвутся из-за разных путей.
2️⃣Короткие TCP-флоу - хеш распределяет трафик неравномерно, часть линков простаивает.
3️⃣Асимметричный маршрут - входящие и исходящие пакеты идут по разным линкам.
4️⃣Динамическое добавление или удаление линков - внезапное перераспределение трафика вызывает jitter и packet loss.
5️⃣VPN-туннели - пакеты разбросаны, туннель становится нестабильным.

Как проверить:

show ip route
show ip cef summary
ping 10.0.0.2 repeat 100
traceroute 10.0.0.2

N.A.

Читать полностью…

UDLD aggressive mode

UDLD (Unidirectional Link Detection) помогает обнаруживать односторонние линки, когда физически интерфейс up, но трафик идёт только в одну сторону.

На L2 это особенно опасно: STP видит линк как рабочий, петли не детектятся, трафик теряется или ходит по странным путям.

Aggressive mode не просто логирует проблему - он переводит интерфейс в err-disable, чтобы остановить распространение проблем по сети до того, как STP или другие протоколы успеют «поймать» ошибку.

Включение глобально:

udld enable

На интерфейсе с агрессивным режимом:

interface Gi0/1
 udld port aggressive

Для оптики и аплинков:

interface TenGigabitEthernet1/1
 udld port aggressive

Проверка состояния UDLD:

show udld interface
show udld neighbors

Если порт ушёл в err-disable:

show errdisable recovery
errdisable recovery cause udld
errdisable recovery interval 300

N.A.

Читать полностью…

Route leaking между VRF

VRF создают иллюзию жёсткой изоляции: разные таблицы маршрутизации, разные интерфейсы, всё аккуратно разложено.

Проблемы начинаются, когда маршруты из одного VRF внезапно появляются в другом - без явного intent.

Основная причина - import/export Route Target. RT это просто метка. Если один VRF экспортирует маршрут с RT, а другой его импортирует, маршрут появится, даже если сегменты логически не должны видеть друг друга.

Частый сценарий тут:
есть VRF PROD и MGMT. Для «временного доступа» или теста добавляют общий RT. Потом про него забывают. В итоге management-сеть внезапно получает маршруты в production или наоборот.

Пример некорректной конфигурации.

VRF PROD экспортирует маршруты:

vrf definition PROD
 rd 65000:10
 route-target export 65000:10
 route-target export 65000:99

VRF MGMT импортирует тот же RT:

vrf definition MGMT
 rd 65000:99
 route-target import 65000:99

Результат: все маршруты из PROD с RT 65000:99 появляются в MGMT. Никаких ACL, никаких предупреждений - маршруты валидны с точки зрения control plane.

Снаружи это выглядит странно: пакеты доходят до «чужих» подсетей, traceroute внезапно проходит, firewall «ничего не блокирует», потому что трафик уже оказался не там, где ожидали.

⏺Как это обычно обнаруживается:
— неожиданные маршруты в show ip route vrf
— асимметричный трафик между VRF
— утечки через shared-services VRF
— доступ туда, где его быть не должно, без явного L3-соединения

Проверка RT:

show vrf detail
show bgp vpnv4 unicast all
show ip route vrf PROD
show ip route vrf MGMT

Особенно опасны shared RT вроде 65000:100, которые используются «для удобства». Один лишний import — и изоляция превращается в условность.

N.A.

Читать полностью…

DHCP Snooping + IP Source Guard

DHCP Snooping позволяет коммутатору понять, какие IP-адреса легитимны, а какие нет.
Без этого любой хост может поднять rogue DHCP или подменить IP и начать MITM внутри VLAN.
⏺Типичный симптом: сеть «работает», но клиенты периодически получают странные шлюзы, пропадает доступ или трафик уходит не туда.

DHCP Snooping строит binding-таблицу IP–MAC–VLAN–port и делает её источником правды для других механизмов защиты.

Включение DHCP Snooping глобально и для VLAN:
ip dhcp snooping
ip dhcp snooping vlan 10,20
Настройка trusted-портов (uplink к DHCP-серверу или L3):
interface Gi0/24
ip dhcp snooping trust
Ограничение скорости DHCP-запросов на access-портах:
interface Gi0/3
ip dhcp snooping limit rate 15
Проверка binding-таблицы:
show ip dhcp snooping binding
IP Source Guard использует эту таблицу и блокирует трафик с поддельным IP.

Включение на access-порте:
interface Gi0/3
ip verify source
Проверка статуса:
show ip verify source
Связка DHCP Snooping + IP Source Guard предотвращает IP spoofing и rogue DHCP на уровне L2, без участия firewall или L3-логики.

N.A.

Читать полностью…

QoS для нескольких классов трафика

QoS (Quality of Service) позволяет разделять трафик по классам и приоритетам, чтобы критичные приложения, например голос или финансовые сервисы, не страдали при перегрузке линков.

Это особенно важно в сетях с большим количеством сервисов и смешанным трафиком.

Пример настройки на Cisco:

Создание класса для критичного трафика:

class-map CRITICAL
 match ip dscp ef

Создание политики и приоритизация:

policy-map PRIORITY
 class CRITICAL
  priority
 class class-default
  fair-queue

Применение политики на интерфейсе:

interface Gi0/1
 service-policy output PRIORITY

Проверка статистики QoS:

show policy-map interface Gi0/1
show class-map

N.A.

Читать полностью…

Хочешь освоить профессию DevOps-инженер, но не знаешь с чего начать?

Тебе знакомо это чувство: открываешь вакансию DevOps, а там - десятки технологий, и каждая требует опыта?
Ты пытаешься учить всё подряд, но в итоге тратишь месяцы, а работодатели всё равно говорят: "Не хватает знаний, опыта".

DevOps - это не про зубрежку инструментов, а про системный подход. Нужно понимать, что учить в первую очередь, а с чем можно повременить.

Чтобы не метаться между мануалами и не тратить время впустую, подписывайся на канал Евгения Вдовиченко.
Он вырос из эникея в Senior DevOps Engineer и получил опыт работы в Сбере, МТС, TerraLink и других компаниях, а так же вел курс - профессия DevOps-инженер и успешно обучил 500+ учеников.

Недавно он записал гайд - Как освоить профессию DevOps-инженер с нуля в 2026 году. В котором рассказывает о том, какие технологии и инструменты стоит изучать, а на какие не нужно тратить время и силы.
Гайд доступен в закрепе канала Евгения!

Подписывайтесь, здесь личный опыт как и что изучать для успешного вкатывания в DevOps.
👉 evgeniyvdovichenko

Читать полностью…

TDR тест на коммутаторах

TDR (Time-Domain Reflectometer) проверяет физическое состояние кабелей на коммутаторах.

Он выявляет разрывы, плохие пары или неправильную разводку до того, как это станет причиной проблем в сети. Даже если интерфейс «зелёный», пакеты могут теряться из-за физики кабеля, а TDR это покажет.

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

Проверка кабеля:

test cable-diagnostics tdr interface Gi0/1

Просмотр результатов:

show cable-diagnostics tdr interface Gi0/1

⏺Ну и немного советов по использованию:
• Делайте TDR-тесты после установки нового кабеля или замены оборудования.
• Сравнивайте результаты с предыдущими тестами, чтобы заметить ухудшение качества линка.
• Используйте вместе с проверкой счётчиков ошибок интерфейсов:

show interfaces counters errors
show interfaces status

Это помогает заранее найти проблемы и сэкономить время на поиск причин нестабильного трафика.

N.A.

Читать полностью…

Зачем проверять MTU перед поднятием VPN

MTU (Maximum Transmission Unit) определяет максимальный размер пакета, который может пройти по сети без фрагментации.

Для VPN это критично: инкапсуляция добавляет заголовки, и если MTU на пути меньше, пакеты начинают фрагментироваться или теряться. 

В итоге туннель рвётся или работает медленно.

Проверка MTU заранее помогает избежать проблем до поднятия VPN.

Пример на Linux для тестирования пути:

ping 10.1.1.1 -M do -s 1472

• -M do запрещает фрагментацию
• -s 1472 размер payload, который плюс заголовки даст 1500 байт (стандартный Ethernet MTU)

Если пинг проходит - MTU подходит, если нет - уменьшаем payload или настраиваем TCP MSS clamp на туннеле.

Пример на Cisco для VPN (MSS adjust):

interface Tunnel0
 ip mtu 1400
 ip tcp adjust-mss 1360

N.A.

Читать полностью…

5 случаев, когда ECMP мешает больше, чем помогает

ECMP (Equal-Cost Multi-Path) выглядит как очевидная оптимизация: несколько равных маршрутов - больше пропускная способность, меньше перегрузок.

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

1️⃣Stateful firewall или NAT: ECMP распределяет пакеты по хешу. Если дальше стоит stateful устройство, оно «ждёт» пакеты на одном пути. Когда часть пакетов идёт по другому, сессии рвутся, и соединения начинают ломаться.

2️⃣VPN-туннели: Хеширование ECMP может «разделять» пакеты одной сессии между линками. VPN-туннель теряет целостность, туннель падает или трафик идёт только в одну сторону.

3️⃣VoIP и real-time трафик: Голос и видео требуют последовательности пакетов. Если ECMP отправляет часть пакетов по другому пути, появляются дерганья, потеря качества и jitter.

4️⃣Мониторинг и логирование: Когда трафик идёт по разным линкам, становится сложно понять, где возникла проблема. Инструменты вроде NetFlow, sFlow или SNMP видят разрозненные потоки, а алерты путаются.

5️⃣Пиковые нагрузки: ECMP может показывать стабильную работу при малой нагрузке, но в моменты пиков или flapping линков поведение становится непредсказуемым. Сессии ломаются, а проблема трудно воспроизводится.

⏺В итоге ECMP отлично подходит для DC-трафика, spine-leaf или крупных east-west потоков, где много коротких сессий. На edge, перед stateful устройствами или для критичных приложений лучше использовать один предсказуемый маршрут - меньше «умной» логики, меньше плавающих проблем.

Пример на Linux:

ip route add 10.0.0.0/24 nexthop via 192.168.1.1 nexthop via 192.168.2.1

N.A.

Читать полностью…

Почему стоит включать logging на интерфейсах

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

Логи показывают, что происходит на порту в реальном времени и помогают быстрее найти источник.

Пример на Cisco:

interface GigabitEthernet0/1
 logging event link-status

logging buffered 10000
show logging

Теперь любые изменения состояния порта будут фиксироваться, и искать причину flapping или отключений станет проще.

N.A.

Читать полностью…

Почему нельзя смешивать management и user traffic «потом разделим»

Пока всё спокойно, смешанный трафик кажется нормальным решением.

Как только сеть ловит перегрузку или шторм, management-трафик оказывается в той же очереди, что и пользовательский.

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

Самый простой вариант - отдельный management VLAN.

Пример на Cisco:

vlan 99
 name MANAGEMENT

interface Vlan99
 ip address 10.99.0.10 255.255.255.0
 no shutdown

Access-порты для управления:

interface GigabitEthernet1/0/1
 switchport mode access
 switchport access vlan 99

Транки - только с нужными VLAN:

interface GigabitEthernet1/0/24
 switchport mode trunk
 switchport trunk allowed vlan 10,20,99

Если нужно жёстко отделить управление — VRF:

vrf definition MGMT
 rd 65000:99

interface Vlan99
 vrf forwarding MGMT
 ip address 10.99.0.10 255.255.255.0

N.A.

Читать полностью…

Дедлайн Новый год стучится в дверь! 😊

Я думаю, что все устали и всем пора отдыхать, набираться сил. Все дедлайны позади, а о будущих думать пока не стоит! 😊

Я пожелаю Вам хороших каникул, счастья, здоровья, поменьше выгорания и успехов в новом году! 😊

С наступающим, 2026! 😊

Читать полностью…

На Stepik вышел курс по Linux

Внутри 20+ модулей: от установки Linux и работы с файлами до сетей, прав, дисков, процессов, автоматизации на Bash и многого другого. Всё сразу закрепляется на практике (200+ заданий с автопроверкой)

Материал подаётся понятным языком, шаг за шагом, на реальных примерах и с наглядными схемами.

После прохождения вы получите сертификат, который можно добавить в резюме.

Есть бесплатные демо-уроки для ознакомления. В ближайшие 48ч курс доступен со скидкой 25% по промокоду «ADMIN25»: открыть курс на Stepik

P.S. Курс можно купить в подарок на Новый год

Читать полностью…