I've labelled this as converting mesh to star; that being said, our specific issue is that we are adding in a local DR gateway, don't want to lose secrets, and don't want to mesh the two at our end. Historically for this customer, these kinds of point to point VPNs were set up as mesh, which was probably never ideal.
SO.... there is no official way to convert from a mesh to a star. This is a shame. A mesh is very obviously a subset of star, with only centre gateways in use, so it should be possible to upgrade.
A little scripting testing shows that this is possible, and in fact the key differentiator is the "featuresPreset" field on the generic-bject, which seems to allow fairly flexible conversion. In fact, I've basically solved the problem. I'm going to show you the code, and many arms will go up in horror:
#!/bin/bash
mc()
{
mgmt_cli -s SID -f json $*
}
mgmt_cli -m 127.0.0.1 login |tee SID
COMM="$1"
COMMUID=$(mc show vpn-communities-meshed | jq -r --arg NAME "${COMM}" '."objects"[] | select(."name" == $NAME).uid')
#mc show generic-object uid ${COMMUID}
mc set generic-object uid ${COMMUID} \
featuresPreset "e2e58d83-37af-3659-ae43-072580b4ea5d" \
icon VPNCommunities/Star \
topology STAR
mc logout
rm SID
This actually works much better than I was expecting. I was expecting danger, but I observe that updating featuresPreset to match normally-created star communities works perfectly. Object type fields are automatically adjusted to reflect the new object type. This gives me confidence that this is legitimate. And happily, gateways from the mesh are now listed perfectly as centre gateways in the updated object.
So... other than general latent fear, does anyone know of anything that could go wrong? Any changes that don't cascade correctly from this, or other corruption?
Thank you!
