MitchellGulledge / Meraki-vWAN

5 stars 4 forks source link

New Function App created - Getting 500 Internal Server Error #33

Closed Tony-FCTG closed 3 years ago

Tony-FCTG commented 3 years ago

We have created a second function app in a different region exactly the same way and set to a different Meraki Org Name. When we run the Code test we get a HTTP response code of 500 Internal Server Error.

In the log we also get the following: 2021-06-18T14:15:00Z [Verbose] Sending invocation id:ac3b1676-5b46-45d6-a9b8-770e2363730c 2021-06-18T14:15:00Z [Verbose] Posting invocation id:ac3b1676-5b46-45d6-a9b8-770e2363730c on workerId:c741ebe7-46c0-4815-9343-5a2112a5c276 2021-06-18T14:15:00Z [Error] Executed 'Functions.Meraki-VWAN-Automation' (Failed, Id=ac3b1676-5b46-45d6-a9b8-770e2363730c, Duration=20ms) 2021-06-18T14:15:00Z [Information] Executing 'Functions.Meraki-VWAN-Automation' (Reason='Timer fired at 2021-06-18T14:15:00.0054436+00:00', Id=ac3b1676-5b46-45d6-a9b8-770e2363730c)

MitchellGulledge commented 3 years ago

I will redeploy the function app and see if I am getting the same results, can you confirm what region you are deploying to?

MitchellGulledge commented 3 years ago

Yea looks like I am receiving the same error too: 2021-06-19T16:00:00Z [Error] Executed 'Functions.Meraki-VWAN-Automation' (Failed, Id=2be315ff-e8d4-452e-ac4f-9dc9354eff7d, Duration=21ms)

I am going to test now the updated version of Meraki API branch with a new field that allows you to add your own custom private subnets in case they are not in the Azure effective routes table:

https://github.com/MitchellGulledge/Meraki-vWAN/tree/v1API

Screen Shot 2021-06-19 at 9 04 35 AM

For the meraki_private_subnets field just provide a list of IPs with no quotes or brackets or anything. So for example: 1.1.1.1/30, 2.2.2.2/32.

I am not getting 500 internal server errors and everything appears to be working as expected. Please let me know if this solves your problem as well and I will work on getting this into master ASAP :)

Tony-FCTG commented 3 years ago

Thanks for looking at this. Do we need to create a new function app to test the new field? Issue we have is that our Azure environment has moved to a managed service and has to go through change process and unfortunately not straight forward.

Can you explain what the purpose of the new field is please and why it is different to how our original function app worked?

Tony-FCTG commented 3 years ago

I will redeploy the function app and see if I am getting the same results, can you confirm what region you are deploying to?

Our existing function app is in UK West. Our new function app is in UK South. It looks like both function apps have the same symptoms. Not sure for how long.

MitchellGulledge commented 3 years ago

Completely understood, the main difference is that we have upgraded the code in the function app to use version 1 of our Meraki API. (I suspect something may have happened to one of the v0 endpoints resulting in a 500 error) When I run it on the upgraded v1 version it works fine.

The new custom_vpn_prefixes field allows us to add routes to Meraki config for prefixes that are not in the effective routes table. (Azure secure hub for instance). This field is optional but if you want to add a supernet for something that azure casn reach but may not be in the effective routes table you can do that now as well.

MitchellGulledge commented 3 years ago

Actually, let me clean up one more thing before you redeploy. I want to make this a truly optional field

MitchellGulledge commented 3 years ago

https://documentation.meraki.com/MX/Deployment_Guides/Cisco_Meraki_MX_Branch_to_Azure_Virtual_WAN_Deployment_Guide Updated the documentation with explanation of the field and am field testing myself with no issues thus far. The new field is optional and for now we can just leave the default value in the new field :)

Tony-FCTG commented 3 years ago

Thanks for the update. Can you confirm that we will need to redeploy the function app? There is no way of updating an existing function app with the new feature?

Our existing function app in UK West does not have the 500 error but has started to log the same failure in the log. Fortunately we only have one vpn on this app which is still up and is used for backup access. Should this function app need to be redeployed as well?

MitchellGulledge commented 3 years ago

I have been trying to figure out how to modify an already deployed app but have not been able to figure it out unfortunately :( And ideally I threw in some conditional statements to prevent some further errors, what errors are you seeing in the logs currently?

Tony-FCTG commented 3 years ago

Thanks for trying. For the new UK South app it's less of an if we have to redeploy as it's not in production. Just a long process. :(

The issues will be with existing production apps. It looks like it started to error around middle of June.

Meraki UK West Insights Meraki UK West Count Meraki UK West Log

Looks like it doesn't like the subnet.

MitchellGulledge commented 3 years ago

After discussing with the team as well, the current proposal is to revert the commits made on the v1API branch where the original function was running from and create a new branch with the changes past the newly deployed app and have the documentation point to that button.

MitchellGulledge commented 3 years ago

Yea looks like when I changed the v1API version of the branch the previously deployed app was pulling this code for meraki_vpn_private_subnets which was not available when originally deploying the app. Causing python to throw a key error and now we have made a new branch v1API2 that the documentation now points to and reverted the changes for the v1API branch. So those key errors should have gone away :)

Tony-FCTG commented 3 years ago

Yea looks like when I changed the v1API version of the branch the previously deployed app was pulling this code for meraki_vpn_private_subnets which was not available when originally deploying the app. Causing python to throw a key error and now we have made a new branch v1API2 that the documentation now points to and reverted the changes for the v1API branch. So those key errors should have gone away :)

Great. Thanks for fixing. One less thing to worry about.

Tony-FCTG commented 3 years ago

I'm a bit confused by the different versions and deployments. I've just checked the new app we created in UK South and it isn't erroring anymore and everything is Success. Looks like the document we used to deploy still pointed to the old deployment code and after you resolved the v1API branch it fixed both our apps.

The new app will be used in production for all our remote sites. Are we ok to continue with this build? Would you suggest we rebuild with the newer option? Other than the subnet field are they any other major changes that we will need to take into consideration?

MitchellGulledge commented 3 years ago

Awesome to hear, so the documentation has been updated with the new version of the button. APIv2. The github button still points to the old branch. I am going to leave the old v1api branch so that it doesnt affect your deployed function app. The deploy button on here: https://documentation.meraki.com/MX/Deployment_Guides/Cisco_Meraki_MX_Branch_to_Azure_Virtual_WAN_Deployment_Guide references the new branch. (Apologies for the confusion I was very confused at this behavior as well)

MitchellGulledge commented 3 years ago

Tony can you confirm if you redeployed the new app and able to connect a site?

Tony-FCTG commented 3 years ago

Apologies. We haven't redeployed. Both apps we have deployed look to have resolved their issues after you fixed the v1API branch. Including the initial error that I reported. I don't have resources to be able to test the new app with vpn's yet though.

Unless you think we should redeploy with APIv2, it looks like our apps are functional.

MitchellGulledge commented 3 years ago

Awesome to hear! And no need, just know if you deploy a new function it will pull from that branch. I am going to close this case, thanks for working with me and your patience :)