is there any IPAM feature in the future on how can I implement IPAM for Meraki networks?, some SDWAN networks are pretty large and I want to read some experiences / ideas around this feature.
I might think this is a "Make a Wish" post, but the section "Remote VPN participants" inside Site-to-Site VPN is a good start but it only implies SDWAN networks.
I actually though a lot about this but as we all know, it'll take a lot of time to develop a solution as an IPAM feature. Or is out there any solution I don't actually know that can interact with Meraki API to acoomplish this task?
This could evolve as how IPAM solutions would integrate with Meraki. But for today I got a great API call:
this would give me the details related to the config, this is one step.
I'll try to undesrtand what's needed to develop an IPAM solution arround API or SNMPing the ARP at least. Let's see how it goes though.
Also tried to compare prices for this solutions and those are quite expensive. I didn't know that until now.
I would also go the separate push/pull API based solution.
Software than plans your address space on it's own and then reads your current org for subnets and push out own addresses per network.
A bit like you have DNA-center carving out subnets for each site in a design section and then creating networks with the IP addresses.
I also don't particularly like the current Meraki template implementation where they choose random subnets for template networks if you have multiple VLAN's.
For larger networks I allocate a supernet and let a template sub-allocate the address space itself. You can search the route table of a hub to check for any specifically allocated subnet.
For other things, I just use Excel ...
Hey @PhilipDAth that was what I was referring to.
If you have multiple VLAN's per template network the carving of subnets will be random.
For example if you have 10.0.0.0/8 as an IP block to carve from and you want /24's for each VLAN on a template network one branch could get 10.5.15.0/24 and 10.66.22.0/24 with the Meraki implementation. That's just horrible IMHO. I'd rather have that one branch would get 10.5.15.0/24 for VLAN x and 10.5.16.0/24 for VLAN y.
It would have been better that you could choose:
1) your ip block to carve from
2) an ip block per site
3) an offset for each VLAN that applies to all template branches.
I guess one could script that 🙂