Automating Post-Quantum IPsec on Cisco Routers – IPsec Series, Part 12

I know, I know… I said I was done with the IPsec series, BUT what would this series say about me if I did notautomateeverything??

In the last few blog posts we reviewed the CLI story: classical baseline, PPK, ML-KEM hybrid, ML-DSA certificates, the atomic cutover. That’s how you LEARN a platform. But that is not how you RUN a fabric.

And if you’ve been hanging aroundDevNetfor a while, you already know the next move. That was the point the whole time: enable the community on programmability so you can stop typing at boxes and start driving them through APIs. YANG, NETCONF, RESTCONF, Ansible: years of that work. API-driven automation was one of the main goals. Let’s now use those habits to configure Post-quantum IPsec!

Type the same IKEv2 profile on three boxes, change two addresses, and you’ll get two routers agreeing and one that doesn’t. You’ll find out a week later. The post-quantum posture is adecision: ML-KEM-768, optional or required, ML-DSA-65. You want to state it once, push it, andprovethe live SA actually used it. DONE.

This post is that layer. Same lab, same RFCs, same two pillars. The interface is Ansible over NETCONF instead of three consoles.

All docs and Ansible playbooks are availablein my GitHubfor your own testing, but if you don’t have three routers in your lab you can still follow. You won’t be typing along unless you’ve got the boxes. What you’ll see is the playbooks we ran, the XML that actually landed, and the show output that came back.