-
Notifications
You must be signed in to change notification settings - Fork 60
No clean up occurs #2
Comments
For this first version, yes. It's something we would like to add to the solution in a future version, but wanted to get customer feedback about what sort of clean-up workflow they would like (or expect) to have in place for the following reasons:
As a simple approach, a spoke VGW could be deleted, which will essentially leave the CSR with unused VRF connections. For some deployments, the extra configuration will be negligible, or could be cleaned up manually if desired. How would you like clean-up to be triggered? Is simply removing (or modifying) the VGW tag sufficient? |
Hi Steve, Thanks for getting back to me. I'd imagine clean up being triggered on tag removal, tag value change, or vgw removal would be fine. |
Agreed on tag removal or value change. |
ditto.... I would also like to see the clean-up triggered on the VGW tag removal. |
I created a fork for testing clean-up as well as the ability to configure spoke preferred paths (for active/standby path creation rather than active/active). Clean up will occur if the transit VPC tag does not exist, or if it has any other value rather than the configured value (by default it is transitvpc:spoke = true). Removing the tag or setting the value to "false", , or anything other than "true" will result in the VPN connections for that VGW getting deleted and the tunnel configuration removed from the CSRs. After I get some testing feedback, I'll merge the changes back into this repo. |
wow @stevemorad thank you very much! Long live the amazon customer obsession. |
Updated code has been committed that now provide cleaning up spoke VPCs if the spoke tag does not equal the expected tag value. Also, we added the ability to specify a preferred path if you want to configure the CSRs in an active/standby configuration rather than active/active for each spoke. |
When the transitvpc:spoke=true tag is removed from a VPC no clean up on the Cisco CSRs occurs.
Is this by design for some reason?
The text was updated successfully, but these errors were encountered: