Не все стеки одинаково полезны, или стеки StackWise

Введение

Некоторые модели коммутаторов компании Cisco могут быть объединены в стек с использованием специализированных стековых кабелей. Обычно это устройства, занимающие один-два юнита в стойке; часто с неизменяемой конфигурацией. Конечно же, модульные шасси тоже имеют механизмы для объединения нескольких физических устройств, но в данной статье мы не будем касаться этих механизмов, а сфокусируем своё внимание исключительно на физическом стекировании.

На момент написания статьи нам было известно четыре разных версии стека: FlexStack, StackWise, StackWise Plus и StackWise-480. В стек по технологии FlexStack могут быть объединены коммутаторы Cisco Catalyst 2960S. Пропускная способность стека FlexStack составляет 20 Гбит/с в режиме дуплекса, то есть по 10 Гбит/с в каждую сторону. Технология StackWise поддерживается, например, коммутаторами серий Catalyst 3750. Пропускная способность стека StackWise составляет 32 Гбит/с в дуплексе, то есть 16 Гбит/с в каждую сторону. Коммутаторы серий Cisco Catalyst 3750-E и 3750-X поддерживают уже стек версии StackWise Plus, отличающийся от StackWise увеличенной до 64/32 Гбит/с полосой пропускания, а также рядом новых возможностей. Стоит также отметить, что линейка коммутаторов Catalyst 3750-X поддерживает также технологию StackPower, позволяющую обеспечивать отказоустойчивость устройств в стеке для случая отказа блока питания какого-либо коммутатора. Коммутаторы Cisco Catalyst 3850 обладают поддержкой стека StackWise-480, имеющим пропускную способность 480 Гбит/с.

Объединение коммутаторов в стек предоставляет администратору целый ряд преимуществ: единые подсистемы управления и коммутации, улучшенная отказоустойчивость и высокая доступность. Так, например, можно управлять всем стеком как единым устройством с помощью единственной сессий telnet/SSH. Фреймы и пакеты передаются между коммутаторами через стековые порты, что освобождает обычные интерфейсы 10/100 Мбит/с и 1/10 Гбит/с. Внутри стека доступны функции EtherChannel в случае, когда физические каналы подключаются в разные коммутаторы (нечто похожее (vPC – virtual PortChannel) есть и в L3-коммутаторах Cisco Nexus, но это устройства совсем другого класса).

Одним из отличий между технологиями StackWise и StackWise Plus является поддержка последней локальной коммутации. Суть локальной коммутации заключается в том, что если отправитель и получатель подключены к портам одного коммутатора, то фрейм пересылается напрямую, то есть данные в стек не передаются. При отсутствии локальной коммутации, то есть при использовании StackWise, любые данные пересылаются через стек. Из стека фрейм удаляется коммутатором отправителя. Таким образом, если отправитель и получатель подключены к одному устройству, то данные передаются через стековое кольцо, возвращаются на тот же коммутатор и уже затем пересылаются через нужный порт. Получается, что если отправитель и получатель подключены даже в соседние порты одного и того же коммутатора, данные всё равно пройдут через стек. Естественно, такое «путешествие» кадров вносит дополнительную задержку. Технология StackWise Plus лишена такого недостатка, так как в ней не происходит отправки лишних данных в стек (Local Switching), а данные из стека удаляются коммутатором получателя (Destination Stripping). Наверняка, дополнительно вносимая стеком задержка невелика, однако в ситуациях, где решающую роль играет каждая микросекунда, даже такое незначительно изменение может быть заметно. В данной статье мы решили установить, какое количественное влияние оказывает стек, собранный по технологии StackWise, на передаваемый трафик.

Тестирование

В нашем распоряжении было два коммутатора Cisco Catalyst 3750G: C3750G-12S-S и C3750G-24TS-S1U, поддерживающих StackWise. Тестирование мы проводили совместно с нашими друзьями из проекта Anticisco с помощью IXIA XM2. Во время тестирования мы использовали пять различных сценариев подключения, перечисленных ниже.

1. Без использования стека отправитель и получатель подключались в первый и двадцать четвёртый порты.
2. Без использования стека отправитель и получатель подключались в первый и второй порты.
3. При наличии стека отправитель и получатель подключались в первый и двадцать четвёртый порты одного коммутатора.
4. При наличии стека отправитель и получатель подключались к первым портам разных коммутаторов.
5. При наличии стека отправитель и получатель подключались к первому и второму порту одного коммутатора.

Для каждого из сценариев мы проводили измерения минимальной, средней и максимальных задержек при передаче кадров по 100, 400, 1400 и 1518 байт. Фреймы каждого из размеров передавались при загрузке интерфейсов коммутатора на 10, 55, 77,5 88,75 и 100 процентов. На графиках ниже представлены только средние значения задержек.

Анализируя каждый представленный график, можно сказать, что задержка коммутации прямо зависит от текущей загрузки интерфейса, а также размера передаваемого кадра. Вполне предсказуемый результат!

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

Как мы видим, сценарии подключения пользователей распределились следующим образом (задержка увеличивается от наименьшей к наибольшей): 1, 2, 4, 3, 5. Нам бы хотелось привести здесь некоторые наши соображения, связанные с полученными в тестах результатами.

Судя по полученным значениям задержек, коммутация между портами из разных порт-групп происходит быстрее, данное явление не связано со стеком, но с прочими особенностями внутренней архитектуры коммутаторов Cisco Catalyst. Указанная зависимость наблюдается как на включенном в стек коммутаторе, так и на отдельном. Ещё одно наблюдение связано с задержкой на коммутацию больших фреймов. Задержка на сериализацию кадра длиной, например, 1400 байт будет составлять более 10 мкс, тогда как задержка на коммутацию меньше этой величины (примерно 7,8 мкс), отсюда следует, что в коммутаторах Cisco Catalyst 3750G используется один из двух методов коммутации: Cut Through или Fragment Free, но никак не Store and Forward.

Включение коммутатора в стек увеличивает значение задержки при передаче данных между теми же самыми портами. Данное явление связано с необходимостью пересылки данных через стековое кольцо в технологии StackWise. Грубо оценить значение дополнительно вносимой стеком задержки можно в полторы микросекунды. Данная оценка получается из сравнения графиков для следующих пар сценариев: 1 и 3, 2 и 5.

Дополнительная задержка на прохождение стека между портами разных коммутаторов приблизительно составляет половину вносимой стеком задержки при коммутации между портами одного устройства. Данное явление легко объяснить тем, что при подключении абонентов к разным коммутаторам стека фрейм проходит лишь половину стекового кольца до того момента, как он попадёт на коммутатор получателя. Здесь есть тонкий момент: после того, как фрейм по стеку доставлен на коммутатор получателя, он не прекращает своё движение по стековому кольцу, которое в нашем случае займёт у него ещё приблизительно 0.75 мкс, но он уже может обрабатываться коммутационной матрицей устройства, к которому подключен получатель, то есть дальнейшее движение фрейма по стеку уже не оказывает никакого влияния на суммарную задержку. Из стека данный фрейм удалит отправивший его коммутатор.

На этом мы завершаем измерение и обсуждение вносимых стеком Cisco StackWise задержек и переходим к подведению итогов. Для желающих провести собственный анализ полученных данных мы предлагаем скачать с нашего сайта архив с результатами измерений.

Заключение

Подключение коммутатора Cisco Catalyst в стек StackWise увеличивает задержки коммутации для абонентов, подключенных к этому коммутатору. Такое поведение устройств обусловлено логикой работы стека: фрейм прогоняется по нему вне зависимости от того, где друг относительно друга расположены отправитель и получатель.

Технология StackWise Plus обратно совместима со StackWise, то есть коммутаторы Cisco Catalyst серий 3750-X и 3750-E могут быть добавлены в один стек с обычными коммутаторами серии 3750, однако сам стек при этом будет собран по технологии StackWise. Единственное, на что стоит обратить внимание, так это на поддержку локальной коммутации моделями серий 3750-X и 3750-E, то есть эти коммутаторы не будут отправлять в стек фреймы, отправитель и получатель которых подключены к этому устройству, что должно снизить задержку коммутации.

Для уменьшения задержки коммутации при использовании моделей 2960-S и 3750 мы рекомендуем подключать отправителя и получателя в порты разных порт-групп коммутатора, не подключенного в стек. Если такой возможности нет, то тогда следует задействовать порты одной порт-группы, но также в коммутаторе без стека. Здесь мы руководствуемся лишь желанием уменьшения задержки коммутации и не принимаем во внимание никакие другие аспекты функционирования (например, отказоустойчивость) коммутаторов и стеков.

Если же без стека обойтись не удаётся, то тогда стоит продумать подключение таким образом, чтобы фрейм от отправителя до получателя проходил по наиболее короткому пути в стеке. В случае, когда важно значение RTT, то подключать отправителя и получателя необходимо к разным коммутаторам в стеке. Уменьшение количества коммутаторов в стеке также приведёт к снижению задержки как при подключении отправителя и получателя к одному устройству, так и к разным.

Напоследок хотелось бы обратить внимание читателя на зависимость задержки коммутации от загрузки сетевых интерфейсов. Не стоит подключать абонентов, требующих минимизации задержки, в высоконагруженные стеки. При расчёте нагрузки следует обращать внимание не только на загрузку интерфейсов, через которые передаётся пользовательский трафик, но и на суммарную загрузку стека, так как в технологии StackWise все фреймы передаются через стек. Выяснить версию стека можно с помощью команды show switch stack-ring speed, а текущая загрузка интерфейсов и стекового кольца представлена в выводе команды show controllers utilization.

test-3750#show switch stack-ring speed
Stack Ring Speed        : 32G
Stack Ring Configuration: Full
Stack Ring Protocol     : StackWise
test-3750#show controllers utilization
Port       Receive Utilization  Transmit Utilization
Gi1/0/1            0                    0
Gi1/0/2            0                    0
Gi1/0/3            0                    0
Gi1/0/4            0                    0
Gi1/0/5            0                    0
Gi1/0/6            0                    0
Gi1/0/7            0                    0
Gi1/0/8            0                    0
Gi1/0/9            0                    0
Gi1/0/10           0                    0
Gi1/0/11           0                    0
Gi1/0/12           0                    0
Gi1/0/13           0                    0
Gi1/0/14           0                    0
Gi1/0/15           0                    0
Gi1/0/16           0                    0
Gi1/0/17           0                    0
Gi1/0/18           0                    0
Gi1/0/19           1                    0
Gi1/0/20           0                    0
Gi1/0/21           0                    0
Gi1/0/22           0                    0
Gi1/0/23           0                    0
Gi1/0/24           0                    0
Gi2/0/1            0                    0
Gi2/0/2            0                    0
Gi2/0/3            0                    0
Gi2/0/4            0                    0
Gi2/0/5            0                    0
Gi2/0/6            0                    0
Gi2/0/7            0                    0
Gi2/0/8            0                    0
Gi2/0/9            0                    0
Gi2/0/10           0                    0
Gi2/0/11           0                    0
Gi2/0/12           0                    0
Gi2/0/13           0                    0
Gi2/0/14           0                    0
Gi2/0/15           0                    0
Gi2/0/16           0                    0
Gi2/0/17           0                    0
Gi2/0/18           0                    0
Gi2/0/19           0                    0
Gi2/0/20           0                    0
Gi2/0/21           0                    0
Gi2/0/22           0                    0
Gi2/0/23           0                    0
Gi2/0/24           0                    0
Total Ports : 48
Switch Receive Bandwidth Percentage Utilization  : 0
Switch Transmit Bandwidth Percentage Utilization : 0
Stack Ring Percentage Utilization : 0

Удачи в построении и использовании стеков!

Перехват трафика с помощью Cisco Nexus

Прослушивание сети может быть осуществлено не только на аппаратных брандмауэрах Cisco PIX/ASA и маршрутизаторах ASR, о которых мы писали ранее, но также и на коммутаторах того же производителя. В данной статье мы расскажем о том, как осуществить перехват на коммутаторе Cisco Nexus. Сразу бы хотелось отметить, что речь идёт о перехвате данных, пересылаемых через control plane и management plane, то есть тех, что требуют обработки центральным процессором. К числу таких данных можно отнести сообщения следующих протоколов: ARP, STP, ICMP, LACP, CDP и другие. Кадры и пакеты, которые коммутируются через ASIC (не пересылаются на процессор) рассматриваемым способом перехватить не удастся, для этого придётся организовывать SPAN-сессию. Перехваченные данные можно анализировать локально (через telnet-сессию или консоль), либо пересылать на удалённый сервер для последующего анализа. Обсуждаемая нами функциональность носит название Ethanalyzer. В нашем распоряжении была модель Nexus 5548UP, основные характеристики которой указаны ниже.

nexus5548up# sho ver
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Documents: http://www.cisco.com/en/US/products/ps9372/tsd_products_support_series_home.html
Copyright (c) 2002-2013, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.
Software
 BIOS:      version 3.6.0
 loader:    version N/A
 kickstart: version 6.0(2)N1(2)
 system:    version 6.0(2)N1(2)
 Power Sequencer Firmware:
 Module 1: version v1.0
 Module 3: version v5.0
 Microcontroller Firmware:        version v1.2.0.1
 SFP uC:    Module 1: v1.0.0.0
 QSFP uC:   Module not detected
 BIOS compile time:       05/09/2012
 kickstart image file is: bootflash:///n5000-uk9-kickstart.6.0.2.N1.2.bin
 kickstart compile time:  3/14/2013 1:00:00 [03/14/2013 08:53:55]
 system image file is:    bootflash:///n5000-uk9.6.0.2.N1.2.bin
 system compile time:     3/14/2013 1:00:00 [03/14/2013 11:28:50]
Hardware
 cisco Nexus5548 Chassis ("O2 32X10GE/Modular Universal Platform Supervisor")
 Intel(R) Xeon(R) CPU         with 8262944 kB of memory.
 Processor Board ID FOC16227FRP
 Device name: nexus5548up
 bootflash:    2007040 kB
Kernel uptime is 0 day(s), 2 hour(s), 53 minute(s), 48 second(s)
Last reset at 957034 usecs after  Mon Apr  8 05:32:48 2013
 Reason: Disruptive upgrade
 System version: 5.2(1)N1(1a)
 Service:
plugin
 Core Plugin, Ethernet Plugin

На нашей платформе используется операционная система Linux Montavista kernel, Version 2.6.10, значит, на ней могут быть установлены дополнительные модули расширения. Одним из таких модулей является TShark, - часть утилиты Wireshark (бывший Ethereal).

nexus5548up# ethanalyzer ?
 local  Start local capture of frames to Sup
nexus5548up# ethanalyzer local ?
 <CR>
 >          Redirect it to a file
 >>         Redirect it to a file in append mode
 interface  A live capture will start on following interface
 read       Filename to read the captured packet
 |          Pipe command output to filter

Также как и в Wireshark здесь есть возможность использования фильтров. Фильтры бывают двух типов: фильтр отображения (display-filter) и фильтр перехвата (capture-filter), принцип работы которых совпадает с аналогичными в Wireshark.

nexus5548up# ethanalyzer local interface mgmt ?
 <CR>
 >                      Redirect it to a file
 >>                     Redirect it to a file in append mode
 autostop               Capture autostop condition
 capture-filter         Filter on ethanalyzer capture
 capture-ring-buffer    Capture ring buffer option
 detail                 Display detailed protocol information
 display-filter         Display filter on frames captured
 limit-captured-frames  Maximum number of frames to be captured (default is 10)
 limit-frame-size       Capture only a subset of a frame
 raw                    Hex/Ascii dump the packet with possibly one line summary
 write                  Filename to save capture to
 |                      Pipe command output to filter

Пару слов стоит сказать об интерфейсах. Nexus 5548UP имеет три «интерфейса»: inbound-hi для высокоприоритетного входящего трафика (LACP, CDP, FCoE, DCBX), inbound-low для низкоприоритетного трафика (IGMP, ARP) и mgmt для данных, приходящих через Management порт коммутатора.

nexus5548up# ethanalyzer local interface ?
 inbound-hi   Inbound(high priority) interface
 inbound-low  Inbound(low priority) interface
 mgmt         Management interface

По умолчанию Ethanalyzer сохраняет десять перехваченных кадров. Это значение можно изменить с помощью параметра limit-captured-frames.

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

nexus5548up# ethanalyzer local interface mgmt capture-filter "icmp" write bootflash:foxtesticmp.cap
Capturing on mgmt0
2013-04-08 09:12:00.073872 192.168.1.2 -> 192.168.1.1 ICMP Echo (ping) request
2013-04-08 09:12:00.073947 192.168.1.1 -> 192.168.1.2 ICMP Echo (ping) reply
2013-04-08 09:12:01.075255 192.168.1.2 -> 192.168.1.1 ICMP Echo (ping) request
2013-04-08 09:12:01.075451 192.168.1.1 -> 192.168.1.2 ICMP Echo (ping) reply
2013-04-08 09:12:02.075737 192.168.1.2 -> 192.168.1.1 ICMP Echo (ping) request
2013-04-08 09:12:02.075927 192.168.1.1 -> 192.168.1.2 ICMP Echo (ping) reply
2013-04-08 09:12:03.079609 192.168.1.2 -> 192.168.1.1 ICMP Echo (ping) request
2013-04-08 09:12:03.079788 192.168.1.1 -> 192.168.1.2 ICMP Echo (ping) reply
nexus5548up# 8 packets captured
ag-nexus5548-7# dir bootflash:
 319    Aug 24 11:48:26 2012  MDS*****.lic
 322    Sep 03 11:45:41 2012  MDS*****.lic
 744    Apr 08 09:12:04 2013  foxtesticmp.cap
 34672128    Apr 08 05:13:03 2013  n5000-uk9-kickstart.6.0.2.N1.2.bin
 238082390    Apr 08 05:05:54 2013  n5000-uk9.6.0.2.N1.2.bin
 4096    Jan 01 11:16:26 2009  vdc_2/
 4096    Jan 01 11:16:26 2009  vdc_3/
 4096    Jan 01 11:16:26 2009  vdc_4/
 4096    Apr 08 05:35:30 2013  virt_strg_pool_bf/
 676    Dec 06 06:01:02 2012  vlan.dat
Usage for bootflash://sup-local
 390414336 bytes used
 1258209280 bytes free
 1648623616 bytes total

Анализ сохранённого ранее перехвата может быть проведён как локально, так и удалённо. Для локального анализа необходимо использовать опцию read.

nexus5548up# ethanalyzer local read bootflash:foxtesticmp.cap limit-captured-frames 1 detail
Frame 1 (74 bytes on wire, 74 bytes captured)
 Arrival Time: Apr  8, 2013 09:12:00.073872000
 [Time delta from previous captured frame: 0.000000000 seconds]
 [Time delta from previous displayed frame: 0.000000000 seconds]
 [Time since reference or first frame: 0.000000000 seconds]
 Frame Number: 1
 Frame Length: 74 bytes
 Capture Length: 74 bytes
 [Frame is marked: False]
 [Protocols in frame: eth:ip:icmp:data]
Ethernet II, Src: 00:e0:4d:08:4f:ea (00:e0:4d:08:4f:ea), Dst: 54:7f:ee:a9:0c:81 (54:7f:ee:a9:0c:81)
 Destination: 54:7f:ee:a9:0c:81 (54:7f:ee:a9:0c:81)
 Address: 54:7f:ee:a9:0c:81 (54:7f:ee:a9:0c:81)
 .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
 .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
 Source: 00:e0:4d:08:4f:ea (00:e0:4d:08:4f:ea)
 Address: 00:e0:4d:08:4f:ea (00:e0:4d:08:4f:ea)
 .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
 .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
 Type: IP (0x0800)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.1 (192.168.1.1)
 Version: 4
 Header length: 20 bytes
 Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
 0000 00.. = Differentiated Services Codepoint: Default (0x00)
 .... ..0. = ECN-Capable Transport (ECT): 0
 .... ...0 = ECN-CE: 0
 Total Length: 60
 Identification: 0x5f0b (24331)
 Flags: 0x00
 0.. = Reserved bit: Not Set
 .0. = Don't fragment: Not Set
 ..0 = More fragments: Not Set
 Fragment offset: 0
 Time to live: 128
 Protocol: ICMP (0x01)
 Header checksum: 0x3cf7 [correct]
 [Good: True]
 [Bad : False]
 Source: 192.168.1.2 (192.168.1.2)
 Destination: 192.168.1.1 (192.168.1.1)
Internet Control Message Protocol
 Type: 8 (Echo (ping) request)
 Code: 0 ()
 Checksum: 0x45fd [correct]
 Identifier: 0x0001
 Sequence number: 1886 (0x075e)
 Data (32 bytes)
0000  61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70   abcdefghijklmnop
0010  71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69   qrstuvwabcdefghi
 Data: 6162636465666768696A6B6C6D6E6F707172737475767761...
 [Length: 32]

Для удалённого анализа необходимо выгрузить сохранённый файл с использованием любого доступного протокола обмена файлами, например, TFTP.

nexus5548up# copy bootflash:foxtesticmp.cap tftp:
Enter vrf (If no input, current vrf 'default' is considered): management
Enter hostname for the tftp server: 192.168.1.2
Trying to connect to tftp server......
Connection to Server Established.
TFTP put operation was successful
Copy complete, now saving to disk (please wait)... 

На этом мы завершаем рассмотрение возможностей функции Cisco Ethanalyzer и желаем успешного решения сетевых проблем с её помощью.

Перехват пакетов с помощью коммутатора NETGEAR FSM726v3

Для начала сохранения передаваемых пакетов во внутреннюю память устройства необходимо из конфигурационного режима выполнить команду capture all packets.

(FSM726V3) (Config)#capture ?
all                      Enable/Disable capturing All packets..
receive                  Enable/Disable capturing Receive packets..
transmit                 Enable/Disable capturing Transmit packets..
wrap                     Enable/Disable Log Wrapping Configuration..
(FSM726V3) (Config)#capture all ?
packets                  Enable/Disable capturing All packets..
(FSM726V3) (Config)#capture all packets ?
<cr>                     Press enter to execute the command.
(FSM726V3) (Config)#capture all packets

Получить доступ к перехваченным пакетам можно с помощью той же управляющей сессии и команды show capture packets. Ниже представлен вывод одного из таких перехваченных пакетов.

(FSM726V3) #show capture packets
1/0/26  Length = 64  [RECEIVE]
===================
02:04:46.0000
0000 01 80 c2 00 00 00 fc fb fb 7e fd 92 81 00 00 01
0010 00 26 42 42 03 00 00 00 00 00 61 4f 64 a0 e7 73
0020 ae 00 00 00 00 04 81 4f fc fb fb 7e fd 80 80 12
0030 01 00 14 00 02 00 0f 00 00 00 00 00 00 00 00 00
0040 31 2e 31 0d 0a 48 6f 73 74 3a 32 33 39 2e 32 35
0050 35 2e 32 35 35 2e 32 35 30 3a 31 39 30 30 0d 0a
0060 53 54 3a 75 72 6e 3a 73 63 68 65 6d 61 73 2d 75
0070 70 6e 70 2d 6f 72 67 3a 64 65 76 69 63 65 3a 53
===================

Весь полученный таким образом «текст» мы сохранили в отдельный файл. Теперь нам необходимо привести его к виду, понимаемому утилитой text2pcap, входящей в состав сетевого анализатора Wireshark. Конечно, можно анализировать полученные данные и вручную, но с использованием Wireshark или других подобных программ, это будет намного удобнее. Процедуру подготовки данных для утилиты text2pcap мы подробно описывали ранее в статье, посвящённой перехвату трафика с помощью маршрутизатора ASUS SL1200, поэтому сейчас не будем вдаваться в детали. Также мы решили предоставить нашим читателям подготовленный файл. Преобразовываем подготовленный файл к виду, понимаемому Wireshark.

C:\Program Files\Wireshark>text2pcap.exe capture3.txt capture.pcap
Input from: capture3.txt
Output to: capture.pcap
Wrote packet of 128 bytes at 0
Wrote packet of 128 bytes at 128
Wrote packet of 128 bytes at 256
Wrote packet of 128 bytes at 384
Wrote packet of 128 bytes at 512
Read 5 potential packets, wrote 5 packets

Теперь получившийся файл может быть открыт сетевым анализатором.

Также стоит указать, что использовать подобный перехват следует с осторожностью, так как нам несколько раз удалось перезагрузить коммутатор, просто запустив бесконечный ping пакетами по 10000 байт.

Единственное, о чём нам бы ещё хотелось упомянуть, так это об ограничениях подобного перехвата. Сохраняемые Fast Ethernet коммутатором NETGEAR FSM726v3 пакеты имеют размер 128 байт.