Hello Team. In fact, I would like your help to check if my understanding is correct about NSX Upgrade. 1) The NSX Upgrade order (from 3.x -> 4.x or 4.x -> 4.x) is Edge Nodes -> Hosts -> Manage...
See more...
Hello Team. In fact, I would like your help to check if my understanding is correct about NSX Upgrade. 1) The NSX Upgrade order (from 3.x -> 4.x or 4.x -> 4.x) is Edge Nodes -> Hosts -> Management? 2) To perform Edge nodes upgrade without network interruption we need to use Serial Option instead of Parallel Option? Thanks!
Hello. Thanks for your answer. When you use the vRNI to define the applications you are using what of these available options? Tags (VMware vCenter Server or AWS tags) VM Names ServiceNow Fl...
See more...
Hello. Thanks for your answer. When you use the vRNI to define the applications you are using what of these available options? Tags (VMware vCenter Server or AWS tags) VM Names ServiceNow Flows Advanced properties such as a combination of VM names, VM tags, NSX-V security tags, and security groups.
Hello Folks. If anyone has already made use of vRNI to create waves of migration (communication affinity, who talks to whom), If yes, what were the challenges and problems faced? I know that vRN...
See more...
Hello Folks. If anyone has already made use of vRNI to create waves of migration (communication affinity, who talks to whom), If yes, what were the challenges and problems faced? I know that vRNI received flows from vDS with source, port source, destination and port destination to create DFW rules but he can help with wave migrations to establish affinity group communication?
Hello Team. I would like to confirm with you all something that I found on this withepaper: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/docs/vmware-nsx-distributed-ids-ips-tec...
See more...
Hello Team. I would like to confirm with you all something that I found on this withepaper: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/docs/vmware-nsx-distributed-ids-ips-tech-white-paper.pdf It is possible uses NSX IDS/IPS with VLAN Segment? Or it's necessary/mandatory to use Overlay Segment to implement NSX IDS/IPS? If my understanding is right, the IDS/IPS is apply after the traffic being "approved" by DFW even if this is a VLAN Segment traffic.
Hello Team. I have this problem solved with VMware GSS recently. I raised a support request to NSX Team and the NSX Support Engineer told me that NSX was ok and he didn't find any problem. With N...
See more...
Hello Team. I have this problem solved with VMware GSS recently. I raised a support request to NSX Team and the NSX Support Engineer told me that NSX was ok and he didn't find any problem. With NSX Support Engineer we identified that the "Application crashed" error which was showing up on NSX Manager GUI was related to one core dump on /var/core/ of each transport node (ESXi host). Once this was a service core dump this wasn't a human-readable file so the VMware GSS ESXi read the service core dump and they saw that someone HPe module called smx was causing the core dump. We uninstalled this smx module (which we weren't using) and the problem stopped being present. PS: to stop application crash message you must to move or delete the core dump file on /var/core/ I could observe an interesting thing about this core dump: The core dump was generated only when the ESXi host was prepared for being NSX Transport Node or when we choose to remove NSX from the host. After removing the smx module the core dump stops to be showing up during ESXi preparation host and during the process to remove too Maybe the problem with you environment could be another module so I suggest you to check /var/core/ partition on ESXi host and see if this is generating during ESXi prepare process to be a NSX Transport node or during the NSX removing process.
I also have the same error with the same NSX version. in my case, I did observe that the ESXi hosts /var/core/ had and sfcb service core dump. All transport node had the same core dump with the same...
See more...
I also have the same error with the same NSX version. in my case, I did observe that the ESXi hosts /var/core/ had and sfcb service core dump. All transport node had the same core dump with the same date/hour. As it is a production environment, I opened a VMware support case to read the core dump service
Hello. I'm using L4 stateful distributed firewall and I would like to know if it's possible to see the current "connection table" that it's used by a stateful firewall to check the flow is related t...
See more...
Hello. I'm using L4 stateful distributed firewall and I would like to know if it's possible to see the current "connection table" that it's used by a stateful firewall to check the flow is related to some active connection.
Hello, ShahabKhan. Thank you so much for the reply. Do you know if there is any VMware documentation about it? I can only find documentation saying that Jumbo Frame "is required for overlay". Tha...
See more...
Hello, ShahabKhan. Thank you so much for the reply. Do you know if there is any VMware documentation about it? I can only find documentation saying that Jumbo Frame "is required for overlay". Thank you.
Hello. I was reading about the requirements to use overlay encapsulation (GENEVE) and it's clear to use the minimum MTU 1700. But if we are working just with VLAN Backed, is it still necessary to us...
See more...
Hello. I was reading about the requirements to use overlay encapsulation (GENEVE) and it's clear to use the minimum MTU 1700. But if we are working just with VLAN Backed, is it still necessary to use a minimum of 1700 MTU once there isn't overlay segments? Should we set MTU 1700 because of TEP between transport nodes or with VLAN Backed isn't necessary? Is there any documentation from VMware saying that it's not necessary change MTU valeu with only VLAN Backend segments? Thanks.
Hello Rick. I would like to thank you again for your time and help here. I was able to log VLAN Backed traffic on vRealize Log Insight now using NSX-T 4.0.0.1.0.20159689 and vRealize Log Insight ...
See more...
Hello Rick. I would like to thank you again for your time and help here. I was able to log VLAN Backed traffic on vRealize Log Insight now using NSX-T 4.0.0.1.0.20159689 and vRealize Log Insight 8.8.2-20056468 plus I hadn't configured vRealize Log Insight as ESXi hosts syslog and now I configured it. It's perfectly working. Thank you again.
Thanks for your answer. I did enable the logging toggle on the DFW Rule and I did set the log label. In the vRealize Log Insight, I filter the search to the log label but vRealize Log Insight doesn...
See more...
Thanks for your answer. I did enable the logging toggle on the DFW Rule and I did set the log label. In the vRealize Log Insight, I filter the search to the log label but vRealize Log Insight doesn't register any VLAN Backend activity when some traffic hit the DFW Rule only Overlay activity are registered. Regards.
Hello guys. I'm facing a problem to use vRealize Log Insight to log VLAN Backend traffic. I did create a VLAN Backend segment and all my VMs are attached to this port-group segment and working we...
See more...
Hello guys. I'm facing a problem to use vRealize Log Insight to log VLAN Backend traffic. I did create a VLAN Backend segment and all my VMs are attached to this port-group segment and working well. I created two Distributed Firewall rule One called Catchall-Inbound and the other Cathall-Outbound with the source and destination this VLAN Backend subnet. These two rules have any destination and any sources for any services. I did enable the "Logging" option on each DFW Rule and I did set a Log Label to find more easily the rules on vRealize Log Insight. I am sure that these two rules are working because when I disable both rules the traffic immediately stops. But on vRealize Log Insight when I go to event tabs I can't see any traffic on this two rule. But when I set to DFW accept traffic from Overlay Networing the vRealize Log Insight show immediately all the traffic. My doubt is: Can the NSX-T DFW rules and vRealize Log Insight only log and log traffic coming from overlay networks? Or we can do the same for VLAN Backend Segment once that we can normally apply DFW rules to the VLAN Backend Segment.
