Welcome to Catch Up

cancel
Showing results for 
Search instead for 
Did you mean: 
Need help?

CU+ http 504 error

Red Carpet

Re: CU+ http 504 error


@andrewgerm wrote:

Thanks for the CF link! Had no idea MC were hosting this way.

Got some reading ahead of me Smiley Happy


 

Some more information on CF:

Posted On: Jul 12, 2018 Details: Amazon CloudFront announces four new Edge locations: Cape Town, South Africa; Denver, Colorado; Frankfurt, Germany; and Taipei, Taiwan. Cape Town is our second Edge location in South Africa, the first being Johannesburg, launched in June 2018. Customers delivering content in South Africa are already seeing up to 75% latency improvements on average. The addition of a new Edge location in Denver, Colorado doubles our capacity in Denver. The new Edge location in Frankfurt is the seventh in the city, while the new Edge location in Taipei is the third in the city. The addition of these locations continues to expand CloudFront's global footprint and capacity, allowing us to deliver better performance and scale for our customers.
Posted On: xx Jun 2018 The Edge location in Johannesburg is Amazon CloudFront’s first PoP on the African continent.Amazon CloudFront’s expansion into South Africa further improves availability and performance of content delivery to viewers in the region. We expect that customers who use Amazon CloudFront to reach viewers in South Africa will see performance improvements of as much as 75% from reductions in latency for their content.

 

 

 

Octo LNB; 2 by 2x4 MS; 2 by ES 5-2; Dedicated PSU for LNB, ES's, MS's; HD PVR 4P x 2; Explora 1; DSD 660; FSM
Red Carpet

Re: CU+ http 504 error

2ms is impossible on any network in SA so that reading you got is just plain wrong.

And yes the issue is the cdn setup/configuration between MC and CF. Not sure who has screwed up but I have my suspicions ......

Here are my ping results for that IP address

Microsoft Windows [Version 10.0.17134.228]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\xxxxxxxxxxxxxxxxx>tracert 143.204.165.142

Tracing route to server-143-204-165-142.dfw3.r.cloudfront.net [143.204.165.142]
over a maximum of 30 hops:

  1     1 ms     1 ms    <1 ms  
2 * * * Request timed out. 3 * 26 ms 27 ms 105-187-232-69.telkomsa.net [105.187.232.69] 4 29 ms 28 ms 26 ms 105.224.0.154 5 27 ms 27 ms 26 ms ipc-aggr-2.north.telkomsa.net [105.228.0.13] 6 27 ms 27 ms 27 ms rrba-ip-hsll-2-wan.telkom-ipnet.co.za [165.165.216.217] 7 211 ms 212 ms 211 ms 196.43.9.106 8 * 209 ms 210 ms te0-7-0-11.agr21.fra06.atlas.cogentco.com [149.11.20.65] 9 210 ms 210 ms 210 ms be2844.rcr22.fra06.atlas.cogentco.com [130.117.0.29] 10 209 ms 209 ms 209 ms be2846.ccr42.fra03.atlas.cogentco.com [154.54.37.29] 11 210 ms 209 ms 209 ms be2814.ccr42.ams03.atlas.cogentco.com [130.117.0.141] 12 301 ms 301 ms 301 ms be12266.ccr42.par01.atlas.cogentco.com [154.54.56.174] 13 301 ms 302 ms 301 ms be12489.ccr42.lon13.atlas.cogentco.com [154.54.57.69] 14 301 ms 301 ms 301 ms be2490.ccr42.jfk02.atlas.cogentco.com [154.54.42.85] 15 302 ms 302 ms 302 ms be2916.ccr22.alb02.atlas.cogentco.com [154.54.41.61] 16 301 ms 302 ms 301 ms be2879.ccr22.cle04.atlas.cogentco.com [154.54.29.173] 17 302 ms 303 ms 302 ms be2718.ccr42.ord01.atlas.cogentco.com [154.54.7.129] 18 313 ms 313 ms 314 ms be2832.ccr22.mci01.atlas.cogentco.com [154.54.44.169] 19 323 ms 323 ms 323 ms be2433.ccr32.dfw01.atlas.cogentco.com [154.54.3.213] 20 325 ms 324 ms 326 ms be2764.ccr41.dfw03.atlas.cogentco.com [154.54.47.214] 21 339 ms 337 ms 339 ms 38.122.38.242 22 358 ms 359 ms 362 ms 54.239.105.123 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 346 ms 348 ms 347 ms server-143-204-165-142.dfw3.r.cloudfront.net [143.204.165.142] Trace complete. C: xxxxxxxxxxxxxxxxxxx>ping 143.204.165.142 Pinging 143.204.165.142 with 32 bytes of data: Reply from 143.204.165.142: bytes=32 time=347ms TTL=237 Reply from 143.204.165.142: bytes=32 time=347ms TTL=237 Reply from 143.204.165.142: bytes=32 time=347ms TTL=237 Reply from 143.204.165.142: bytes=32 time=347ms TTL=237 Ping statistics for 143.204.165.142: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 347ms, Maximum = 347ms, Average = 347ms C:\
Octo LNB; 2 by 2x4 MS; 2 by ES 5-2; Dedicated PSU for LNB, ES's, MS's; HD PVR 4P x 2; Explora 1; DSD 660; FSM
Highlighted
Anime

Re: CU+ http 504 error


@GeoffD wrote:

No not really.  It makes sense that access to CF would be available in all the major date centres in the country. It is what happens after that where there may be network issues, inside CF and MC. ...... And we are blind to that because all we "see" is the CF front, back and side doors ....

Incidently, if you have a look at the final IP addresses, for CF, you will notice a reference to JNB50, CPT50 etc.

One of the traces to the Explora cdn resolved out as 143.204.165.142, which ended up overseas somewhere. Any stream via that door would timeout for certain.


Er no. That IP is a cloudfront IP. And it isn't timing out, in fact it has great latency for me at 2ms.  It is a local SA gateway (there's no possible way for a ping to travel to US and back in 2ms).

 

The tracert that we can see is only the route to the distributed server. We can't see what is happening behind the scenes, i.e how the content is being distributed within the cdn. And that is likely where the issue is. Something is misconfigured.

Re: CU+ http 504 error

Thanks for the CF link! Had no idea MC were hosting this way.

Got some reading ahead of me Smiley Happy

Red Carpet

Re: CU+ http 504 error


@andrewgerm wrote:

For what it's worth.

Just did a few tracerts on the CDN.

Out of the three, all had CPT in the hostname.

Every one I did had a timeout on the three hops just before the last hop

 

I got the CDN resolved to IPs 143.204.65.142 and 143.204.65.110

Doing a whois lookup on those, both comeback in WA, USA, as owned by Amazon.

 

A ping to each sits at 25ms, same for each hop that didn't timeout.

 

I have swapped my DNS back to my own ISP's servers (MWeb, CPT)


The fact that a hop times out does not mean there is a problem on that device or hop. It just means that ping and tracert requests are blocked because the device is set to block these requests. It is bad configuration practice, because it prevents proper fault diagnosis, BUT is very common amongst IT people and companies for various rerasons which are not valid anymore in today's networks and infrastructure.  I have a document that details the whole issue. If I find it I will post the link.

 

Octo LNB; 2 by 2x4 MS; 2 by ES 5-2; Dedicated PSU for LNB, ES's, MS's; HD PVR 4P x 2; Explora 1; DSD 660; FSM
Red Carpet

Re: CU+ http 504 error

Ja good idea. It is not your DNS settings that are screwing things up, it is the way in which CF has been setup, either by MC or by CF or both.

CF is an Amazon company/division.  Using whois does not really help with the physical location of a router/server etc, it will generllay quote the details of who registered the IP address and not the physical location of the device. That is a more complicated process not something to debate here.

But for those interested in how CF is supposed to work have a look at this link.

Then we can debate where all of this is breaking down, what aspect, settings/configuration is broken, and what will happen when the designated servers that are supposed to deliver the request become overloaded. This is just another cdn service. MC used to use Optinet now it is CF.  They still don't know how to setup and deploy cdn!

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html

Octo LNB; 2 by 2x4 MS; 2 by ES 5-2; Dedicated PSU for LNB, ES's, MS's; HD PVR 4P x 2; Explora 1; DSD 660; FSM

Re: CU+ http 504 error

For what it's worth.

Just did a few tracerts on the CDN.

Out of the three, all had CPT in the hostname.

Every one I did had a timeout on the three hops just before the last hop

 

I got the CDN resolved to IPs 143.204.65.142 and 143.204.65.110

Doing a whois lookup on those, both comeback in WA, USA, as owned by Amazon.

 

A ping to each sits at 25ms, same for each hop that didn't timeout.

 

I have swapped my DNS back to my own ISP's servers (MWeb, CPT)

Red Carpet

Re: CU+ http 504 error

Yes correct.  So if this is the path the stream was attempting to use at that time, it means the MC addresses are not resolving correctly, which is the exact same error that was present 5 years ago!

Octo LNB; 2 by 2x4 MS; 2 by ES 5-2; Dedicated PSU for LNB, ES's, MS's; HD PVR 4P x 2; Explora 1; DSD 660; FSM
BoxOffice

Re: CU+ http 504 error


@GeoffD wrote:

No not really.  It makes sense that access to CF would be available in all the major date centres in the country. It is what happens after that where there may be network issues, inside CF and MC. ...... And we are blind to that because all we "see" is the CF front, back and side doors ....

Incidently, if you have a look at the final IP addresses, for CF, you will notice a reference to JNB50, CPT50 etc.

One of the traces to the Explora cdn resolved out as 143.204.165.142, which ended up overseas somewhere. Any stream via that door would timeout for certain.

 That IPis for a SP in America


 

Explora 2A (primary) Explora 3A Secondary SLNB LMX501  Samsung S9   Samsung Tab
Red Carpet

Re: CU+ http 504 error

No not really.  It makes sense that access to CF would be available in all the major date centres in the country. It is what happens after that where there may be network issues, inside CF and MC. ...... And we are blind to that because all we "see" is the CF front, back and side doors ....

Incidently, if you have a look at the final IP addresses, for CF, you will notice a reference to JNB50, CPT50 etc.

One of the traces to the Explora cdn resolved out as 143.204.165.142, which ended up overseas somewhere. Any stream via that door would timeout for certain.

Octo LNB; 2 by 2x4 MS; 2 by ES 5-2; Dedicated PSU for LNB, ES's, MS's; HD PVR 4P x 2; Explora 1; DSD 660; FSM