Troubleshooting часть 2

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 обсчётом. Особенно это черевато на старых устройствах со слабой аппаратной начинкой. И опасаются потерять управление консолью, когда каждую секунду в консоль сыпется десяток сообщений, при этом набрать команду невозможно. Что тут можно придумать? Самое первое: для дебага есть много команд и много опций, нужно выбрать наиболее специфичную команду дебага, чем больше указано опций для команды, тем меньше вывод. Второе дебаг с условием.

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 ip packet - немного ждём
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.

Troubleshooting часть 2

И затем:

R1# terminal length 0
R1# show logging

Добавить комментарий