Как анализировать трафик виртуальной инфраструктуры, использующей VMware NSX
Виртуализация прочно вошла в нашу жизнь, и мы все чаще в проектах встречаем необходимость захвата трафика или снятие копии трафика для мониторинга производительности приложений, которые развернуты внутри виртуальной инфраструктуры. Компания VMWARE представила и активно развивает новую платформу NSX для виртуализации сети, которая набирает популярность. Поэтому в рамках данного практикума мы решили рассказать, как встроенное средство ESXi - pktcap-uw можно использовать для диагностики NSX и захвата трафика.
Для того чтобы оценить возможности был собран вот такой стенд. Для каждого эксперимента генерировался трафик ICMP и/или SSH между виртуальными машинами:
На скриншоте ниже указаны правила, настроенные на NSX Distributed Firewall (DFW).
Ну а теперь приступим к захвату трафика в разных местах виртуального пространства.
1. Захват трафика из и в виртуальную машину
Для того чтобы контролировать трафик на уровне входа и выхода из виртуальной машины мы можем воспользоваться идентификатором порта виртуального коммутатора –switchport . В данной точке мы видим трафик еще не затронутый правилами NSX файервола и не инкапсулированный в какой-либо VXLAN. В данном примере мы будем собирать трафик при общении между двумя виртуальными машинами Web 1 и Web 2 на уровне виртуального сетевого адаптера Web1. Точка захвата указана на диаграмме.
Для того чтобы получить идентификатор порта (port-ID) существуют два способа. Первый способ запустить команду esxtop на ESXi Compute1 и получить список, в котором присутствует и наш сервер Web 1:
Способ 2 запустить команду net-stats -l и также увидеть port-ID:
[root@compute1:~] net-stats -l
PortNum Type SubType SwitchName MACAddress ClientName
33554434 4 0 vSwitch0 00:0c:29:db:8c:f0 vmnic0
33554436 3 0 vSwitch0 00:0c:29:db:8c:f0 vmk0
33554437 3 0 vSwitch0 00:50:56:63:1b:bb vmk1
33554438 3 0 vSwitch0 00:50:56:65:b8:b8 vmk3
50331650 4 0 vSwitch1 00:0c:29:db:8c:04 vmnic2
67108866 4 0 vSwitch2 00:0c:29:db:8c:0e vmnic3
83886082 4 0 DvsPortset-0 00:0c:29:db:8c:fa vmnic1
83886084 3 0 DvsPortset-0 00:50:56:6c:a8:61 vmk2
83886086 5 9 DvsPortset-0 00:50:56:9c:36:ac WEB1.eth0
[root@compute1:~]
Для того чтобы видеть трафик в двух направлениях нам необходимо запустить 2 сессии захвата трафика — для направления из машины Web1 – это направление –dir 0, а направление в машину Web 1 - dir 1. Формат и опции команды pktcap-uw можно уточнить в базе знаний Vmware.
Между машинами генерировался трафик и все пакеты сохранялись в файлы VM-WEB1.OUT.pcap и VM-WEB1-IN.pcap
[root@compute1:~] [root@compute1:~] pktcap-uw --switchport 83886086 --dir 0 --dstip 10.1.100.12 -o VM-WEB1.OUT.pcap
The switch port id is 0x05000006
The dir is Rx
The session filter destination IP address is 10.1.100.12
The output file is VM-WEB1.OUT.pcap
No server port specifed, select 46305 as the port
Local CID 2
Listen on port 46305
Accept...Vsock connection from port 1067 cid 2
Dump: 6, broken : 0, drop: 0, file err: 0Join with dump thread failedDestroying session 43
Dumped 6 packet to file VM-WEB1.OUT.pcap, dropped 0 packets.
Done.
[root@compute1:~]
[root@compute1:~] pktcap-uw --switchport 83886086 --dir 1 --srcip 10.1.100.12 -o VM-WEB1-IN.pcap
The switch port id is 0x05000006
The dir is Tx
The session filter source IP address is 10.1.100.12
The output file is VM-WEB1-IN.pcap
No server port specifed, select 46308 as the port
Local CID 2
Listen on port 46308
Accept...Vsock connection from port 1068 cid 2
Dump: 1, broken : 0, drop: 0, file err: 0Join with dump thread failedDestroying session 44
Dumped 1 packet to file VM-WEB1-IN.pcap, dropped 0 packets.
Done.
[root@compute1:~]
Далее можно воспользоваться TCP Dump или Wireshark для анализа трафика:
[root@compute1:~] tcpdump-uw -r VM-WEB1-OUT.pcap
reading from file VM-WEB1-OUT.pcap, link-type EN10MB (Ethernet)
09:08:18.111526 IP 10.1.100.11 > 10.1.100.12: ICMP echo request, id 7877, seq 1, length 64
09:08:20.913056 IP 10.1.100.11.43534 > 10.1.100.12.ssh: Flags [S], seq 2293133161, win 29200, options [mss 1460,sackOK,TS val 278378 ecr 0,nop,wscale 5], length 0
09:08:21.912298 IP 10.1.100.11.43534 > 10.1.100.12.ssh: Flags [S], seq 2293133161, win 29200, options [mss 1460,sackOK,TS val 278628 ecr 0,nop,wscale 5], length 0
09:08:23.112307 ARP, Request who-has 10.1.100.12 tell 10.1.100.11, length 46
09:08:23.916291 IP 10.1.100.11.43534 > 10.1.100.12.ssh: Flags [S], seq 2293133161, win 29200, options [mss 1460,sackOK,TS val 279129 ecr 0,nop,wscale 5], length 0
09:08:27.928284 IP 10.1.100.11.43534 > 10.1.100.12.ssh: Flags [S], seq 2293133161, win 29200, options [mss 1460,sackOK,TS val 280132 ecr 0,nop,wscale 5], length 0
[root@compute1:~]
[root@compute1:~] tcpdump-uw -r VM-WEB1-IN.pcap
reading from file VM-WEB1-IN.pcap, link-type EN10MB (Ethernet)
06:48:29.883208 IP 10.1.100.12 > 10.1.100.11: ICMP echo reply, id 9484, seq 1, length 64
[root@compute1:~]
Как видно из примера ICMP трафик прошел от машины Web 1 к машине Web 2 и получен ответ. А вот трафик SSH не прошел и тут сработали правила на файерволе NSX DFW (помним выше, что мы разрешили проход только ICMP трафика).
2. Захват трафика после NSX Distributed Firewall (DFW)
В процессе диагностики может потребоваться проверить работу NSX DFW и поэтому рассмотрим следующую точку после фильтров файервола. Для этого существуют две опции для pktcap-uw:
–capture <точка захвата>
Варианты и применение двух точек захвата:
Точка захвата |
Используется для |
PreDVFilter |
захвата пакетов перед тем как фильтр будет применен. |
PostDVFilter |
захвата пакетов после фильтрации. |
Для того чтобы трафик захватить в точке 2 (см. диаграмму) нам нужна опция –capture PostDVFilter:
–dvfilter <filter name>
DVFilter который мы хотим применить для конкретной виртуальной сетевой карты vNIC
В данном эксперименте мы будем захватывать трафик от машины Web 1 в точке PostDVFilter. Но сначала мы должны узнать имя фильтра для карты Web 1. Это может быть сделано, используя команду summarize-dvfilter:
[root@compute1:~] summarize-dvfilter
Fastpaths:
agent: dvfilter-faulter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter
agent: ESXi-Firewall, refCount: 5, rev: 0x1010000, apiRev: 0x1010000, module: esxfw
agent: dvfilter-generic-vmware, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter-generic-fastpath
agent: dvfilter-generic-vmware-swsec, refCount: 2, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter-switch-security
agent: bridgelearningfilter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: vdrb
agent: dvfg-igmp, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfg-igmp
agent: vmware-sfw, refCount: 2, rev: 0x1010000, apiRev: 0x1010000, module: vsip
Slowpaths:
Filters:
world 0
port 33554436 vmk0
vNic slot 0
name: nic-0-eth4294967295-ESXi-Firewall.0
agentName: ESXi-Firewall
state: IOChain Attached
vmState: Detached
failurePolicy: failOpen
slowPathID: none
filter source: Invalid
port 33554437 vmk1
vNic slot 0
name: nic-0-eth4294967295-ESXi-Firewall.0
agentName: ESXi-Firewall
state: IOChain Attached
vmState: Detached
failurePolicy: failOpen
slowPathID: none
filter source: Invalid
port 83886084 vmk2
vNic slot 0
name: nic-0-eth4294967295-ESXi-Firewall.0
agentName: ESXi-Firewall
state: IOChain Attached
vmState: Detached
failurePolicy: failOpen
slowPathID: none
filter source: Invalid
port 33554438 vmk3
vNic slot 0
name: nic-0-eth4294967295-ESXi-Firewall.0
agentName: ESXi-Firewall
state: IOChain Attached
vmState: Detached
failurePolicy: failOpen
slowPathID: none
filter source: Invalid
world 36278 vmm0:WEB1 vcUuid:'50 1c 3a f6 63 50 fc 29-88 09 5a a6 9e 7a c3 00'
port 83886086 WEB1.eth0
vNic slot 2
name: nic-36278-eth0-vmware-sfw.2
agentName: vmware-sfw
state: IOChain Attached
vmState: Detached
failurePolicy: failClosed
slowPathID: none
filter source: Dynamic Filter Creation
vNic slot 1
name: nic-36278-eth0-dvfilter-generic-vmware-swsec.1
agentName: dvfilter-generic-vmware-swsec
state: IOChain Attached
vmState: Detached
failurePolicy: failClosed
slowPathID: none
filter source: Alternate Opaque Channel
[root@compute1:~]
Далее мы можем опять запустить захват трафика (ICMP и SSH).
[root@compute1:~] pktcap-uw --capture POSTDVFILTER --dvfilter nic-36278-eth0-vmware-sfw.2 --ip 10.1.100.12 -o WEB1-POSTDVFILTER.pcap
The session capture point is POSTDVFILTER
The name of the dvfilter is nic-36278-eth0-vmware-sfw.2
The session filter IP(src or dst) address is 10.1.100.12
The output file is WEB1-POSTDVFILTER.pcap
No server port specified, select 50163 as the port
Local CID 2
Listen on port 50163
Accept...Vsock connection from port 1071 cid 2
Dump: 2, broken : 0, drop: 0, file err: 0Join with dump thread failedDestroying session 47
Dumped 2 packet to file WEB1-POSTDVFILTER.pcap, dropped 0 packets.
Done.
[root@compute1:~]
Посмотрим наш файл WEB1-POSTDVFILTER.pcap:
[root@compute1:~] tcpdump-uw -r WEB1-POSTDVFILTER.pcap
reading from file WEB1-POSTDVFILTER.pcap, link-type EN10MB (Ethernet)
07:01:06.487368 IP 10.1.100.11 > 10.1.100.12: ICMP echo request, id 9486, seq 1, length 64
07:01:06.487849 IP 10.1.100.12 > 10.1.100.11: ICMP echo reply, id 9486, seq 1, length 64
[root@compute1:~]
Как мы видим, трафик ICMP прошел без проблем, а SSH трафика не видно, так как его не пропустил файервол.
3. Захват инкапсулированного трафика VXLAN
В данном примере мы будем захватывать трафик после его инкапсуляции. Например, для решения проблем связи виртуального коммутатора с физическим сетевым адаптером на физическом сервере. Для решения этой задачи используются следующие опции для pktcap-uw:
–capture <точка захвата>
Точка захвата как всегда зависит от направления трафика:
Точка захвата |
Используется для |
UplinkSnd |
захвата пакетов в направлении от виртуального коммутатора в сторону физического сетевого адаптера |
UplinkRcv |
захвата пакетов от физического сетевого адаптера |
–uplink <vmnicX>
Имя физического сетевого адаптера (vmnic)
–vxlan <VNI>
Номер VXLAN
В данном примере мы захватываем VXLAN трафик для VNI 5001 – точка «3» на диаграмме.
Во время захвата выполнили команду ping от Web1 в сторону Web2.
[root@compute1:~] pktcap-uw --uplink vmnic1 --capture UplinkSnd --vxlan 5001 -o VXLAN-Sn
d.pcap
The name of the uplink is vmnic1
The session capture point is UplinkSnd
The vxlan is 5001
The output file is VXLAN-Snd.pcap
No server port specifed, select 52459 as the port
Local CID 2
Listen on port 52459
Accept...Vsock connection from port 1043 cid 2
Dump: 2, broken : 0, drop: 0, file err: 0Join with dump thread failedDestroying session 19
Dumped 2 packet to file VXLAN-Snd.pcap, dropped 0 packets.
Done.
[root@compute1:~]
Итог представлен ниже:
[root@compute1:~] tcpdump-uw -enr VXLAN-Snd.pcap
reading from file VXLAN-Snd.pcap, link-type EN10MB (Ethernet)
13:06:46.313928 00:50:56:6c:a8:61 > 00:50:56:62:54:8f, ethertype IPv4 (0x0800), length 148: 172.16.1.10.58914 > 172.16.1.11.8472: VXLAN, VNI 5001, Flags [I]
00:50:56:9c:36:ac > 00:50:56:9c:b0:9a, ethertype IPv4 (0x0800), length 98: 10.1.100.11 > 10.1.100.12: ICMP echo request, id 7998, seq 1, length 64
13:06:51.321047 00:50:56:6c:a8:61 > 00:50:56:62:54:8f, ethertype IPv4 (0x0800), length 110: 172.16.1.10.49290 > 172.16.1.11.8472: VXLAN, VNI 5001, Flags [I]
00:50:56:9c:36:ac > 00:50:56:9c:b0:9a, ethertype ARP (0x0806), length 60: Reply 10.1.100.11 is-at 00:50:56:9c:36:ac, length 46
[root@compute1:~]
Как видим выше ICMP echo request был инкапсулирован и отправлен с интерфейса VTEP VMkernel Compute1 (172.16.1.10) в сторону интерфейса VTEP VMkernel Compute2 (172.16.1.11).
Для смены направления захвата трафика необходимо заменить точку захвата с UplinkSnd на UplinkRcv.
4. Захват трафика после маршрутизатора NSX Distributed Logical Router (DLR)
Если необходимо проверить корректность работы встроенного распределенного логического маршрутизатора, то для решения этой задачи необходимо выяснить идентификатор порта port-ID маршрутизатора vdrport. Для этого мы можем воспользоваться утилитой ESXTOP или через командную строку NSX:
nsx-manager1.ipcraft.lab> show cluster all
No. Cluster Name Cluster Id Datacenter Name Firewall Status
1 temp domain-c715 DC1 Not Enabled
2 Management & Edge domain-c189 DC1 Enabled
3 Cluster-A domain-c7 DC1 Enabled
4 Cluster-B domain-c9 DC1 Enabled
nsx-manager1.ipcraft.lab> show cluster domain-c7
Datacenter: DC1
Cluster: Cluster-A
No. Host Name Host Id Installation Status
1 compute1.ipcraft.lab host-22 Ready
nsx-manager1.ipcraft.lab> show logical-switch host host-22 vni 5001 verbose
VXLAN Global States:
Control plane Out-Of-Sync: No
UDP port: 8472
VXLAN network: 5001
Multicast IP: N/A (headend replication)
Control plane: Enabled (multicast proxy,ARP proxy)
Controller: 192.168.0.211 (up)
MAC entry count: 0
ARP entry count: 0
Port count: 2
VXLAN port: vdrPort
Switch port ID: 83886085
vmknic ID: 0
VXLAN port: 68
Switch port ID: 83886086
vmknic ID: 0
nsx-manager1.ipcraft.lab>
Для определения направления трафика мы используем опции –dir 0 для захвата трафика от DLR (egress) в сторону виртуального коммутатора. Кроме этого мы можем указать интерфейс с исходящим трафиком, используя –vxlan <VNI>.
На примере ниже мы используем интерфейс VXLAN 5009 и опять генерируем.
[root@compute1:~] pktcap-uw --switchport 83886085 --dir 0 --vxlan 5009 --dstip 10.1.2.11 -o DLR-Egress.pcap
The switch port id is 0x05000005
The dir is Rx
The vxlan is 5009
The session filter destination IP address is 10.1.2.11
The output file is DLR-Egress.pcap
No server port specifed, select 28758 as the port
Local CID 2
Listen on port 28758
Accept...Vsock connection from port 1072 cid 2
Dump: 1, broken : 0, drop: 0, file err: 0Join with dump thread failedDestroying session 48
Dumped 1 packet to file DLR-Egress.pcap, dropped 0 packets.
Done.
[root@compute1:~]
Так выглядит захваченный трафик:
[root@compute1:~] tcpdump-uw -enr DLR-Egress.pcap
reading from file DLR-Egress.pcap, link-type EN10MB (Ethernet)
02:53:41.655412 02:50:56:56:44:52 > 00:50:56:9c:fa:4d, ethertype IPv4 (0x0800), length 98: 10.1.100.11 > 10.1.2.11: ICMP echo request, id 10187, seq 1, length 64
[root@compute1:~]
5. Захват управляющего трафика в NSX
Мы можем использовать pktcap-uw для анализа управляющего трафика между хостом ESXi и контроллером NSX и NSX менеджером. Трафик при общении зашифрован, но мы сможем проверить корректность заголовков на уровне 2, 3 или 4 модели OSI.
На ESXi управляющий трафик отправляется и получается через интерфейс VMkernel, поэтому для начала необходимо определится с точкой захвата.
Первый параметр, который необходимо указать для pktcap-uw это название интерфейса VMkernel –vmk. Интерфейс управления на нашем ESXi называется vmk0. Далее нам необходимо указать направление для захвата трафика – точку захвата:
Точка захвата |
Используется для |
PortOutput |
захвата пакетов от виртуального коммутатора в интерфейс VMkernel |
PortInput |
захвата пакетов из интерфейса в сторону виртуального коммутатора |
На примере ниже мы захватываем трафик между хостом ESXi и контроллером NSX. Управляющий трафик – это netcpa, который использует порт 1234 в точке «5»:
Мы активируем две сессии для каждого из направлений (хост ESXi – контроллер NSX) в файл netcpad-to-Controller.pcap:
[root@compute1:~] pktcap-uw --vmk vmk0 --dstport 1234 --capture PortInput -o netcpad-to-
Controller.pcap
The name of the vmk is vmk0
The session filter destination TCP port is 1234
The session capture point is PortInput
The output file is netcpad-to-Controller.pcap
No server port specifed, select 18075 as the port
Local CID 2
Listen on port 18075
Accept...Vsock connection from port 1059 cid 2
Dump: 8, broken : 0, drop: 0, file err: 0Join with dump thread failedDestroying session 35
Dumped 8 packet to file netcpad-to-Controller.pcap, dropped 0 packets.
Done.
[root@compute1:~]
Сессия для захвата netcpa в направлении от контроллера NSX в сторону хоста ESXi:
[root@compute1:~] pktcap-uw --vmk vmk0 --srcport 1234 --capture PortOutput -o ne
tcpad-fr-Controller.pcap -s 0
The name of the vmk is vmk0
The session filter source TCP port is 1234
The session capture point is PortOutput
The output file is netcpad-fr-Controller.pcap
The snap len is 0
No server port specifed, select 18078 as the port
Local CID 2
Listen on port 18078
Accept...Vsock connection from port 1060 cid 2
Dump: 8, broken : 0, drop: 0, file err: 0Join with dump thread failedDestroying session 36
Dumped 8 packet to file netcpad-fr-Controller.pcap, dropped 0 packets.
Done.
[root@compute1:~]
Пакеты в файлах выглядят следующим образом:
[root@compute1:~] tcpdump-uw -enr netcpad-to-Controller.pcap
reading from file netcpad-to-Controller.pcap, link-type EN10MB (Ethernet)
14:46:40.989398 00:0c:29:db:8c:f0 > 00:50:56:9c:6e:c7, ethertype IPv4 (0x0800), length 135: 192.168.0.205.15669 > 192.168.0.211.1234: Flags [P.], ack 2204720771, win 130, options [nop,nop,TS val 2182465 ecr 134584671], length 69
14:46:41.495263 00:0c:29:db:8c:f0 > 00:50:56:9c:6e:c7, ethertype IPv4 (0x0800), length 66: 192.168.0.205.15669 > 192.168.0.211.1234: Flags [.], ack 70, win 130, options [nop,nop,TS val 2182516 ecr 134587171], length 0
14:46:50.998976 00:0c:29:db:8c:f0 > 00:50:56:9c:6e:c7, ethertype IPv4 (0x0800), length 135: 192.168.0.205.15669 > 192.168.0.211.1234: Flags [P.], ack 70, win 130, options [nop,nop,TS val 2183466 ecr 134587171], length 69
14:46:51.485171 00:0c:29:db:8c:f0 > 00:50:56:9c:6e:c7, ethertype IPv4 (0x0800), length 66: 192.168.0.205.15669 > 192.168.0.211.1234: Flags [.], ack 139, win 130, options [nop,nop,TS val 2183515 ecr 134589671], length 0
14:47:01.007521 00:0c:29:db:8c:f0 > 00:50:56:9c:6e:c7, ethertype IPv4 (0x0800), length 135: 192.168.0.205.15669 > 192.168.0.211.1234: Flags [P.], ack 139, win 130, options [nop,nop,TS val 2184467 ecr 134589671], length 69
14:47:01.485063 00:0c:29:db:8c:f0 > 00:50:56:9c:6e:c7, ethertype IPv4 (0x0800), length 66: 192.168.0.205.15669 > 192.168.0.211.1234: Flags [.], ack 208, win 130, options [nop,nop,TS val 2184515 ecr 134592172], length 0
14:47:11.017465 00:0c:29:db:8c:f0 > 00:50:56:9c:6e:c7, ethertype IPv4 (0x0800), length 135: 192.168.0.205.15669 > 192.168.0.211.1234: Flags [P.], ack 208, win 130, options [nop,nop,TS val 2185468 ecr 134592172], length 69
14:47:11.484969 00:0c:29:db:8c:f0 > 00:50:56:9c:6e:c7, ethertype IPv4 (0x0800), length 66: 192.168.0.205.15669 > 192.168.0.211.1234: Flags [.], ack 277, win 130, options [nop,nop,TS val 2185515 ecr 134594672], length 0
[root@compute1:~]
[root@compute1:~] tcpdump-uw -enr netcpad-fr-Controller.pcap
reading from file netcpad-fr-Controller.pcap, link-type EN10MB (Ethernet)
14:46:40.989819 00:50:56:9c:6e:c7 > 00:0c:29:db:8c:f0, ethertype IPv4 (0x0800), length 66: 192.168.0.211.1234 > 192.168.0.205.15669: Flags [.], ack 3041791823, win 83, options [nop,nop,TS val 134587073 ecr 2182465], length 0
14:46:41.382309 00:50:56:9c:6e:c7 > 00:0c:29:db:8c:f0, ethertype IPv4 (0x0800), length 135: 192.168.0.211.1234 > 192.168.0.205.15669: Flags [P.], ack 1, win 83, options [nop,nop,TS val 134587171 ecr 2182465], length 69
14:46:50.999589 00:50:56:9c:6e:c7 > 00:0c:29:db:8c:f0, ethertype IPv4 (0x0800), length 66: 192.168.0.211.1234 > 192.168.0.205.15669: Flags [.], ack 70, win 83, options [nop,nop,TS val 134589576 ecr 2183466], length 0
14:46:51.382398 00:50:56:9c:6e:c7 > 00:0c:29:db:8c:f0, ethertype IPv4 (0x0800), length 135: 192.168.0.211.1234 > 192.168.0.205.15669: Flags [P.], ack 70, win 83, options [nop,nop,TS val 134589671 ecr 2183466], length 69
14:47:01.007915 00:50:56:9c:6e:c7 > 00:0c:29:db:8c:f0, ethertype IPv4 (0x0800), length 66: 192.168.0.211.1234 > 192.168.0.205.15669: Flags [.], ack 139, win 83, options [nop,nop,TS val 134592078 ecr 2184467], length 0
14:47:01.382519 00:50:56:9c:6e:c7 > 00:0c:29:db:8c:f0, ethertype IPv4 (0x0800), length 135: 192.168.0.211.1234 > 192.168.0.205.15669: Flags [P.], ack 139, win 83, options [nop,nop,TS val 134592172 ecr 2184467], length 69
14:47:11.018032 00:50:56:9c:6e:c7 > 00:0c:29:db:8c:f0, ethertype IPv4 (0x0800), length 66: 192.168.0.211.1234 > 192.168.0.205.15669: Flags [.], ack 208, win 83, options [nop,nop,TS val 134594580 ecr 2185468], length 0
14:47:11.383095 00:50:56:9c:6e:c7 > 00:0c:29:db:8c:f0, ethertype IPv4 (0x0800), length 135: 192.168.0.211.1234 > 192.168.0.205.15669: Flags [P.], ack 208, win 83, options [nop,nop,TS val 134594672 ecr 2185468], length 69
[root@compute1:~]
В дальнейшем мы можем объединить два разных файла в один с помощью Wireshark для удобства анализа двунаправленного трафика, используя функцию Merge:
Выводы
В рамках данного практикума мы продемонстрировали 5 наиболее важных точек, в которых с целью диагностики виртуального мира может возникнуть необходимость захвата трафика с помощью встроенной команды NSX и бесплатных анализаторов протокола TCP Dump и Wireshark. Это позволит понять корректность работы разных элементов виртуальной платформы NSX.
Всегда на связи, Игорь Панов.
Делитесь нашими статьями в соцсетях и задавайте вопросы в комментариях!
См. также:
Авторизуйтесь для этого