<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>EvertAM Tracker</title>
    <link>https://communities.vmware.com/wbsdv95928/tracker</link>
    <description>EvertAM Tracker</description>
    <pubDate>Fri, 10 Nov 2023 23:31:05 GMT</pubDate>
    <dc:date>2023-11-10T23:31:05Z</dc:date>
    <item>
      <title>Re: MULTI_OVERLAY_TZ_USE_COUNT not supported for configuration import on global manager</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/MULTI-OVERLAY-TZ-USE-COUNT-not-supported-for-configuration/m-p/2995101#M17065</link>
      <description>&lt;P&gt;I have no hand's on experience with Federation, so this might be a stupid suggestion, but have you checked that you don't have any unassigned TZ overlays?&lt;/P&gt;</description>
      <pubDate>Fri, 10 Nov 2023 10:49:25 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/MULTI-OVERLAY-TZ-USE-COUNT-not-supported-for-configuration/m-p/2995101#M17065</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-11-10T10:49:25Z</dc:date>
    </item>
    <item>
      <title>Re: NSX cluster backup error</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-cluster-backup-error/m-p/2995100#M17064</link>
      <description>&lt;P&gt;Have you tried removing and recreating the scheduled backup?&lt;/P&gt;</description>
      <pubDate>Fri, 10 Nov 2023 10:44:09 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-cluster-backup-error/m-p/2995100#M17064</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-11-10T10:44:09Z</dc:date>
    </item>
    <item>
      <title>Re: Export of DFW from NSXT</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/Export-of-DFW-from-NSXT/m-p/2995091#M17061</link>
      <description>&lt;P&gt;Not PowerCLI, but you should be able to retrieve all DFW rules through the API as well.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Loop through this to get all policy id's:&lt;BR /&gt;GET /policy/api/v1/infra/domains/&amp;lt;domain-id&amp;gt;/security-policies&lt;BR /&gt;&lt;BR /&gt;Then use the results to loop through this to get an overview of all the rule-ids within each policy:&lt;BR /&gt;GET /policy/api/v1/infra/domains/&amp;lt;domain-id&amp;gt;/security-policies/&amp;lt;security-policy-id&amp;gt;/rules&lt;BR /&gt;&lt;BR /&gt;And finally, you could loop this to get the details for every rule within the policy:&lt;BR /&gt;GET /policy/api/v1/infra/domains/&amp;lt;domain-id&amp;gt;/security-policies/&amp;lt;security-policy-id&amp;gt;/rules/&amp;lt;rule-id&amp;gt;&lt;BR /&gt;&lt;BR /&gt;This should allow you to output it all in JSON.&amp;nbsp;&lt;BR /&gt;Alternatively, consider managing the rulebase through IaC, that should give you a permanent overview of your rules in a repository.&lt;/P&gt;</description>
      <pubDate>Fri, 10 Nov 2023 10:04:39 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/Export-of-DFW-from-NSXT/m-p/2995091#M17061</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-11-10T10:04:39Z</dc:date>
    </item>
    <item>
      <title>Re: NSX-T log source port</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-T-log-source-port/m-p/2995089#M17059</link>
      <description>&lt;P&gt;The client is in charge of choosing it's TCP source port, either completely dynamically, like you'll see with a browser, or a fixed port (or pool of ports) for something like DHCP for example.&lt;/P&gt;&lt;P&gt;It appears that the client (the source in this logs) has setup multiple connections to the same host.&lt;BR /&gt;It's hard to tell if this is normal in this specific instance, tcp/343 is not an IANA assigned port and I personally don't really recognize it.&lt;/P&gt;</description>
      <pubDate>Fri, 10 Nov 2023 09:53:43 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-T-log-source-port/m-p/2995089#M17059</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-11-10T09:53:43Z</dc:date>
    </item>
    <item>
      <title>Re: NSX cluster backup error</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-cluster-backup-error/m-p/2995083#M17056</link>
      <description>&lt;P&gt;You probably already did this, but have you verified the available disk space? It wouldn't really explain why the manual backup works, but it never hurts to check I guess.&lt;/P&gt;</description>
      <pubDate>Fri, 10 Nov 2023 09:28:15 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-cluster-backup-error/m-p/2995083#M17056</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-11-10T09:28:15Z</dc:date>
    </item>
    <item>
      <title>Re: VMware ALB - Email Alerts Are Slooooow</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/VMware-ALB-Email-Alerts-Are-Slooooow/m-p/2993914#M17044</link>
      <description>&lt;P&gt;Gotcha. Only other config item I can think of is that the alert itself might be set for "Rolling window" instead of instance. It might be worth a check, my personal next stap would be to contact support and ask them&lt;/P&gt;</description>
      <pubDate>Thu, 02 Nov 2023 13:25:37 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/VMware-ALB-Email-Alerts-Are-Slooooow/m-p/2993914#M17044</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-11-02T13:25:37Z</dc:date>
    </item>
    <item>
      <title>Re: VMware ALB - Email Alerts Are Slooooow</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/VMware-ALB-Email-Alerts-Are-Slooooow/m-p/2993827#M17040</link>
      <description>&lt;P&gt;Have you checked the health monitor to make sure it triggers instantly? Generally, you want some leniency to make sure you don't generate false alerts.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 01 Nov 2023 23:26:22 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/VMware-ALB-Email-Alerts-Are-Slooooow/m-p/2993827#M17040</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-11-01T23:26:22Z</dc:date>
    </item>
    <item>
      <title>Re: Add NSX NAT Rule with service entry configured with port number range</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/Add-NSX-NAT-Rule-with-service-entry-configured-with-port-number/m-p/2993826#M17039</link>
      <description>&lt;P&gt;I believe your issue might be that you're adding multiple ports to both the original and the translated ports. Adding multiple ports is generally used for NAT overload.&amp;nbsp;&lt;/P&gt;&lt;P&gt;Based in your screenshot, you're trying to NAT all traffic to an IP, but only allow certain ports in. This would be better handled using a firewall rule. If you are specifically trying to NAT only 3 ports (while handling traffic to other ports differently), I think you'll need multiple NAT rules.&lt;/P&gt;</description>
      <pubDate>Wed, 01 Nov 2023 23:23:11 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/Add-NSX-NAT-Rule-with-service-entry-configured-with-port-number/m-p/2993826#M17039</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-11-01T23:23:11Z</dc:date>
    </item>
    <item>
      <title>Re: NSX ALB Avi 30.1.1 - macro API "Input object does not have model_name field" even thou</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-ALB-Avi-30-1-1-macro-API-quot-Input-object-does-not-have/m-p/2993824#M17038</link>
      <description>&lt;P&gt;Do you have a (cleaned up if needed) example of the payload you used?&lt;/P&gt;</description>
      <pubDate>Wed, 01 Nov 2023 23:28:36 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-ALB-Avi-30-1-1-macro-API-quot-Input-object-does-not-have/m-p/2993824#M17038</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-11-01T23:28:36Z</dc:date>
    </item>
    <item>
      <title>Re: NSX-T API - Add a Group with Multiple Tags</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-T-API-Add-a-Group-with-Multiple-Tags/m-p/2993822#M17037</link>
      <description>&lt;P&gt;It should be possible (the Terraform provider supports it at least).&lt;/P&gt;&lt;P&gt;Make sure you have the syntax completely correct. Based on the output there, you'll need both expression AND expressions in your body.&lt;/P&gt;</description>
      <pubDate>Wed, 01 Nov 2023 23:15:54 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-T-API-Add-a-Group-with-Multiple-Tags/m-p/2993822#M17037</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-11-01T23:15:54Z</dc:date>
    </item>
    <item>
      <title>Re: Which NSX API should I use?</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/Which-NSX-API-should-I-use/m-p/2990941#M16984</link>
      <description>&lt;P&gt;Do I correctly understand that you want to verify if a transport node has been removed from the fabric? Or do you want to check if NSX was outright uninstalled from the machine?&lt;/P&gt;</description>
      <pubDate>Fri, 13 Oct 2023 08:57:40 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/Which-NSX-API-should-I-use/m-p/2990941#M16984</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-10-13T08:57:40Z</dc:date>
    </item>
    <item>
      <title>Re: Migration and Infrastructure preparation</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/Migration-and-Infrastructure-preparation/m-p/2990235#M16969</link>
      <description>&lt;P&gt;This might sound obvious but have you checked if that group already exists in NSX-T?&lt;/P&gt;&lt;P&gt;You can find them under Inventory -&amp;gt; Groups&lt;/P&gt;</description>
      <pubDate>Mon, 09 Oct 2023 09:59:05 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/Migration-and-Infrastructure-preparation/m-p/2990235#M16969</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-10-09T09:59:05Z</dc:date>
    </item>
    <item>
      <title>Re: NON-IP Distributed Firewall Category</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/NON-IP-Distributed-Firewall-Category/m-p/2988982#M16944</link>
      <description>&lt;P&gt;Ethernet would be considered non-IP, it is meant for all your L2 rules.&lt;/P&gt;&lt;P&gt;However, the categories themselves do not necessarily restrict you from the rules you can make in them. They are recommendations for to help you with ordering and building your firewall policies.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;A href="https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/administration/GUID-6AB240DB-949C-4E95-A9A7-4AC6EF5E3036.html" target="_blank"&gt;https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/administration/GUID-6AB240DB-949C-4E95-A9A7-4AC6EF5E3036.html&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;The documentation is for 3.2, but this hasn't really changed between recent versions I believe, it's still the same in 4.x at least.&lt;/P&gt;</description>
      <pubDate>Fri, 29 Sep 2023 14:29:48 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/NON-IP-Distributed-Firewall-Category/m-p/2988982#M16944</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-09-29T14:29:48Z</dc:date>
    </item>
    <item>
      <title>Re: Use Aria Operations for Network (vRNI) to build wave migration</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/Use-Aria-Operations-for-Network-vRNI-to-build-wave-migration/m-p/2983887#M16845</link>
      <description>&lt;P&gt;We've been doing it manually actually, but our environment is smell enough. As part of our migration we do also tag new VM's with a predefined set of categories to identify them.&amp;nbsp;We use these as the member criteria for our NSX Security groups as well.&amp;nbsp;&lt;/P&gt;&lt;P&gt;Assuming you've already consistently tagged VM's, using those is probably not a bad idea &lt;img class="lia-deferred-image lia-image-emoji" src="https://communities.vmware.com/html/@7651DD0E8772B3B5D93ADA9ABA2E067C/emoticons/1f642.png" alt=":slightly_smiling_face:" title=":slightly_smiling_face:" /&gt;&lt;/P&gt;</description>
      <pubDate>Fri, 25 Aug 2023 06:39:22 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/Use-Aria-Operations-for-Network-vRNI-to-build-wave-migration/m-p/2983887#M16845</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-08-25T06:39:22Z</dc:date>
    </item>
    <item>
      <title>Re: NSX-ALB System-Default-Secure-Channel-Cert</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-ALB-System-Default-Secure-Channel-Cert/m-p/2983634#M16837</link>
      <description>&lt;P&gt;It doesn't seem to be universal, we've recently upgrade to 22.1.4 but did not encounter the issue.&lt;/P&gt;&lt;P&gt;Based in the expiration dates, it seems like your System-Default-Root-CA was somehow renewed. Our controllers show the same expiration dates for both the root and the Secure-Channel-Cert (with the root expiring one second earlier).&lt;/P&gt;&lt;P&gt;You could try to renew the Secure-Channel-Cert, but that might be bit risky in a production environment.&lt;/P&gt;</description>
      <pubDate>Wed, 23 Aug 2023 15:17:38 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-ALB-System-Default-Secure-Channel-Cert/m-p/2983634#M16837</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-08-23T15:17:38Z</dc:date>
    </item>
    <item>
      <title>Re: Use Aria Operations for Network (vRNI) to build wave migration</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/Use-Aria-Operations-for-Network-vRNI-to-build-wave-migration/m-p/2983570#M16836</link>
      <description>&lt;P&gt;We're in the process of doing this right now now.&lt;/P&gt;&lt;P&gt;Some of our experiences below:&lt;BR /&gt;- Try to add other sources outside of your VMware environment (switches, loadbalancers, ...), this will help in identifying flows that aren't necessarily virtual.&amp;nbsp;&lt;BR /&gt;- vRNI has a LOT of information, and it can be quite a challenge to sift through it&lt;BR /&gt;- Flows are only ever stored for 30 days, something to keep in mind if you have flows that might only occur every so often&lt;BR /&gt;- Define your applications and tiers in vRNI (under Applications -&amp;gt; All Applications -&amp;gt; Add). This will help tremendously in analyzing flows&lt;/P&gt;&lt;P&gt;I don't believe it's a good idea to use vRNI to define the contents of your waves. Identify (some of) your applications, and sort those into waves. Secure based on an application, not a VM.&lt;/P&gt;</description>
      <pubDate>Wed, 23 Aug 2023 10:04:18 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/Use-Aria-Operations-for-Network-vRNI-to-build-wave-migration/m-p/2983570#M16836</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-08-23T10:04:18Z</dc:date>
    </item>
    <item>
      <title>Re: NSX IDS/IPS with VLAN Segment</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-IDS-IPS-with-VLAN-Segment/m-p/2981598#M16741</link>
      <description>&lt;P&gt;Your understanding is correct. This IDS/IPS engine is part of the distributed firewall, which does not require NSX overlay segments to function.&lt;/P&gt;</description>
      <pubDate>Wed, 09 Aug 2023 15:55:45 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/NSX-IDS-IPS-with-VLAN-Segment/m-p/2981598#M16741</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-08-09T15:55:45Z</dc:date>
    </item>
    <item>
      <title>Re: IP Prefix on BGP tunnels</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/IP-Prefix-on-BGP-tunnels/m-p/2981597#M16740</link>
      <description>&lt;P&gt;That's probably not gonna work for your goal. The out filter will filter out routes that the T0 advertises to the outside world. Based on your message, you want to apply something like this to the the MPLS peers (incoming):&lt;/P&gt;&lt;P&gt;0.0.0.0/0 Deny&lt;BR /&gt;Any&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; Allow&lt;BR /&gt;&lt;BR /&gt;This will cause the MPLS peers to not accept a default route from the remote side, this in turn will cause the T0 to not install a default route from the MPLS peers in it's routing table. You might additionally want to add some extra rules in there for other public IP's, but that will depend on your environment.&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;For this usecase, you don't necessarily need any other filters I believe.&lt;/P&gt;&lt;P&gt;It is best practice to only allow your own public address space on an outgoing BGP filter (even though your ISP should be filtering this as well), and to deny any incoming private subnets from your ISP (again, they should not send this, but if everyone did there job properly, most of us would be out of a job). All of this assumes that you are directly peering to an ISP of course &lt;img class="lia-deferred-image lia-image-emoji" src="https://communities.vmware.com/html/@7651DD0E8772B3B5D93ADA9ABA2E067C/emoticons/1f642.png" alt=":slightly_smiling_face:" title=":slightly_smiling_face:" /&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 09 Aug 2023 15:52:05 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/IP-Prefix-on-BGP-tunnels/m-p/2981597#M16740</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-08-09T15:52:05Z</dc:date>
    </item>
    <item>
      <title>Re: IP Prefix on BGP tunnels</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/IP-Prefix-on-BGP-tunnels/m-p/2981550#M16736</link>
      <description>&lt;P&gt;Are you applying these as incoming or outgoing filters?&lt;/P&gt;</description>
      <pubDate>Wed, 09 Aug 2023 12:50:20 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/IP-Prefix-on-BGP-tunnels/m-p/2981550#M16736</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-08-09T12:50:20Z</dc:date>
    </item>
    <item>
      <title>Re: IP Prefix on BGP tunnels</title>
      <link>https://communities.vmware.com/t5/VMware-NSX-Discussions/IP-Prefix-on-BGP-tunnels/m-p/2981490#M16732</link>
      <description>&lt;P&gt;Where did you apply these exactly?&amp;nbsp;&lt;/P&gt;&lt;P&gt;You'll generally use prefix lists to filter which routes you accept into the routing table, and which prefixes you want to advertise.&amp;nbsp;&lt;/P&gt;&lt;P&gt;Your screenshots don't have the name on them, but one of them outright denies everything right at the top, so that's a likely culprit. The list will be checked top to bottom and hit on the first match.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Am I understanding correctly that you're trying to force internet traffic through the internet line, and all other traffic through the MPLS?&lt;/P&gt;</description>
      <pubDate>Wed, 09 Aug 2023 06:58:21 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-NSX-Discussions/IP-Prefix-on-BGP-tunnels/m-p/2981490#M16732</guid>
      <dc:creator>EvertAM</dc:creator>
      <dc:date>2023-08-09T06:58:21Z</dc:date>
    </item>
  </channel>
</rss>

