Posts tagged ‘ontap’

Как изменить serialnumber у ONTAP Edge?

Если вы используете Data ONTAP Edge в своей инфраструктуре хранения (это, напомню, “виртуальный NetApp” в виде VSA, Virtual Storage Appliance, виртуальной машины с Data ONTAP внутри), в особенности если вы используете не один Edge, а несколько, в пределах одной инфраструктуры управления, то наверняка уже столкнулись с неприятной проблемой. Все Edge устанавливаются с одним и тем же “серийным номером” системы, а это приводит к неприятным эффектам для софта управления, например VSC. Однако есть решение.

Нужно при загрузке VSA прервать нормальную загрузку, и выйти в boot prompt (SIMLOADER), нажав Ctrl-C на сообщение “Hit [Enter] to boot immediately, or any other key for command prompt”. Далее введите следующие команды:

  1. set bootarg.nvram.sysid=1111111101
  2. set SYS_SERIAL_NUM=1111111101
  3. boot

В этих командах 1111111101 – нужный вам серийный номер данного “контроллера” Data ONTAP Edge.

??зменения в схеме лицензирования Data ONTAP 8.2

Процесс постепенного перехода и перевода пользователей с good ol’ 7-mode на shiny new Cluster-mode своей неторопливостью и неспешностью порой мне напоминает ту сердобольную семейку, которая своему щенку фокстерьера хвостик отрезала по кусочку. К меня такое ощущение, что я уже всю жизнь с NetApp провел в процессе transition-а продуктов компании с 7-моде на Кластер. Ну да впрочем хватит бухтеть. :)

На носу у нас Data ONTAP 8.2, с новыми интересными возможностями, а пока на глаза мне попался документ, посвященный изменениям в лицензировании. Как вы заметили, NetApp экспериментиует с лицензированием уже довольно давно, что-то явно получается неплохо, взять хотя бы модель Data ONTAP Essentials.

Начиная с Data ONTAP 8.2 NetApp меняет лицензионные ключи и всю схему лицензий на 7-Mode и Cluster-mode.

Во-первых, вводятся новые, единые лицензионные ключи, единые для 7-Mode и Cluster-mode. Если вы интересовались темой, то знаете, что в Cluster-mode были отдельные ключи, и до 8.2 вам приходилось явно, на этапе покупки системы выбирать, какую систему вы покупаете, чтобы получить нужный набор. Теперь вводятся новые лицензионные ключи софтварных фич, длиной аж 28 символов, которые будут работать на обоих mode Data ONTAP, начиная с 8.2.

Во-вторых, лицензии будут привязаны к серийнику контроллера. Это неприятная новость, но рано или поздно это должно было произойти. На практике, для честного приобретателя, это означает, что теперь, при замене контроллера (head swap), вам также потребуется получит под его серийник новый набор ключей. Соответственно усложняется и удлиняется эта, ранее довольно простая, процедура.

Наконец, лицензи могут существовать “не-cluster-wide”, например часть узлов в кластере может иметь один набор лицензий, а часть – другой, оставаясь при этом единым кластером.* (см комментарий). Напомню, что “кластером” с прошлого года в этом блоге я называю всегда только группу HA-пар контроллеров, работающих в Cluster-mode (C-mode), а то что иногда раньше называлось “кластером”, а именно пара контроллеров под управлением “старой” 7-mode, теперь называется HA-парой (High Availability pair). На HA-пару лицензии по-прежнему единые.

Впрочем, более интересные новости грядут с самим выходом Data ONTAP 8.2, не переключайте ваши браузеры :)

Data ONTAP 8.1 GA release!

??так, 19 апреля наконец случилось долгожданное событие, дооооолгий путь версии 8.1 к пользователю, через казавшиеся бесчисленными Relelease Candidates (RC), завершился, наконец, выходом General Availability Release.

Напомню, это та самая версия, в которой, наконец-то, появился 4-нодовый Cluster-mode для блочных протоколов FC/iSCSI/FCoE. Плюс ряд новых возможностей.

К сожалению, не обошлось и без ряда неприятных потерь, о которых я хочу упомянуть отдельно (потому что про победы вы прочитаете в пресс-релизах, а о факапах придется читать мелким шрифтом, где нибудь в Release Notes).

Во-первых, и об этом я хочу сказать с недоумением и негодованием, не думайте, что фоннатство в отношении NetApp мне напрочь глаза застило, это то, что теперь более не поддерживается Flash Cache на младших моделях линейки 3100/3200, то есть для 3140 и 3210.

А вот так. Физически поставить можно, а в 8.1 не поддерживается. То есть человек покупает 3210, с Flash Cache и 8.0.2,  в котором она поддерживается. Платит за пару Flash Cache 40 тысяч баксов. Платит за Software Subscription сколько-то тысяч, расчитывая получить поддержку и новые версии. Спустя три месяца выходит новая версия, и человек внезапно осознает, что его система более не поддерживается. А вот так вот. Либо новая версия Data ONTAP, и девайс на 40 штук баксов в ведро, либо оставить Flash Cache и тогда стоимость Software Subscription в ведро, и новых версий Data ONTAP для вас нет.

Причины не ясны. То есть варианта два. Либо это сознательное решение, вызванное маркетинговой попыткой “сегментировать”, и повысить привлекательность 3240 для тех, кто при прочих равных выбрал бы систему подешевле. Либо это конструктивный просчет на этапе создания линейки (есть и такое мнение, что на что-то в новой версии перестало хватать памяти). Причем я даже искренне не знаю, что из этих двух причин хуже, то что впервые на моей памяти инженера NetApp так пролетают с расчетом, или что компания так жостко кинула своих клиентов 3210/3140 с Flash Cache и SSP, по схеме, описанной выше.

Напомню, что 3210 с Flash Cache это официальная, опубликованная и валидированная конфигурация FlexPod, как она опубликована, например, в Cisco Validated Design.

UPD: Как совершенно справедливо заметили мои читатели в комментах, читающие внимательно Release Notes (в отличие от меня, позор), на самом деле там написано:
Attention: If you have a 3210 or 3140 storage system with Flash Cache modules installed, do not upgrade your system to Data ONTAP 8.1 7-Mode. Flash Cache modules are not supported in 3210 or 3140 storage systems with Data ONTAP 8.1.
The issue is under investigation and a long-term strategy will be communicated as soon as possible.

Что-ж, будем надеяться на лучшее. Видимо и вправду косяк вылез неожиданно, а так как 8.1 давно уже отстала от графика выпуска, было, по-видимому, решено выпускать как есть, а не откладывать еще раз, а такую неприятную особенность править в последующих Patch Releases.

.

.

Остальное это уже мелочи, на мой взгляд.

Окончательно исчезла поддержка полочных интерфейсных модулей ESH2 (DS14mk2), то есть 2Gb/s FC к полкам. Это, что называется, “туда и дорога”, тем более, что системы с ESH2 не продаются уже лет пять минимум, и в живой системе они могут появиться только как глубокое legacy.

Больше нет FilerView (веб-интерфейса, открывающегося по адресу http://filer/na_admin). Ну я понимаю, что он в своем нынешнем виде уже был позорно анахроничен внешне, и непригоден для Cluster-mode (хотя, наверное, можно было и обновить, и что-нибудь придумать). Но кому он мешал в качестве стандартного инструмента, по-прежнему годного для администрирования 7-mode? Ну то есть я понимаю, у нас теперь всюду Cluster-mode “шагает впереди”, но тем не менее, будем смотреть правде в глаза, в ближайшие пару лет 7-mode все еще будет занимать подавляющее число инсталляций.

Так что теперь у нас для администрирования осталась лишь командная строка и творение развеселого бангалорского гения – System Manager 2.0, который… ну-у… неоднозначный продукт, скажем обтекаемо.

Но главное, конечно, и это ничуть не уменьшается со всем, перечисленным выше, это окончательное появление на рынке полноценного многоузлового кластера, в том числе и для блочных протоколов. Поздравления NetApp, ждем Success Stories, в том числе и на российском рынке!

Вышел Data ONTAP 8.1 RC

Вышел долгожданный 8.1

Напомню, что по введенной с июля 2010 года модели именования релизов, выпуск под названием RC (Release Candidate) является полноценным релизом, оттестированным и готовым в продакшн.

Цитата с сайта:

Release Candidate (RC)

All Data ONTAP releases are made available first as release candidates (RCs). The RC classification indicates that NetApp has completed the internal testing of the major release. RCs are provided primarily to customers who want to start exploring the major or maintenance releases for either new features or bug fixes early on. RC releases are fully tested and are suitable for production usage. (выделение мое, romx)

NetApp might provide multiple RCs, as necessary, to address any specific issues found before the release becomes a general availability (GA) release. NetApp Global Services (NGS) provides support for RCs. After RCs move to GA, all maintenance and patch releases are based on the GA release and not on the RC.

Релизы “цифра после запятой” (Major Release) выходят каждые 18 месяцев, после их выпуска, каждые 6 месяцев выпускаются так называемые Maintenance Release.

image

Список изменений довольно велик и существеннен. Очень много важных изменений, поэтому далее я собрал почти все значимое, в кратком переводе. Порядок пунктов хаотичный и не слишком системный, просто FYI.

Continue reading ‘Вышел Data ONTAP 8.1 RC’ »

5 причин перейти на Data ONTAP 8.0.1

А сегодня у меня в блоге наверное самый активный и интересный нетапповский блоггер, директор и евангелист направления виртуализации и cloud computing – Vaughan Stewart.

Напоминаю, что по средам я публикую переводы недавних интересных постов блоггеров самого NetApp, с их собственной блогохостинговой площадки blogs.netapp.com, кто свободно читает по-английски – рекомендую подписываться на тамошних авторов.

5 Reasons to Upgrade to Data Ontap 8.0.1

Vaughan Stewart - Director & Evangelist, Virtualization & Cloud Computing

На прошлой неделе, проводя наш Virtualization Field Readiness Summit, я много говорил с Dr.Desktop (Chris Gebhardt), который показал мне множество преимуществ наших технологий в области виртуализации десктопов, а также тем, какие преимущества несет с собой новая Data ONTAP 8.0.1, и я решил поделиться этим с вами.

Причина номер 1 – 64-битные aggregates

64-битные aggregate, или “пулы хранения”, позволяют увеличивать размеры aggregates, так как поднимают верхний лимит с 16TB в Data ONTAP 7.x.x до 100TB (в зависимости от типа и мощности контроллера). Для тех, кто еще не знаком с технологиями NetApp, aggregate это набор физических дисков, собранных в RAID-группы

Aggregate это то, как NetApp логически отделяет емкость и производительность в IOPS от физического диска, и использует их в виде ресурсного пула. Такая модель позволяет использовать физические ресуосы с более высоким чем обычно уровнем утилизации, большим, чем можно достичь с помощью традиционных технологий RAID.

При использовании 64-bit aggregate и RAID-DP, наш пользователи могут увеличить размер своих разделов данных, не поступаясь при этом степенью их защиты.

Причина номер 2 – NetApp DataMotion for FC, FCoE, & iSCSI LUN

NetApp DataMotion for LUNs это одна из наших технологий для организации многоуровневого хранения, с помощью которой мы можем, не прерывая доступа к данным на LUN-е, перемещать его (и соответствующий ему FlexVol) с одного aggregate на другой, на том же контроллере. DataMotion выполняет миграцию LUN-ов, вместе со всеми сопутствующими им атрибутами,такими как снэпшоты, состояние thin provisioning, состояние дедупликации и отношений между датасетами (например источник или получатель репликации, “зеркальность” для другого тома, и так далее), причем, как сказано выше, “на ходу”, не прерывая ввод-вывод данных с этих LUN-ов.

Причина номер 3 – 10GbE & FCoE Unified Target Adapter

Data ONTAP 8.0.1 обеспечивает поддержку (в форме драйверов устройств) для нашего Unified Connect Target Adapter (UTA). UTA более известен как Converged Network Adapter (CNA). Наши клиенты с UTA могут использовать его для всего их рабочего трафика, как SAN (FCoE, iSCSI), так и NAS (NFS, CIFS), одновременно, по одному проводу, с использованием Data Center Ethernet (DCE), известного как “10Gb Ethernet”, через одну карту PCI-E.

UTA кроме этого позволяет пользователям потенциально увеличить емкость хранения данных, так как позволяет высвободить слоты PCI-E, занятые под карты портов SAN и Ethernet, и установить в них порты для подключения дополнительных дисковых полок. Слоты PCI-E тут важны, так как, например, такая наша система среднего уровня, как FAS3270, может адресовать до 1,9PB хранения.

Причина номер 4 – Онлайн-компрессия на файловой системе

В свете непрерывно расширяющихся объемов хранения, пользователи требуют средств для хранения данных в виртуализованной форме, при которой “логическая” емкость может значительно превышать “физическую” емкость хранилища, такого как диски или ленты. Сжатие данных это наиболее новое предложение NetApp в области повышения эффективности хранения, среди всех наших многочисленных решений в этой области, нацеленных на такие задачи, как хранение данных виртуальных машин, систем передачи сообщений или баз данных.

Хотя во многих своих постах я подчеркивал наши возможности по дедупликации данных на уровне диска и в кэше, компрессия это отличное средство, дополняющее дедупликацию, и еще более увеличивающее экономию места для данных, не исчерпывающихся виртуальными машинами, например таких, как домашние директории пользователей, инженерные и архивные данные. А самое лучшее тут то, что лицензия на компрессию – бесплатна!

Причина номер 5 – поддержка VMware VAAI

Data ONTAP 8.0.1 обеспечивает поддержку VMware Storage APIs for Array Integration (VAAI), новой возможности появившейся в vSphere 4.1. Это такие возможности, как: Full Copy, Block Zeroing и Hardware-assisted Locking, расширяющие возможности масштабирования виртуальной инфраструктуры, путем переноса части операций по вводу-выводу на аппаратуру системы хранения. В настоящий момент поддерживаются только хранилища VMFS, но, верьте мне, в ближайшем будущем тут будет еще много интересного.

Ну ОК, я немного промахнулся, когда счел, что числа “пять” для причин будет достаточно. Есть еще кое-что, пусть это будет бонусом.

Бонус – Повышенная производительность!

В релизе 8.0.1 мы повысили быстродействие логики дедупликации в кэше массива, что дало нам прирост в различных тестах от 10% до 48% увеличения производительности.

Я хочу процитировать своего коллегу, Dr.Desktop, на стенде которого был проведен эксперимент с одновременной загрузкой 5000 виртуальных десктопов (VDI, VMware View) под Windows 7, что заняло 50 минут на всего 24 дисках SAS. Этот результат на 28% улучшил предыдущий результат, полученный с использованием на контроллерах Data ONTAP 7.3.4.

В комментариях указали еще один немаловажный плюс, который я счел необходимым внести в переводе (прим.romx)

Бонус 2 – лимит тома с дедупликацией теперь поднят до 16 TB для всех платформ!

Если раньше, на Data ONTAP семейства 7.х.х, емкость тома, на котором можно было включить дедупликацию, была ограничена различными величинами, в зависимости от типа контроллера, например для FAS2020 можно было включить дедупликацию только на томе, физическим размером не более 1TB, а для 2040 – 3TB, то на 8.0.1 эти лимиты на всех системах, поддерживающих 8.0.1, включая и 2040, лимиты емкости для тома с возможностью дедупликации подняты до 16TB.

Закругляясь.

??нженеры NetApp каждодневно работают над улучшением и увеличением возможностей нашей платформы, и с релизом 8.0.1 пользователи получили дополнительную функциональность и увеличение производительности для уже имеющихся у них систем. Я добавлю, что количество причин будет в дальнейшем только расти, с появлением все новых релизов.

С тех пор как нам удалось обеспечить непрерывающий (non-disruptive) работу системы хранения апгрейд с Data ONTAP 7.x на 8.0.1, апгрейд на новую версию не может быть проще!

Встроенное шифрование данных в Data ONTAP 8.0.1

По сведениям, опубликованным блогом Geek ONTAP, Data ONTAP с версии 8.0.1 будет уметь использовать диски, сертифицированные по FIPS 140-2 level 2, с так называемым “аппаратным шифрованием”, то есть встроенной системой шифрования-дешифрования данных с помощью уникального для каждого диска ключа.

Это, так сказать, не функция Data ONTAP как такового, просто возможность использовать средства, предоставляемые оборудованием. Подобные диски вот уже несколько лет как есть на рынке, к сожалению, из-за ограничений ввоза криптографических систем, они в России почти не встречаются, по крайней мере в официально поставляемых системах.

Так как вся эта кухня с ключами и шифрованием работает, по сути “на уровне диска”, то специальных особых требований к уровню OS данная система не предъявляет, оставаясь “прозрачной” для уровня приложений, однако поддержку и валидацию работы с NSE (NetApp Storage Encryption) требуют SnapMirror и SnapVault, что и было проделано для версии 8.0.1.
Работу с ключами обеспечивает специальный сервер ключей.

Еще раз повторюсь, для России все эти возможности остаются сугубо теоретическими, вследстве жесткой политики ограничения импорта сильной криптографии в стране, не позволяющих такие устройства в страну ввозить на практике.

Powershell Toolkit for Data ONTAP

Занимающимся администрированием систем NetApp в серверной инфраструктуре Windows, и владеющим навыками использования продукта Microsoft Powershell, может быть интересен постепенно развивающийся в комьюнити NetApp проект Powershell Toolkit for Data ONTAP.

Скачать с сайта communities (для появления возможности download вы должны иметь логин на Communities.NetApp)
Примеры скриптов
Прочая документация
Скачать v 1.2 не с сайта NetApp (без логина):
http://www.divshare.com/download/12954906-87d

Data ONTAP 7G Cookbook

Бродя по бесконечным просторам внутренних пространств вебсайта NetApp обнаружил там в глухом уголке чрезвычайно полезную вещь, каковой и поделюсь.
Называется Data ONTAP Cookbook.

Представляет собой сравнительно краткий “сборник рецептов” (cookbook – кулинарная книга) для повседневной жизни админа, этакая “настольная книга домосистемохозяина”.
Как и обычная кулинарная книга это сборник пошаговых инструкций по выполнению тех или иных практических действий на системе хранения NetApp, например:

  • Как создать том
  • Настроить NFS export
  • Сконфигурировать порт FC
  • ??зменить размер LUN
  • Создать и настроить VIF/ifgrp
  • Настроить SnapMirror
  • …и так далее, всего 70 страниц.

Скачать можно тут: http://www.divshare.com/download/12748580-cab

Встроенный сниффер: pktt

В недрах OS Data ONTAP скрывается много удивительных гитик.
Вот, например, в каждой системе хранения NetApp, вернее в ее OS, имеется встроенный сниффер, запускаемый командой pktt, и собирающий дамп с интерфейса для последующей разборки, в формате стандартного юниксного tcpdump.

??спользование:
pktt start {if | all} [-b bsize] [-d dir] [-s size] [-m pklen] [-v] [-i ipaddr] [-i ipaddr] …
pktt pause {if | all}
pktt dump {if | all} [-d dir]
pktt stop {if | all}
pktt status [{if | all}] [-v]
pktt delete [filename.trc]+
pktt list

Команда pktt управляет простым встроенным средством сбора ethernet-трафика. Пакеты захватываются с указаного интерфейса в специальный trace buffer, и после этого записываются в файл на диске. Данные записываются в формате “tcpdump”, который может быть прочитан разнообразными средствами, такими как tcpdump, ethereal (wireshark), и прочими программами-анализаторами и просмотрщиками. Вывод можно также конвертировать (утилитой editcap) в различные другие употребимые форматы, например для Sniffer, NetMon, и snoop.

pktt может захватывать пакеты для всех поддерживаемых типов медиа.

pktt start {if | all} [-b bsize] [-d dir] [-s size] [-m pklen] [-v] [-i ipaddr] [-i ipaddr] …

Команда start запускает трассировку, (или рестартует ее, если pktt находился в положении paused). Данные собираются в память, и пишутся в кольцеой буфер в памяти в формате “tcpdump”. Опции могут быть следующие:

-b размербуфера
Устанавливает размер буфера, который может быть определен в килобайтах или мегабайтах, при задании ‘k’ или ‘m’ после числа. Если не определен, то будет равен 128K, если вы не задали также опцию -d, что немного, но может быть достаточно в ряде случаев. Если задана опция -d, то значение буфера по умолчанию равно 1M. Значение может быть от 8K до 32M, то в очень редких случаях стоит устанавливать его большим 1-2M. Максимальный объем пространства, доступного pktt в памяти, равен 64M.

-d директория
Определяет путь к существующей директории, куда будет записан файл дампа. Файл будет иметь имя “if.trc” где”if” это имя интерфейса (например e0, fa3, и так далее.). Если опция не указана, то данные будут собиратся только в памяти, и после его заполнения, данные будут перезаписываться по кругу. Однак в любой момент можно сбросить содержимое буфера на диск с помощью команды pktt dump. Обратите внимание, что если система не будет успевать записывать все пакеты, то будет расти показатель счетчика “dropped” в выводе статуса pktt. Помните, что запись дампа всего трафика на диск может вызвать значительную нагрузку на запись для системы, и замедлить ее работу, поэтому, если это возможно, всегда ограничивайте область трассировки определенными IP-адресами и интерфейсами. Кроме этого, если вам не нужно сохранять содержимое всего пакета, то вы можете обрезать его командой -m.

??мейте ввиду, что любой существующий файл .trc будет молча перезаписан при выполнении этой команды.

-s размер
Эта опция позволяет вам задать максимальный размер файла дампа. Величина может быть задана с указанием “k”, “m”, или “g”. По умолчанию - 1G. Этот параметр всегда используется вместе с опцией -d. После достижения максимального лимита по размеру, пакеты продолжают собираться в буфер, но уже не пишутся на диск.

-m длинапакета
Этот параметр задает длину обрабатываемых пакетов (обрезая все что выходит за заданные пределы). По умолчанию - 1514 байт, что подходит для обычного ethernet, но может быть недостаточно для gigabit ethernet с использованием jumbo frames. ??ногда может быть использован для ситуаций, когда не обязательно сохранять полное содержимое пакета. Однако, во многих случаях полезно сохранять полное содержимое всего пакета. В этом случае, если пакеты имеют размер свыше 1514 байт, вы можете задать желаемый максимум. ??мейте виду, что некоторые декодеры (как пример - snoop) не обрабатывают пакеты более 1514 байт. Декодер ethereal/wireshark не имеет такой проблемы.

-i ipaddr [-i ipaddr] …
Эта опция включает простую возможность фильтрации. Можно задать до чтырех IP-адресов, для которых (на которые и с которых) будет записываться трафик. Это, кроме всего прочего, ограничит записываемый трафик только IP-пакетами, то есть в него не попадут пакеты, например arp/rarp, и прочие подобные.

pktt pause {if | all}
Команда “pause” приостанавливает сбор трафика с указаных интерфейсов. Незаписанные данные в буфере сбрасываются на диск. С помощью команды pktt start без других опций, можно возобновить сбор данных.

pktt dump {if | all} [-d dir]
Команда dump вызывает сброс содержимого кольцевого буфера в памяти в файл на диске. Если задана опция -d dir, то файл будет создан в указанной директории, в противном случае - в корневой директории root volume. ??мя файла всегда равно if.trc (где if это название интерфейса), и содержимое записывается в формате “tcpdump”. Если файл уже существует, то он будет молча перезаписан.

pktt stop {if | all}
Эта команда выполнит остановку сбора дампа для всех заданных (или вообще всех) интерфейсов. Если вы пишете на диск, то все незаписанные на этот момент данные в буфере будут сброшен на диск. Если вы не задали файл записи дампа, то все данные в буфере будут потеряны. Это действие не требует подтверждения, так что будьте аккуратны.

pktt status [{if | all}] [-v]
Эта команда покажет вым состояние буфера и файла дампа для действующей трассировки. ??спользуя “pktt status -v” вы получите полный статус всех интерфейсов.

pktt delete [filename.trc]+
Эта команда позволит вам удалить один или неколько файлов дампа в корневой директории. Длжен быть указан хотя бы один файл.

pktt list
Показывает список всех файлов трассировки в корневой директории.

Примеры:
pktt start e0
Эта команда начинает захват трафика с интерфейса “e0″. Весь трафик пищется в кольцевой буфер, размером 128K. ??ли же, если предыдущая команда приостановила сбор дампа, то она его возобновит.

pktt start fa3 -d / -s 100m -b 2m
Эта команда начинает захватывать дамп трафика на интерфейсе “fa3″, и писать в файл под названием “/fa3.trc” которому будеи позволено расти до максимальног размера в 100MB, с использованием буфера в 2MB.

pktt start el10 -d /home -m 10k -b 500k -i ehost1 -i ehost2
Эта команда начинает захватывать пакеты на и с определенных хостов, в данном примере “ehost1″ и “ehost2″ записывая их в файл “/home/el10.trc”. Пакеты размером до 10K записываются в буфер, размером 500K buffer. Отметьте, это будет работать только в том случае, если имена заданных хостов будут успешно резолвиться в DNS.

pktt start all -b 128k -i 172.20.4.1
Все интерфейсы начинают записыват дамп трафика на и с определенного IP-адреса. Это простой и быстрый способ посмотреть трафик, сли вы не уверены в том, какой интерфейс используется, но хотите увидеть пакеты с одного или более адресов IP.