Разница между отсутствием IP-канала и отсутствием физического канала

Существует разница между интерфейсом, который административно активен , но отключен или административно отключен .

Отключено

Интерфейс получает статус Несущая отключена . Его правильная обработка может зависеть от драйвера интерфейса и версии ядра. Обычно это доступно с ip link show. Например, с виртуальным ethernet veth интерфейсом:

# ip link add name vetha up type veth peer name vethb
# ip link show type veth
2: vethb@vetha: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 02:a0:3b:9a:ad:4d brd ff:ff:ff:ff:ff:ff
3: vetha@vethb: <NO-CARRIER,BROADCAST,MULTICAST,UP,M-DOWN> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether 36:e3:62:1b:a8:1f brd ff:ff:ff:ff:ff:ff

vetha , которая сама административно включена, отображает NO-CARRIERи эквивалент operstateLOWERLAYERDOWNфлаги :отключены.

Также существуют эквивалентные /sys/записи:

# cat /sys/class/net/vetha/carrier /sys/class/net/vetha/operstate
0
lowerlayerdown

В обычных настройках для интерфейса, который административно вверх несущая и операционное состояние соответствуют (NO -CARRIER <=> LOWERLAYERDOWN или НИЖЕ _ВВЕРХ <=> ВВЕРХ ). Единственным исключением может быть, например, использование аутентификации IEEE 802.1X. (дополнительные сведения о operstate описаны в этой документации по ядру:Operational States , но в этом объяснении это не требуется ).

ethtoolзапрашивает API более низкого уровня для получения того же статуса оператора связи.

Отсутствие несущей не препятствует действию настроек уровня 3. Когда это происходит, ядро ​​не меняет адреса или маршруты. Просто в конце концов пакет, который должен быть отправлен, не будет отправлен интерфейсом, и, конечно же, никакого ответа не придет.Так, например, попытка подключиться к другому адресу IPv4 рано или поздно снова вызовет запрос ARP, который завершится ошибкой, и приложение получит сообщение «Нет маршрута к хосту». Установленные TCP-соединения просто ждут своего часа и остаются установленными.

Административное отключение

Выше vethb имеет рабочее состояние DOWN и не отображает никакого состояния несущей (, поскольку для обнаружения этого он должен быть включен. Физический интерфейс Ethernet, конечно же, ведет себя так же ).

Когда интерфейс отключен (ip link set... down), несущая больше не может быть обнаружена, так как базовое аппаратное устройство, скорее всего, было выключено, и рабочее состояние становится «отключенным». ethtoolпросто скажет, что ссылки тоже нет, поэтому ее нельзя надежно использовать для этого (она наверняка также отобразит несколько неизвестных записей, но есть ли надежная схема для этого? ).

На этот раз это повлияет на сетевые настройки уровня 3. Ядро откажется добавлять маршруты, использующие этот интерфейс, и удалит все предыдущие маршруты, связанные с ним :

• добавлены автоматические(proto kernel)маршруты LAN при добавлении адреса
• добавлен любой другой маршрут (например, :маршрут по умолчанию )в любой таблице маршрутизации (не только основная таблица маршрутизации )в зависимости непосредственно от интерфейса(scope link)или на других ранее удаленных маршрутах (, вероятно, тогдаscope global). Поскольку они не появятся снова, когда интерфейс будет восстановлен (ip link set... up), они будут потеряны до тех пор, пока инструмент пользовательского пространства не добавит их обратно.

Взаимодействие с пользовательским пространством

При использовании последних инструментов, таких как NetworkManager, можно запутаться и подумать, что отключение похоже на отключение интерфейса. Это потому, что NM отслеживает ссылки и будет выполнять действия, когда такие события происходят. Чтобы получить представление, можно использовать инструмент ip monitorдля мониторинга из скриптов,но в настоящее время у него нет стабильного/анализируемого вывода (нет доступного вывода JSON ), поэтому его использование ограничено.

Таким образом, когда провод отключается, NM, скорее всего, решит, что он больше не использует текущую конфигурацию, если только это не запрещено специальной настройкой :, а затем сам удалит адреса и маршруты. Когда провод будет снова подключен, NM снова применит свою конфигурацию :, добавит обратные адреса и маршруты (, используя DHCP, если необходимо ). Это похоже на то же самое, но это не так. Все это время интерфейс оставался активным , иначе NM даже не смог бы получить предупреждение, когда соединение восстановится.

Резюме

• Легко отличить два случая::ip link showбудет отображать NO-CARRIER+ LOWERLAYERDOWNдля отключенного интерфейса и DOWNдля административно отключенного интерфейса.

• установка интерфейса административно вниз (и вверх )может привести к потере маршрутов

• потеря несущей и ее восстановление не нарушает настройки сети. Если задержка достаточно короткая, она не должна прерывать даже текущие сетевые подключения

  .

• но приложения, управляющие сетью, могут отреагировать и изменить сетевые настройки, иногда с результатом, аналогичным административному отключению

• вы можете использовать такие команды, как ip monitor linkдля получения событий об интерфейсах, установленных административно вниз/вверх или смене оператора, или ip monitorдля получения всех множественных связанных событий (, включая изменения адреса или маршрута ), которые могут произойти в это время или вскоре после.

• Большинство ipкоманд (, но не ip monitor), имеют выходные данные JSON, доступные с ip -json...для помощи сценариям (вместе сjq).

  Пример (, продолжение первого veth пример):

  vethb все еще недоступен:

  # ip -j link show dev vethb | jq '.[].operstate'
  "DOWN"
  
  # ip -j link show dev vetha | jq '.[].operstate'
  "LOWERLAYERDOWN"
  

  Установите vethb вверх,который теперь получает носитель на обоих:

  # ip link set vethb up
  # ip -j link show dev vetha | jq '.[].operstate'
  "UP"
  

  Это говорит о 3 обычных состояниях :административно вниз , нижний уровень вниз(т.е. :вверх, но отключен )или вверх(т.е. :рабочий ).