Fighting at the forefront: Early 5.0.0.x experiences

 5.0.0.0 came around with a ton of exciting new features I was eager to test

    • IPv6 (Dual Stack) in Underlay and Overlay 

    • Better Gateway throughput

    • Data loss prevention in SASE 

      However, new Version, new Bugs


  • I first upgraded my company Orchestrator to 5.0.0.0 (after creating a snapshot to be able to roll back to 4.5). This worked quite well, only after going to all parts of the new UI I found out that I could not reach the "General Settings" in the new UI, but the content was perfectly visible in the old UI.

    Fortunately a 5.0.0.1 upgrade solved that problem.

    Another strange items, still in version 5.0.0.1 as well, is the fact that in the old and the new UI our Edges now are showing  

    0 % memory utilization, 

    which is either an incredible efficient new code or simply a bug.

     

    Next I tried IPv6

    As my Internet provider at home still does not support IPv6, I used the new 5.0 IPv6 features to build IPv6 connectivity using the Dual Stack Overlay and the fact, that our Gateways in our Datacenter have a dual stack connectivity to the Internet.

    So I tried to ping the Google IPv6 DNS server with very mixed results:

    C:\Users\xandl>ping 2001:4860:4860::8888

     

    Pinging 2001:4860:4860::8888 with 32 bytes of data:

    Request timed out.

    Reply from 2001:4860:4860::8888: time=41ms

    Reply from 2001:4860:4860::8888: time=46ms

    Reply from 2001:4860:4860::8888: time=45ms

     

    Ping statistics for 2001:4860:4860::8888:

        Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),

    Approximate round trip times in milli-seconds:

        Minimum = 41ms, Maximum = 46ms, Average = 44ms

    The next try a Traceroute and further pings resulted in a complete loss of IPv6 connectivity:

     

    C:\Users\xandl>tracert 2001:4860:4860::8888

     Tracing route to dns.google [2001:4860:4860::8888]

    over a maximum of 30 hops:

      1  Destination host unreachable.

     Trace complete.

    C:\Users\xandl>ping 2001:4860:4860::8888

     Pinging 2001:4860:4860::8888 with 32 bytes of data:

    Destination host unreachable.

    Destination host unreachable.

    Destination host unreachable.

    Destination host unreachable.

     Ping statistics for 2001:4860:4860::8888:

        Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

    After some minutes a retry worked but only for the first request.

    So it seems that something with the Flow or the SNAT on the gateway prevents a second request to the same destination. At least until a timeout cancels the corresponding entry.

     


     But the biggest problems I faced when trying to upgrade my labenvironment to version 5.0.0.0

    Due to the fact that I overlooked the 90 days validity of the vcadmin password 2 of my 3 gateways were locked and needed a new deploy and reactivation.

    So I first upgraded the LAB Orchestrator (after a snapshot) and then redeployed the Gateways with a 5.0 image.

    But the gateways did not successfully activate even though I correctly set the necessary System parameter:

    Cloud-Init always came back with the below error

    [   83.971366] cloud-init[2986]: 2022-04-02 15:24:28,211 - cc_velocloud.py[ERROR]: Activation failed: message=b"Cannot read property 'enabled' of null\n", stderr=b'Generating RSA private key, 2048 bit long modulus (2 primes)\n..........................+++++\n.......................................................+++++\ne is 65537 (0x010001)\n'

    [   83.980086] cloud-init[2986]: 2022-04-02 15:24:28,220 - util.py[WARNING]: Running module velocloud (<module 'cloudinit.config.cc_velocloud' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_velocloud.py'>) failed

    [   84.119170] cloud-init[2986]: Cloud-init v. 21.4-0ubuntu1~18.04.1 finished at Sat, 02 Apr 2022 15:24:28 +0000. Datasource DataSourceNoCloud [seed=/dev/sr0][dsmode=net].  Up 84.08 seconds

     Even manual activation resulted in similar error message

     So I had to use my snapshot and step back to version 4.5 until this bug will be resolved.

    From friends inside VMware I heared that the bug is there whenever you try to activate or reactivate a Partner-Gateway.

     Now I also understood why in my 3rd SD-Wan environment, a SASE Proof of Concept   with Orchestrator and SASE-POP provided by VMware the version is still on 4.5, and testing new features like DLP is currently not available there.

Comments

Post a Comment