Второй выпуск команд, способных оказаться крайне полезными в процессе настройки и диагностики оборудования на базе ОС Cisco IOS.
Если у вас имеются кандидаты в данный список – указывайте в комментариях.
- logging discriminator
Аналогично debug condition из первого выпуска, для logging так же имеется возможность произвести фильтрацию вывода.
Команда оказывается крайне полезной в тех случаях, где мы ждём только конкретный вывод в консоль или, что чаще, желаем видеть всё, кроме какого-то раздражающего уведомления. Примером такого сообщения может быть уведомление о неработающем втором fan-модуле, следующего вида:
1 |
%FAN-3-FAN_FAILED: Fan 1 had a rotation error reported. |
, решить которое по ряду причин может не предствляться возможным.
Для исключения данного вида сообщений из вывода можно воспользовать следующим набором команд:
1 2 3 4 5 6 7 8 9 |
! указываем имя дискриминатор (NOMOREFAN) ! условие наличия именно в тексте сообщения (msg-body) ! действие (drops) - отбрасывание данных сообещний из сообщений подлежащих выводу ! и подстроку (Fan), совпадение с которой приводит к выполнению действия logging discriminator HIDEFAN msg-body drops Fan ! ! привязывает дискриминатор к логированию на консоль и в лог-буфер logging buffered discriminator HIDEFAN logging console discriminator HIDEFAN |
- no ip icmp rate-limit unreachable
Несмотря на то, что для управления политиками безопасности для control plane существует специальный Control plane policing (CoPP), имеется набор быстрых команд, обеспечивающих управление ограничениями для ICMP-трафика.
Одна из таких команд ограничивает количество пакетов ICMP Type 3 (Destination Unreachable), которые маршрутизатор может послать в единицу времени.
Примером, на котором будет заметна работа данной команды, является использование простого traceroute в сторону маршрутизатора Cisco. Как известно, предпоследний пакет трейсинга маршрутизатора Cisco всегда завершается выводом символа “*” (астериск) и связно это именно в ограничениями на количество ICMP-ответов, которые узел назначения может послать в секунду.
Значения по умолчанию:
1 2 3 4 5 6 7 8 9 |
R2#show ip icmp rate-limit DF bit unreachables All other unreachables Interval (millisecond) 500 500 Interface # DF bit unreachables # All other unreachables --------- --------------------- ------------------------ GigabitEthernet0/1 0 0 R2# |
, те не чаще 1 раза каждые 500мс.
Вывод до применения команды:
1 2 3 4 5 6 7 |
R1#traceroute 10.0.12.2 Type escape sequence to abort. Tracing the route to 10.0.12.2 1 10.0.12.2 0 msec * 0 msec R1# |
Убираем ограничение:
1 2 |
R2(config)#no ip icmp rate-limit unreachable R2(config)# |
Вывод после применения команды:
1 2 3 4 5 6 7 |
R1#traceroute 10.0.12.2 Type escape sequence to abort. Tracing the route to 10.0.12.2 1 10.0.12.2 0 msec 4 msec 0 msec R1# |
Не могу утверждать точно, но если вы используете traceroute как инструмент в составе системы мониторинга, вывод * тоже может вызывать проблемы.
- buffers huge size
Особенность обнаружена при подготовке к JNCIP-ENT, когда требовалось организовать какую-либо генерацию относительно заметного объёма трафика, используя устройства Cisco и Juniper. Если на Juniper мы может использовать размер ICMP пакетов вплоть до 65535 байт, то в Cisco максимальным значением оказалось
1 2 |
R1#ping 1.1.1.1 size ? <36-18024> Datagram size |
18024 байта. И ладно бы это было ограничением для исходящего ICMP, но и пинг с Juniper с размером выше 18024 попросту отбрасывались.
Поиск ограничителя оказался крайне прост:
1 2 3 4 |
R1#show tech-support | include 18024 265 2EA1D628 2E818024 0 1 693E030C 693A0D40 2E818024 0000 Huge buffers, 18024 bytes (total 0, permanent 0): R1# |
Т.е. значение некоего “huge buffers” и является ограничителем, осталось лишь изменить его значение:
1 2 3 4 5 |
R1(config)#buffers huge size ? <18024-65535> Size of huge buffers R1(config)#buffers huge size 65535 R1(config)# |
Так как это общее ограничение для буфера под большие пакеты, то это должно сказаться и на ограничении для исходящего трафика:
1 2 |
R1#ping 1.1.1.1 size ? <36-65535> Datagram size |
Как видно теперь мы не только можем принимать большие пакеты, но и отправлять таковые.
- ethanalyzer [cisco.com]
Благодаря тому, что операционная система Cisco NX-OS создана на базе операционной системы Linux MontaVista, имеется возможность комплектации дистрибутива дополнительным ПО и обеспечить его использование прямо из командной строки. Одним из таких инструментов стало ПО Wireshark (!).
Для начала прослушивания трафика на локальных интерфейсах используется следующий синтаксис:
1 |
ethanalyzer local interface [inbound-hi|inbound-low|mgmt] (options) |
inbound-hi и inbound-low представляют разделение видов трафика на группы:
– UDP, TCP, IP, IGMP, ARP – считаются нижними (inbound-low);
– STP, OSPF, LACP, FCoE – считаются верхними (inbound-hi);
– трафик получаемый OOB-интерфейсом mgmt попадает в отдельную категорию (mgmt).
Примеры:
1 2 |
! вылавливаем первых 4 пакета ethanalyzer local interface inbound-hi limit-captured-frames 4 |
1 2 3 |
! обнаруживаем пакеты протокола ARP, содержащие значение "4c:60:de:25:01:04" ! ждём такого трафика 200к пакетов ethanalyzer local interface inbound-low display-filter "arp contains 4c:60:de:25:01:04" limit-captured-frames 200000 |
1 2 |
! вылавливаем первые 10 пакетов протокола OSPF и детально показываем содержимое ethanalyzer local interface inbound-hi display-filter "ospf" detail limit-captured-frames 10 |
Благодаря такой возможности отсутствует необходимость SPAN’ить трафик в сторону отдельной машины.
- show ip ospf border-routers
Удобная и быстрая команда определения списка ABR/ASBR.
Команда проверяет LSDB на наличие соседей приславших LSA3, 5, 7 и именно их показывает в выводе команды. При выполнении настройки касающейся добавления или удаления статуса ABR/ASBR, данную команду можно использовать для быстрой диагностики корректной настройки, так как вывод занимает несколько строк и лёгко поддаётся анализу.
Со множеством интересных команд OSPF можно ознакомиться здесь.