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 не получится и вполне можно экспериментировать).
Метки: troubleshooting
Опубликовано: Vyatta
Про identify — супер фича 🙂
Спасибо за статью — познавательно.
Ага, еще бы понять, от чего именно зависит будет ли этот identify работать (:
Вчера проводил небольшое исследование, обнаружил, что работает как правило на довольно серьезных картах (Intel, гигабитный d-link для pci-e), причем у некоторых интеловских только начиная с определенной версии прошивки. В итоге так и непонятно, все ли карты это аппаратно умеют и дело только в прошивке и драйвере, или нет. Если будет время и силы, почитаю в коде как оно вообще реализовано (: