Comments (5)
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.
from ipam.
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!
from ipam.
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?
from ipam.
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
from ipam.
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:
- A better view that can show everything that is attached to a given CIDR range (e.g. all reservations, external networks, virtual networks, etc.)
- Improved error messages that help better identify overlap scenarios
- 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).
from ipam.
Related Issues (20)
- deploy.ps1 error while deploying appServiceModule HOT 2
- IP Planner Tool does not display the available ranges /28 - /30 correctly HOT 9
- Export data?
- vNets in Block becoming unassociated and duplicated HOT 5
- Running AppOnly with AsFunction returns error HOT 3
- Errors on Engine pods after setting up ipam on AKS HOT 9
- Releases and versioning HOT 1
- Add next available vNet CIDR to GUI HOT 5
- Engine 502 and seems not working HOT 6
- Provide some option to limit which principals can create reservations HOT 1
- Implement using Private endpoint HOT 4
- Reservations for External networks HOT 5
- Operation returned an invalid status code 'Forbidden HOT 4
- Support setting up IPAM at management groups other than the tenant root HOT 2
- Forward Slash in block names HOT 4
- block reservation with 2 vnets HOT 7
- Block filter in VNETS page is case sensitive HOT 3
- Access denied to "Configure" page HOT 5
- Welcome to Azure IPAM Discussions! HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ipam.