All Posts

jamannatmtgov · ‎11-17-2023

Wat is the recommended config for an interface connection to a down stream switch? Layer 2 trunk or a layer 3 sub-interfaces. Thanks!

yusukehirata01 · ‎11-17-2023

Is it an Organization ID ,and not an Enterprise ID? I don't think either of these are necessary when contacting VMware Support. https://kb.vmware.com/s/article/83702 There are many cases where E...

Is it an Organization ID ,and not an Enterprise ID? I don't think either of these are necessary when contacting VMware Support. https://kb.vmware.com/s/article/83702 There are many cases where Enterprise ID is used in Rest API. https://developer.vmware.com/apis/1237/

niceed00 · ‎11-02-2023

Support is asking for my Org ID. Where do I find this?

kurni_andriy · ‎10-24-2023

Hi, Did anybody face issue for running velocloud orchestrator on eve-ng/pnetlab? I have issue with cloud-init which throwing error for user-data. [ OK ] Started Wait for Network to be Configured. ...

Hi, Did anybody face issue for running velocloud orchestrator on eve-ng/pnetlab? I have issue with cloud-init which throwing error for user-data. [ OK ] Started Wait for Network to be Configured. Starting Initial cloud-init job (metadata service crawler)... [ 17.154197] cloud-init[997]: Cloud-init v. 21.1-19-gbad84ad4-0ubuntu1~18.04.2 running 'init' at Tue, 24 Oct 2023 11:58:10 +0000. Up 15.28 seconds. [ 17.159224] cloud-init[997]: ci-info: +++++++++++++++++++++++++++++++++++++++Net device info+++++++++++++++++++++++++++++++++++++++ [ 17.164041] cloud-init[997]: ci-info: +--------+-------+-----------------------------+---------------+--------+-------------------+ [ 17.167932] cloud-init[997]: ci-info: | Device | Up | Address | Mask | Scope | Hw-Address | [ 17.171985] cloud-init[997]: ci-info: +--------+-------+-----------------------------+---------------+--------+-------------------+ [ 17.175838] cloud-init[997]: ci-info: | eth0 | True | X.X.X.X | 255.255.255.0 | global | MAC | [ 17.179723] cloud-init[997]: ci-info: | eth0 | True | IPv6 | . | link | MAC | [ 17.183831] cloud-init[997]: ci-info: | eth1 | False | . | . | . | MAC | [ 17.187131] cloud-init[997]: ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | host | . | [ 17.190635] cloud-init[997]: ci-info: | lo | True | ::1/128 | . | host | . | [ 17.194564] cloud-init[997]: ci-info: +--------+-------+-----------------------------+---------------+--------+-------------------+ [ 17.197919] cloud-init[997]: ci-info: ++++++++++++++++++++++++++++++++Route IPv4 info++++++++++++++++++++++++++++++++ [ 17.201559] cloud-init[997]: ci-info: +-------+---------------+---------------+-----------------+-----------+-------+ [ 17.205844] cloud-init[997]: ci-info: | Route | Destination | Gateway | Genmask | Interface | Flags | [ 17.210326] cloud-init[997]: ci-info: +-------+---------------+---------------+-----------------+-----------+-------+ [ 17.215675] cloud-init[997]: ci-info: | 0 | 0.0.0.0 | X.X.X.X | 0.0.0.0 | eth0 | UG | [ 17.219355] cloud-init[997]: ci-info: | 1 | X.X.X.X | 0.0.0.0 | 255.255.255.0 | eth0 | U | [ 17.222668] cloud-init[997]: ci-info: | 2 | X.X.X.X | 0.0.0.0 | 255.255.255.255 | eth0 | UH | [ 17.225649] cloud-init[997]: ci-info: +-------+---------------+---------------+-----------------+-----------+-------+ [ 17.228515] cloud-init[997]: ci-info: +++++++++++++++++++Route IPv6 info+++++++++++++++++++ [ 17.230585] cloud-init[997]: ci-info: +-------+-------------+---------+-----------+-------+ [ 17.234197] cloud-init[997]: ci-info: | Route | Destination | Gateway | Interface | Flags | [ 17.238534] cloud-init[997]: ci-info: +-------+-------------+---------+-----------+-------+ [ 17.241153] cloud-init[997]: ci-info: | 1 | fe80::/64 | :: | eth0 | U | [ 17.243519] cloud-init[997]: ci-info: | 3 | local | :: | eth0 | U | [ 17.246437] cloud-init[997]: ci-info: | 4 | ff00::/8 | :: | eth0 | U | [ 17.249604] cloud-init[997]: ci-info: +-------+-------------+---------+-----------+-------+ [ 17.252232] cloud-init[997]: 2023-10-24 11:58:12,185 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [0/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f11d6d911d0>: Failed to establish a new connection: [Errno 111] Connection refused',))] [ 18.157946] cloud-init[997]: 2023-10-24 11:58:13,190 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [1/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f11d7218828>: Failed to establish a new connection: [Errno 111] Connection refused',))] I have followed step from https://docs.vmware.com/en/VMware-SD-WAN/4.3/sd-wan-orchestrator-deployment-and-monitoring-guide/GUID-46F3C13D-038E-4C92-B639-864B516AE663.html but no luck at all. Thank you!

UnknownUsername · ‎10-23-2023

Was there ever an answer given for this error? Im having this same issue and coming up empty handed on help for it.

Benjaman · ‎10-23-2023

I second what @yusukehirata01 said above.

yusukehirata01 · ‎10-23-2023

Is what you want as shown in the picture below? It's possible. For static routing settings, please refer to the document below. https://docs.vmware.com/en/VMware-SD-WAN/5.2/VMware-SD-WA...

Is what you want as shown in the picture below? It's possible. For static routing settings, please refer to the document below. https://docs.vmware.com/en/VMware-SD-WAN/5.2/VMware-SD-WAN-Administration-Guide/GUID-839747B6-43D2-4AAB-A581-5F8B8693BEFF.html

Benjaman · ‎10-21-2023

Hi @amirimran, Kindly check from "Remote Diagnostics" - "Flow Dump" to see what business rule this flow is actually taking. I suspect it might be hitting two types of business rules. One is the App...

Hi @amirimran, Kindly check from "Remote Diagnostics" - "Flow Dump" to see what business rule this flow is actually taking. I suspect it might be hitting two types of business rules. One is the Application category(Rule defined just with Application) and the other could be the rule which is under the bottom pointing to "Internet" and might have been backhauled to the Hub. Depending on the load of the edge, its model, traffic patterns, and the number of applications used, the edge also might be exhausting its application identification database due to which it is failing to hit the top rule. If route 52.123.128.14 is learned from a specific remote branch, today there is no visibility to which branch it's going in the "Flows" tab. This should be an enhancement. The Route types can either be "Branch to Branch", "Cloud via Gateway", "Branch to datacenter", or "Brach to backhaul" depending on the destination route. If this is the only spoke that shows Branch to Branch, then there should not be a route 52.123.128.14 learned from any other branches. If there is not already then we need to check further on why it displays "Branch to Branch" instead of "Cloud via Gateway" as I expect it should hit the gateway route if the business rule with just application-defined matches. Route table dump in "Remote Diagnostics" would help and also "Overlay Flow Control" would help from which branch this route is being initiated. Probably this might need more eyes from a support stand point if you see any discrepancies. Please feel free to create a support ticket after you research a bit more.

amirimran · ‎10-21-2023

Thanks @Benjaman for the explanation. The same Business Policy is being used for other spokes. We don't have a specific rule for that application "Microsoft Office 365" but we do have the rule for "I...

Thanks @Benjaman for the explanation. The same Business Policy is being used for other spokes. We don't have a specific rule for that application "Microsoft Office 365" but we do have the rule for "Internet" destination backhauling to the Hub. It's just weird to me that only this spoke is having issue connecting to the destination IP address while the other spokes are working fine. For the other spokes, the Route is only showing "Branch to Backhaul" for that destination IP address. That is the only difference I can see. Back to the Flow table of the problematic spoke, if the route to 52.123.128.14 is learned from other Branch, shouldn't the Next Hop showed the Branch Edge name instead of the Hub for flow that is showing "Branch to Branch"? This is another thing that confused me. I will try your suggestion playing around with the Business Policy and see what the results are. Thanks!!

Benjaman · ‎10-21-2023

Hi @amirimran Thank you for providing the screenshot. I think there are a few things to consider. Firstly, if you see the route as "Branch to Branch" or "Branch to Backhaul" on the spoke side "Flo...

Hi @amirimran Thank you for providing the screenshot. I think there are a few things to consider. Firstly, if you see the route as "Branch to Branch" or "Branch to Backhaul" on the spoke side "Flows" tab, it is completely expected if 1. There is a business rule using just the "Application Name" and not the IP address in the destination IP field and 2. A business rule under the above indicating the destination as "Internet" and backhauling traffic to the Hub. Reason is that VCE takes a few packets from the flows to read and identify the application name from the flow which involves a bit of time. During this process, as the application name for that flow is not yet determined, VCE sends the traffic out using the next best business rule. So for a few flows, seeing "Branch to Backhaul" is expected since it's backhauling the traffic to the Hub, and for many more flows "Brach to Branch" should be seen since the subsequent flows start hitting the policy that has just the application name. With respect to the Link Name not reflecting for a few flows, it's expected since for the flows that are being load-shared, it does not reflect the Interface or Link Name as it sends the traffic out of multiple links. Coming to the original query on why you are unable to access the application - 1. Please check if it's expected that the public route i.e., in the Flow dump that you shared, the route towards 52.123.128.14 is expected to be learnt from a remote branch. If not, please stop advertising it at the source VCE. If it's expected to be learnt from the remote branch, then you can take captures on the LAN side of both VCEs to check if the packets that are actually sent are reaching the other side. 2. Try configuring the business rule with IP address and play with it sending "Direct"/"Multipath"/"Backhaul" and observe the results. If you feel that VCE is dropping the traffic, please feel free to engage support and take it forward as this would have confidential data of your customer which they might not want to be discussed in this forum.

amirimran · ‎10-21-2023

Hi @Benjaman , Attached is the screenshot. Just noticed that for some flows, it is also not showing the link info. Is this normal?

Benjaman · ‎10-21-2023

@amirimran Can you help share the outputs that you are observing? Like screenshots etc.

amirimran · ‎10-21-2023

Hi, I have a setup of hub and spoke where internet traffic will go via hub's internet link. One of the spoke (Spoke1) is showing the Next Hop as the hub (eg: Hub1) but the Route are 2 different typ...

Hi, I have a setup of hub and spoke where internet traffic will go via hub's internet link. One of the spoke (Spoke1) is showing the Next Hop as the hub (eg: Hub1) but the Route are 2 different types; 1 is Branch to Branch and the other is Branch to Backhaul. This is for the same source and destination IPs. When I checked the other spokes (Spoke2 and Spoke3) for the same destination IP (which is Microsoft public IP), the flow report is showing the Next Hop as the hub (Hub1) but there's only 1 type of Route which is Branch to Backhaul. Right now, Spoke1 is having issue connecting to that Microsoft public IP. I can also see the Fortigate firewall log that we put between Hub1 and ISP link, that the traffic to that Microsoft public IP is showing as "IP connection error" which seems to suggest asymmetric routing. Spoke1, 2 and 3 are all using the same profiles so I am currently stuck as why Spoke1 is seeing 2 different type of Route for the Next Hop Hub1. I am inclined to think that the different type of Route is causing the issue in Spoke1. Appreciate any help

khirom · ‎10-20-2023

Hi, I have successfully configured a VPN between Fortigate and VMware SD-WAN Gateway. Fortigate interface had a public IP address. I have not tested it in a NAT environment. Initially, I tried us...

Hi, I have successfully configured a VPN between Fortigate and VMware SD-WAN Gateway. Fortigate interface had a public IP address. I have not tested it in a NAT environment. Initially, I tried using AES128, SHA-1, and DH2. After confirming the VPN was established, I switched to stronger parameters. After setting NSD in the profile, the VPN was established. I think VMware SD-WAN Gateway is the responder and Fortigate is the Initiator.

khirom · ‎10-18-2023

Hi, I configured IPsec VPN between AWS and VMware SD-WAN Edge using NSD via Edge. It was amazingly easy. However, I have not yet had success with FW. It seems that SD-WAN Edge is the Initiator a...

Hi, I configured IPsec VPN between AWS and VMware SD-WAN Edge using NSD via Edge. It was amazingly easy. However, I have not yet had success with FW. It seems that SD-WAN Edge is the Initiator and NAT-T is used.

Kandarp_Desai · ‎10-12-2023

Hello, We have multiple deployments of VMware SDWAN (Velo Cloud) Edges (Specifically Edge 610) and would like to know the following: 1. Of all the protections present in Network Flood Protection, ...

Hello, We have multiple deployments of VMware SDWAN (Velo Cloud) Edges (Specifically Edge 610) and would like to know the following: 1. Of all the protections present in Network Flood Protection, are there any protections that should be enabled irrespective of network flow/ architecture? A protection that is highly recommended to be enabled. 2. If there are no TCP/UDP services/ports exposed to the Internet on any of the edges. Is it still beneficial to enable TCP/UDP Flood protections (i.e. to set a New Connection Threshold). Does enabling this option protect the SDWAN box from overconsumption of bandwidth and hardware resources even though there are no services open to the Public Internet. 3. On application of the suggested Flood Protections, is there a need for any type of incident response or are these features mainly applied and left to work on their own. Any other resources or recommendations from someone who has worked on these settings will be really helpful !

KLC_Engineer · ‎10-11-2023

Thank you for the info Benjaman!

TalalTayyaroğlu · ‎10-11-2023

Good day, I have a problem where I need to route traffic destined for certain networks/hosts to a gateway other than the default router (currently an Edge). Since the Edge which acts as a default g...

Good day, I have a problem where I need to route traffic destined for certain networks/hosts to a gateway other than the default router (currently an Edge). Since the Edge which acts as a default gateway and DHCP server does not support DHCP Option 121, I had to temporarily solve this by configuring static route entries on the workstation level. Something upper management does not look warmly upon (TBH, neither do I). Is it possible to configure internal routing in the Edge to solve this problem? Lets assume the Edge VLAN1 IP address is 10.0.0.1. A Cisco router on the same network handing L2L VPN is at 10.0.0.2 (the Cisco's LAN interface that is). The edge needs to route traffic sent to it (as the default gateway) destined for specific destinations (for example 10.10.0.0/24) to the local IP address of the Cisco router within VLAN1 before applying any other logic to it. Currently, I am using the following command added to Windows to achieve the same result: route -p add 10.10.0.0 MASK 255.255.255.0 10.0.2

Benjaman · ‎10-10-2023

@KLC_Engineer From the symptoms, I think the set up is hitting the defect which is not fixed in 5.0.1.4 or 4.5.1. The defect ID is #97152 This is fixed in 5.1.0.x, 4.5.2 and 4.3.1 Please feel fr...

@KLC_Engineer From the symptoms, I think the set up is hitting the defect which is not fixed in 5.0.1.4 or 4.5.1. The defect ID is #97152 This is fixed in 5.1.0.x, 4.5.2 and 4.3.1 Please feel free to check the release notes of those versions. https://docs.vmware.com/en/VMware-SASE/5.1.0/rn/vmware-sase-510-release-notes/index.html

KLC_Engineer · ‎10-10-2023

Hi Benjaman, On version 4.5.1, I observed the problem both with and without a LINK DEAD condition: A couple of our branches had a "Public Wired" LINK DEAD event and failed over to wireless. The...

Hi Benjaman, On version 4.5.1, I observed the problem both with and without a LINK DEAD condition: A couple of our branches had a "Public Wired" LINK DEAD event and failed over to wireless. The traffic governed by the Business policy did not restore until the Wired Link restored the next day. Also, when testing in my lab while on 4.5.1, I relabeled my wired link to "Public wireless", saved the config and all applicable traffic immediately stopped - my Voip phone de-registered and I could not reach any of the destinations in that business policy rule. I also restarted the edge in this condition and the problem remained. I then relabeled the link as "Public wired" and saved the configuration, then the traffic immediately restored. So in this scenario there was no LINK DEAD event. This leads me to believe that an edge with only a wireless link available would have this problem permanently. For version 5.0.1.4, I have only validated the condition by relabeling the link type between wired/wireless, not with a link down event. I presume it would be the same scenario as on 4.5.1. Coincidentally, I just acquired a Cradlepoint for my lab, so I could reproduce/test the link DEAD condition while on 5.0.1.4, if that is helpful.

All

All Posts

Recommnded interface config to connect to a downstream switch

Re: Where do I locate my OrgID ?

Where do I locate my OrgID ?

velocloud orchestrator 4.3

Re: "invalid probe interval for interface GE4" Error while configuring static IP addresses

Re: Internal routing

Re: Internal routing

Re: Flow report is showing 2 different Route for the same Next Hop, Source and Destination IPs

Re: Flow report is showing 2 different Route for the same Next Hop, Source and Destination IPs

Re: Flow report is showing 2 different Route for the same Next Hop, Source and Destination IPs

Re: Flow report is showing 2 different Route for the same Next Hop, Source and Destination IPs

Re: Flow report is showing 2 different Route for the same Next Hop, Source and Destination IPs

Flow report is showing 2 different Route for the same Next Hop, Source and Destination IPs

Re: VPN DO NOT ESTABLISH BETWEEN VELOCLOUD GATEWAY AND FORTIGATE

Re: VPN to Non-SD-WAN destination (NSD) directly from Edge?

Suggestions for Network and Flood Protection for VMWare SDWAN - Velocloud.

Re: Velocloud Business Policy "Link State" Logic broken

Internal routing

Re: Velocloud Business Policy "Link State" Logic broken

Re: Velocloud Business Policy "Link State" Logic broken