Virtual networks not discoverable

[cata008]

Describe the bug
Virtual networks are not discoverable on blocks if external networks with overlapping CIDRs are associated with the block.

To Reproduce
I was trying to associate a new set of virtual networks CIDRs to an existing block when I realized the vnets were not discoverable. While checking the external networks, I found out some of them were overlapping with the vnets that wouldn't show up.
As a test, I removed those external vnets, refreshed the IPAM page (not just the network association refresh button) and the virtual networks showed up this time.

Expected behavior
Have all vnets discoverable even if they are conflicting with other vnets/external networks CIDRs.

[DCMattyG]

Hi @cata008, what you are describing is by design. When you are looking at the list of Virtual Networks which are available to be associated to a Block, what is the purpose of seeing Virtual Networks which cannot be associated?

Can you help me understand more as to why adding these options to the list which cannot be selected (due to their overlap) would be useful?

[cata008]

Hi @DCMattyG. The issue that I have seen is:

• Cloud VNET with two address spaces
• Local VNET added to the external networks

While trying to associate the cloud vnet with an existing block, I would only see the vnet containing one address space (I later realized that was because the 2nd address space was overlapping with the local vnet, thus it was not displayed at all). Needless to say, the block association fails since there is an IP address range conflicting with the external networks.

Now, because of this current behavior, I couldn't initially determine what was the conflict here. Only when I went on the vnet Discovery page I realized the cloud vnet was actually using two address spaces, one of which was conflicting with an external network (having the error message return the actual conflicting network would've helped, but I already addressed this with you in a different discussion).

At the moment, from what I've seen, vnets with conflicting ranges are displayed. And when there's a conflict you get an error message. I don't see why we wouldn't keep the same consistent behavior when it comes to vnets and external networks.
IPAM is supposed to be the source of truth and if there are conflicting vnets, obviously not deployed with IPAM, we should detect that quickly and address it.

Cheers,
Catalin

[DCMattyG]

Ok @cata008, I think I have a much better understanding of what you're looking for here, so let me think through this with you...

You are correct that the view shows Virtual Networks which overlap, but this is because you could have a situation like this:

• You have two or more Virtual Networks which align to the Block's CIDR like:
  • TestNetwork01 -> 10.0.0.0/24 ☑
  • TestNetwork02 -> 10.0.0.0/24 ☐
• You could de-select TestNetwork01 and then select TestNetwork02 as both are viable options which can be associated with the target Block

Now when you define an External Network, you are effectively telling IPAM that this network lives outside of IPAM and any assignments of this address space will be handled elsewhere. So anything in the defined range won't ever really be "available" to associate to a Block and this is why Virtual Networks that overlap External Networks are hidden from view.

So I guess my question to you is this....

Can we solve the above with one of the following items:

1. A better view that can show everything that is attached to a given CIDR range (e.g. all reservations, external networks, virtual networks, etc.)
2. Improved error messages that help better identify overlap scenarios
3. A combination of 1 & 2

Additionally, I'm happy to schedule some time to discuss this with you 1:1 so we can make sure we're 100% aligned on what needs to be done to make this experience the best that it can possibly be. I'm more than happy to work around YOUR time zone. Please don't hesitate to drop me an email and I'll get something scheduled right away (we've exchanged emails before).

[cata008]

Hi @DCMattyG. Thanks for getting back on this.

Now when you define an External Network, you are effectively telling IPAM that this network lives outside of IPAM and any assignments of this address space will be handled elsewhere. So anything in the defined range won't ever really be "available" to associate to a Block and this is why Virtual Networks that overlap External Networks are hidden from view.

I partially agree with the statement above. Let me explain why. Whilst the assignment of external networks is handled elsewhere, I believe the direction, when using an IPAM tool, is not only to centralize the IP address spaces used across the organization, but also the decision making. In other words, the IPAM team should be responsible with the IP address space allocation no matter whether it is a vnet in Azure or a datacenter somewhere in the world, as long as they're all connected to the same infrastructure.

Now, in a conflicting scenario like the one previously described, the IPAM team should be aware of the overlapping vnet and external network and come with an action plan to remediate the conflict (e.g. reconfigure an on-prem datacenter with a different range, redeploy the Azure workloads etc). Nobody wants conflicts but unfortunately this does happen in some organizations especially after "centralizing" your networks in an Excel file and connecting new BUs that configured their local infrastructure with very creative CIDRs like 10.0.0.0/16.

Addressing this by providing more information in the error message is defintely something that would help. But nonetheless, even if you get a hint over the existing external network that conflicts with the vnet, you'd still have to check the vnet in the discovery page and see whether there might be some address space, hidden from view, that might cause this error.

If you still want to connect to further clarify things, 7-8am your time should be ok.

[DCMattyG]

Excellent points @cata008. I'll send out an invite for us to meet....I have a feeling I'll need to redesign the UI a bit and I'd love your input on what the new experience should look like.

Talk soon!