12610
Обучающий канал по сетевому и системному администрированию. Сотрудничество: @dad_admin Биржа: https://telega.in/c/networkadm РКН: https://bit.ly/4ioc61C
TTL Security / GTSM для BGP
TTL Security (или GTSM - Generalized TTL Security Mechanism) ограничивает BGP-сессии так, чтобы соседний роутер мог «достучаться» только с ожидаемого количества хопов.
Любой пакет с меньшим TTL считается подозрительным и отбрасывается. Это защищает control-plane от spoofed BGP-пакетов и DoS через подмену source IP.
router bgp 65001
neighbor 10.0.0.2 remote-as 65002
neighbor 10.0.0.2 ttl-security hops 2
show bgp neighbors 10.0.0.2
show bgp summary
Давно планировал выучить Go, но не хотел тонуть в теории?
Курс «Golang-разработчик» в Слёрме стартует 30 января. Мы создали его для бэкенд-разработчиков и DevOps-инженеров, которые хотят сменить стек или научиться писать инфраструктурные инструменты на Go.
Важно: курс не для новичков.
Почему этот курс дает результат:
• 80% обучения — это практика. Вместо скучных лекций вы получите 53 часа прикладной работы.
• Спикер-практик. Обучение ведет Виталий Лихачев, SRE в Booking.com.
• Реальный проект в портфолио. Ты с нуля спроектируешь отказоустойчивый сервис на выбор: онлайн-банк, мессенджер или файловое хранилище.
Попробуй продукт бесплатно: мы открываем демо-доступ на 3 дня. Ты сможешь оценить платформу, подачу материала и решить, подходит ли тебе темп обучения, прежде чем платить.
👉 Занять место или получить демо-доступЧитать полностью…
👉 Проверь свои знания и получи полезные материалы от экспертов рынка.
Control Plane Policing (CoPP)
Control Plane Policing ограничивает трафик, направленный к самому устройству.
Data plane может быть в порядке, но перегруженный 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
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
service-policy input CP-POLICY
show policy-map control-plane
show processes cpu sorted
BFD для быстрого детекта линка
BFD (Bidirectional Forwarding Detection) позволяет обнаруживать падение линка за миллисекунды вместо секунд.
Это критично для OSPF, BGP и MPLS, где быстрый failover снижает влияние на приложения и сервисы.
interface Gi0/1
ip ospf bfd
router bgp 65001
neighbor 10.0.0.2 remote-as 65002
neighbor 10.0.0.2 fall-over bfd
show bfd neighbors
show bfd sessions
show bfd summary
show ip ospf neighbor
show ip ospf interface
debug bfd
mpls traffic-eng tunnels
mpls traffic-eng bfd
show mpls traffic-eng tunnels
show mpls traffic-eng bfd
Проверка резервных маршрутов
Redundant link может быть физически поднят, но маршрутизация или ACL могут блокировать трафик.
Иногда резервный линк выглядит активным, но пакеты по нему не идут. Проверка резервных маршрутов заранее позволяет убедиться, что failover сработает корректно, и экономит время при инцидентах.
Примеры команд на Cisco:
Проверка reachability через резервный путь:
ping 10.0.0.2 source 10.0.0.1
show ip route
traceroute 10.0.0.2
Почему стоит проверять качество кабельной разводки
Даже идеально настроенный коммутатор или роутер не спасёт сеть от проблем с плохими кабелями.
show interfaces status
show interfaces counters errors
test cable-diagnostics tdr interface Gi0/1
show cable-diagnostics tdr interface Gi0/1
Static route vs Dynamic route
Выбор между static и dynamic напрямую влияет на стабильность и управляемость сети.
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
network 192.168.1.0 0.0.0.255 area 0
Почему стоит проверять резервные пути и failover
Redundant link сам по себе не гарантирует стабильность сети.
Даже если линк поднят и маршруты выглядят корректно, приложения могут страдать: маршрутизация не пересчиталась, firewall блокирует новый путь, ECMP разбил сессии неправильно.
Пример практики на Cisco:
show ip route
show ip cef
ping 10.0.0.2 source 10.0.0.1
Failover стоит проверять регулярно - после изменений в конфигурации, апгрейда прошивки или добавления новых VLAN. Это снижает риск, что в момент инцидента резерв не сработает.
Почему SNMP community «public» опасен
По умолчанию на многих устройствах есть SNMP community public.
snmp-server community MySecret RO 10
snmp-server community MySecret RW 192.168.10.0 255.255.255.0
Когда стоит настраивать ECMP, а когда он только мешает
ECMP выглядит как очевидное улучшение: несколько равных путей, больше пропускная способность, меньше перегрузок.
Для stateless-трафика и большого количества потоков это действительно работает хорошо.
ECMP хорошо подходит для spine-leaf, DC-трафика, east-west потоков, где много коротких сессий и нет жёсткой привязки состояния к одному пути. Там он действительно даёт масштабирование.
Почему лучше явно задавать STP root, а не оставлять «по умолчанию»
Когда STP root не задан, сеть выбирает его сама - по наименьшему BID. Пока топология не меняется, всё выглядит стабильно и «работает». Проблемы начинаются в момент изменений.
spanning-tree vlan 10,20 priority 4096
spanning-tree vlan 10,20 root primary
show spanning-tree vlan 10
Зачем на транках отключать DTP, даже если соседи свои
DTP хорош, пока сеть маленькая и все помнят, что где включено.
В реальной жизни это редкость. Достаточно один раз перепутать порт или скопировать конфиг - и access внезапно начинает вести себя как trunk.
interface GigabitEthernet1/0/24
switchport mode trunk
switchport trunk allowed vlan 10,20,30
switchport nonegotiate
interface GigabitEthernet1/0/10
switchport mode access
switchport access vlan 20
switchport nonegotiate
show interfaces Gi1/0/24 switchport
Зачем ограничивать MAC-адреса на порту, если есть VLAN
VLAN изолирует трафик, но никак не ограничивает количество устройств за портом.
Для коммутатора access-порт по умолчанию готов принять десятки MAC-адресов, если они в одном VLAN.
interface GigabitEthernet1/0/10
switchport mode access
switchport access vlan 20
switchport port-security
switchport port-security maximum 2
switchport port-security violation restrict
switchport port-security mac-address sticky
switchport port-security violation shutdown
show port-security interface Gi1/0/10
show mac address-table interface Gi1/0/10
Почему сеть сложнее приложений?
Приложение можно уронить и поднять обратно. В худшем случае - откатить релиз или перезапустить контейнер.
Поэтому сеть не любит эксперименты в продакшене. Здесь нельзя просто «задеплоить и посмотреть».
Route leaking между VRF
VRF создают иллюзию жёсткой изоляции: разные таблицы маршрутизации, разные интерфейсы, всё аккуратно разложено.
Проблемы начинаются, когда маршруты из одного VRF внезапно появляются в другом - без явного intent.
vrf definition PROD
rd 65000:10
route-target export 65000:10
route-target export 65000:99
vrf definition MGMT
rd 65000:99
route-target import 65000:99
show vrf detail
show bgp vpnv4 unicast all
show ip route vrf PROD
show ip route vrf MGMT
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
show policy-map interface Gi0/1
show class-map
Хочешь освоить профессию 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
show interfaces counters errors
show interfaces status
Зачем проверять MTU перед поднятием VPN
MTU (Maximum Transmission Unit) определяет максимальный размер пакета, который может пройти по сети без фрагментации.
Для VPN это критично: инкапсуляция добавляет заголовки, и если MTU на пути меньше, пакеты начинают фрагментироваться или теряться.
ping 10.1.1.1 -M do -s 1472
interface Tunnel0
ip mtu 1400
ip tcp adjust-mss 1360
5 случаев, когда ECMP мешает больше, чем помогает
ECMP (Equal-Cost Multi-Path) выглядит как очевидная оптимизация: несколько равных маршрутов - больше пропускная способность, меньше перегрузок.
Для некоторых сценариев это действительно работает, но есть ситуации, когда ECMP создаёт больше проблем, чем пользы.
ip route add 10.0.0.0/24 nexthop via 192.168.1.1 nexthop via 192.168.2.1
Почему стоит включать logging на интерфейсах
Интерфейсы иногда падают, флапают или уходят в err-disable, и без логов вы просто не заметите проблему, пока не начнутся жалобы пользователей.
Логи показывают, что происходит на порту в реальном времени и помогают быстрее найти источник.
Пример на Cisco:
interface GigabitEthernet0/1
logging event link-status
logging buffered 10000
show logging
Почему нельзя смешивать 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
interface GigabitEthernet1/0/1
switchport mode access
switchport access vlan 99
interface GigabitEthernet1/0/24
switchport mode trunk
switchport trunk allowed vlan 10,20,99
vrf definition MGMT
rd 65000:99
interface Vlan99
vrf forwarding MGMT
ip address 10.99.0.10 255.255.255.0
Дедлайн Новый год стучится в дверь! 😊
Я думаю, что все устали и всем пора отдыхать, набираться сил. Все дедлайны позади, а о будущих думать пока не стоит! 😊
Я пожелаю Вам хороших каникул, счастья, здоровья, поменьше выгорания и успехов в новом году! 😊
С наступающим, 2026! 😊
На Stepik вышел курс по Linux
Внутри 20+ модулей: от установки Linux и работы с файлами до сетей, прав, дисков, процессов, автоматизации на Bash и многого другого. Всё сразу закрепляется на практике (200+ заданий с автопроверкой)
Материал подаётся понятным языком, шаг за шагом, на реальных примерах и с наглядными схемами.
После прохождения вы получите сертификат, который можно добавить в резюме.
Есть бесплатные демо-уроки для ознакомления. В ближайшие 48ч курс доступен со скидкой 25% по промокоду «ADMIN25»: открыть курс на Stepik
P.S. Курс можно купить в подарок на Новый год
Почему ACL лучше писать длиннее, но понятнее
Короткий ACL выглядит красиво и экономит строки, но на практике это почти всегда ловушка.
! Короткое ACL — вроде работает, но что именно разрешено?
access-list 101 permit tcp any any eq 80
access-list 101 permit tcp any any eq 443
access-list 101 permit udp any any range 5000 6000
! Длинное ACL — сразу понятно, для чего каждая строка
! Веб-трафик
access-list 101 permit tcp any any eq 80 comment Web HTTP
access-list 101 permit tcp any any eq 443 comment Web HTTPS
! UDP для приложений
access-list 101 permit udp any any range 5000 6000 comment App UDP
Когда L2-ошибка страшнее L3
L3 ломается громко и понятно. Нет маршрута - трафик не идёт. traceroute обрывается, логика очевидна: ищем, где потерялся next hop.
L2 ведёт себя иначе. Ошибка может существовать долго и выглядеть как «плавающая» проблема.
Ещё хуже, когда проблема затрагивает control-plane. STP пересчитывается слишком часто, порты то блокируются, то открываются, и сеть сама себя дестабилизирует. Это выглядит как деградация приложений, хотя корень проблемы — обычный L2.
Проблема: при построении высокоскоростных систем при использовании мощного GPU конфигурация часто упирается в скорость передачи данных из хранилища.
Решение: схема GPU-сервер с GDS + Сервер Dell PowerEdge R7725xd
Наглядно показываем, как организовать систему, в которой передача данных из хранилища в GPU происходит напрямую с минимальными задержками. Приятные сюрпризы ожидают специалистов, работающих с 1С и СУБД😉 Краткое пояснение оставили в карточках.
А подробнее о том, как такая архитектура реализована, для кого подходит, каких результатов достигает и что показали тесты — читайте в статье📲
Сервер, сторадж & два свича
Реклама. ООО "ИТЕЛОН". ИНН 7701527528. erid: 2W5zFJekSDW
📘 На Stepik вышел курс — «SRE-инженер: От основ до продакшена»
Хотите строить системы, которые не падают, управлять инцидентами без хаоса и внедрять культуру надёжности? Этот курс — полный путь SRE-инженера.
• SRE-фундамент: философия SRE, error budgets, toil reduction, blameless culture
• SLI/SLO/SLA: метрики надёжности, договорённости с бизнесом
• Observability: Prometheus, Grafana, ELK Stack, Jaeger, OpenTelemetry
• Алертинг: эффективные алерты, runbooks, on-call ротации
• Incident Management: классификация, эскалация, координация
• Post-mortem: root cause analysis, предотвращение повторений
• Отказоустойчивость: graceful degradation, circuit breakers, failover
• Chaos Engineering: Chaos Monkey, Litmus, Game Days
• Продакшен: High Availability, Disaster Recovery, RTO/RPO
🎓 Сертификат — добавьте в резюме или LinkedIn
🚀 Скидка 25%, действует 48 часов
👉 Пройти курс на Stepik