Мониторинг физического уровня контролирует связность устройства с непосредственно сопряжённым физическим устройством и производится по сигналу 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.