andrewassis Tracker

Re: Unable to see open Velo tickets on my account

andrewassis — Sun, 10 Sep 2023 20:29:01 GMT

I understand that you're having trouble viewing all the support tickets, including open tickets, in your VMware support request history. To access your open tickets and resolve this issue, you should follow these steps:

1. **Log into My VMware:**
- Go to the My VMware portal: https://my.vmware.com/
- Sign in using your VMware account credentials. This account should have the appropriate permissions and entitlements to view your support tickets.

2. **Access Support Requests:**
- Once you're logged in, locate and click on the "Support Requests" or "My Support Requests" section. This should take you to a list of your support requests, both open and closed.

3. **Filter and Sort:**
- By default, the support request list may show only the most recent requests, including closed tickets. Look for options to filter or sort the list to view open tickets specifically.

4. **Check Support Request Status:**
- Review the status of each support request in the list. Open tickets should have a status that indicates they are still in progress or open.

5. **Contact VMware Support (if needed):**
- If you are still unable to locate your open tickets or have any concerns, it's advisable to contact VMware Support directly. They can assist you in finding and managing your support requests.

6. **Verify Entitlement:**
- Ensure that your VMware account is associated with the correct entitlement account (in your case, 579712866 AT&T). If there are any discrepancies or issues with your entitlement, this could affect your ability to view support tickets.

7. **Check Account Permissions:**
- Verify that your VMware account has the appropriate permissions to access and view support tickets associated with your entitlement account.

If you're unable to find your open support tickets despite following these steps, reaching out to VMware Support directly is your best course of action. They can assist you in resolving any account-related issues and help you access the information you need regarding your open support requests.

Re: Guest VM unpredictably lost connection when using NSX-V edge gateway

andrewassis — Sun, 10 Sep 2023 20:28:13 GMT

The symptoms you're experiencing with random NSX-V Edge Gateway hang issues on vCenter-A but not on vCenter-B can be challenging to diagnose, but I can provide some steps and considerations to help you troubleshoot and potentially resolve the problem:

1. **Verify Compatibility:**
- Ensure that all components, including ESXi hosts, NSX-V, vCenter, and physical infrastructure, are on the VMware Compatibility Guide for your specific versions. Incompatible hardware or software versions can lead to unexpected issues.

2. **Collect Logs and Diagnostics:**
- When the issue occurs, collect logs and diagnostics from the affected Edge Gateway VM and the corresponding ESXi host. Analyzing these logs can provide insights into what's happening at the time of the hang.

3. **Review Edge Gateway Configuration:**
- Verify the configuration of the affected Edge Gateway VMs. Pay attention to firewall rules, routing, NAT, and any custom configurations. Ensure that they align with your network design and requirements.

4. **Monitor Resource Utilization:**
- Monitor the resource utilization (CPU, memory, and network) on the affected ESXi host and Edge Gateway VMs. High resource utilization can lead to performance issues and hangs.

5. **Check for Network Issues:**
- Examine the physical network infrastructure for any potential problems such as packet loss, congestion, or switch issues. Ensure that the network configuration on vCenter-A matches vCenter-B.

6. **Review VMware KB Articles:**
- Search VMware's Knowledge Base for any known issues or solutions related to NSX-V Edge Gateway hangs for your specific version. VMware often publishes articles with troubleshooting steps and fixes for common issues.

7. **Check for ESXi Host Isolation:**
- Ensure that the ESXi hosts where Edge Gateway VMs are running are not experiencing isolation events or network issues. Host isolation can lead to communication problems.

8. **Check for VMware Tools and ESXi Updates:**
- Ensure that VMware Tools inside the VMs and ESXi hosts are up-to-date. Outdated or incompatible versions can lead to communication issues.

9. **Consider NSX-V Version Compatibility:**
- While you mentioned upgrading NSX on vCenter-A, ensure that NSX-V version 6.4.14 is fully compatible with your vCenter and ESXi versions.

10. **Engage VMware Support:**
- If the issue persists and you can't identify the root cause, consider opening a support case with VMware. They have the expertise and tools to diagnose and resolve complex issues.

11. **Performance Monitoring:**
- Implement performance monitoring and alerting for your NSX-V environment. Tools like vRealize Operations Manager can help you proactively detect performance issues.

12. **HA and Fault Tolerance:**
- Consider enabling High Availability (HA) and Fault Tolerance (FT) for critical VMs, including Edge Gateway VMs, to provide redundancy and minimize downtime in case of issues.

13. **Regular Maintenance:**
- Schedule regular maintenance windows to perform updates and patches on your VMware infrastructure components. This can help ensure that you have the latest bug fixes and security updates.

Given the complexity of your environment and the intermittent nature of the issue, it's essential to thoroughly investigate each potential cause and monitor the situation closely. VMware support may be your best resource for diagnosing and resolving this issue, especially if it's specific to vCenter-A and not reproducible on vCenter-B.

Re: ClusterComputeResource' is not supported in NSX-T. "

andrewassis — Sun, 10 Sep 2023 20:27:31 GMT

The error message "ClusterComputeResource' is not supported in NSX-T" typically indicates that there are Distributed Firewall (DFW) rules in your VMware environment that reference a compute cluster. NSX-T does not support using compute clusters in DFW rules as you would in a traditional vSphere environment. To mitigate this issue and make your DFW rules compatible with NSX-T, you should update these rules. Here's how you can proceed:

1. **Identify DFW Rules with Cluster References:**
- First, identify the specific DFW rules that reference the "ClusterComputeResource." These rules may have been created in your vSphere environment.

2. **Understand the Intent of Cluster Rules:**
- Understand the purpose of these rules. In traditional vSphere environments, it's common to use clusters for grouping VMs, but in NSX-T, segmentation and security are typically achieved differently.

3. **Update DFW Rules:**
- For each rule that references a cluster, you'll need to update it to work with NSX-T. The exact changes will depend on the intent of the rule. Here are some considerations:

a. **Replace Cluster References:** If the cluster was used to group VMs for security purposes, you'll need to replace the cluster reference with references to the specific VMs or security groups in NSX-T. This means redefining the source and destination objects of the rule.

b. **Redesign Rules:** If the rules were using cluster-based logic that's not directly translatable to NSX-T, you may need to redesign the rules to fit the NSX-T security model. This could involve creating new security groups, tags, or policies as needed.

c. **Review Policies:** Reevaluate the policies that these cluster-based rules were a part of. NSX-T has a different way of managing security policies, so you may need to create new policies to replace the old ones.

4. **Test and Validate:** Before making any changes in a production environment, thoroughly test the updated DFW rules in a test or staging environment. Ensure that the new rules achieve the desired security outcomes without any unintended consequences.

5. **Apply Changes:** Once you're confident that the updated rules are working correctly, apply them in your NSX-T environment.

6. **Documentation:** Document the changes you've made to the DFW rules for future reference and auditing.

7. **Review Other Configuration:** Review your overall NSX-T configuration to ensure it aligns with your security and segmentation requirements. Make sure that you have appropriate security groups, tags, and policies in place to manage security effectively.

8. **Seek Assistance if Needed:** If you encounter complexities or challenges during this process, consider seeking assistance from VMware support or consulting with a VMware NSX-T expert who can provide guidance specific to your environment.

Updating DFW rules from a vSphere-based model to an NSX-T model may require some significant changes, but it's essential to ensure that your security posture remains effective in the new environment while avoiding any compatibility issues.

Re: "Manually create shadow firewall rules for ip-based IDFW traffic"

andrewassis — Sun, 10 Sep 2023 20:26:31 GMT

The message you're encountering during V2T (VMware vCenter to Tanzu) migration regarding IP-based IDFW (Identity Firewall) rules suggests that there are security rules in place that might disrupt network traffic during migration. To resolve this and ensure a smooth migration, you can follow these steps:

1. **Understand IP-Based IDFW Rules:**
- VMware's Identity Firewall (IDFW) relies on user identity and context for security rules. During migration, especially if you're transitioning from a traditional vCenter-based network to Tanzu, these rules can potentially block traffic since user context might change.

2. **Create Shadow Firewall Rules:**
- To avoid traffic interruption during migration, you should create shadow firewall rules that mimic your existing IP-based IDFW rules but don't depend on user identity or context. These shadow rules should permit the same traffic as your IDFW rules but without the user-specific conditions.

3. **Testing Shadow Rules:**
- Before applying the shadow rules, thoroughly test them in a controlled environment to ensure they work as expected and allow the necessary traffic. This step is crucial to avoid accidental disruption of network services.

4. **Apply Shadow Rules:**
- Once you are confident that the shadow rules are correctly configured, apply them to the relevant firewall or security groups within Tanzu. These rules should essentially replicate the functionality of your IP-based IDFW rules.

5. **Monitor Traffic:**
- During and after migration, monitor network traffic closely to ensure that it is not being blocked or interrupted by the shadow rules. If any issues arise, you can adjust the shadow rules as needed.

6. **Remove Shadow Rules After Migration:**
- After the migration is completed successfully, you can remove the shadow rules since they were only intended as temporary replacements for IP-based IDFW rules.

7. **Documentation:**
- Document your changes thoroughly, including the creation and removal of shadow rules. This documentation will be valuable for reference and auditing purposes.

It's important to note that the exact steps and configurations will depend on your specific network setup and requirements. You should also consult VMware documentation and consider seeking assistance from VMware support if you encounter any challenges during the migration process, especially regarding security rules and policies. Proper planning and testing are key to ensuring a seamless migration without disruptions to network traffic.

Re: Error 522003 when attempting to add QoS Binding Map to segment via API

andrewassis — Sun, 10 Sep 2023 20:26:00 GMT

The error message you're encountering, "invalid qos profile in segment monitoring profile map" in NSX-T version 3.2.3, indicates that there may be an issue with the QoS profile configuration when trying to create a binding map for a segment. To troubleshoot and resolve this issue, here are some steps you can follow:

1. **Verify QoS Profile Configuration:**
- Double-check the QoS profile you are trying to associate with the segment. Ensure that the QoS profile is correctly configured with the desired settings and is in an active state.

2. **Check JSON Format:**
- Ensure that the JSON payload you are sending in your API request is correctly formatted. Make sure there are no syntax errors, missing or extra fields, and that the QoS profile path is specified correctly.

3. **API Version Compatibility:**
- Confirm that you are using the correct API version and endpoints for your NSX-T version (3.2.3 in your case). Ensure that there are no breaking changes or updates in the API between your version and earlier versions.

4. **Testing with a Known Good QoS Profile:**
- To isolate the issue, try creating a binding map with a known good QoS profile to see if it works. If it does, it may suggest that there is an issue with the specific QoS profile you are trying to use.

5. **Logs and Debugging:**
- Review the NSX Manager logs for any additional error messages or details related to the "invalid qos profile" error. This might provide more context on what's going wrong.

6. **Upgrading NSX-T:**
- Check if there are any known issues or bug fixes related to QoS profiles in NSX-T 3.2.3. If there is a known issue, consider upgrading to a newer version that addresses the problem.

7. **Contact VMware Support:**
- If you are still unable to resolve the issue, consider reaching out to VMware support for assistance. They can provide more specific guidance and potentially help with any potential bugs or issues in your NSX-T version.

8. **Automation and Scripting:**
- Since you mentioned that you have thousands of segments to update, consider using automation and scripting to streamline the process. You can use tools like PowerShell, Python, or Ansible to automate the task of creating binding maps for segments with QoS profiles.

By following these steps and ensuring that your QoS profiles and API requests are correctly configured, you should be able to resolve the "invalid qos profile in segment monitoring profile map" error in NSX-T 3.2.3.

Re: multicast dns(MDNS)

andrewassis — Sun, 10 Sep 2023 20:24:17 GMT

Enabling MDNS (Multicast DNS) packet traffic on NSX-T routers for specific VLANs can involve several steps. NSX-T provides features for controlling and allowing multicast traffic, but you'll need to ensure that your configuration is correct to permit MDNS traffic to flow between segments and devices on different subnets. Here are some steps and considerations to help you troubleshoot and configure MDNS support in NSX-T:

1. **Verify NSX-T Multicast Configuration:**
- Check if multicast is configured correctly on NSX-T. Ensure that IGMP Snooping and PIM (Protocol Independent Multicast) are properly configured on the NSX-T routers.
- Make sure that multicast is enabled on the segments where MDNS traffic needs to be allowed.

2. **Check for Block Rules:**
- Review the NSX-T firewall rules to check if there are any rules that might be blocking MDNS traffic. Look for rules on both the T0 and T1 routers that may be impacting MDNS traffic flow.

3. **Create Firewall Rules:**
- If you don't have specific firewall rules in place to allow MDNS traffic, you may need to create them. Configure rules that permit UDP traffic on port 5353 (the standard MDNS port) between the source and destination segments or subnets.

4. **MDNS Gateway Configuration:**
- Ensure that the MDNS Gateway feature is configured correctly. The MDNS Gateway should be attached to the appropriate segments and subnets where MDNS traffic needs to be allowed. Verify that it's correctly listening for MDNS traffic.

5. **Monitoring and Troubleshooting:**
- Use NSX-T monitoring tools and logs to trace the flow of MDNS packets. Check for any drop or deny events in the NSX-T logs that may indicate the packets are being blocked.
- You can also use packet capture tools or Wireshark to capture MDNS traffic at various points in your network to see if it's reaching the expected destinations or being blocked.

6. **Contact VMware Support:**
- If you are unable to identify the issue and resolve it through the above steps, consider reaching out to VMware support for assistance. They can provide specific guidance for your NSX-T version and configuration.

7. **Documentation and Vendor Support:**
- Consult the official VMware NSX-T documentation for your specific version to ensure that you're following recommended practices for multicast and MDNS support.
- Check with your radio system vendor to ensure that their equipment and software are compatible with NSX-T and that they have any specific configuration requirements for MDNS.

It's worth noting that MDNS traffic can be tricky to manage in virtualized network environments like NSX-T due to its multicast nature. Proper configuration and troubleshooting are essential to ensure that MDNS packets can flow between segments and devices on different subnets. Be sure to backup your configuration before making any significant changes, and consider testing changes in a controlled environment before applying them to a production network.

Re: Problemas NSX

andrewassis — Tue, 25 Jul 2023 16:36:12 GMT

Qual foi a solução?

Problemas NSX

andrewassis — Tue, 25 Jul 2023 16:33:03 GMT

Quais os maiores problemas que já tiveram com NSX dentro de um ISP?

Implementação de NSX

andrewassis — Tue, 25 Jul 2023 16:30:24 GMT

Qual o passo a passo para implementar NSX em ISP?

NSX ISP

andrewassis — Tue, 25 Jul 2023 16:27:18 GMT

Qual a função principal do NSX em um ambiente ISP?