Crazy about VMware SD-WAN

 In this Blog we look into the necessary settings for allowing Secure Access to the EDGE via CLI. This new feature allows priviledged secure access using script and shell and for Basic access there is a scripted procedure with a restricted set of commands. In principle many of the information can also be retrieved using remote diagnostics BUT the CLI access is much quicker without waiting for the next hearbeat (~ 30 seconds) before getting the result. These are the necessary steps to activate the new feature using key-based access Step 1: Activating Secure Edge Access (once per customer) Step 2: In the same window switch to Key Based Authentication Step 3: any superuser can then define if Basic (script based only) or Priviledged (script or shell) should be allowed NOTE: the CLI username is   <1 character e ... enterprise, o...operator><user-id><username (with "@" and "." converted to "_")> Now the user can under "My Account"/...

  OSPF v2 ( IPv4) is supported for LAN and WAN interfaces. I recently defined a redundant OSPF LAN connection between an VMware 6X0 edge and a Sophos UTM 9 Firewall  The Edge forwards Overlay Routes to LAN as OSPF E1 routes, thus playing an ASBR (Autonomous System Boundary Router) within the OSPF area and domain. On the UTM Firewall static routes and connected routes are advertised via OSPF E2, again playing the role of an ASBR. During testing various features for Internet Backhaul we also played with advertising a default route into the Velocoud Overlay.  In order to prevent the default route from being advertised via OSPF to the UTM FW we entered a filter on "Outbound Route Advertisement" on both SFP interfaces. But on one of the connecting interfaces we forgot to check the "Exact Match" field which resulted in a Outbound filter of DENY ANY instead of the planned DENY DEFAULT ROUTE. The result was not what we expected: When testing we found out that routes adveri...

 In my previous blog I stated, that in VMware SD-WAN we can have Branch to Branch connectivity via overlay, as long as we have the branch routes announced with a maximum of 2 overlay hops away. Now let´s proof this assumption in my lab and modify it in order to establish a 4-tier hierarchy: I applied a new profile to the Regional Hubs, which now have only overlay tunnels to the 2 DC-Hubs, thus removing the permanant tunnel between all Regional Hubs. There is no change in paths between Branch Edges and DC-network  VPC-A1> ping 10.1.201.2   (VPC-DC) 84 bytes from 10.1.201.2 icmp_seq=1 ttl=60 time=58.340 ms 84 bytes from 10.1.201.2 icmp_seq=2 ttl=60 time=19.604 ms 84 bytes from 10.1.201.2 icmp_seq=3 ttl=60 time=48.628 ms 84 bytes from 10.1.201.2 icmp_seq=4 ttl=60 time=180.321 ms 84 bytes from 10.1.201.2 icmp_seq=5 ttl=60 time=23.469 ms VPC-A1> trace 10.1.201.2   (VPC-DC) trace to 10.1.201.2, 8 hops max, press Ctrl+C to stop  1   10.2.201....

  Recently my teaching collegues from VMware sent me this range of questions: "Can I create a full, global mesh even using different hubs? Gateways are not an option in this scenario. In other words, I have: AMER DC with Hub Cluster EMEA DC with Hub Cluster APAC DC with Hub Cluster  And I have profiles that use dynamic E2E VPN set to use the regional hub.  Can we, in this topology, get, essentially, a full overlay mesh between Edges directly? Like, can I actually build a tunnel from, say, a Tokyo Edge to a Chicago Edge even with different hubs?   Will secondary hubs in the VPN config provide the meet-in-the-middle connectivity in order to create the E2E VPN?  My understanding of the hub cluster order in the Cloud VPN config is that we simply use the first cluster, but if that is unavailable, we use the next cluster in the list." My first assumption was:  In my opinion (static or dynamic) E2E works only when there is a single or 2 hop continuo...