Troubleshooting часть 2 — используем встроенный дебаг устройств CISCO, выполняем дебаг с условием, безопасный дебаг без вывода в консоль.
С помощью пинга и трассировки выяснили где не работает, локализовали точку сбоя, нашли устройство. Затем просматриваем конфигурацию устройства, лог и вывод команд show. Так определяем что не работает. Теперь нужно узнать почему. Обычно ответ где-то на поверхности. Если же причины выяснить не удалось, то вот как раз в этот момент и приходит на помощь дебаг. Не говорю что схема каждый раз именно такая, но это близко к жизни.
Пример
Два роутера R1 и R2 настраиваются под OSPF и не формируют отношения смежности:
R1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.2.2 1 EXCHANGE/DR 00:00:38 192.168.2.2 Ethernet0/1
Просматриваем устройства. Сбрасываем процесс OSPF, без результата. В логе ничего полезного:
*Aug 1 12:14:34.866: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.2.2 on Ethernet0/1 from EXCHANGE to DOWN, Neighbor Down: Too many retransmissions *Aug 1 12:14:48.306: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.2.2 on Ethernet0/1 from DOWN to DOWN, Neighbor Down: Interface down or detached
Беглый просмотр конфигурации и команд show никакой информации о проблеме не дают. Запускаем дебаг:
R1# debug ip ospf adj OSPF adjacency debugging is on R1# *Aug 1 12:16:04.346: OSPF-1 ADJ Et0/1: Rcv DBD from 192.168.2.2 seq 0x1FA5 opt 0x52 flag 0x7 len 32 mtu 1470 state EXCHANGE *Aug 1 12:16:04.346: OSPF-1 ADJ Et0/1: Nbr 192.168.2.2 has smaller interface MTU *Aug 1 12:16:04.346: OSPF-1 ADJ Et0/1: Send DBD to 192.168.2.2 seq 0x1FA5 opt 0x52 flag 0x0 len 32
На втором из роутеров (R2), на интерфейсе MTU 1470. Почему? Никто не знает, нигде не задокументированно. Знакомо? Даже если ведётся Change Management, чего ни в одной компании нет, найти причины будет сложно.
Возможно немного притянуто за уши и гуру OSPF скажет: "Я сразу понял в чём дело". Но не все же гуру? Не все. И не все помнят какие там требования для установления соседства OSPF (а условий этих дофига). Дебаг же помогает быстро найти причину.
Conditional Debugging
Вывод дебага обычно огромен, поэтому многие опасаются использовать его чтобы не подвесить устройство, нагрузив CPU обсчётом. Особенно это черевато на старых устройствах со слабой аппаратной начинкой. И опасаются потерять управление консолью, когда каждую секунду в консоль сыпется десяток сообщений, при этом набрать команду невозможно.
Что тут можно придумать? Самое первое: для дебага есть много команд и много опций, нужно выбрать наиболее специфичную команду дебага, чем больше указано опций для команды, тем меньше вывод. И меньше нагрузка на CPU устройства. Второе дебаг с условием.
Warning! Последующие примеры только для наглядности. Повторять их следует в тестовой среде. Не использовать в продакшене, без полного понимания последствий своих действий.
ACL
На дебаг можно повесить ACL, выглядит это так:
R1(config)# access-list 1 permit host 192.168.2.2 R1(config)# exit R1# debug ip packet 1 IP packet debugging is on for access list 1 *Aug 1 12:45:42.910: IP: s=192.168.2.2 (Ethernet0/1), d=224.0.0.13, len 58, rcvd 0 *Aug 1 12:45:42.910: IP: s=192.168.2.2 (Ethernet0/1), d=224.0.0.13, len 58, input feature, packet consumed, MCI Check(99), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Aug 1 12:45:46.131: IP: s=192.168.2.2 (Ethernet0/1), d=224.0.0.5, len 76, rcvd 0 ...
Количество вывода дебага снизится.
Interface
Второй приём дебага с условием, это выбор интерфейса:
R1# debug interface Ethernet 0/0 Condition 1 set R1# debug ip packet IP packet debugging is on *Aug 1 13:11:10.545: IP: s=192.168.1.1 (local), d=224.0.0.13 (Ethernet0/0), len 58, sending broad/multicast *Aug 1 13:11:10.545: IP: s=192.168.1.1 (local), d=224.0.0.13 (Ethernet0/0), len 58, output feature, MFIB Adjacency(86), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Aug 1 13:11:10.545: IP: s=192.168.1.1 (local), d=224.0.0.13 (Ethernet0/0), len 58, sending full packet ...
Останавливаем дебаг и смотрим:
R1# undebug all
All possible debugging has been turned off
...
R1# show debugging condition
Condition 1: interface Et0/0 (1 flags triggered)
Flags: Et0/0
Дебаг остановили, но условие осталось. Его теперь надо удалять руками:
R1# no debug condition interface Ethernet 0/0 This condition is the last interface condition set. Removing all conditions may cause a flood of debugging messages to result, unless specific debugging flags are first removed. Proceed with removal? [yes/no]: yes Condition 1 has been removed
Или no debug condition 1, или no debug condition all. А может быть и так, зависит от IOS:
R1# undebug all 1 conditions have been removed All possible debugging has been turned off
Дебаг остановили и вместе с ним дропнулось условие.
Безопасный дебаг
Пишем в лог без вывода в консоль, затем спокойно просматриваем. Если сидим локально на устройстве:
R1(config)# logging buffered debugging R1(config)# no logging console R1(config)# end R1# debug all This may severely impact network performance. Continue? (yes/[no]): yes Persistent variable debugs All enabled ... - немного ждём R1# undebug all All possible debugging has been turned off R1# show logging
Соотвественно, если мы сидим в удалённой консоли SSH, то тут ещё проще. Нам не выводятся никакие сообщения до ввода команды terminal monitor. Получается либо не вводим эту команду и сохраняем дебаг в буфер, либо отключаем на время terminal no monitor, либо:
R1(config)# logging buffered debugging R1(config)# no logging monitor ...
Таким образом мы не теряем управление консолью из-за бешенного вывода дебага, но высокая нагрузка на CPU при дебаге остаётся. Важно не перегрузить CPU, а золотое правило сетевого инженера здесь: все настройки и тесты after business hours.
Минус здесь в том, что старый лог частично (или скорее полностью) затрётся. И увеличение размера буфера лога может и не помочь. В этом случае очень удобно предварительно сохранить лог с помощью SecureCRT в текстовый файл: File-Log Session.
И затем:
R1# terminal length 0 R1# show logging