antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 18 Апрель , 2010

Vyatta располагает достаточно большим набором средств отладки и диагностики, которые помогают понять, что именно идет не так. Здесь я описываю, по возможности, только штатные (присутствующие в родном CLI) средства, хотя ничто не мешает использовать произвольные инструменты Linux.

Системные сообщения

Первое, с чего стоит начинать поиск. Сообщения (логи) вполне информативны, и часто одних их вполне достаточно. Смотреть их можно командой операционного режима show log, имеющей ряд аргументов. show log tail будет показывать их по мере поступления новых сообщений. show log all покажет все накопившиеся сообщения.

Типичный формат сообщения таков: [дата и время] [компонент]: [сообщение]. Например,
Apr 1 06:39:30 vyatta vyatta-zebra[1923]: interface vtun6 index 602 deleted.

Кроме того, для некоторых типов интерфейсов можно посмотреть сообщения, касающиеся исключительно их (например, для PPPoE).

$show interfaces pppoe pppoe0 log
Wed Mar 24 14:43:46 NOVT 2010: PPP interface pppoe0 created
Wed Mar 24 14:44:01 NOVT 2010: Stopping PPP daemon for pppoe0
Wed Mar 24 14:44:02 NOVT 2010: Starting PPP daemon for pppoe0
Serial connection established.

Для выхода из просмотра сообщений используйте клавишу q.

Соединения и проходящий трафик.

Просмотреть активные соединения можно командой show system connections. Выглядеть будет примерно так:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address              State      
tcp        0                 0 0.0.0.0:22                       0.0.0.0:*                    LISTEN     
tcp        0                 0 90.188.xxx.xxx:9754     0.0.0.0:*                    LISTEN     
tcp        0                 0 0.0.0.0:1723                   0.0.0.0:*                    LISTEN     
tcp        0                 0 90.188.xxx.xxx:1723     90.125.xx.xx:54619  ESTABLISHED


Используя аргумент этой команды tcp или udp можно получить, соответственно, только TCP или только UDP соединения.

Кроме того, можно в реальном времени просматривать проходящий через интерфейс трафик командой show interfaces [type] [name] capture. Там показывают весьма детальную статистику проходящих пакетов со сведениями о типе их содержимого (а также адресами отправителя и получателя, флагами TCP и прочими полезными сведениями).

# run show interfaces ethernet eth0 capture
Capturing traffic on eth0 ...
0.000000 00:1b:11:79:53:98 -> 01:80:c2:00:00:00 STP Conf. Root = 32768/00:1b:11:79:53:98 Cost = 0 Port = 0x8001
0.504377 10.91.19.1 -> 10.91.19.5 SSH Encrypted response packet len=160
0.504506 10.91.19.5 -> 10.91.19.1 TCP 34550 > 22 [ACK] Seq=1 Ack=161 Win=501 Len=0 TSV=185862671 TSER=532169015
0.661132 10.91.19.5 -> 205.188.7.50 AIM Keep Alive

Также можно использовать аргументы port PORT_NUMBER и not port PORT_NUMBER чтобы просмотреть пакеты только на определенный порт, или наоборот, на все кроме заданного (например, исключить порт 22 чтобы не видеть соединение по SSH между собой и маршрутизатором).
К сожалению, для интерфейсов VPN-сессий так просмотреть трафик не получится: их просто нет в CLI. Но можно сказать sudo tshark -i pppX и получить в точности то же самое.
У Wireshark (бывший Ethereal), который служит бэкендом захвата пакетов, есть еще графическая оболочка, которой теоретически можно этот вывод скормить для более визуального просмотра и анализа. Я не пробовал, но если у кого будет желание, расскажите верно мое предположение или нет.

Межсетевой экран

Для проверки работы правил МСЭ можно посмотреть статистику командой show firewall statistics или, для получения более подробных сведений, show firewall detail.

$show firewall statistics
IPv4 Firewall "InternetToLocal":
 Active on (eth1,IN)
rule  packets   bytes     action      source              destination
----  -------        -----        ------        ------                  -----------
1     172.75M   78.48G    ACCEPT  0.0.0.0/0           0.0.0.0/0           
10    0         0                  ACCEPT  0.0.0.0/0           0.0.0.0/0           
20    548.49K   30.16M    ACCEPT  0.0.0.0/0           0.0.0.0/0           
25    222       11.37K       ACCEPT  0.0.0.0/0           0.0.0.0/0           
--------------------------------------------------------------------------------
IPv4 Firewall "InternetToRouter":
 Active on (eth1,LOCAL)
rule  packets   bytes     action  source              destination
----     -------     -----        ------      ------                 -----------
1        57.06M   14.72G  ACCEPT   0.0.0.0/0          0.0.0.0/0           
10      22.87K   2.18M    ACCEPT   0.0.0.0/0          0.0.0.0/0           
20      1.25K     61.55K   ACCEPT   0.0.0.0/0          0.0.0.0/0           


Как видно, вывод показывают отдельно по каждому набору правил МСЭ и правилу в нем. Для большей наглядности изменения счетчиков в процессе работы их можно предварительно сбросить командой clear firewall RULESET_NAME.

Если какие-то правила вызывают сомнения или просто мешают, можно отключить их с помощью опции disable (set firewall RULESET_NAME rule 10 disable).

NAT

Процесс отладки трансляции сетевых адресов целом напоминает то же с МСЭ. Можно просмотреть активные трансляции с помощью show nat translations, статистику работы правил через show nat statistics и сбросить счетчики командой clear nat counters rule NUMBER.

# run show nat statistics 
Type Codes:  SRC - source, DST - destination, MASQ - masquerade
rule  count     type        IN         OUT
----  -------       ----      ---------  ---------
10    571K       MASQ      -      pppoe0
20    4023K     MASQ      -      pppoe0
150   548K      DST    pppoe0         -      
155   222        DST    pppoe0         -      


Неугодное правило трансляции можно отключить той же опцией disable (set service nat rule NUMBER disable).

Сетевые интерфейсы

Для физических интерфейсов, например Ethernet, можно получить некоторые диагностические сведения. Например, show interfaces ethernet ethX statistics покажет счетчики прошедших пакетов (сбросить можно путем clear interfaces ethernet ethX counters). С помощью show interfaces ethernet ethX physical можно увидеть сведения о режиме работы интерфейса (поддерживаемые и текущая скорость передачи, дуплекс, наличие линка), используемый драйвер и прочее в этом духе. Параметр bus-info из вывод этой команды показывает номер слота шины, в котором он стоит, что может быть полезно для сопоставления имен интерфейсов с сетевыми картами.

Для задачи поиска нужного интерфейса (а на произвольной машине это актуально, поскольку в отличии от готовых решений подписей под ними нет) есть команда show interfaces ethernet ethX identify, которая заставит выбранный интерфейс моргать индикаторами. К сожалению, работает не для всех типов сетевых карт.

Отладка протоколов маршрутизации

Режим отладки можно включить командой debug PROTOCOL TYPE, например, debug ospf events, а просмотреть включена ли отладка с помощью show debugging PROTOCOL. Отладочные сообщения будут показаны в логах. Отключить обратно можно с помощью no debug WHATEVER. Традиционные show ip PROTOCOL OPTION тоже в наличии, но настройка динамической маршрутизации и связанные вопросы это явно тема для отдельной статьи (:

Проблемы с самой системой

Если с самим маршрутизатором произошло что-то страшное, либо просто хочется узнать подробности его жизни, можно использовать следующие команды:

  • Вполняющиеся процессы: show system processes
  • Сообщения ядра в процеесе работы: show system kernel-messages
  • Сообщения ядра во время загрузки: show system boot-messages
  • Использование памяти: show system memory. С аргументов quagga оно выведет использования памяти стеком маршрутизации.
  • Использование дискового пространства: show system storage
  • Список устройств PCI: show hardware pci

А дальше?

Конечно, я описал далеко не все возможные варианты. Для каждой функции в show из операционного режима есть что-то интересное, и разобраться с ним не должно составить особых проблем (тем более, что причинить вред системе с помощью show не получится и вполне можно экспериментировать).

 

Метки:
Опубликовано: Vyatta

 

2 комментария “Отладка и поиск неисправностей во Vyatta”

comment rss - Trackback

  1. Про identify — супер фича 🙂

    Спасибо за статью — познавательно.

    • Ага, еще бы понять, от чего именно зависит будет ли этот identify работать (:
      Вчера проводил небольшое исследование, обнаружил, что работает как правило на довольно серьезных картах (Intel, гигабитный d-link для pci-e), причем у некоторых интеловских только начиная с определенной версии прошивки. В итоге так и непонятно, все ли карты это аппаратно умеют и дело только в прошивке и драйвере, или нет. Если будет время и силы, почитаю в коде как оно вообще реализовано (:

» Оставить комментарий

Вы должны войти чтобы прокомментировать.