Discovery - Endpoint on Latest version not working

[tonydean37]

Hi @DCMattyG,

I hope you had a nice weekend. I've been testing our deployment in prod today and noticed that there has been an update to the UI - I can now see our vwan, which is great :). Unfortauntely, I appear to have lost access to the Endpoint screen. When I click on it, it starts loading the table (I see the column titles, but then the screen goes white:

I've had a look at the network tab ias in above and can see that data is transferred in the multi section, which contains the list of endpoints though.

To ensure it wasn't the deployment, I have stopped and started our pre-prod environment and this is having the same issues, so I'm wondering if it is something in the config of the new version?

[DCMattyG]

Hey there @tonydean37, the most likely explanation for what you're seeing is that there is an unexpected piece of data in the "endpoints" that is causing the rendering of the grid to crash (likely because I'm not handling something properly).

Can you share what you are seeing in the "Console" tab of the Developer Tools (similar to the above) when the crash happens?

[tonydean37]

Cheers for taking a look. The two errors that are circled in red appeared when the page went white:

[DCMattyG]

Interesting....it looks like there may be a flaw in my logic for looking up subscription names and matching them to their respective resources.

I'm going to make a DEV build of IPAM for us to do a little testing and get to the bottom of this. I'll post instructions here once the build is ready so you can access it and test things out.

[DCMattyG]

Hey there @tonydean37, can you restart your App Service and test the UI again? You may need to close your browser & re-open it to avoid a cached version. Much appreciated buddy!

[tonydean37]

Morning @DCMattyG - I've been able to test on our pre-prod system and that is now working :). I've got a PIM request in for the other, so will let you know once tested, but sure it will have worked on that one too - will post again once tested. :)

[tonydean37]

I did notice another thing on the new version too, which is that in the Analysis - Peering visualizer the logo for the vWAN takes up most of the screen. It appears to be more of an issue in our prod environment, which is probably due to the amount of VNETs we have connected to it, but it makes it very hard to see them. I would prefer not to send a screenshot of this on here, but can send over email if required.

[DCMattyG]

Yes @tonydean37 please send a screenshot to me at [email protected]. If the sizing is off we can definitely work on getting that dialed in better for you!

[tonydean37]

Just managed to get access to our prod App, given it a reboot and the Endpoint screen is now working. Thanks for sorting so quickly!!

[tonydean37]

Hi @DCMattyG, sorry to bother you again, but we are seeing another issue on the new version of IPAM. When we create a new VNET using Azure DevOps, we run through the workflow as before, but we are getting this error message:

We can see that the VNET is created in Azure Portal and IPAM has it in its' database:

But when I try to assign the VNET to a block in the GUI, I cannot see it in there:

So I am wondering if this is causing a problem when we are trying to use a PUT request to add the VNET into the Block with our code?

Cheers,
MS

[tonydean37]

Just seen that if I delete the reservation then I can add the VNET to block, so we can flip our reserve and delete around to resolve that.

[DCMattyG]

Yes @tonydean37, one of the updates that came in the new code is preventing a Network from being associated to a Block which overlaps a Reservation that hasn't been fulfilled. This would prevent a scenario where user A creates a Reservation holding the CIDR 10.0.0.0/24, and then user B comes along and wants to associate an existing Virtual Network with the same CIDR to the same Block. If this were allowed and the Virtual Network were associated, once the Reservation was fulfilled you would have created overlapping IP space in a Block.

You are absolutely correct, the new flow would be to DELETE the Reservation just before the PUT to update the Virtual Networks for the Block. I do hope that's an acceptable workaround for you, but if it's not please let me know and we can work through a more preferred solution.

Have a great rest of your day!

[tonydean37]

Cheers for confirming that @DCMattyG. :) I think we are actually going to move to your in-built tagging solution and advise users to pick a single suitable address space/if a Vnet needs expanding then assess this manually, until there is in-built support for multiple address spaces per Vnet. Then we can re-assess our options from there. Have a great weekend!!

[tonydean37]

@DCMattyG - I think I may have come across another little issue, where if we are adding a VNET to IPAM using the tagging system, then deleting the VNET from the portal then we get this error, where the VNET does not get removed from the assigned VNET list:

If I complete a GET on the block then I see the status of that VNET as False.

I wondered how the deletion process is handled and if there is anything we need to change?

Sorry to keep messaging! :)

[DCMattyG]

Hi there @tonydean37, what you're seeing is by design. At this point, we've decided not to automatically removed anything from IPAM once it's removed from the Azure Portal, but to instead indicate that it was removed.

The reason behind this is, we use API calls to see what's currently in Azure and let's say for some period of time the API calls we use don't work or fail for some unknown reason. What we don't want to happen is that the IPAM tool believes (via API call) that a Virtual Network was removed, then accidentally remove that Virtual Network from the IPAM interface, but in fact the Virtual Network is still there, we just needed to wait a small amount of time for the API call to return the proper value.

So, three things....

1. For now, when deleting Virtual Network programmatically, you could add a step to remove it from IPAM as well.
2. When deleting networks from the Portal, at this time you will also need to remove that Virtual Network from the Block in IPAM as well.
3. We've talked about adding a setting in IPAM along the lines of "automatically delete Virtual Networks when they are no longer available in Azure" as a choice that users can make to allow a more "automated" process to happen.

Hope all of that clears things up!

[tonydean37]

Again really appreciate that - makes complete sense and we will look at our scripting to remove these programmatically, as this is our best practice that we currently don't do! :)

We can also look at running a tidy up job every 3 months or so to delete the old VNETs.