12610
Обучающий канал по сетевому и системному администрированию. Сотрудничество: @dad_admin Биржа: https://telega.in/c/networkadm РКН: https://bit.ly/4ioc61C
Как сделать резервный интернет-канал с автоматическим переключением
Чтобы при падении основного провайдера трафик автоматически уходил на backup, используется IP SLA + track + floating static route.
1️⃣Настроить IP SLA для проверки доступности внешнего узла:
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
Почему OSPF соседство не поднимается
Интерфейсы в состоянии up/up, IP-адреса корректные, но соседи в OSPF не переходят в Full.
Чаще всего причина в несовпадении параметров: area ID, network type, hello/dead timers, MTU или authentication.
224.0.0.5 блокируется ACL’ом.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
Поздравляем, скоро у вас будет еще один мини-Mikrotik
N.A.
Как понять, что firewall блокирует трафик «мимо правил»
Иногда кажется, что все правила настроены правильно, но трафик не проходит. Проблема часто кроется в особенностях stateful firewall.
show conn
show session all
show logging | include DROP
traceroute <destination>
show ip route
Почему SSL/TLS соединения падают при смене времени
Даже когда сертификаты вроде валидны и сервер доступен, HTTPS-сессии могут обрываться или выдавать ошибки handshake.
Основная причина в том, что TLS строго проверяет время: если системные часы сервера или клиента сильно отстают или опережают реальное время, сертификаты могут считаться просроченными или ещё не действительными.
show ntp status
date
openssl s_client -connect <host>:443
timedatectl
show logging | include NTP
Почему трафик концентрируется на одном линке в агрегированных каналах
Даже когда в сети настроено несколько линков через LACP / Port-Channel или ECMP, трафик иногда упорно идёт по одному физическому каналу. Интерфейсы подняты, агрегирование активно, но один линк перегружен, а остальные почти пустые.
Такое поведение часто вводит в заблуждение - кажется, что резервные линки «не работают», хотя на самом деле алгоритм распределения трафика делает именно так.
Если большинство сессий используют одинаковые параметры (например, много трафика к одному серверу или одному сервису), хэш-функция распределяет их на один линк.
show etherchannel summary
show interfaces port-channel 1
show interfaces Gi0/1 etherchannel
show etherchannel load-balance
show platform hardware port-channel statistics
5 команд для проверки ARP-таблицы
ARP - ключевой механизм для L2 ↔ L3 связи. Неправильные или устаревшие записи приводят к недоступности хостов, конфликтам IP и «рандомным» потерям пакетов.
show arp
show ip arp | include <IP_ADDRESS>
show ip arp | include <MAC_ADDRESS>
clear arp-cache
ping <IP_ADDRESS> repeat 5
MSS clamping в туннелях и WAN-линках
MSS clamping используется, чтобы TCP-сессии корректно работали поверх туннелей и каналов с уменьшенным MTU.
Без него соединение может устанавливаться нормально, но передача данных становится медленной, нестабильной или прерывается.
interface Tunnel0
ip tcp adjust-mss 1360
interface Dialer1
ip tcp adjust-mss 1452
policy-map MSS-CLAMP
class class-default
set tcp-mss 1360
interface Tunnel0
service-policy input MSS-CLAMP
Диагностика VLAN leakage
VLAN leakage - ситуация, когда трафик из одного VLAN неожиданно появляется в другом. Обычно это не «баг», а следствие ошибок в trunk-настройках, native VLAN или некорректного tagging’а.
⏺Основные источники VLAN leakage
Чаще всего проблема возникает из-за несовпадения native VLAN на транке, когда untagged трафик интерпретируется по-разному на соседних устройствах.
Второй частый сценарий - trunk mismatch: VLAN разрешён с одной стороны, но не с другой. Третья причина - устройства или гипервизоры, которые отправляют трафик без тегов там, где ожидается tagged frame.
⏺Проверка trunk-интерфейсов
show interfaces trunk
show running-config interface Gi0/24
show interfaces Gi0/24 switchport
show spanning-tree vlan <VLAN_ID>
show mac address-table vlan <VLAN_ID>
show mac address-table interface Gi0/24
show interfaces Gi0/24 counters errors
show vlan brief
Мифические продукты: мультивендорные NMS, автоматическое обнаружение устройств, построение топологии сети
26 февраля в 17:00 команда «Инфосистемы Джет» проведет открытый стрим, на котором разберет тему отсутствия по-настоящему мультивендорных решений и объяснит, почему универсальные системы управления сетью NMS до сих пор остаются скорее мечтой, чем реальностью. Эксперты расскажут, с какими архитектурными и технологическими ограничениями сталкиваются разработчики таких систем и к каким компромиссам приходят на практике. Отдельной темой станет ПО для автоматического обнаружения устройств и отрисовки сетевой топологии.
В программе стрима:
▪Ключевые функции (FCAPS) и компоненты систем управления сетью;
▪Разбор того, что получилось у создателей NMS Juniper Apstra: поддерживаемые архитектуры, производители, версии софта;
▪Проблематика создания NMS: подходы, транспорт, интерфейсы, формат данных, модели YANG, поддержка;
▪Системы отрисовки топологии: с доступом на оборудование и без доступа на оборудование;
▪Ответы спикеров на вопросы участников.
Стрим будет особенно полезен для специалистов, которые управляют сетевым оборудованием разных производителей, сталкиваются с ограничениями NMS и хотят разобраться в реальных возможностях и границах существующих технологий.
Чтобы попасть на стрим, не забудьте заранее зарегистрироваться на сайте.
Понимание и использование протокола DNSSEC
DNS — основа Интернета, но он подвержен атакам, таким как Man-in-the-Middle и Cache Poisoning, где злоумышленники могут подменить DNS-ответы.
DNSSEC (Domain Name System Security Extensions) решает эту проблему, обеспечивая защиту целостности и подлинности DNS-запросов с помощью криптографических методов.
Как работает DNSSEC?
⏺Цифровая подпись: Ответы DNS подписываются приватным ключом, а получатель может проверить их подлинность с помощью публичного ключа.
⏺Цепочка доверия: Публичные ключи проверяются через цепочку доверия, начиная с корневого DNS-сервера.
Почему это важно:
DNSSEC предотвращает:
• Man-in-the-Middle атаки — защита от подделки DNS-ответов.
• Cache Poisoning — защита от подмены данных в кэше DNS-сервера.
• Подделку ответов — гарантия, что данные не были изменены.
Как настроить DNSSEC?
1️⃣Генерация ключей: Создайте пару ключей (приватный и публичный) для домена.
2️⃣Подпись записей: Подпишите DNS-записи приватным ключом.
3️⃣Добавление записей на сервер: Обновите DNS-записи, добавив RRSIG и DNSKEY.
4️⃣Проверка: Убедитесь, что все записи правильно подписаны и работают.
N.A.
Как разделить management и пользовательский трафик
Смешивание management и пользовательского трафика кажется удобным «пока всё работает», но при перегрузке сети вы можете потерять доступ к оборудованию именно тогда, когда оно нужно для исправления проблем.
Отдельный management VLAN или VRF обеспечивает изоляцию и предсказуемость управления.
vlan 99
name MANAGEMENT
interface Vlan99
ip address 10.99.0.10 255.255.255.0
no shutdowninterface GigabitEthernet1/0/1
switchport mode access
switchport access vlan 99interface GigabitEthernet1/0/24
switchport mode trunk
switchport trunk allowed vlan 10,20,99vrf definition MGMT
rd 65000:99
interface Vlan99
vrf forwarding MGMT
ip address 10.99.0.10 255.255.255.0show vlan brief
show ip route vrf MGMT
ping vrf MGMT 10.99.0.10
5 команд для продвинутой диагностики QoS на L3 интерфейсе
Интерфейс зелёный, линк up, а приложения всё равно жалуются на задержки или потерю пакетов? Скорее всего, виноват QoS.
Даже небольшие ошибки в политике могут создавать узкие места, особенно для критичных сервисов. Вот как это проверить.
1️⃣Какая политика висит на интерфейсе:
show policy-map interface GigabitEthernet1/0/1
show policy-map interface GigabitEthernet1/0/1 class CRITICAL
show queueing interface GigabitEthernet1/0/1
show interfaces GigabitEthernet1/0/1 counters
show policy-map interface GigabitEthernet1/0/1 statistics
ARP / ND cache exhaustion
В больших сетях таблицы ARP (IPv4) и Neighbor Discovery (IPv6) могут переполняться.
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
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
ping 10.0.0.2 size 9000 df-bit
show interfaces Gi0/1
ip link set dev eth0 mtu 9000
ping -M do -s 8972 10.0.0.2
Почему после добавления нового VLAN пропадает связь
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
interface Gi0/1
switchport trunk allowed vlan add <id>
interface Vlan<id>
ip address 10.10.<id>.1 255.255.255.0
no shutdown
show ip arp vlan <id>
ping 10.10.<id>.1
🎥 Вебинар по Linux: С Windows на Linux: первый шаг системного администратора
На вебинаре вы узнаете:
- В чем принципиальные отличия Linux и Windows
- Какие базовые команды нужны для работы в консоли Linux
- Как устроена файловая система Linux и где искать нужные файлы
В результате вебинара вы:
- Научитесь выполнять базовые команды в терминале Linux
- Поймете структуру файловой системы и принципы работы с файлами
- Сможете устанавливать программы и управлять пакетами
- Разберетесь, как адаптироваться к Linux после Windows
👉 Для участия зарегистрируйтесь: https://otus.pw/oMpD/
🎁 Все участники вебинара получат специальные условия на полное обучение курса "Administrator Linux. Basic"
Курс создан для тех, кто хочет перейти от случайного опыта к уверенной работе с сервером. Вы освоите основы операционной системы, научитесь работать в Bash, поймёте, как устроены сети, научитесь запускать веб-сервисы, работать с MySQL, Docker, Git, Prometheus и Grafana. Это фундамент, без которого невозможен дальнейший рост.
👉 Повысить свои навыки: https://otus.pw/oMpD/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
IP-форвардинг в L2 и L3 сегментах
IP-пакеты «почему-то» не доходят, хотя линк поднят, VLAN настроен и маршруты вроде есть. В 90% случаев проблема в том, что вы путаете, что именно происходит на L2 и что на L3, и где сеть реально принимает решение «форвардить или нет».
📅 На открытом уроке 24 февраля в 20:00:
— Разберём, как передаются IP-пакеты внутри L2-сегмента и как меняется логика в L3-сегменте.
— Соберём L2 и L3 сегменты на практике и посмотрим, где именно возникают типовые ошибки в коммутации и маршрутизации.
Урок не для тех, кто ждёт «волшебные команды», не хочет разбираться в логике прохождения трафика и считает, что сети — это только «настроить VLAN и забыть».
👉 Записаться: https://otus.pw/4xlsj/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
🔥 likeabus channel 🔥
Канал сетевого архитектора с многолетним опытом в сетях, возглавляющего одно из сетевых направлений в крупнейшем облачном провайдере.
Сергей пишет про технологии внутри ЦОД, делится архитектурами, обзором различных новостей мира телеком, проводит митапы.
Ну и мемы тоже бывают, куда без мемов то! 🧐
Почему серверы теряют доступ к 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 могут рвать соединения. Сервер вроде отправляет пакеты, а ответы не доходят.
Как проверить
show ip arp
ping <gateway>
show ip route
show ip interface brief
show logging | include ARP
Что происходит при конфликте IP-адресов
IP-конфликт - это ситуация, когда два устройства в одной подсети считают один и тот же адрес «своим».
На бумаге всё выглядит корректно: маска правильная, gateway задан, линк зелёный. Но на уровне ARP начинается борьба за право отвечать на запросы.
На коммутаторе можно увидеть, что трафик для этого IP приходит то с одного порта, то с другого.
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-таблицы и её состояния:
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
show running-config interface Gi0/10
show mac address-table limit
show platform hardware capacity mac
show logging | include MAC
show logging | include SECURITY
show storm-control interface Gi0/10
show ip dhcp snooping
show ip arp inspection
🌐 Сети для всех — сообщество для тех, кто хочет разобраться в компьютерных сетях и системном администрировании.
👉 Наш Telegram-канал:
/channel/Networks_anyone
Внутри сообщества вас ждет:
- практические задания и разборы
- понятная теория без воды
- видеолекции и примеры конфигураций
- обсуждение реальных и нестандартных сетевых задач
- помощь и живое общение с единомышленниками
🎓 Курсы команды «Сети для всех»:
1️⃣ Компьютерные сети (Cisco — введение)
https://stepik.org/a/227855
2️⃣ Компьютерные сети (Cisco — продвинутый уровень)
https://stepik.org/a/230932
3️⃣ Компьютерные сети (MikroTik — практическое администрирование)
https://stepik.org/a/260615
👥 Более 300 студентов уже с нами — присоединяйтесь к сообществу и прокачивайте сети вместе с нами.
Сети для всех — понятно, практично, по делу.
#СетиДляВсех #NetworksForAll
Проверка интерфейсов на ошибки и flapping. Часть 2
Когда базовые счётчики «чистые», а проблемы всё равно всплывают, имеет смысл копать глубже - в тайминги, hardware-события и влияние интерфейса на control/data plane.
Команды расширенной диагностики на Cisco
show interfaces Gi0/1 | include rate
show interfaces Gi0/1 | include drops
show controllers ethernet-controller Gi0/1
show logging onboard ethernet Gi0/1
show interfaces Gi0/1 switching
show platform hardware interface Gi0/1 statistics
show event manager history events | include Gi0/1
show spanning-tree interface Gi0/1 detail
Проверка интерфейсов на ошибки и flapping
Даже когда интерфейс «зелёный», стоит регулярно проверять логи и статистику, чтобы убедиться в стабильности линка и отсутствии скрытых проблем.
Команды для диагностики на Cisco
show logging
show interfaces Gi0/1
show interfaces Gi0/1 counters errors
show interfaces status | include Gi0/1
show log | include Gi0/1
Статические и динамические маршруты: проверка и исправление
Даже когда сеть работает «в целом», неправильные или нестабильные маршруты могут вызывать flapping, асимметрию путей и проблемы с ECMP.
Правильная проверка и настройка маршрутов помогает поддерживать стабильность и предсказуемость сети.
show ip route static
show ip route <network>
ping <destination>
traceroute <destination>
show ip route ospf
show ip route bgp
show ip bgp summary
show ip route
show ip cef summary
show ip cef <prefix> detail
traceroute <prefix>
ping <prefix> repeat 10
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
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
router bgp 65001
neighbor 192.168.1.2 remote-as 65002
Как проверить и исправить скорость и дуплекс на коммутаторах и серверах
Даже если линк выглядит «зелёным», многие проблемы с 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
! Быстрая проверка состояния конкретного порта
interface Gi0/1
speed 1000
duplex full
no shutdownshow interfaces Gi0/1 status
show interfaces Gi0/1
ping <сервер-IP> repeat 100
Зачем явно задавать root bridge в STP
Если root bridge не назначен вручную, роль root получает коммутатор с наименьшим BID.
После перезагрузки, добавления нового коммутатора или замены железа root может неожиданно переехать, и трафик пойдёт по другим путям.
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
spanning-tree vlan 1 root primary
spanning-tree vlan 10 root secondary
spanning-tree vlan 1 priority 24576
spanning-tree vlan 10 priority 28672
ECMP pitfalls
На бумаге ECMP - мечта: несколько равных путей, балансировка, более высокая пропускная способность.
На деле же для stateful трафика это как «разбросанные дорожки»: пакеты одного соединения идут разными путями, и соединение начинает вести себя странно.
show ip route
show ip cef summary
ping 10.0.0.2 repeat 100
traceroute 10.0.0.2
UDLD aggressive mode
UDLD (Unidirectional Link Detection) помогает обнаруживать односторонние линки, когда физически интерфейс up, но трафик идёт только в одну сторону.
На L2 это особенно опасно: STP видит линк как рабочий, петли не детектятся, трафик теряется или ходит по странным путям.
udld enable
interface Gi0/1
udld port aggressive
interface TenGigabitEthernet1/1
udld port aggressive
show udld interface
show udld neighbors
show errdisable recovery
errdisable recovery cause udld
errdisable recovery interval 300