Network Admin

Ping внешнего IP: что происходит с ICMP-пакетом На первый взгляд ping 8.8.8.8 прост, но под капотом - целый путь через стек и сеть. Шаги прохождения пакета: 1️⃣Формирование пакета Ping создаёт ICMP Echo Request через RAW-сокет. Источник - твой IP, цель - 8.8.8.8. 2️⃣Локальный стек Пакет проходит через iptables/netfilter. Если политика DROP - даже локально он не уйдёт. 3️⃣Маршрутизация Ядро выбирает интерфейс и next-hop для внешнего IP. NAT может поменять исходный адрес. 4️⃣Физический путь Пакет выходит на интерфейс, проходит коммутаторы и маршрутизаторы. TTL уменьшается на каждом hop. 5️⃣Удалённый узел Echo Reply создаётся на хосте и идёт обратно по пути, определённому его routing table. 6️⃣Возврат и RTT Пакет возвращается, ping фиксирует RTT и выводит результат. Что может сломать ping: Пинг может не работать, если на локальной машине или по пути к цели блокируют ICMP пакеты (firewall/ACL), отсутствует маршрут к внешнему IP, некорректно настроен NAT, или TTL пакета слишком мал, чтобы достичь удалённого узла. Полезные команды:

    
        traceroute 8.8.8.8
tcpdump -i eth0 icmp
iptables -L -v -n
ip route get 8.8.8.8{}
    

N.A.

🤩 Admin Books —электронные книги о компьютерных технологиях. Используй предстоящие новогодние выходные наилучшим образом! Изучай новые технологии или закрой пробелы в знаниях по своему стеку. Стань экспертом в следующих направлениях: • Системное администрирование • Информационная безопасность • Сетевое администрирование • Этичный хакинг Ссылка для своих: https://t.me/admbooks

Что происходит при ping 127.0.0.1: путь ICMP-пакета в loopback ping 127.0.0.1 кажется банальной вещью, но под капотом — полноценный сетевой стек. Вот что происходит по шагам:

    
        Сначала утилита ping создает RAW-сокет и формирует ICMP Echo Request. Пакет получает IP-адрес источника 127.0.0.1 и тот же адрес в качестве получателя.{}
    

Пакет проходит через iptables/netfilter и может быть отброшен или модифицирован (например, логгирован или помечен). Если политика DROP — ICMP даже на localhost не дойдет. Ядро направляет пакет в loopback-интерфейс lo, где он сразу попадает обратно в приемный путь — физически никуда не выходит. Приемный стек получает ICMP Echo Request и отправляет в ответ Echo Reply — снова через loopback.

    
        Утилита ping ловит Echo Reply и выводит строку с временем RTT, даже если интерфейс lo отключен — это чисто внутренняя маршрутизация.{}
    

Как можно сломать Отключен интерфейс lo: ifconfig lo down — ping не будет работать, хотя кажется, что это локальный вызов. ICMP фильтруется iptables -A INPUT -p icmp -j DROP — даже пинг 127.0.0.1 будет теряться.

    
        Сломана маршрутизация: удалена запись 127.0.0.0/8 dev lo — пакеты просто не найдут путь.{}
    

Полезные команды для диагностики ip route get 127.0.0.1 — какая таблица маршрутов применяется iptables -L -v -n — проверка, не режется ли ICMP tcpdump -i lo icmp — убедиться, что пакеты доходят ss -npi — посмотреть, что происходит с сокетом N.A.

Дирижируем сетевым оркестром: маршрутизация на основе политик (PBR) Как сделать так, чтобы трафик в сети шел не просто по кратчайшему пути, а по заданным правилам и приоритетам? На открытом вебинаре курса OTUS Network Engineer. Professional Константин Григорьев расскажет, как маршрутизировать трафик «по нотам» — с помощью политик, IP SLA и механизмов контроля доступа. 🗓 17 декабря, 20:00 Дирижируем сетевым оркестром: маршрутизация на основе политик (PBR) — разбор основных правил построения политик; — проверка работы маршрутизации и отладка; — создание тестов IP SLA для мониторинга каналов; — основы распределения трафика и защиты сети. Вебинар будет полезен сетевым инженерам, администраторам и специалистам по информационной безопасности, которые хотят научиться управлять трафиком и строить гибкие сетевые решения. 👉Зарегистрируйтесь: https://otus.pw/Ore7x/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Как вычислить «молчаливый» ARP-флуд в сети Даже если обычный трафик нормальный, сеть может испытывать проблемы из-за частого повторного ARP-запроса, который почти не виден в интерфейсных counters, но забивает CPU коммутатора или broadcast-домен. Особенно важно для IoT, камер и массовых DHCP-сетей. Проверим 👇 1️⃣Счётчики ARP на коммутаторе

    
        show ip arp summary
show interfaces Gi1/0/10 counters{}
    

Если количество ARP-запросов растёт неравномерно - возможен флуд. 2️⃣Логи и события ARP

    
        show logging | include ARP{}
    

Ищем «arp request rate» или warnings от CPU. 3️⃣Сетевой capture На Linux или коммутаторе с capture:

    
        tcpdump -nn -i eth0 arp{}
    

Смотрим частоту ARP-запросов. Если сотни/тысячи в секунду - это перегрузка. 4️⃣Проверяем защиту На Cisco можно включить ARP Inspection/Snooping, чтобы ограничить flood:

    
        show ip arp inspection{}
    

N.A.

Джуны — всё, ИИ победил. По статистике BCG, за последний год компании выбросили на улицу 75% молодняка. При этом миддлам и сеньорам зарплаты подняли в 4 (!) раза. Чтобы подняться до уровня элит в аномально короткие сроки — подпишитесь на легендарные каналы для айтишников: Новости и инсайды Фронтенд разработка ИИ и биг дата Node js Вёрстка Питон и нейросети QA-тестировщики Там раскрыли инфу из курсов общей стоимостью 5.000.000р в эксклюзивных пошаговых инструкциях. Пока остальные пойдут на дно якорем, вы войдете в 10% тех, кто сломал систему.

Как найти «утекающий» DHCP‑трафик Когда клиенты жалуются, что «IP не выдаётся», причина часто не в сервере, а в том, что DHCP broadcast где‑то теряется по пути. Это трудно заметить, потому что обычный трафик при этом работает. Вот короткая схема проверки: 1️⃣Проверяем Snooping Если включён DHCP Snooping, он может блокировать сервер или relay на недоверенном порту.

    
        show ip dhcp snooping
show ip dhcp snooping binding{}
    

Если сервер сидит на untrusted‑порту - DISCOVER не проходит. 2️⃣Ищем зону, где режется broadcast Storm Control, ACL или неправильные VLAN могут «убивать» DHCP‑кадры.

    
        show storm-control
show vlan brief
show access-lists{}
    

Если на порту агрессивный storm‑control или ACL с deny udp 67/68 - пакеты не доходят. 3️⃣Проверяем Relay (IP Helper): Если используется relay, проверяем, что он настроен на правильный сервер.

    
        show running-config interface <uplink>{}
    

Если ip helper указывает на старый/неправильный адрес - OFFER/ACK «теряются». 4️⃣Смотрим счётчики на интерфейсах: На некоторых портах могут быть drops именно по L2 broadcast.

    
        show interface Gi1/0/15 counters{}
    

Если broadcast-drops растут - DHCP Discover там «тонет». 5️⃣Тестируем вручную На Linux:

    
        tcpdump -ni eth0 port 67 or port 68{}
    

Если DISCOVER уходит, а OFFER не приходит - проблема выше по цепочке. N.A.

🧭 Как вычислить сломанную политику QoS с Shaping и Token-Bucket Иногда трафик вроде классифицирован правильно, но на пиках появляются задержки или пакеты «теряются» без видимых drop’ов. Причина часто в неправильно настроенном shaping или drift token-bucket - hardware ограничивает throughput неравномерно, либо буфер переполняется. Важно понимать, что QoS работает только если shaping и token-bucket настроены согласованно по всей цепочке. 1️⃣Проверяем статистику очередей:

    
        show policy-map interface Gi1/0/1{}
    

Ищем drops, match, transmitted packets и rate-limits. 2️⃣Смотрим token-bucket counters:

    
        show queueing interface Gi1/0/1{}
    

Если токены расходуются быстрее, чем refill → пиковый трафик режется. 3️⃣Сравниваем с hardware counters:

    
        show platform hardware qfp active statistics drop{}
    

Если есть drop на ASIC — shaping реально ограничивает throughput, возможно, неправильно выставлен burst. 4️⃣Анализируем traffic flow:

    
        monitor capture ...{}
    

Сравниваем пиковый traffic с лимитами QoS. Если падает на microburst — лимит слишком жёсткий или token-bucket «дрейфует». N.A.

Наконец-то ребята из контейнерной платформы “Штурвал” прислушались к сообществу и сделали альтернативу бесячей форме на сайте для получения community-лицензии. Теперь ее можно получить через бота в телеге: @l4_helper_bot. Может ещё и Open-Source-версию сделают?

Как найти порты с неправильными Storm Control-лимитами Иногда Storm Control включён, но лимиты выставлены слишком жёстко - и коммутатор начинает резать обычный трафик как «шторм». Типичный признак - порты рандомно падают в suppression, появляются жалобы на «плавающий» доступ, особенно в сетях с VoIP, камерой или IoT. Важно понять две вещи: ⏺где включён Storm Control, ⏺и не слишком ли низкий порог стоит для конкретного трафика. 1️⃣Проверяем текущее состояние лимитов:

    
        show storm-control{}
    

Если по порту suppression счётчик растёт — порог занижен. 2️⃣Смотрим конфигурацию интерфейса:

    
        show running-config interface Gi1/0/10 | include storm{}
    

Обрати внимание на kbit/s или процент - именно они определяют, как быстро порт будет уходить в ограничение. 3️⃣Проверяем, были ли события suppression: show storm-control interface Gi1/0/10 Если suppression last occurred недавно - лимит стоит пересматривать. 4️⃣Через SNMP можно вытянуть статистику по всем портам:

    
        snmpwalk -v3 -u user -l authPriv -a SHA -A authpass -x AES -X privpass <switch> .1.3.6.1.4.1.9.9.187{}
    

OID Cisco Storm-Control вернёт counters broadcast/multicast/unicast для каждого порта, что удобно для массового анализа. N.A.