Мониторинг физического уровня контролирует связность устройства с непосредственно сопряжённым физическим устройством и производится по сигналу Carrier Detect физического порта. Однако для разных типов портов он работает по-разному:

• Для портов PPP сигнал Carrier Detect модема учитывается всегда (если только он не отключён сознательно при помощи опции local). Однако для наиболее актуального случая — сотовых соединений — он не полностью информативен и не достаточен. Падение сигнала DCD безусловно означает разрыв связи, но вместе с тем в сотовых сетях возможны ситуации, когда соединение формально не разорвано, DCD поднят, но фактическая скорость соединения равна нулю. Таким образом, он, безусловно, полезен (чтобы обеспечить реакцию в кратчайшее время при корректном разрыве соединения), но его необходимо дублировать средствами более высоких уровней на случай некорректной работы сети или "зависания" внутреннего ПО сотового модема.
• Для портов Ethernet сигнал DCD контролирует, по существу, связь устройства с ближайшим коммутатором. Если выдернуть кабель между ними, то сигнал, естественно, упадёт. Но в реальности проблемы возникают, как правило, не в непосредственно подключённом кабеле, а где-то в вышестоящих промежуточных соединениях, отделённых от порта устройства NSG одним или несколькими коммутаторами и маршрутизаторами. Отследить их средствами физического уровня Ethernet принципиально невозможно, поэтому вместо них необходимо использовать средства мониторинга вышестоящих уровней. Например, это может быть LCP Echo в соединении PPPoE, или netping в общем случае.
  Помимо этого, если порт оснащен встроенным коммутатором, то отключить его конструктивно невозможно. Выдергивание кабелей из внешних портов коммутатора никак не сказывается при этом на состоянии внутреннего порта процессора.
• Для туннелей аналогом сигнала CD является готовность нижележащего сетевого интерфейса, через который работает туннель. Однако средства для такого мониторинга имеются не во всех типах туннелей.

Мониторинг канального уровня контролирует связность устройства со смежным устройством этого уровня — например, с сервером PPP, минуя все промежуточные устройства нижележащих уровней (сотовые и телефонные сети с их собственными инкапсуляциями и протоколами, и т.п.) Из числа технологий, актуальных на сегодняшний день, он предусмотрен только в PPP в виде обмена пакетами LCP Echo Request / Echo Reply. Если не получено несколько пакетов подряд, соединение считается разорванным.

Мониторинг на канальном и на любых вышестоящих уровнях принципиально не может быть мгновенным, а может основываться, так или иначе, исключительно на посылке контрольных пакетов (в отсутствие полезных данных). Либо каждая сторона, независимо от другой, посылает через установленные интервалы времени пакеты Request некоторого протокола и ждёт ответных Reply (так сделано, например, в PPP), либо обе стороны посылают пакеты keepalive и следят за тем, чтобы они регулярно приходили от другой стороны (например, в Cisco-HDLC). В обоих случаях время срабатывания контрольных механизмов всегда конечное и равно, в наихудшем случае, произведению интервала посылки на допустимое число потерянных пакетов.

Мониторинг сетевого уровня контролирует связность устройства с конечным IP-хостом, минуя все промежуточные узлы IP-сети и все промежуточные устройства нижележащих уровней (коммутаторы Ethernet, системы доступа Ethernet-over-xDSL, сотовые сети и т.п.) в каналах связи между этими узлами. Он также возможен только по принципу keepalive либо echo и имеет конечное время срабатывания.

Наиболее употребительным вариантом является netping — скрипт на основе утилиты ping, использующий пакеты ICMP Echo Request / Echo Reply. Именно его удобно использовать для контроля каналов доступа Ethernet. Возможны также механизмы и на основе других типов пакетов.

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

Встроенные средства мониторинга в туннелях (разнообразные keepalive, echo, dead peer detection — в зависимости от технологии) работают аналогично механизмам прикладного уровня. Однако существенная разница состоит в том, что концы туннеля находятся непосредственно в руках сетевого администратора. С другой стороны, следует помнить, что поверх них могут работать ещё механизмы мониторинга прикладного уровня.

При одновременной работе нескольких механизмов мониторинга возникает дополнительная проблема — несогласованность их работы на разных уровнях. Практическое инженерное правило состоит в том, что время срабатывания контрольного механизма на каждом вышестоящем уровне должно быть примерно в 3 раза больше, чем на нижележащем, чтобы они не дёргали систему вразнобой. Предположим, например, что банкомат работает по туннелю, устанавливаемому через сотовую сеть 2G. Для устойчивого, без ложных срабатываний, обнаружения отказов сети рекомендуется, по практическому опыту, таймаут LCP Echo 3×15 сек = 45 сек. Тогда таймаут разрыва туннеля должен составлять порядка 2 мин, а таймаут прикладного ПО банкомата — 5–6 мин, что находится уже на пределе разумного. Именно по этой причине, в частности, актуален переход на сети 3G (UMTS), которые обеспечивают существенно меньшие задержки пакетов и, как следствие, позволяют сократить таймаут LCP Echo до 10 сек; пропорционально ему сокращаются и все остальные таймауты, что позволяет, в конечном счёте, вписаться в таймауты прикладного ПО банкомата.

Во всех случаях целесообразно использовать механизмы мониторинга соединений самого нижнего уровня из доступных. Для соединений PPP это комбинация DCD и LCP Echo — чтобы обеспечить гарантированное срабатывание плюс, по возможности, минимальное время срабатывания. Для соединений Ethernet приходится использовать, как правило, netping. Для соединений псевдо-Ethernet "точка-точка" и "точка-многоточка" (Ethernet-over-G.703.6, туннели GRE с инкапсуляцией Ethernet, LTE, клиенты Wi-Fi) возможно использовать контроль DCD или его эквивалента.

ПРИМЕЧАНИЕ. В сетях отдельных операторов имеет место ситуация, когда при исчерпании средств на счету PPP-соединение устанавливается успешно, но при попытке выхода в Интернет клиент безусловно перенаправляется на платёжный портал оператора. Такие случай не могут быть обнаружены встроенными средствами мониторинга PPP 1–2 уровней и требуют применения механизмов более высоких уровней (netping и др.).