Traffic not redirected to 3rd party vendor SVM
Article ID: 384522
Updated On: 02-12-2025
Products
Issue/Introduction
- You have configured E-W network introspection on NSX-T
- Deployment has been successful without issues.
- You are using an SVM from a 3rd party vendor.
- You observe in the dfwpktlogs.log on the ESXI host that the FWD and REV path MAC address are zeros.
<timestamp> 253d62d7 INET match PBR 3049 OUT 92 ICMP 192.168.1.2-> 192.168.1.3 FG 0 SFG 0 FID 67108992 SCID 0 V 3 FA 1 |FWD: 00:00:00:00:00:00 SI 0 SPI 0 TTL 0 |REV 00:00:00:00:00:00 SI 0 SPI 0 TTL 0
<timestamp> e27d6a15 INET match PBR 3049 IN 92 ICMP 172.16.130.100->172.16.128.100 FG 0 SFG 0 FID 50331776 SCID 0 V 3 FA 1 |FWD: 00:00:00:00:00:00 SI 0 SPI 0 TTL 0 |REV 00:00:00:00:00:00 SI 0 SPI 0 TTL 0
- While running the command vsipioctl getsinshtable on the ESXI where the SVM resides you observe that the "Service MAC" matches MAC address of the SVM deployed.
[root@esx-05:~] vsipioctl getsinshtable
nsh table has 2 entries
-----------------------------------------------------------------------------------
SPI_KEY, SI_KEY | SERVICE MAC | SERVICE TYPE | MODE |
-----------------------------------------------------------------------------------
6 ,1 | 00:50:56:9d:e7:b8 | COMPATIBILITY | REDIRECT |
5 ,1 | 00:50:56:9d:e7:b8 | COMPATIBILITY | REDIRECT |
-----------------------------------------------------------------------------------
- While running the command vsipioctl getsisvctable on the ESXI where the SVM resides you observe that the the "FWD SERVICE MAC" and the "REV SERVICE MAC" is not populated.
[root@esx-05:~] vsipioctl getsisvctable
Service table has 1 entries
service table count 1
--------------------------------------------------------------------------------------------------------------------------------------------------
PATH INDEX| UUID | FWD SPI,SI,SCID | FWD SERVICE MAC | REV SPI,SI,SCID | REV SERVICE MAC | FAILURE POLICY|
--------------------------------------------------------------------------------------------------------------------------------------------------
23342f9f-1443-47a0-b2dd-b570deffcf39 | ALLOW |
--------------------------------------------------------------------------------------------------------------------------------------------------
- While running the command vsipioctl getsisvmstats -p <SVM-switchport> on the ESXi where the SVM resides you observe that the "to_svm_liveness_pkts" counter is incrementing.
- You will observe that the "from_svm_liveness_pkts" is not incrementing.
- You will observed that the "SVM_alive" parameter is set to 0x0, indicating the SVM is not alive from a dataplane perspective.
- The "SVM_alive" parameter needs to be set to 0x1, indicating that the SVM is alive from a dataplane perspective.
[root@esx-05:~] vsipioctl getsisvmstats -p 67108887
calling the SI Ioctl for stats ...
Statistic name | Statistic value
------------------------------------------------------------
rx_from_svm | 9
rx_from_iochain | 2405
to_svm_liveness_pkts | 2405 <<<<<<
from_svm_liveness_pkts | 0 <<<<<<
native_length_patch_fail | 0
bad_eth_hdr | 0
quench | 0
get_nsh_fail | 0
ingress_inject_fail | 0
copy_fail | 0
nsh_ttl_expired | 0
zero_si | 0
unknown_next_hop | 0
set_nsh_fail | 0
push_headroom_fail | 0
insufficient_decap_bytes | 0
insufficient_spf_bytes | 0
insufficient_map_bytes | 0
partial_copy | 0
from_svm_drop_outhereth | 0
from_svm_drop_wrongflc | 0
liveness_checks_performed | 2405
svm_alive | 0x0 <<<<<<<<
liveness_bitmap | 0
sequence_number | 0
is_copy_world_on | 0
copy_world_count | 0
- While taking packet captures on the SVM's switchport you observe similar Gratuitous ARPs being sent. However, we do not see a response from the SVM.
- These are the liveness probes being sent by NetX to the SVM
2024-10-09 11:52:12.043 VMware_9d:e7:b8 VMware_9d:e7:b8 ARP 138 0x0000 (0) Gratuitous ARP for 0.0.0.0 (Request)
2024-10-09 11:52:13.043 VMware_9d:e7:b8 VMware_9d:e7:b8 ARP 138 0x0000 (0) Gratuitous ARP for 0.0.0.0 (Request)
2024-10-09 11:52:14.043 VMware_9d:e7:b8 VMware_9d:e7:b8 ARP 138 0x0000 (0) Gratuitous ARP for 0.0.0.0 (Request)
NOTE: The preceding log excerpts are only examples. Date, time and environmental variables may vary depending on your environment.
Environment
VMware NSX-T Data Center 3.X
VMware NSX 4.X
Cause
- The traffic is not redirected to the SVM as the NetX function believes that the SVM is not alive.
- For the SVM to be marked as alive from a dataplane perspective the SVM needs to respond to the liveness probes sent by NetX.
Resolution
If you observe the above syptoms it is suggested to check with the Vendor to why the SVM is not responding to liveness probes.
Feedback
