Linux ошибки сетевого интерфейса

Пожалуйста, сообщите об этом — просто выделите ошибочное слово или фразу и нажмите Shift Enter.

Как посмотреть статистику ошибок на сетевых интерфейсах

Написал microsin

24.04.2008

На Linux это можно сделать командой ifconfig и netstat. На FreeBSD — командой netstat. Под Windows netstat -e (к сожалению, без указания конкретного интерфейса). Под IOS Cisco show interfaces имя_интерфейса. Примеры:

Windows
D:\Documents and Settings\user>netstat -e
Interface Statistics
Received Sent
Bytes 1318170969 1331072579
Unicast packets 17579014 19350523
Non-unicast packets 7408 7298
Discards 0 0
Errors 0 0
Unknown protocols 0

Red Hat Linux
[ root@localhost

]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:C0:DF:0B:1D:08
inet addr:a.b.11.111 Bcast:10.255.255.255 Mask:255.0.0.0
inet6 addr: fe80::2c0:dfff:fe0b:1d08/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12440467 errors:0 dropped:0 overruns:0 frame:0
TX packets:54452 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1136982908 (1.0 GiB) TX bytes:5774730 (5.5 MiB)
Interrupt:169 Base address:0x1000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1635 errors:0 dropped:0 overruns:0 frame:0
TX packets:1635 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1743404 (1.6 MiB) TX bytes:1743404 (1.6 MiB)
[root@localhost

]# netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 12564444 0 0 0 54645 0 0 0 BMRU
lo 16436 0 1635 0 0 0 1635 0 0 0 LRU

Источник

unixforum.org

Форум для пользователей UNIX-подобных систем

Темы без ответов
Активные темы
Поиск
Статус форума

[Решено] Пропало сетевое подключение eth0

Модератор: Bizdelnick

[Решено] Пропало сетевое подключение eth0

Сообщение m.E » 09.11.2020 15:58

Добрый всем день!

Пару дней назад было возможно подключаться к Интернет через сетевой кабель, а вот сегодня система не видит eth0. При этом я не делал никаких обновлений системы или каких-то изменений в настройках.
Моя тема подобна этой: Решено: Настройка сетевой карты:не поднимается eth0. Но такое ощущение, что проблема в моём случае не с переименованием eth0, а с чем то другим.

Помогите, пожалуйста, разобраться и устранить (если возможно) проблему.

Вот что имеем:
Debian GNU/Linux 10 (buster),

Re: Пропало сетевое подключение eth0

Сообщение Hephaestus » 09.11.2020 17:23

m.E
Система «не видит» eth0, потому что он не активен (не поднят).
Команда ifconfig покажет только поднятые интерфейсы.
Попробуйте ifconfig -a и скорее всего окажется, что eth0 на месте, но не поднялся (а может, он уже и не eth0 на самом деле).

Если проводной интерфейс таки окажется на месте, можно попробовать поднять его вручную тем же ifconfig:
ifconfig eth0 up
и посмотреть, что будет.
Поднимется вручную — значит, проблема где-то на этапе инициализации (в настройках сервисов).

Источник

Имитируем сетевые проблемы в Linux

Всем привет, меня зовут Саша, я руковожу тестированием бэкенда в FunCorp. У нас, как и у многих, реализована сервис-ориентированная архитектура. С одной стороны, это упрощает работу, т.к. каждый сервис проще тестировать по отдельности, но с другой — появляется необходимость тестировать взаимодействие сервисов между собой, которое часто происходит по сети.

В этой статье я расскажу о двух утилитах, с помощью которых можно проверить базовые сценарии, описывающие работу приложения при наличии проблем с сетью.

Имитируем проблемы с сетью

Обычно ПО тестируется на тестовых серверах с хорошим интернет-каналом. В суровых условиях продакшена всё может быть не так гладко, поэтому иногда нужно проверять программы в условиях плохого соединения. В Linux с задачей имитации таких условий поможет утилита tc.

tc (сокр. от Traffic Control) позволяет настраивать передачу сетевых пакетов в системе. Эта утилита обладает большими возможностями, почитать про них подробнее можно здесь. Тут же я рассмотрю лишь несколько из них: нас интересует шедулинг трафика, для чего мы используем qdisc, а так как нам нужно эмулировать нестабильную сеть, то будем использовать classless qdisc netem.

Запустим echo-сервер на сервере (я для этого использовал nmap-ncat):

Для того чтобы детально вывести все таймстемпы на каждом шаге взаимодействия клиента с сервером, я написал простой скрипт на Python, который шлёт запрос Test на наш echo-сервер.

Запустим его и посмотрим на трафик на интерфейсе lo и порту 12345:

Всё стандартно: трёхстороннее рукопожатие, PSH/ACK и ACK в ответ дважды — это обмен запросом и ответом между клиентом и сервером, и дважды FIN/ACK и ACK — завершение соединения.

Задержка пакетов

Теперь установим задержку 500 миллисекунд:

Запускаем клиент и видим, что теперь скрипт выполняется 2 секунды:

Что же в трафике? Смотрим:

Можно увидеть, что во взаимодействии между клиентом и сервером появился ожидаемый лаг в полсекунды. Гораздо интереснее себя ведёт система, если лаг будет больше: ядро начинает повторно слать некоторые TCP-пакеты. Изменим задержку на 1 секунду и посмотрим трафик (вывод клиента я показывать не буду, там ожидаемые 4 секунды в total duration):

Видно, что клиент дважды посылал SYN-пакет, а сервер дважды посылал SYN/ACK.

Помимо константного значения, для задержки можно задавать отклонение, функцию распределения и корреляцию (со значением для предыдущего пакета). Делается это следующим образом:

Здесь мы задали задержку в промежутке от 100 до 900 миллисекунд, значения будут подбираться в соответствии с нормальным распределением и будет 50-процентная корреляция со значением задержки для предыдущего пакета.

Вы могли заметить, что в первой команде я использовал add, а затем change. Значение этих команд очевидно, поэтому добавлю лишь, что ещё есть del, которым можно убрать конфигурацию.

Потеря пакетов

Попробуем теперь сделать потерю пакетов. Как видно из документации, осуществить это можно аж тремя способами: терять пакеты рандомно с какой-то вероятностью, использовать для вычисления потери пакета цепь Маркова из 2, 3 или 4 состояний или использовать модель Эллиота-Гилберта. В статье я рассмотрю первый (самый простой и очевидный) способ, а про другие можно почитать здесь.

Сделаем потерю 50% пакетов с корреляцией 25%:

К сожалению, tcpdump не сможет нам наглядно показать потерю пакетов, будем лишь предполагать, что она и правда работает. А убедиться в этом нам поможет увеличившееся и нестабильное время работы скрипта client.py (может выполниться моментально, а может и за 20 секунд), а также увеличившееся количество retransmitted-пакетов:

Добавление шума в пакеты

Помимо потери пакетов, можно имитировать их повреждение: в рандомной позиции пакета появится шум. Сделаем повреждение пакетов с 50-процентной вероятностью и без корреляции:

Запускаем скрипт клиента (там ничего интересного, но выполнялся он 2 секунды), смотрим трафик:

Видно, что некоторые пакеты отправлялись повторно и есть один пакет с битыми метаданными: options [nop,unknown-65 0x0a3dcf62eb3d,[bad opt]>. Но главное, что в итоге всё отработало корректно — TCP справился со своей задачей.

Дублирование пакетов

Что ещё можно делать с помощью netem? Например, сымитировать ситуацию, обратную потере пакетов, — дубликацию пакетов. Эта команда также принимает 2 аргумента: вероятность и корреляцию.

Изменение порядка пакетов

Можно перемешать пакеты, причём двумя способами.

В первом часть пакетов посылается сразу, остальные — с заданной задержкой. Пример из документации:

С вероятностью 25% (и корреляцией 50%) пакет отправится сразу, остальные отправятся с задержкой 10 миллисекунд.

Второй способ — это когда каждый N-й пакет отсылается моментально с заданной вероятностью (и корреляцией), а остальные — с заданной задержкой. Пример из документации:

Каждый пятый пакет с вероятностью 25% будет отправлен без задержки.

Изменение пропускной способности

Обычно везде отсылаются к TBF, но с помощью netem тоже можно изменить пропускную способность интерфейса:

Эта команда сделает походы по localhost такими же мучительными, как серфинг в интернете через dial-up-модем. Помимо установки битрейта, можно также эмулировать модель протокола канального уровня: задать оверхед для пакета, размер ячейки и оверхед для ячейки. Например, так можно сымитировать ATM и битрейт 56 кбит/сек.:

Имитируем connection timeout

Ещё один важный пункт в тест-плане при приёмке ПО — таймауты. Это важно, потому что в распределённых системах при отключении одного из сервисов остальные должны вовремя сфоллбэчиться на другие или вернуть ошибку клиенту, при этом они ни в коем случае не должны просто зависать, ожидая ответа или установления соединения.

Есть несколько способов сделать это: например, использовать мок, который ничего не отвечает, или подключиться к процессу с помощью дебаггера, в нужном месте поставить breakpoint и остановить выполнение процесса (это, наверное, самый извращённый способ). Но один из самых очевидных — это фаерволлить порты или хосты. С этим нам поможет iptables.

Для демонстрации будем фаерволлить порт 12345 и запускать наш скрипт клиента. Можно фаерволлить исходящие пакеты на этот порт у отправителя или входящие на приёмнике. В моих примерах будут фаерволлиться входящие пакеты (используем chain INPUT и опцию —dport). Таким пакетам можно делать DROP, REJECT или REJECT с TCP флагом RST, можно с ICMP host unreachable (на самом деле дефолтное поведение — это icmp-port-unreachable, а ещё есть возможность послать в ответ icmp-net-unreachable, icmp-proto-unreachable, icmp-net-prohibited и icmp-host-prohibited).

При наличии правила с DROP пакеты будут просто «исчезать».

Запускаем клиент и видим, что он зависает на этапе подключения к серверу. Смотрим трафик:

Видно, что клиент посылает SYN-пакеты с увеличивающимся по экспоненте таймаутом. Вот мы и нашли небольшой баг в клиенте: нужно использовать метод settimeout(), чтобы ограничить время, за которое клиент будет пытаться подключаться к серверу.

Сразу удаляем правило:

Можно удалить сразу все правила:

Если вы используете Docker и вам нужно зафаерволлить весь трафик, идущий на контейнер, то сделать это можно следующим образом:

REJECT

Теперь добавим аналогичное правило, но с REJECT:

Клиент завершается через секунду с ошибкой [Errno 111] Connection refused. Смотрим трафик ICMP:

Видно, что клиент дважды получил port unreachable и после этого завершился с ошибкой.

REJECT with tcp-reset

Попробуем добавить опцию —reject-with tcp-reset:

В этом случае клиент сразу выходит с ошибкой, потому что на первый же запрос получил RST пакет:

REJECT with icmp-host-unreachable

Попробуем ещё один вариант использования REJECT:

Клиент завершается через секунду с ошибкой [Errno 113] No route to host, в ICMP трафике видим ICMP host 127.0.0.1 unreachable.

Можете также попробовать остальные параметры REJECT, а я остановлюсь на этих 🙂

Имитируем request timeout

Еще одна ситуация — это когда клиент смог подключиться к серверу, но не может отправить ему запрос. Как отфильтровать пакеты, чтобы фильтрация началась как бы не сразу? Если посмотреть на трафик любого общения между клиентом и сервером, то можно заметить, что при установлении соединения используются только флаги SYN и ACK, а вот при обмене данными в последнем пакете запроса будет флаг PSH. Он устанавливается автоматически, чтобы избежать буферизации. Можно использовать эту информацию для создания фильтра: он будет пропускать все пакеты, кроме тех, которые содержат флаг PSH. Таким образом, соединение будет устанавливаться, а вот отправить данные серверу клиент не сможет.

Для DROP команда будет выглядеть следующим образом:

Запускаем клиент и смотрим трафик:

Видим, что соединение установлено, и клиент не может послать данные серверу.

REJECT

В этом случае поведение будет таким же: клиент не сможет отправить запрос, но будет получать ICMP 127.0.0.1 tcp port 12345 unreachable и увеличивать время между переотправкой запроса по экспоненте. Команда выглядит так:

REJECT with tcp-reset

Команда выглядит следующим образом:

Мы уже знаем, что при использовании —reject-with tcp-reset клиент получит в ответ RST-пакет, поэтому можно предугадать поведение: получение RST-пакета при установленном соединении означает непредвиденное закрытие сокета с другой стороны, значит, клиент должен получить Connection reset by peer. Запускаем наш скрипт и удостоверяемся в этом. А вот так будет выглядеть трафик:

REJECT with icmp-host-unreachable

Думаю, уже всем очевидно, как будет выглядеть команда 🙂 Поведение клиента в таком случае будет немного отличаться от того, которое было с простым REJECT: клиент не будет увеличивать таймаут между попытками переотправить пакет.

Вывод

Не обязательно писать мок для проверки взаимодействия сервиса с зависшим клиентом или сервером, иногда достаточно использовать стандартные утилиты, которые есть в Linux.

Рассмотренные в статье утилиты обладают ещё большим количеством возможностей, чем было описано, поэтому вы можете придумать какие-то свои варианты их использования. Лично мне всегда хватает того, про что я написал (на самом деле даже меньше). Если вы используете эти или подобные утилиты в тестировании в своей компании, напишите, пожалуйста, как именно. Если же нет, то надеюсь, ваше ПО станет качественней, если вы решите проверять его в условиях проблем с сетью предложенными способами.

Источник