Versa TITANic or Scratching along the Iceberg
3 months ago I was asked to prepare a Versa Titan course for a customer and in the starting meeting I was promised a Titan environment to play with and support and help if necessary.
In this 3 month it turned out, that this half officially set-up Titan POC environment was neither supported by the Versa TAC support nor fully functioning.
Therefore I recently canceled my okay for giving that course.
What happened after my cancellation is another story but in this LAST Blog I will tell you what I have learned about TITAN and how problematic this product was at least for me.
BUT why the Title: only 9% of an iceberg is visible above the waterline, and that is the nice marketing of TITAN being an easy to use SD-WAN solution for LEAN-IT, the other invisible 91% I have experienced in the last 3 months, and yes they are nearly as dangerous and devastating as the real iceberg was to the Titanic.
Within the provided TITAN environment, where my account and my provided organization had to be setup twice before I could start doing small things,was also a Versa built up SASE Gateway, providing Internet Gateway functions and Secure Access, but the latter one only worked for around one week in that 3 months.
Trying to forward this device to a newly created subtenant resulted in
but the new subtenant had no active or configured device AND the SASE gateway belonged to Versa
Trying to delete and create a new tenant resulted in another bug:
and on a second try to forward the Versa SASE gateway to subtenant resulted in
Beside constant certificate problems on the Secure Access, which I assume was only in this POC version of TITAN, were I never could access any website being internally or externally, a test to create some additional devices as Service Provider and forward them to subtenants was only theoretically possible on a "Private Gateway" type of device, but also never worked as applying to the subtenant reulted in various error messages.
Other devices like Hub-controler or hubs could not be shared, so TITAN is multitenant only in a very restricted way
This "private Gateway" was also the gateway device into a lab environment where branches and hub-controlers were implemented and on that connection also a whole bunch of bugs and problems arose.
Preventing a local defined static route to be forwarded via BGP not only failed, but trying to remove it resulted in an inconsistency between device and TITAN, Afterwards Publishing failed every time and I had to completely remove the device and set it up again from scratch.
One generally important point when installing SD-WAN is that it is almost always Brownfield installation, so the newly SD-WAN installation should adapt to the already existing environment.
Generally SD-WAN has its own routing and injecting routes from outside should be done quite restrictive.
In BGP you typically could use the network statement (not available in TITAN) or route filtering to only advertise needed routes.
Now in TITAN you can define to allow or block routes inbound and outbound by specifying a prefix and a mask (like 192.168.1.0/24) but for example blocking 192.168.1.0/24 but explicitely allowing 192.168.1.100/32 did not work at all.
As SD-WAN has its own treatment and usage of default routes, it is of utmost importance to prevent any default route from being injected into SD-WAN.
BUT trying to block the default route also did not work.
The reason for that is the rather strange and undocumented way TITAN is treating the customer specified prefix, as it is automatically prepended it to a prefix-list with a "le 32" parameter . Thus deny 0.0.0.0/0 means deny any and there is no way to deny the default route as it would need a deny 0.0.0.0/0 without le 32.
I had to use the console and look into the curly bracket type of configuration to find that reason.
If you think its better to use OSPF than BGP there are some additional hurdles to handle.
First at least in my provided TITAN environment the default MTU size on Ethernet interfaces was 1400 instead of the normally set 1500, so typically thus prevent the link state packet exchange and the full adjacency state
and
second the default OSPF interface type was (undocumented) broadcast with no knob to change it to pt2pt.
A lot of networking vendors using OSPF have implemented a mechanism, that a neighborship will not be established when the interface type does not match on both sides. Not so with Versa, the adjacency and neighborship comes up, full exchange of routing will be done, but then the routes will not be established in the routing table as there is no common interface between 2 OSPF device with different interface type.
A prospos Routing and Routes: the lab environment I connected to, had around 500 routes which were forwarded to the SD-WAN gateway, but when looking into the TITAN Monitoring only the first 50-100 were seen and even when using the search field all other routes were invisible inside Titan. Makes troubleshooting a lot more challenging.
And troubleshooting is not easy as you typically have only access to the monitoring and anylytics part of the director (but you need special privileges for that), there is no access into the director config or into the appliance.
Regarding IP, forget about IPv6, TITAN can only IPv4.
If you as a Service Provider wants to implement some hub controler for your clients there is also a lot of restrictions, beside the fact, that you can only forward devices of type Private Gateway.
You can create a hub controler BUT you cannot use the hub controler for staging (even though there are some staging parameter configurable in Titan) staging via URL-based ZTP via local ethernet or Wifi or Buetooth only connects to the Versa established main controlers which can only do Internet.
I tried to overcome that problem by using script based staging but it seems that TITAN does not implement all necessary functions and by searching for the necessary parameter I had to go direct in the hub controlers curly bracket configuration on the device via console access, but also with the correct staging parameters for staging, there are some missing configuratio items on the hub-controler, so that also this way failed.
Thus simple speaking, with TITAN you cannot activate MPLS-only connected appliances.
Generally staging is cumbersome as meaningful messages are missing, so that you clearly cannot see at which stage it is and if it is still working on the upgrade or if it failed. TITAN after one hour automatically considers an activation as failed, even when the activation was successful but slow.
I had to use the console and check the interfaces and packet statictics to be able to detect if SW upgrade was still running or if it failed and had to be restarted.
If you now think that I am the only one with a whole bunch of Titan problems, if you try to open a new support ticket you see this:
All other products, even similar ones like Concerto have one category whereas TITAN support requests are subdivided into 7 categories
All that happened when in vain tried to prepare for giving a TITAN course and my resume, also sent to Versa was:
Comments
Post a Comment