Правильное Питание (ПП) коммутационного оборудования
Система резервного электроснабжения должна обеспечивать не просто бесперебойное, но правильное питание. ПП — как у зожников, только для электроприборов. Много есть неочевидных нюансов — и первые в мире ПП-ИБП, решающие все проблемы с плохим качеством электричества, делает Systeme Electric.
Тотальный онлайн-ЗОЖ — онлайн Защита от Отключений Железа. ПП-ИБП Systeme Electric с онлайн-топологией двойного преобразования обеспечат чистый синус, защитят от помех и скачков напряжения.
Повышенная БЖУ — Бесперебойность Жизненно-важных Устройств. Тянут нагрузку в 150% от номинальной. Система не рухнет в момент включения мощных потребителей (именно в это время возникают краткосрочные, но сильные перегрузки).
Настоящий суперфуд для оборудования — высочайший КПД 95%. Из-за этого ПП-ИБП Systeme Electric не перегреваются.
Самое полное ПП-меню — поддерживают все возможные интерфейсы и протоколы (EPO, SNMP, RS-485, RS-232, USB, RJ45/RJ11, EMBS). Не будет сложностей с подключением нового бесперебойника к существующему оборудованию.
Гарантия рекордная — 3 года — такую больше никто не дает.
Техподдержка 24/7 (в мессенджерах, днем и по телефону): после 6 — можно!
ПП-ИБП Systeme Electric — это не какой-то китайский электро-фастфуд. Это бывшее российское подразделение Schneider Electric, производителя легендарных APC. Технологии и лучшая команда инженеров те же самые — только вывеска новая (из-за евросанкций). Эти люди точно знают: на здоровье оборудования не экономят!
Первые в мире ПП-ИБП тут.
Система резервного электроснабжения должна обеспечивать не просто бесперебойное, но правильное питание. ПП — как у зожников, только для электроприборов. Много есть неочевидных нюансов — и первые в мире ПП-ИБП, решающие все проблемы с плохим качеством электричества, делает Systeme Electric.
Тотальный онлайн-ЗОЖ — онлайн Защита от Отключений Железа. ПП-ИБП Systeme Electric с онлайн-топологией двойного преобразования обеспечат чистый синус, защитят от помех и скачков напряжения.
Повышенная БЖУ — Бесперебойность Жизненно-важных Устройств. Тянут нагрузку в 150% от номинальной. Система не рухнет в момент включения мощных потребителей (именно в это время возникают краткосрочные, но сильные перегрузки).
Настоящий суперфуд для оборудования — высочайший КПД 95%. Из-за этого ПП-ИБП Systeme Electric не перегреваются.
Самое полное ПП-меню — поддерживают все возможные интерфейсы и протоколы (EPO, SNMP, RS-485, RS-232, USB, RJ45/RJ11, EMBS). Не будет сложностей с подключением нового бесперебойника к существующему оборудованию.
Гарантия рекордная — 3 года — такую больше никто не дает.
Техподдержка 24/7 (в мессенджерах, днем и по телефону): после 6 — можно!
ПП-ИБП Systeme Electric — это не какой-то китайский электро-фастфуд. Это бывшее российское подразделение Schneider Electric, производителя легендарных APC. Технологии и лучшая команда инженеров те же самые — только вывеска новая (из-за евросанкций). Эти люди точно знают: на здоровье оборудования не экономят!
Первые в мире ПП-ИБП тут.
❤5🤔2
Почему после изменения ACL пропадает доступ к части сети
Настроили новый ACL на интерфейсе или между сегментами, но часть сервисов перестала отвечать: одни IP доступны, другие нет, часть приложений зависает на таймаутах.
Чаще всего проблема не в самом ACL, а в порядке правил и скрытых “deny any” в конце. Также часто забывают про обратный трафик, из-за чего запрос проходит, а ответ блокируется.
Типовые причины:⏺ правило блокирует обратный трафик (return traffic) ⏺ ACL применён не в том направлении (in/out) ⏺ отсутствуют разрешения для established/related соединений ⏺ правило выше по списку перекрывает нужный allow ⏺ забытый implicit deny в конце списка ⏺ ACL применён только на одном интерфейсе в цепочке
Команды для проверки:
Проверка пути:
Проверка логики ACL:
Если проблема в направлении применения ACL:
Если ломается из-за порядка правил — правило выше перекрывает нужный трафик, поэтому проверять нужно сверху вниз, а не по смыслу.
N.A.
Настроили новый ACL на интерфейсе или между сегментами, но часть сервисов перестала отвечать: одни IP доступны, другие нет, часть приложений зависает на таймаутах.
Чаще всего проблема не в самом ACL, а в порядке правил и скрытых “deny any” в конце. Также часто забывают про обратный трафик, из-за чего запрос проходит, а ответ блокируется.
Типовые причины:
Команды для проверки:
show access-lists
show ip interface
show run interface Gi0/0
debug ip packet
(аккуратно в проде)
Проверка пути:
traceroute <ip>
ping <ip>
Проверка логики ACL:
show access-lists <name>
Если проблема в направлении применения ACL:
interface Gi0/0
ip access-group <name> in
ip access-group <name> out
Если ломается из-за порядка правил — правило выше перекрывает нужный трафик, поэтому проверять нужно сверху вниз, а не по смыслу.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤1🥱1
Почему после добавления VLAN пропадает связь
Добавили VLAN, всё выглядит корректно, но хосты внезапно перестают видеть шлюз или друг друга. При этом линк “зелёный”, порты up, явных ошибок нет.
Проверка обычно начинается с того, что VLAN вообще существует и не потерялся на уровне коммутатора.
Дальше почти всегда упирается в транк: VLAN создан, но между устройствами он просто не доходит.
Если с транком всё ок, проверяется интерфейс с точки зрения реальной конфигурации, а не ожиданий.
Если есть L3, дальше смотрят SVI - и тут часто оказывается, что интерфейс просто не поднялся.
Проверка маршрутов иногда быстро подтверждает картину.
N.A.
Добавили VLAN, всё выглядит корректно, но хосты внезапно перестают видеть шлюз или друг друга. При этом линк “зелёный”, порты up, явных ошибок нет.
Проверка обычно начинается с того, что VLAN вообще существует и не потерялся на уровне коммутатора.
show vlan brief
Дальше почти всегда упирается в транк: VLAN создан, но между устройствами он просто не доходит.
show interfaces trunk
Если с транком всё ок, проверяется интерфейс с точки зрения реальной конфигурации, а не ожиданий.
show running-config interface Gi0/1
Если есть L3, дальше смотрят SVI - и тут часто оказывается, что интерфейс просто не поднялся.
show ip interface brief | include Vlan
Проверка маршрутов иногда быстро подтверждает картину.
show ip route connected
N.A.
👍12❤2💯1
Почему сервис “умирает” после включения retry
Retry включили на клиенте или gateway, и вместо стабилизации получили рост нагрузки и ощущение деградации, хотя инфраструктура не менялась.
Дальше это проявляется как рост latency и “тяжёлые” ответы, даже если сервис формально не падает.
Если посмотреть на уровень пакетов:
На HTTP уровне это превращается в повторяющиеся обращения к одному endpoint без необходимости.
N.A.
Retry включили на клиенте или gateway, и вместо стабилизации получили рост нагрузки и ощущение деградации, хотя инфраструктура не менялась.
curl -v <url>
Дальше это проявляется как рост latency и “тяжёлые” ответы, даже если сервис формально не падает.
mtr <ip>
Если посмотреть на уровень пакетов:
tcpdump -i <iface>
На HTTP уровне это превращается в повторяющиеся обращения к одному endpoint без необходимости.
curl -I <url>
N.A.
👍5❤2
Почему “не видно проблему” в сети, пока не посмотришь состояние TCP очередей
Иногда сервис не падает, но начинает “вязнуть”: запросы идут, ответы есть, но задержки растут без очевидной причины.
В таких случаях полезно смотреть не соединения как факт, а их внутреннее состояние в ядре.
Почему “всё открывается”, но часть запросов теряется
Бывает ситуация, когда сеть вроде бы живая, но часть пакетов просто не доходит. Это не видно на уровне приложения, пока не посмотреть статистику интерфейса.
Почему DNS “работает”, но поведение разное у клиентов
Иногда проблема вообще не в резолвинге как таковом, а в том, как ядро кеширует и повторно использует результаты.
N.A.
Иногда сервис не падает, но начинает “вязнуть”: запросы идут, ответы есть, но задержки растут без очевидной причины.
В таких случаях полезно смотреть не соединения как факт, а их внутреннее состояние в ядре.
ss -tin state established
Почему “всё открывается”, но часть запросов теряется
Бывает ситуация, когда сеть вроде бы живая, но часть пакетов просто не доходит. Это не видно на уровне приложения, пока не посмотреть статистику интерфейса.
ip -s link show <iface>
Почему DNS “работает”, но поведение разное у клиентов
Иногда проблема вообще не в резолвинге как таковом, а в том, как ядро кеширует и повторно использует результаты.
getent ahosts <domain>
N.A.
👍6❤1
Cisco: Private VLAN для изоляции устройств
Private VLAN (PVLAN) — это механизм L2-изоляции внутри одного большого VLAN.
Используется там, где клиенты должны видеть интернет, но не видеть друг друга: отели, коворкинги, общественные сети.
Как это работает:
PVLAN делит один VLAN на подтипы:
⏺ Primary VLAN — основной VLAN.
⏺ Isolated VLAN — хосты не могут общаться между собой, только с promiscuous-портом.
⏺ Promiscuous port — обычно uplink к маршрутизатору/фаерволу. Видит всех.
В итоге, 100 клиентов в одном VLAN → каждый полностью изолирован, без создания сотен отдельных VLAN.
⚙️ Конфигурация PVLAN на Cisco
1️⃣ Создаём primary и isolated VLAN
2️⃣ Связываем их
3️⃣ Настраиваем promiscuous порт (uplink)
4️⃣ Настраиваем обычные клиентские порты (isolated)
И финально проверяем
N.A.
Private VLAN (PVLAN) — это механизм L2-изоляции внутри одного большого VLAN.
Используется там, где клиенты должны видеть интернет, но не видеть друг друга: отели, коворкинги, общественные сети.
Как это работает:
PVLAN делит один VLAN на подтипы:
В итоге, 100 клиентов в одном VLAN → каждый полностью изолирован, без создания сотен отдельных VLAN.
vlan 100
private-vlan primary
vlan 101
private-vlan isolated
vlan 100
private-vlan association 101
interface Gi1/0/1
switchport mode private-vlan promiscuous
switchport private-vlan mapping 100 101
interface range Gi1/0/10 - 20
switchport mode private-vlan host
switchport private-vlan host-association 100 101
И финально проверяем
show vlan private-vlan
show interfaces switchport
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍9❤2
Разное поведение DNS у разных клиентов
Снаружи всё выглядит одинаково, но поведение разъезжается по группам клиентов.
Первое, что обычно всплывает — не сами ответы DNS, а то, как они кешируются и переиспользуются в системе.
Дальше полезно посмотреть не “что резолвится”, а как именно система выбирает адреса и в каком порядке.
Следующий слой - системные кеши и библиотечный резолвинг, который вообще не виден через обычные проверки.
N.A.
Сервис у части пользователей работает нормально, у части периодически “проваливается” или уходит в странные задержки.
Снаружи всё выглядит одинаково, но поведение разъезжается по группам клиентов.
Первое, что обычно всплывает — не сами ответы DNS, а то, как они кешируются и переиспользуются в системе.
resolvectl query <domain>
Дальше полезно посмотреть не “что резолвится”, а как именно система выбирает адреса и в каком порядке.
getent ahostsv4 <domain>
Следующий слой - системные кеши и библиотечный резолвинг, который вообще не виден через обычные проверки.
strace -e trace=network -f curl -s <url>
N.A.
👍9
Service работает через IP, не через DNS
Сервис открывается по IP нормально, но по доменному имени начинает вести себя странно: таймауты, разные ответы, иногда вообще “не тот” backend.
Часто это, когда клиент и DNS живут разной жизнью: IP уже поменялся, а часть систем продолжает ходить по старым записям.
Дальше полезно посмотреть, что реально возвращается не “в теории”, а в контексте системы.
N.A.
Сервис открывается по IP нормально, но по доменному имени начинает вести себя странно: таймауты, разные ответы, иногда вообще “не тот” backend.
Часто это, когда клиент и DNS живут разной жизнью: IP уже поменялся, а часть систем продолжает ходить по старым записям.
resolvectl status
Дальше полезно посмотреть, что реально возвращается не “в теории”, а в контексте системы.
getent hosts <domain>
ip route get <ip>
curl -v --resolve <domain>:443:<ip> https://<domain>
N.A.
👍8
Неравномерное распределение трафика LB
⏺ Снаружи всё выглядит нормально: LB живой, backend’ы подняты, трафик есть, но один инстанс стабильно перегружен, а остальные почти пустые.
Распределение часто ломается не на уровне новых подключений, а на уровне уже установленных сессий и того, как они “прилипают” к backend’ам.
⏺ По общей картине видно, что соединения есть, но это ничего не говорит о том, как они распределены между нодами и как долго живут.
Если разложить соединения глубже, становится заметно, что часть клиентов держит длинные сессии и фактически закрепляется за конкретным backend’ом.
⏺ И именно эти долгоживущие соединения начинают создавать перекос: новые запросы уже не успевают “выровнять” баланс.
Иногда эффект усиливается просто из-за того, что клиенты создают разное количество соединений и неравномерно их переиспользуют.
⏺ При повторных запросах можно заметить, что ответы стабильно приходят с одних и тех же backend’ов, даже если ожидается равномерное распределение.
N.A.
Распределение часто ломается не на уровне новых подключений, а на уровне уже установленных сессий и того, как они “прилипают” к backend’ам.
ss -s
Если разложить соединения глубже, становится заметно, что часть клиентов держит длинные сессии и фактически закрепляется за конкретным backend’ом.
ss -tn sport = :80
Иногда эффект усиливается просто из-за того, что клиенты создают разное количество соединений и неравномерно их переиспользуют.
curl -I <url>
ipvsadm -Ln
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤2
5 команд, которые реально помогают ловить “невидимые” сетевые проблемы
1️⃣ TCP-состояние и скрытые retransmit’ы
Когда сервис “живой”, но всё тормозит - обычные проверки ничего не показывают. Тут полезно смотреть, что происходит прямо в TCP-очередях.
2️⃣ Реальное поведение маршрута ядра (а не “как должно быть”)
Иногда проблема не в сети, а в том, куда система на самом деле отправляет трафик.
3️⃣ Где именно ломается соединение (DNS / connect / TLS / HTTP)
Когда всё “медленно”, важно понять, на каком этапе зависает запрос.
4️⃣ Потери, которые не видно через ping
ICMP может быть чистым, а TCP уже страдает. Нужен более честный взгляд на поток.
5️⃣ Реальная картина очередей и backpressure
Когда система “не падает, но не отвечает” - это почти всегда очереди.
N.A.
Когда сервис “живой”, но всё тормозит - обычные проверки ничего не показывают. Тут полезно смотреть, что происходит прямо в TCP-очередях.
ss -ti state all
Иногда проблема не в сети, а в том, куда система на самом деле отправляет трафик.
ip route get <ip>
Когда всё “медленно”, важно понять, на каком этапе зависает запрос.
curl -w "@-" -o /dev/null -s <url>
ICMP может быть чистым, а TCP уже страдает. Нужен более честный взгляд на поток.
mtr -T -P 443 <host>
Когда система “не падает, но не отвечает” - это почти всегда очереди.
ss -ltnp
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍6
Traceroute не совпадает с реальным путём
Сервис ведёт себя так, будто трафик идёт по одному маршруту, но traceroute показывает совсем другую картину.
При этом ping может быть стабильным, а задержки появляться “внезапно” и без логики.
⏺ Дело в том, что traceroute показывает не путь пакета, а поведение промежуточных узлов, которые могут по-разному отвечать на TTL-expired. В реальности трафик часто идёт через ECMP или policy routing, которые в traceroute просто не видны.
Иногда расхождение усиливается из-за балансировки на уровне ядра или оборудования, когда разные потоки уходят по разным линкам, а traceroute показывает только один из возможных путей.
N.A.
Сервис ведёт себя так, будто трафик идёт по одному маршруту, но traceroute показывает совсем другую картину.
При этом ping может быть стабильным, а задержки появляться “внезапно” и без логики.
traceroute <ip>
ip route get <ip>
Иногда расхождение усиливается из-за балансировки на уровне ядра или оборудования, когда разные потоки уходят по разным линкам, а traceroute показывает только один из возможных путей.
mtr -T <ip>
tracepath <ip>
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤1
VTP - почему его лучше отключить и как безопасно мигрировать без него
VTP (VLAN Trunking Protocol) автоматически синхронизирует VLAN-базу между коммутаторами. Звучит удобно, но по факту это бомба замедленного действия.
Главная проблема, что любой коммутатор с более высоким revision number перезапишет VLAN-базу на всех остальных. Подключил старый свич из кладовки, и все VLAN на продакшене слетели.
Почему отключают:
⏺ Один неверный свич уничтожает всю VLAN-конфигурацию сети
⏺ Сложно контролировать изменения - нет нормального аудита
⏺ VTP v1/v2 не поддерживает extended VLAN (
⏺ В современных сетях проще и безопаснее управлять VLAN вручную или через автоматизацию
Как безопасно мигрировать
1️⃣ Сначала зафиксируй текущую VLAN-базу на VTP Server
Сохрани список всех активных VLAN - это твой эталон.
2️⃣ Переводи коммутаторы в VTP Transparent по одному, начиная с краёв сети
Transparent не синхронизирует VLAN с другими, но передаёт VTP-объявления дальше - сеть не ломается сразу.
3️⃣ Убеждаешься, что VLAN-база на каждом свиче совпадает с эталоном
4️⃣ Когда все переведены в Transparent - можно отключить VTP полностью (VTP v3)
В v1/v2 режима off нет, Transparent - финальная точка.
5️⃣ Дальше VLAN управляются вручную на каждом свиче или через Ansible/Netmiko.
⚡️ Revision number обнуляется при смене VTP domain или переключении в Transparent. Если срочно нужно обезвредить «опасный» свич перед подключением - меняй domain name на любой другой.
N.A.
VTP (VLAN Trunking Protocol) автоматически синхронизирует VLAN-базу между коммутаторами. Звучит удобно, но по факту это бомба замедленного действия.
Главная проблема, что любой коммутатор с более высоким revision number перезапишет VLAN-базу на всех остальных. Подключил старый свич из кладовки, и все VLAN на продакшене слетели.
Почему отключают:
1006–4094)Как безопасно мигрировать
show vlan brief
show vtp status
Сохрани список всех активных VLAN - это твой эталон.
vtp mode transparent
Transparent не синхронизирует VLAN с другими, но передаёт VTP-объявления дальше - сеть не ломается сразу.
show vlan brief
vtp mode off
В v1/v2 режима off нет, Transparent - финальная точка.
⚡️ Revision number обнуляется при смене VTP domain или переключении в Transparent. Если срочно нужно обезвредить «опасный» свич перед подключением - меняй domain name на любой другой.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍2🔥2
OSPF: сосед завис в EXSTART/EXCHANGE
EXSTART/EXCHANGE - это этап, где два OSPF-соседа договариваются об обмене LSA. Если сосед завис здесь, база топологии не синхронизируется и маршруты не появятся.
⏺ Три главные причины: MTU mismatch (самая частая, DD-пакеты не проходят если MTU разный), дублирующийся Router ID (два роутера с одинаковым RID не могут завершить negotiation), проблемы аутентификации (пакеты уходят, но отклоняются на другой стороне).
Диагностика
Смотрим состояние соседа:
Если сосед висит в EXSTART/EXCHANGE больше нескольких секунд, уже проблема.
1️⃣ Проверяем MTU
На обоих роутерах значение должно совпадать. Либо выравниваем MTU, либо отключаем проверку:
2️⃣ Проверяем дублирующийся Router ID
RID должен быть уникальным в домене. Меняем вручную и перезапускаем процесс:
3️⃣ Проверяем аутентификацию
Тип аутентификации и ключ должны совпадать на обоих концах. Если используется MD5:
N.A.
EXSTART/EXCHANGE - это этап, где два OSPF-соседа договариваются об обмене LSA. Если сосед завис здесь, база топологии не синхронизируется и маршруты не появятся.
Диагностика
Смотрим состояние соседа:
show ip ospf neighbor
Если сосед висит в EXSTART/EXCHANGE больше нескольких секунд, уже проблема.
show interfaces Gi0/0 | include MTU
На обоих роутерах значение должно совпадать. Либо выравниваем MTU, либо отключаем проверку:
interface Gi0/0
ip ospf mtu-ignore
show ip ospf | include Router ID
RID должен быть уникальным в домене. Меняем вручную и перезапускаем процесс:
router ospf 1
router-id 1.1.1.1
clear ip ospf process
show ip ospf interface Gi0/0
Тип аутентификации и ключ должны совпадать на обоих концах. Если используется MD5:
interface Gi0/0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 <key>
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤1
Wireshark фильтры для диагностики VLAN-трафика
Быстрая шпаргалка для тех, кто разбирает проблемы на trunk-портах или отлавливает трафик конкретного VLAN.
Базовые фильтры
Показать все 802.1Q фреймы, сузить до конкретного VLAN ID или до трафика одного хоста внутри него. Отправная точка для любой диагностики:
ARP, DHCP, STP
ARP помогает отловить конфликты IP и посмотреть кто отвечает на запросы. DHCP покажет, доходят ли Discover-пакеты до сервера. STP нужен когда подозреваешь петлю или нестабильную топологию:
Трафик между двумя хостами и очистка от служебного
Первый фильтр изолирует сессию между конкретными хостами. Второй убирает CDP, LLDP и STP, когда нужно смотреть только на пользовательский трафик без шума:
Double-tag и QoS
Первый фильтр ловит QinQ-фреймы или признаки VLAN hopping, когда внутри тегированного фрейма есть ещё один тег. Второй фильтрует по значению CoS, полезно при диагностике приоритизации трафика:
N.A.
Быстрая шпаргалка для тех, кто разбирает проблемы на trunk-портах или отлавливает трафик конкретного VLAN.
Базовые фильтры
Показать все 802.1Q фреймы, сузить до конкретного VLAN ID или до трафика одного хоста внутри него. Отправная точка для любой диагностики:
vlan
vlan.id == 10
vlan.id == 10 && ip.addr == 192.168.10.5
ARP, DHCP, STP
ARP помогает отловить конфликты IP и посмотреть кто отвечает на запросы. DHCP покажет, доходят ли Discover-пакеты до сервера. STP нужен когда подозреваешь петлю или нестабильную топологию:
vlan.id == 10 && arp
vlan.id == 10 && bootp
vlan.id == 10 && stp
Трафик между двумя хостами и очистка от служебного
Первый фильтр изолирует сессию между конкретными хостами. Второй убирает CDP, LLDP и STP, когда нужно смотреть только на пользовательский трафик без шума:
vlan.id == 20 && ip.addr == 192.168.20.1 && ip.addr == 192.168.20.2
vlan.id == 10 && !stp && !cdp && !lldp
Double-tag и QoS
Первый фильтр ловит QinQ-фреймы или признаки VLAN hopping, когда внутри тегированного фрейма есть ещё один тег. Второй фильтрует по значению CoS, полезно при диагностике приоритизации трафика:
vlan.id == 100 && vlan
vlan.priority == 5
N.A.
👍8❤1
LACP vs Static LAG: когда что использовать
LAG (Link Aggregation Group) объединяет несколько физических линков в один логический. Два способа это сделать: статически или через LACP. Разница принципиальная.
⏺ Static LAG просто объединяет порты без какого-либо согласования. Коммутатор не знает, что происходит на другой стороне, линк считается активным даже если там ничего нет. Быстро настраивается, но слепо.
⏺ LACP (802.3ad) согласовывает агрегат через обмен LACPDU-пакетами. Оба конца знают о состоянии линков, при падении одного порта трафик перераспределяется автоматически. Чуть сложнее в настройке, но надёжнее.
Статику используют когда другая сторона не поддерживает LACP, например старое оборудование или некоторые гипервизоры. В остальных случаях лучше LACP.
Настройка на Cisco
Static LAG:
LACP (active инициирует согласование, passive ждёт):
Проверка агрегата
Смотрим статус Port-Channel и какие порты в него входят:
В выводе show etherchannel summary флаги говорят всё: P - порт в бандле, D - порт упал, S - suspended. Если видишь I (individual) вместо P, порт не попал в агрегат, скорее всего несовпадение настроек speed/duplex или native VLAN.
N.A.
LAG (Link Aggregation Group) объединяет несколько физических линков в один логический. Два способа это сделать: статически или через LACP. Разница принципиальная.
Статику используют когда другая сторона не поддерживает LACP, например старое оборудование или некоторые гипервизоры. В остальных случаях лучше LACP.
Настройка на Cisco
Static LAG:
interface range Gi0/1 - 2
channel-group 1 mode on
LACP (active инициирует согласование, passive ждёт):
interface range Gi0/1 - 2
channel-group 1 mode active
Проверка агрегата
Смотрим статус Port-Channel и какие порты в него входят:
show etherchannel summary
show lacp neighbor
В выводе show etherchannel summary флаги говорят всё: P - порт в бандле, D - порт упал, S - suspended. Если видишь I (individual) вместо P, порт не попал в агрегат, скорее всего несовпадение настроек speed/duplex или native VLAN.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍2
Bonding на Linux: mode 802.3ad и проверка активных линков
Bonding в Linux это аналог LAG на уровне ОС. Mode 802.3ad (LACP) объединяет интерфейсы в агрегат с динамическим согласованием, как на Cisco mode active.
Для работы нужен пакет ifenslave и загруженный модуль bonding:
Настройка через systemd-networkd
Создаём bond-интерфейс:
Привязываем физические интерфейсы к бонду:
Назначаем IP на bond0:
Проверка
Статус агрегата и активных линков:
Покажет режим, активные интерфейсы, состояние LACP и MII каждого слейва. Если слейв показывает MII Status: down, физический линк не поднят или коммутатор не согласовал LACP.
Быстрая проверка через ip:
N.A.
Bonding в Linux это аналог LAG на уровне ОС. Mode 802.3ad (LACP) объединяет интерфейсы в агрегат с динамическим согласованием, как на Cisco mode active.
Для работы нужен пакет ifenslave и загруженный модуль bonding:
modprobe bonding
apt install ifenslave
Настройка через systemd-networkd
Создаём bond-интерфейс:
# /etc/systemd/network/bond0.netdev
[NetDev]
Name=bond0
Kind=bond
[Bond]
Mode=802.3ad
LACPTransmitRate=fast
MIIMonitorSec=100ms
Привязываем физические интерфейсы к бонду:
# /etc/systemd/network/bond-slave.network
[Match]
Name=eth0 eth1
[Network]
Bond=bond0
Назначаем IP на bond0:
# /etc/systemd/network/bond0.network
[Match]
Name=bond0
[Network]
Address=192.168.1.10/24
Gateway=192.168.1.1
Проверка
Статус агрегата и активных линков:
cat /proc/net/bonding/bond0
Покажет режим, активные интерфейсы, состояние LACP и MII каждого слейва. Если слейв показывает MII Status: down, физический линк не поднят или коммутатор не согласовал LACP.
Быстрая проверка через ip:
ip link show bond0
ip -d link show bond0
N.A.
👍6
Документирование сети кажется рутинной задачей, но на практике - это ключ к быстрому восстановлению, анализу и масштабированию. Вот как делать это по шагам.
Фиксируем все устройства, IP, VLAN, интерфейсы и протоколы маршрутизации.
Команды:
ip addr show # список интерфейсов
ip route show # таблица маршрутов
vtysh -c "show running-config" # конфиги роутеров
show vlan brief # VLAN на коммутаторах
2️⃣Структурирование: Систематизируем данные: топология, IP-план, протоколы, ACL/Firewall.
Пример таблицы IP:
Устройство | Интерфейс | IP | VLAN | Примечание
-----------|-----------|--------------|------|------------
r1 | eth0 | 10.0.1.1/24 | 10 | WAN
sw1 | vlan10 | 10.0.1.2/24 | 10 | серверная зона
sw2 | vlan20 | 10.0.2.1/24 | 20 | офисная зона
server1 | eth1 | 10.0.1.10/24 | 10 | база данных
server2 | eth1 | 10.0.1.11/24 | 10 | веб-сервер
git init
git add configs/
git commit -m "Добавлен новый VLAN 20 на sw2"
Пример Mermaid:
graph TD
R1 --> SW1
SW1 --> Server1
SW1 --> Server2
Полезные команды для контроля
git log --oneline --graph # история изменений
diff old_config new_config # что изменилось
ping 10.0.1.2 # проверить доступность после изменений
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14
STP Port States: почему порт долго висит в Listening/Learning
STP переводит порт через несколько состояний перед тем как начать передавать трафик. Blocking, Listening, Learning, Forwarding. В норме переход занимает 30 секунд (15 сек Listening + 15 сек Learning). Если порт завис и не переходит в Forwarding, сеть на этом сегменте не работает.
⏺ Чаще всего дело в одном из трёх: некорректно выбран Root Bridge и порт пересчитывает топологию, на порту включён TCN (Topology Change Notification) и STP постоянно переинициализируется, или PortFast не включён там где должен быть.
⏺ Диагностика
Смотрим состояние портов и кто Root Bridge:
Проверяем TCN, частые topology change говорят о нестабильном линке или петле:
⏺ Что делать?
Если порт ведёт к конечному устройству (PC, сервер, принтер), включаем PortFast. Порт сразу переходит в Forwarding, минуя Listening/Learning:
Если TCN генерирует конкретный порт, включаем BPDU Guard. При получении BPDU порт уходит в err-disabled вместо того чтобы ломать топологию:
Глобально для всех PortFast-портов:
N.A.
STP переводит порт через несколько состояний перед тем как начать передавать трафик. Blocking, Listening, Learning, Forwarding. В норме переход занимает 30 секунд (15 сек Listening + 15 сек Learning). Если порт завис и не переходит в Forwarding, сеть на этом сегменте не работает.
Смотрим состояние портов и кто Root Bridge:
show spanning-tree
show spanning-tree detail
Проверяем TCN, частые topology change говорят о нестабильном линке или петле:
show spanning-tree detail | include topology change
Если порт ведёт к конечному устройству (PC, сервер, принтер), включаем PortFast. Порт сразу переходит в Forwarding, минуя Listening/Learning:
interface Gi0/1
spanning-tree portfast
Если TCN генерирует конкретный порт, включаем BPDU Guard. При получении BPDU порт уходит в err-disabled вместо того чтобы ломать топологию:
interface Gi0/1
spanning-tree bpduguard enable
Глобально для всех PortFast-портов:
spanning-tree portfast default
spanning-tree portfast bpduguard default
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4👌1