MAC learning suppression
MAC learning suppression - состояние, при котором коммутатор перестаёт обучаться MAC-адресам.
Линк остаётся up, VLAN корректный, но трафик начинает фладиться, доступ к узлам становится нестабильным, а поведение сети выглядит «рандомным».
Чаще всего причина в port-security, лимитах MAC-адресов или security-фичах, которые блокируют обучение при превышении порогов или несоответствии политик.
Основные источники проблемы
Port-security с жёсткими лимитами, глобальные ограничения MAC-таблицы, storm-control, а также связка DHCP snooping и Dynamic ARP Inspection.
Команды для анализа на Cisco
Просмотр MAC-таблицы и её состояния:
Проверка конкретного интерфейса:
Если используется port-security, важно смотреть violation и текущие лимиты.
Проверка глобальных лимитов MAC:
Анализ логов на предмет блокировок:
Проверка storm-control и related features:
N.A.
MAC learning suppression - состояние, при котором коммутатор перестаёт обучаться MAC-адресам.
Линк остаётся up, VLAN корректный, но трафик начинает фладиться, доступ к узлам становится нестабильным, а поведение сети выглядит «рандомным».
Чаще всего причина в port-security, лимитах MAC-адресов или security-фичах, которые блокируют обучение при превышении порогов или несоответствии политик.
Основные источники проблемы
Port-security с жёсткими лимитами, глобальные ограничения MAC-таблицы, storm-control, а также связка DHCP snooping и Dynamic ARP Inspection.
Команды для анализа на Cisco
Просмотр MAC-таблицы и её состояния:
show mac address-table
show mac address-table dynamic
show mac address-table count
Проверка конкретного интерфейса:
show mac address-table interface Gi0/10
show port-security interface Gi0/10
Если используется port-security, важно смотреть violation и текущие лимиты.
show running-config interface Gi0/10
Проверка глобальных лимитов MAC:
show mac address-table limit
show platform hardware capacity mac
Анализ логов на предмет блокировок:
show logging | include MAC
show logging | include SECURITY
Проверка storm-control и related features:
show storm-control interface Gi0/10
show ip dhcp snooping
show ip arp inspection
N.A.
👍14❤2
5 команд для проверки ARP-таблицы
ARP - ключевой механизм для L2 ↔ L3 связи. Неправильные или устаревшие записи приводят к недоступности хостов, конфликтам IP и «рандомным» потерям пакетов.
Полный список IP ↔ MAC записей, их age и тип (dynamic/static).
Фильтрация по конкретному IP для быстрого поиска конфликтов или недоступных хостов.
Позволяет найти, где в сети используется конкретный MAC.
Очистка ARP на интерфейсе или устройстве, чтобы динамические записи обновились.
Принудительно создаёт ARP-запросы, помогает проверить, корректно ли обновляется ARP-таблица.
N.A.
ARP - ключевой механизм для L2 ↔ L3 связи. Неправильные или устаревшие записи приводят к недоступности хостов, конфликтам IP и «рандомным» потерям пакетов.
show arp
Полный список IP ↔ MAC записей, их age и тип (dynamic/static).
show ip arp | include <IP_ADDRESS>
Фильтрация по конкретному IP для быстрого поиска конфликтов или недоступных хостов.
show ip arp | include <MAC_ADDRESS>
Позволяет найти, где в сети используется конкретный MAC.
clear arp-cache
Очистка ARP на интерфейсе или устройстве, чтобы динамические записи обновились.
ping <IP_ADDRESS> repeat 5
Принудительно создаёт ARP-запросы, помогает проверить, корректно ли обновляется ARP-таблица.
N.A.
👍11❤3
Что происходит при конфликте IP-адресов
IP-конфликт - это ситуация, когда два устройства в одной подсети считают один и тот же адрес «своим».
Когда кто-то в сети спрашивает: «Кто владелец IP 192.168.1.10?», отвечают оба устройства. В ARP-кэше сохраняется MAC того, кто ответил последним. Через некоторое время ответит второй, и запись перепишется. Трафик начнёт уходить уже к нему.
⏺ Именно поэтому поведение нестабильное:
пинг проходит через раз, веб-интерфейс то открывается, то нет, SSH обрывается, пользователи говорят «само чинится и снова ломается».
Что в этот момент происходит в сети
ARP-таблицы на разных устройствах начинают «мигать»: один и тот же IP связан с разными MAC-адресами.
Если конфликт затрагивает gateway или сервер - последствия становятся заметными сразу: сессии рвутся, NAT ломается, сервисы становятся непредсказуемыми.
Почему это выглядит случайно
Потому что всё зависит от того, чья ARP-ответная гонка победила в конкретный момент. Пока в кэше «правильный» MAC - всё работает. Как только запись обновилась, трафик уходит к другому устройству.
N.A.
IP-конфликт - это ситуация, когда два устройства в одной подсети считают один и тот же адрес «своим».
На бумаге всё выглядит корректно: маска правильная, gateway задан, линк зелёный. Но на уровне ARP начинается борьба за право отвечать на запросы.
Когда кто-то в сети спрашивает: «Кто владелец IP 192.168.1.10?», отвечают оба устройства. В ARP-кэше сохраняется MAC того, кто ответил последним. Через некоторое время ответит второй, и запись перепишется. Трафик начнёт уходить уже к нему.
пинг проходит через раз, веб-интерфейс то открывается, то нет, SSH обрывается, пользователи говорят «само чинится и снова ломается».
Что в этот момент происходит в сети
ARP-таблицы на разных устройствах начинают «мигать»: один и тот же IP связан с разными MAC-адресами.
На коммутаторе можно увидеть, что трафик для этого IP приходит то с одного порта, то с другого.
Если конфликт затрагивает gateway или сервер - последствия становятся заметными сразу: сессии рвутся, NAT ломается, сервисы становятся непредсказуемыми.
Почему это выглядит случайно
Потому что всё зависит от того, чья ARP-ответная гонка победила в конкретный момент. Пока в кэше «правильный» MAC - всё работает. Как только запись обновилась, трафик уходит к другому устройству.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13👍9❤4
Почему трафик концентрируется на одном линке в агрегированных каналах
Даже когда в сети настроено несколько линков через LACP / Port-Channel или ECMP, трафик иногда упорно идёт по одному физическому каналу. Интерфейсы подняты, агрегирование активно, но один линк перегружен, а остальные почти пустые.
↗️ Как работает распределение трафика
Балансировка в LACP и ECMP обычно основана на hash-функции, которая использует параметры пакета для выбора линка:
• Source / Destination MAC
• Source / Destination IP
• Source / Destination TCP/UDP порты
Коммутатор или маршрутизатор вычисляет «хэш» и назначает конкретный линк для этой сессии.
Остальные остаются почти пустыми - это и называется hash polarization.
На практике это проявляется так:
⏺ Один линк работает на 90–100% пропускной способности, другие - почти пустые.
⏺ Сессии к одному серверу всегда идут через один и тот же линк.
⏺ Мониторинг агрегированного канала показывает нормальную пропускную способность, но дисбаланс по отдельным линкам очевиден.
Как проверить на Cisco
Статус всех Port-Channel, активные интерфейсы и режим LACP.
Ошибки, drops, скорость и загрузка агрегированного интерфейса.
Как конкретный физический интерфейс участвует в Port-Channel.
Схема распределения трафика: по MAC, IP или портам.
Аппаратные счётчики по линкам, чтобы увидеть дисбаланс на уровне ASIC.
N.A.
Даже когда в сети настроено несколько линков через LACP / Port-Channel или ECMP, трафик иногда упорно идёт по одному физическому каналу. Интерфейсы подняты, агрегирование активно, но один линк перегружен, а остальные почти пустые.
Такое поведение часто вводит в заблуждение - кажется, что резервные линки «не работают», хотя на самом деле алгоритм распределения трафика делает именно так.
Балансировка в LACP и ECMP обычно основана на hash-функции, которая использует параметры пакета для выбора линка:
• Source / Destination MAC
• Source / Destination IP
• Source / Destination TCP/UDP порты
Коммутатор или маршрутизатор вычисляет «хэш» и назначает конкретный линк для этой сессии.
Если большинство сессий используют одинаковые параметры (например, много трафика к одному серверу или одному сервису), хэш-функция распределяет их на один линк.
Остальные остаются почти пустыми - это и называется hash polarization.
На практике это проявляется так:
Как проверить на Cisco
show etherchannel summary
Статус всех Port-Channel, активные интерфейсы и режим LACP.
show interfaces port-channel 1
Ошибки, drops, скорость и загрузка агрегированного интерфейса.
show interfaces Gi0/1 etherchannel
Как конкретный физический интерфейс участвует в Port-Channel.
show etherchannel load-balance
Схема распределения трафика: по MAC, IP или портам.
show platform hardware port-channel statistics
Аппаратные счётчики по линкам, чтобы увидеть дисбаланс на уровне ASIC.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤1
Почему серверы теряют доступ к gateway
Даже когда линк активен, а сервер «пингуется» в своей подсети, иногда невозможно выйти за пределы VLAN.
Основные причины кроются в логике L2/L3: ARP, маршруты, конфликты IP и асимметричные пути.
Основные причины👇
1️⃣ ARP-проблемы
Если на сервере или коммутаторе устарели ARP-записи, gateway может «исчезнуть» из таблицы. Сервер отправляет пакеты, а коммутатор не знает, куда их направить.
2️⃣ Default route отсутствует или неверная
Без корректного default route сервер не знает, куда уходить за пределы своей подсети. Иногда статическая маршрутизация задаётся неправильно или конфликтует с динамическими маршрутами.
3️⃣ Duplicate IP
Если кто-то в сети использует тот же IP, ARP-кэш может переписываться, и трафик на gateway идёт на чужое устройство. Сессии становятся нестабильными: часть пакетов проходит, часть теряется.
4️⃣ Asymmetric routing
Когда трафик «туда» идёт по одному пути, а «обратно» - по другому, stateful firewall или NAT могут рвать соединения. Сервер вроде отправляет пакеты, а ответы не доходят.
Как проверить
Смотрим MAC-адрес gateway и его актуальность.
Проверяем, доступен ли gateway в реальном времени.
Проверяем наличие default route и маршрутов к другим подсетям.
Статус интерфейсов сервера и коммутатора.
Логи могут показать конфликты и дублирование IP.
N.A.
Даже когда линк активен, а сервер «пингуется» в своей подсети, иногда невозможно выйти за пределы VLAN.
Основные причины кроются в логике L2/L3: ARP, маршруты, конфликты IP и асимметричные пути.
Основные причины
Если на сервере или коммутаторе устарели ARP-записи, gateway может «исчезнуть» из таблицы. Сервер отправляет пакеты, а коммутатор не знает, куда их направить.
Без корректного default route сервер не знает, куда уходить за пределы своей подсети. Иногда статическая маршрутизация задаётся неправильно или конфликтует с динамическими маршрутами.
Если кто-то в сети использует тот же IP, ARP-кэш может переписываться, и трафик на gateway идёт на чужое устройство. Сессии становятся нестабильными: часть пакетов проходит, часть теряется.
Когда трафик «туда» идёт по одному пути, а «обратно» - по другому, stateful firewall или NAT могут рвать соединения. Сервер вроде отправляет пакеты, а ответы не доходят.
Как проверить
show ip arp
Смотрим MAC-адрес gateway и его актуальность.
ping <gateway>
Проверяем, доступен ли gateway в реальном времени.
show ip route
Проверяем наличие default route и маршрутов к другим подсетям.
show ip interface brief
Статус интерфейсов сервера и коммутатора.
show logging | include ARP
Логи могут показать конфликты и дублирование IP.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15❤1
Почему SSL/TLS соединения падают при смене времени
Даже когда сертификаты вроде валидны и сервер доступен, HTTPS-сессии могут обрываться или выдавать ошибки handshake.
⏺ Ещё одна частая причина - неправильно настроенный NTP. Без синхронизации часы расходятся, и handshake с клиентом завершается с ошибкой.
Иногда сбои связаны с expired сертификатами, которые дополнительно усугубляют проблему, особенно на новых соединениях.
Как проверить
Проверка синхронизации времени на сетевых устройствах.
Смотрим системное время на сервере.
Анализ TLS handshake и проверки сертификатов.
Проверка часового пояса и синхронизации на Linux.
N.A.
Даже когда сертификаты вроде валидны и сервер доступен, HTTPS-сессии могут обрываться или выдавать ошибки handshake.
Основная причина в том, что TLS строго проверяет время: если системные часы сервера или клиента сильно отстают или опережают реальное время, сертификаты могут считаться просроченными или ещё не действительными.
Иногда сбои связаны с expired сертификатами, которые дополнительно усугубляют проблему, особенно на новых соединениях.
Как проверить
show ntp status
Проверка синхронизации времени на сетевых устройствах.
date
Смотрим системное время на сервере.
openssl s_client -connect <host>:443
Анализ TLS handshake и проверки сертификатов.
timedatectl
Проверка часового пояса и синхронизации на Linux.
show logging | include NTP
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14❤1
Как понять, что firewall блокирует трафик «мимо правил»
Он отслеживает сессии, и если обратный путь идёт другим маршрутом (asymmetric routing) или таблица состояний переполнена, новые пакеты могут просто сбрасываться, даже если правила разрешают соединение.
⏺ Симптомы: соединение устанавливается частично, ping проходит, а приложения не работают; одни сессии живут, другие рвутся без видимых причин.
Как проверить
Просмотр активных сессий на firewall.
Полная таблица сессий с их состояниями.
Логи о сброшенных пакетах.
Проверка маршрута в обход firewall и выявление асимметрии.
Смотрим маршруты, чтобы убедиться, что обратный путь совпадает.
N.A.
Иногда кажется, что все правила настроены правильно, но трафик не проходит. Проблема часто кроется в особенностях stateful firewall.
Он отслеживает сессии, и если обратный путь идёт другим маршрутом (asymmetric routing) или таблица состояний переполнена, новые пакеты могут просто сбрасываться, даже если правила разрешают соединение.
Как проверить
show conn
Просмотр активных сессий на firewall.
show session all
Полная таблица сессий с их состояниями.
show logging | include DROP
Логи о сброшенных пакетах.
traceroute <destination>
Проверка маршрута в обход firewall и выявление асимметрии.
show ip route
Смотрим маршруты, чтобы убедиться, что обратный путь совпадает.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11❤3
Почему OSPF соседство не поднимается
Интерфейсы в состоянии up/up, IP-адреса корректные, но соседи в OSPF не переходят в Full.
Иногда интерфейс попадает под passive-interface, либо multicast
Также соседство не установится, если Router ID дублируется в домене или если одна сторона работает в stub/NSSA, а другая - нет.
🤖 Что проверить на Cisco
N.A.
Интерфейсы в состоянии up/up, IP-адреса корректные, но соседи в OSPF не переходят в Full.
Чаще всего причина в несовпадении параметров: area ID, network type, hello/dead timers, MTU или authentication.
Иногда интерфейс попадает под passive-interface, либо multicast
224.0.0.5 блокируется ACL’ом.Также соседство не установится, если Router ID дублируется в домене или если одна сторона работает в stub/NSSA, а другая - нет.
show ip ospf neighbor
show ip ospf interface Gi0/1
show ip ospf interface Gi0/1 | include MTU
show ip protocols
show running-config | section router ospf
show ip ospf database
show access-lists
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤1
Почему после добавления нового VLAN пропадает связь
VLAN создан, access-порт назначен, но хосты не видят шлюз или друг друга.
Чаще всего проблема не в самом VLAN, а в транках и L3-части: VLAN не добавлен в allowed list на trunk, native VLAN не совпадает на сторонах линка, SVI не создан или в состоянии down/down.
Иногда VLAN не активируется, если нет ни одного up-порта в этом сегменте.
Команды для быстрой проверки:
Если VLAN не проходит по транку - добавить его в allowed list:
Если нужен L3-шлюз - создать и включить SVI:
После этого проверить ARP и доступность шлюза:
N.A.
VLAN создан, access-порт назначен, но хосты не видят шлюз или друг друга.
Чаще всего проблема не в самом VLAN, а в транках и L3-части: VLAN не добавлен в allowed list на trunk, native VLAN не совпадает на сторонах линка, SVI не создан или в состоянии down/down.
Иногда VLAN не активируется, если нет ни одного up-порта в этом сегменте.
Команды для быстрой проверки:
show vlan brief
show interfaces trunk
show running-config interface Gi0/1
show spanning-tree vlan <id>
show ip interface brief | include Vlan
show ip route connected
Если VLAN не проходит по транку - добавить его в allowed list:
interface Gi0/1
switchport trunk allowed vlan add <id>
Если нужен L3-шлюз - создать и включить SVI:
interface Vlan<id>
ip address 10.10.<id>.1 255.255.255.0
no shutdown
После этого проверить ARP и доступность шлюза:
show ip arp vlan <id>
ping 10.10.<id>.1
N.A.
👍13
Как сделать резервный интернет-канал с автоматическим переключением
Чтобы при падении основного провайдера трафик автоматически уходил на backup, используется IP SLA + track + floating static route.
1️⃣ Настроить IP SLA для проверки доступности внешнего узла:
2️⃣ Создать track-объект:
3️⃣ Основной маршрут через primary ISP:
4️⃣ Backup-маршрут с большей administrative distance:
5️⃣ Проверка работы переключения:
При падении primary SLA перестаёт получать ответы, track переходит в down, основной маршрут удаляется из RIB и трафик автоматически идёт через backup.
N.A.
Чтобы при падении основного провайдера трафик автоматически уходил на backup, используется IP SLA + track + floating static route.
ip sla 1
icmp-echo 8.8.8.8 source-interface Gi0/0
frequency 5
ip sla schedule 1 life forever start-time now
track 1 ip sla 1 reachability
ip route 0.0.0.0 0.0.0.0 1.1.1.1 track 1
ip route 0.0.0.0 0.0.0.0 2.2.2.2 200
show track 1
show ip sla statistics
show ip route 0.0.0.0
При падении primary SLA перестаёт получать ответы, track переходит в down, основной маршрут удаляется из RIB и трафик автоматически идёт через backup.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤2🥴1
5 команд для анализа L3 ECMP и распределения трафика
Даже когда ECMP настроен, трафик может концентрироваться на одном линке из-за hash-функций.
Эти команды помогут понять, как маршрутизатор реально распределяет потоки и почему часть линков простаивает.
Показывает, какие next-hop задействованы и порядок выбора.
CEF detail: next-hop, adjacency и hash, какие линк-пути используются.
Обзор распределения трафика по интерфейсам и подсетям.
Аппаратные счётчики, показывают, какой линк реально получает пакеты.
Смотрим, не «сбрасывает» ли ASIC пакеты из-за некорректного хеша или hardware limitation.
N.A.
Даже когда ECMP настроен, трафик может концентрироваться на одном линке из-за hash-функций.
Эти команды помогут понять, как маршрутизатор реально распределяет потоки и почему часть линков простаивает.
show ip route <prefix> detail
Показывает, какие next-hop задействованы и порядок выбора.
show ip cef <prefix> detail
CEF detail: next-hop, adjacency и hash, какие линк-пути используются.
show ip cef summary
Обзор распределения трафика по интерфейсам и подсетям.
show controllers ethernet-controller <interface> internal
Аппаратные счётчики, показывают, какой линк реально получает пакеты.
show platform hardware qfp active feature cef drop
Смотрим, не «сбрасывает» ли ASIC пакеты из-за некорректного хеша или hardware limitation.
N.A.
👍7❤1
Почему после включения Port-Security порт уходит в err-disable
Port-Security защищает сеть от нежелательных MAC-адресов, но при строгой настройке порта любое несоответствие правил вызывает блокировку.
⏺ На практике это проявляется так: на порту стоят IP-телефон и ПК, виртуальная машина на сервере, или случайно подключили другой коммутатор без согласования. Порт тут же падает, трафик прекращается, и STP перестраивает дерево.
🔎 Как проверить?
👨🎨 Как исправить
1️⃣ Временно восстановить порт:
2️⃣ Настроить лимит MAC или режим реакции:
3️⃣ Проверить актуальные MAC на порту и при необходимости добавить в allowed list:
N.A.
Port-Security защищает сеть от нежелательных MAC-адресов, но при строгой настройке порта любое несоответствие правил вызывает блокировку.
Порт переходит в err-disable, если на нём появляется больше MAC, чем разрешено, если новый MAC не в списке allowed, или если нарушается режим violation (shutdown).
show port-security interface Gi0/1
show port-security address
show interfaces status err-disabled
show mac address-table interface Gi0/1
interface Gi0/1
shutdown
no shutdown
interface Gi0/1
switchport port-security maximum 3
switchport port-security violation restrict
switchport port-security mac-address sticky
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9👎1
Forwarded from Сервер, сторадж & два свича
This media is not supported in your browser
VIEW IN TELEGRAM
Что будет, если героические способности уместить в компактную оболочку?
❓ новый герой Marvel
❓ настольный сервер для задач локального ИИ
❓ маленькая рабочая станция HP Z2 Mini G1a
Рассуждения в сторону, т.к. это тот самый случай, когда все варианты ответов верны!
А чтобы сомнения в могуществе этой машинки отпали раз и навсегда, подготовили небольшой видеообзор HP Z2 Mini G1a. Подсветили главные достоинства, конфигурации, области применения и даже провели наглядный тест — "как 128 ГБ памяти превращаются в локальный ИИ на 120 млрд параметров"
💬 Смотреть в MAX
📺 Смотреть на сайте
А совсем скоро ожидаем рабочую станцию Minisforum. Подписывайтесь, чтобы не пропустить обзор!
Сервер, сторадж & два свича
Реклама. ООО "ИТЕЛОН". ИНН 7701527528. erid: 2W5zFJmdLdo
Рассуждения в сторону, т.к. это тот самый случай, когда все варианты ответов верны!
А чтобы сомнения в могуществе этой машинки отпали раз и навсегда, подготовили небольшой видеообзор HP Z2 Mini G1a. Подсветили главные достоинства, конфигурации, области применения и даже провели наглядный тест — "как 128 ГБ памяти превращаются в локальный ИИ на 120 млрд параметров"
А совсем скоро ожидаем рабочую станцию Minisforum. Подписывайтесь, чтобы не пропустить обзор!
Сервер, сторадж & два свича
Реклама. ООО "ИТЕЛОН". ИНН 7701527528. erid: 2W5zFJmdLdo
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤1🤔1
Пинг проходит, а приложение не работает
ICMP отвечает, маршрут есть, latency нормальная - но сайт не открывается, API не отвечает, RDP/SSH зависает на этапе подключения. Это типичный случай, когда L3 жив, а проблема выше.
⏺ Вторая распространённая причина - stateful firewall. Пакеты могут доходить до сервера, но обратный трафик блокируется из-за отсутствия сессии в таблице состояний или из-за asymmetric routing. В логах - тишина, потому что дроп происходит «легально» по логике state engine.
⏺ Третий сценарий - асимметрия маршрутизации. Запрос идёт через один firewall или edge, а ответ возвращается через другой. Для ICMP это не критично, для TCP — критично. В результате handshake не завершается или соединение обрывается.
Также возможны проблемы на уровне L4–L7: неверный listener на сервере, сервис слушает не тот IP, TLS mismatch, истёкший сертификат, DNS возвращает неправильный адрес.
Пинг до IP проходит, но приложение недоступно по FQDN.
N.A.
ICMP отвечает, маршрут есть, latency нормальная - но сайт не открывается, API не отвечает, RDP/SSH зависает на этапе подключения. Это типичный случай, когда L3 жив, а проблема выше.
Чаще всего причина в несоответствии MSS/MTU: small ICMP-пакеты проходят, а крупные TCP-сегменты фрагментируются или silently дропаются. Особенно актуально для VPN, GRE, PPPoE и overlay-сетей.
Также возможны проблемы на уровне L4–L7: неверный listener на сервере, сервис слушает не тот IP, TLS mismatch, истёкший сертификат, DNS возвращает неправильный адрес.
Пинг до IP проходит, но приложение недоступно по FQDN.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11
NTP для больших сетей MikroTik: несколько серверов и failover
В корпоративной или разветвленной сети важно не просто синхронизировать время на одном роутере, а обеспечить резервирование и согласованность времени на всех устройствах.
⏺ Несколько NTP-серверов
Лучше указывать сразу несколько серверов, чтобы при недоступности одного синхронизация продолжалась с другим:
Первичные и вторичные серверы внутри сети гарантируют, что локальные устройства будут иметь корректное время даже при обрыве интернета.
⏺ Проверка и диагностика
Состояние клиента можно проверить так:
В выводе видны активные серверы и задержка до них. Высокая задержка или отсутствие ответа сигнализируют о проблемах с сетью или firewall.
⏺ Failover и последовательность
1️⃣ Внутренние серверы берут приоритет, если они доступны.
2️⃣ Внешние NTP сервера — резерв.
3️⃣ Если все недоступны — роутер использует локальные часы, но периодически пробует повторно синхронизироваться.
N.A.
В корпоративной или разветвленной сети важно не просто синхронизировать время на одном роутере, а обеспечить резервирование и согласованность времени на всех устройствах.
Лучше указывать сразу несколько серверов, чтобы при недоступности одного синхронизация продолжалась с другим:
/system ntp client set enabled=yes primary-ntp=192.168.1.10 secondary-ntp=192.168.1.11 server-dns-names=0.pool.ntp.org,1.pool.ntp.org
Первичные и вторичные серверы внутри сети гарантируют, что локальные устройства будут иметь корректное время даже при обрыве интернета.
Состояние клиента можно проверить так:
/system ntp client print
/system ntp servers print
В выводе видны активные серверы и задержка до них. Высокая задержка или отсутствие ответа сигнализируют о проблемах с сетью или firewall.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤3
Появился мощный инструмент для прохождения собеседований - Sobes Copilot.
Это нейросеть, которая подсказывает ответы прямо во время интервью, анализируя разговор в реальном времени.
Copilot работает незаметно в Zoom, Google Meet, Teams и других платформах. Поддерживает русский язык, не виден при демонстрации экрана и помогает держать уверенный темп диалога, даже если вопрос сложный или неожиданный.
Что ещё есть в Sobes Copilot:
Генератор резюме - превращает сырой опыт в сильное резюме под конкретную вакансию, с корректными формулировками и акцентами.
Мок-собеседования - тренировка с ИИ, максимально приближённые к реальным интервью: вопросы, фидбек, разбор ошибок.
Пост-анализ интервью - после созвона сервис разбирает диалог, подсвечивает сильные и слабые моменты.
Если хочешь проходить собесы спокойнее и увереннее — изучи возможности сервиса по ссылке.
🎁 Промокод: SOBES26 — даёт 10% скидки на старт.
Это нейросеть, которая подсказывает ответы прямо во время интервью, анализируя разговор в реальном времени.
Copilot работает незаметно в Zoom, Google Meet, Teams и других платформах. Поддерживает русский язык, не виден при демонстрации экрана и помогает держать уверенный темп диалога, даже если вопрос сложный или неожиданный.
Что ещё есть в Sobes Copilot:
Генератор резюме - превращает сырой опыт в сильное резюме под конкретную вакансию, с корректными формулировками и акцентами.
Мок-собеседования - тренировка с ИИ, максимально приближённые к реальным интервью: вопросы, фидбек, разбор ошибок.
Пост-анализ интервью - после созвона сервис разбирает диалог, подсвечивает сильные и слабые моменты.
Если хочешь проходить собесы спокойнее и увереннее — изучи возможности сервиса по ссылке.
🎁 Промокод: SOBES26 — даёт 10% скидки на старт.
3🗿6
Почему после добавления второго uplink трафик идёт неравномерно
Добавили второй uplink для увеличения пропускной способности, а трафик почему-то идёт почти только через один линк.
Причина чаще всего не в физике, а в логике маршрутизации: ECMP использует хеширование по 5-tuple (src/dst IP, src/dst port, protocol). Если сессий немного или все они имеют одинаковые адреса/порты, hash «схлопывается» на один путь.
Ещё возможна асимметричная маршрутизация: ответ идёт через другой линк, firewall/stateful inspection блокирует часть трафика, или маршруты не совпадают в разных VRF/таблицах.
Что проверить
⏺ show ip route <prefix> detail - какие next-hop реально используются.
⏺ show ip cef <prefix> detail - hash и adjacency для конкретного префикса.
⏺ show ip cef summary - распределение трафика по интерфейсам.
⏺ show controllers ethernet-controller <interface> internal - реальные счётчики, какой линк принимает пакеты.
⏺ show platform hardware qfp active feature cef drop - проверка, не сбрасывает ли ASIC пакеты из-за некорректного хеша.
N.A.
Добавили второй uplink для увеличения пропускной способности, а трафик почему-то идёт почти только через один линк.
Причина чаще всего не в физике, а в логике маршрутизации: ECMP использует хеширование по 5-tuple (src/dst IP, src/dst port, protocol). Если сессий немного или все они имеют одинаковые адреса/порты, hash «схлопывается» на один путь.
Также влияет L3 load-balancing: маршрутизатор распределяет пакеты по линкам на основе hash, а не равномерно по объёму. Поэтому маленькие потоки будут «привязаны» к одному интерфейсу.
Ещё возможна асимметричная маршрутизация: ответ идёт через другой линк, firewall/stateful inspection блокирует часть трафика, или маршруты не совпадают в разных VRF/таблицах.
Что проверить
show ip route <prefix> detail
show ip cef <prefix> detail
show ip cef summary
show controllers ethernet-controller <interface> internal
show platform hardware qfp active feature cef drop
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤1
🎥 Вебинар по Linux: GREP и другие регулярные выражения Linux
На вебинаре вы узнаете:
- Разберём, что такое регулярные выражения и в чём разница между их основными типами (Basic, Extended, PCRE)
- Узнаем, как не сломать grep, sed и awk одной неловкой скобкой и заставить их делать ровно то, что вам нужно.
- Составим шаблоны для логов, чтобы находить не просто «ошибки», а именно ту ошибку, которая мешает спать. И чтобы конфиги сами себя проверяли (ну, почти).
- Научимся отлаживать и тестировать регулярные выражения на практике.
В результате вебинара вы:
- Перестанете путать .* с .+ и будете знать, почему это важно.
- Научитесь писать выражения, которые работают с первого раза (ладно, со второго).
- Автоматизируете хотя бы одну рутину прямо на вебинаре. Хватит уже это делать руками.
- Уйдёте с готовыми шаблонами, которые не страшно показать коллегам.
👉 Для участия зарегистрируйтесь: https://otus.pw/k9z8/
🎁 Все участники вебинара получат специальные условия на полное обучение курса "Administrator Linux. Professional"
Курс от OTUS — для тех, кто хочет работать с Linux на уровне профессионала. Упор на Ubuntu 22.04 и реальные задачи: от RAID и LVM до сетей, firewall, мониторинга и тонкой настройки систем под нагрузку.
В программе: Zabbix, Prometheus, Nginx, Docker, ELK, Ansible, SELinux, BGP и другие инструменты, которые реально используются в продакшене.
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
На вебинаре вы узнаете:
- Разберём, что такое регулярные выражения и в чём разница между их основными типами (Basic, Extended, PCRE)
- Узнаем, как не сломать grep, sed и awk одной неловкой скобкой и заставить их делать ровно то, что вам нужно.
- Составим шаблоны для логов, чтобы находить не просто «ошибки», а именно ту ошибку, которая мешает спать. И чтобы конфиги сами себя проверяли (ну, почти).
- Научимся отлаживать и тестировать регулярные выражения на практике.
В результате вебинара вы:
- Перестанете путать .* с .+ и будете знать, почему это важно.
- Научитесь писать выражения, которые работают с первого раза (ладно, со второго).
- Автоматизируете хотя бы одну рутину прямо на вебинаре. Хватит уже это делать руками.
- Уйдёте с готовыми шаблонами, которые не страшно показать коллегам.
👉 Для участия зарегистрируйтесь: https://otus.pw/k9z8/
🎁 Все участники вебинара получат специальные условия на полное обучение курса "Administrator Linux. Professional"
Курс от OTUS — для тех, кто хочет работать с Linux на уровне профессионала. Упор на Ubuntu 22.04 и реальные задачи: от RAID и LVM до сетей, firewall, мониторинга и тонкой настройки систем под нагрузку.
В программе: Zabbix, Prometheus, Nginx, Docker, ELK, Ansible, SELinux, BGP и другие инструменты, которые реально используются в продакшене.
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
👍3👎1