Kadaster werkt niet op verbeterjehuis.nl

Datasets BAG
#21

Hi Stefan,

We hebben de verbose optie uitgeprobeerd. Onze (Engelstalige) developer heeft de volgende terugkoppeling:

As mentioned above with the tcpping (which differs from a simple ping, trying to actually establish a tcp connection), the request is failing with a timeout.
This issue only presents itself when trying it from the IP’s mentioned above, and it’s random in nature, sometimes working.
Also, port 80 shows no issues connecting, only 443, on these IP’s (a similarly configured environment doesn’t have the issue)
As requested, here is the result of the curl request:
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:–:-- --:–:-- --:–:-- 0* Trying 145.77.103.22:443…
0 0 0 0 0 0 0 0 --:–:-- 0:00:20 --:–:-- 0* connect to 145.77.103.22 port 443 failed: Timed out

  • Failed to connect to bag.basisregistraties.overheid.nl port 443: Timed out
    Are you sure you don’t enforce any kind of rate limiting per IP?

Regarding the .NET version:
We are using the version you are referencing (4.7.2). Also, we feel that wouldn’t explain why sometimes it works and sometimes it doesn’t. Do you agree?

#22

OK, dus dan is het een zaak van “zoek de verschillen”.

Nee. Zoiets is nooit random, alleen zien jullie de root cause niet, en dus lijkt het random. Maar er is uiteraard wel een root cause en dat die echt random is geloof ik niet. Zoals ik zei: “zoek de verschillen”.

Nou ja, ik werk niet voor Kadaster, dus ik niet nee… :wink::grin:
Maar even serieus: als er ergens aan afknijpen word gedaan, is dat natuurlijk eenvoudig te checken door simpelweg elke minuut een tiental requests te doen en die qua tijd te loggen. Dan zie je vanzelf wanneer het optreed, en dat is misschien uberhaupt niet zo’n gek idee om dat eens 24 uur te laten draaien: misschien valt er dan een patroon op.
Maar afknijpen vereist dat je contact krijgt met de server. Dus dat kan het nooit geweest zijn, want het contact is er nooit geweest - en dus weet de server niet eens dat je boven je quota zou zitten. Nog even afgezien van het onderzoek dat het Kadaster heeft gedaan waaruit de genoemde ip-adressen niet eens naar voren komen. En bovendien zijn er nogal veel anderen die geen enkel probleem hebben, dus er moet ergens wel iets aan jullie kant zitten. Zoveel is mij nu wel duielijk, maar ik vrees dat ik er verder niks zinnigs meer over kan zeggen zonder jullie environment te kennen.

#23

Bovenstaande klopt idd. We hebben de exacte call die jullie doen zelf ook geprobeerd en krijgen daar zonder problemen een reactie op. We vermoeden echter dat jullie applicatie niet een curl doet maar de aanroep op een andere manier. Om te kunnen helpen zullen we exact moeten weten wat jullie applicatie naar buiten stuurt, en dan de stappen die er gezet worden. Dat moet dan echt vanaf de server waar jullie applicatie op draait, omdat ons vermoeden nog steeds is dat het probleem ergens aan jullie kant zit. En aangezien de call die jullie doen correct is en bij ons zonder problemen werkt, zit het naar verwachting ergens op het netwerkniveau aan jullie kant waarbij jullie aanroep niet naar ons toe gaat.

#24

Aangezien de verbinding vanuit Azure wordt gelegd, is dit artikel mogelijk behulpzaam: Troubleshooting intermittent outbound connection errors in Azure App Service - Azure App Service | Microsoft Learn

Je kan dus tegen de limiet van uitgaande verbindingen vanuit Azure aanlopen. In het artikel staat dat dit te monitoren is in Azure.

1 like
#25

Heel erg bedankt voor jullie reacties en suggesties!
We gaan met jullie opmerkingen en suggesties aan de slag en zullen via dit forum laten weten wat onze bevindingen zijn.

Groeten
Arnout

2 likes
#26

Mijn collega van Devops heeft onderzoek gedaan nav jullie suggesties.

Zijn bevindingen zijn als volgt:

image
image1153×1008 124 KB

En hij voegde hieraan toe:

So this excludes any outbound intermittent connection issues or SNAT issues as suggested here.

At this point in the investigation I see only two possibilities:

  1. being blocked on Kadaster side
  2. some weird network related configuration in the web app it self (webconfig.xml) which is set on prod, but not on test.

We will investigate this further, but if you have any more suggestions that might help, feel free to share them with us!

#27

Ik zal het in het Engels typen:

I’m not convinced that the test excludes the Azure outbound connection limit as a cause.

I assume on PROD the application calls the URL https://bag.basisregistraties.overheid.nl regularly and does not call https://jsonplaceholder.typicode.com which does work in the test.

The SNAT limit means that per IP adress and port combination only 128 outbound connections can be made and after closing a ‘SNAT port’ this becomes available again after 4 minutes. When not using a HTTP connection pool and calling the API often, these 128 ports can be exhausted quickly. Because the jsonplaceholder.typicode.com URL is not called by the application regularly and this is another IP adress and port, the SNAT limit may be reached for the BAG service but not for this service.

Suggestions:

  • Do a test to another API such as jsonplaceholder.typicode.com, but make more than 128 connections in a few minutes using a loop and see whether it fails after that to really exclude SNAT port exhaustion.
  • Log when API calls succeed in addition to failures, so you can tell if they always fails or only sometimes (such as when making more than 128 outbound connections during a few minutes).
  • Assign a public IP to the VM. This provides 64k outbound ports and no 128 host/port SNAT limit.
  • Use a HTTP connection pool
  • Look at the SNAT port usage and allocation, although I’m not sure if this can easily show whether the 128 ports to a specific IP/port combination are exhausted.
  • File an Azure support incident with Azure support.
#28

We zijn ermee aan de slag gegaan, de bevindingen zijn als volgt:

Hi everyone,

I’ve executed the following script from kudo (mili-energielabel-prod). 200 requests with 300ms delay from each. I got 200 out of 200 correct responses from the sandbox API:

for ($c =1; $c -le 200; $c++) {
Invoke-WebRequest -Method Get -Uri “https://jsonplaceholder.typicode.com/posts/1” -Headers $headers -UseBasicParsing Start-
Sleep -Milliseconds 300
}

I believe that this confirms it is not a networking issue on the side of Azure.
We also checked this with Microsoft earlier, in November 2020, when we did similar investigation. A ticket was created to Microsoft and they have also concluded that the issue is not on Azure’s side.

I stay at my previous assessment that the problem is most likely with Kadaster. The only thing which I can think of as a possible test/solution is to actually change the IP addresses of the Energielabel web application and then see if the problem persists.

This will be the next step we will take.

Groeten
Arnout

PS: ik lees dat de antwoordlimiet voor ons in dit topic is bereikt, dus ik kan slechts bestaande antwoorden editen vanaf nu.

#29

Die test maakt inderdaad duidelijk dat het niet aan de SNAT limiet ligt. Het gebruiken van een ander IP adres lijkt me een goed plan, verder geen ideeen, raar probleem.

#30

Na jullie vorige melding hebben wij uitgebreid onderzoek laten zien of er ergens aan onze kant of onze infrastructuurprovider een blokkade aanwezig is die jullie IP’s blokkeert. Uit dat onderzoek is niets naar boven gekomen wat het verkeer kan blokkeren. Ook viel het ons toen op dat we jullie IP adres in onze logging niet voorbij zien komen, oftewel het verkeer vanuit jullie site komt niet bij ons aan. Op dit moment zou ik niet weten wat wij nog kunnen onderzoeken om te achterhalen waar het probleem dat jullie aangeven vandaan komt. Wat het extra bijzonder maakt is dat jullie de enige zijn die dit probleem rapporteren, we hebben nogal wat klanten die van de BAG API gebruik maken en daar hebben we dit probleem nog nooit gehoord of gezien.

Weten jullie nog wat jullie gedaan hebben toen het de vorige keer opgelost was? Wij hebben toen niets aangepast (en ook de 1e keer niet).