aws globalaccelerator suddenly got high ping
aws globalaccelerator make my ping In all servers Bad routing it is not noramll it alwyas connect me through eu first no matter what server i try to connect to i used to have 40 ping ON Bahrain server And 48 on EU server now i have high ping on both! IN EGYPT You can see the routing here
- Newest
- Most votes
- Most comments
The IP 151.148.8.93 in the traceroute before the problem started belongs to AWS. That means that at the time, there was an active peering connection between TE and AWS, probably at the Regional Data Hub in Giza but could alternatively have been over a private network interconnection between TE and AWS. Today's screenshot clearly shows that in addition to the Global Accelerator networks discussed earlier, even these local CloudFront servers in Cairo, whose sole purpose is to provide fast, low-latency service for users in Egypt, are now behind a physical network path 2,000 km longer than previously.
It's impossible to say with any certainty why the peering connection that clearly was there before is no longer active or working properly, but this latest traceroute does confirm that it isn't just specific AWS networks, like those used for Global Accelerator, that are affected, but even the local CloudFront servers do not have a direct path between TE and AWS.
Only TE could check what exactly happened to the peering connection that clearly was there before and how or if it could be restored, but if they aren't interested in pursuing the topic, switching to Vodafone is probably a pragmatic alternative.
It's true that nothing is blocked, but it hasn't been about blocking, because connections are working and just getting routed over an excessively long physical path between operators.
Telecom Egypt's network is AS8452, and AWS's is AS16509. Both are present at the Regional Data Hub that Telecom Egypt has in Cairo: https://www.peeringdb.com/fac/9616. Optimally, TE and AWS should be peering their networks over BGP at that location. This would allow traffic from TE to AWS to jump over to AWS's backbone network already in Giza, instead of first getting taken on a trip through Italy or Bahrain.
Currently, it's Telecom Egypt that is taking traffic towards your Global Accelerator IPs first through GTT's international network to Milan, Italy. No traffic is being blocked either by TE or AWS; traffic just isn't taking the short-distance shortcut route between TE and AWS located in Giza.
There doesn't seem to be a BGP looking glass available from TE, so I can't see what routes TE is receiving from AWS or transit providers. Since you have a contact at TE, I suggest you give them the URL https://www.peeringdb.com/fac/9616 that shows TE's own peering location in Giza and ask them if TE has a BGP peering connection with AS16509 up in Giza. If haven't got it, then that's the primary reason there is no quick way to get from TE to AWS's network. All communication between TE and AWS (not just Global Accelerator traffic) would be enormously more performant if they simply started peering in Giza. It's also possible that there should be a peering connection but that it is temporarily not working, which could be caused by a problem at TE, AWS, or some third party.
If there is a peering connection between TE and AWS active in Giza, then TE should check if they are receiving the routes 75.2.0.0/20 and/or 99.83.144.0/20 over that peering connection. Those are the routes under which your Global Accelerator IPs reside. If they are receiving the routes from AWS in Giza, they should simply check why the local routes at Giza are not getting preferred over the same routes apparently received by TE via GTT in Milan.
I DO NOT think i will be able to reach them and tell them that becuase that is their system
The way the public internet works is that operators/providers "offer" their own networks to each other. This is called "advertising" the networks. When TE is receiving the same route from AWS over multiple physical paths, it is 100% controlled by TE which one they choose to use. AWS or other providers cannot affect TE's choice. The technical people at TE know this full well, so I'm pretty sure they wouldn't mind checking their peering connections and route tables. No one on the outside can really do that, because it's TE's network.
i reached them and Guess what They can not do any thing i do not know what to do he even told me to use a vpn Is there is any 3d party option i can use to fix this
It isn't a data centre issue, it's a network issue. If you talked to someone with the title of datacentre manager, you'll need to get in touch with their NOC, the network operations centre and ask them the three questions I mentioned before: are they peering with AS16509 at RDH in Giza; are they receiving routes for 75.2.0.0/20 and 99.83.144.0/20 over that peering connection; and are those routes preferred over equivalent routes received over other physical paths, such as those of GTT in Italy. A datacentre manager probably wouldn't know what any of these terms even mean.
Yes he told me that he admiting that the only problem is that routing taking over 16 servers to reach the destination and he told me network team will conntact me tmrw but i already did it and what they all care about is speed if you are getting full internet speed then it means u fine i Think AWS is the one who should reach them They wont listean to any of their coustmers via less knowledge in networking I hope this get fix soon
TE wouldn't consider me as their customer, so I doubt they would have much interest in talking to me. The whole re:Post discussion might also be a bit too much for them to read. I think the best would be if you as TE's customer got these simple, short questions to their NOC over email, so that it gets ticketed in their system. The questions should be very easy for them to answer:
- Does TE have have an active BGP peering connection with AS16509 at the Regional Data Hub (RDH) in Giza or elsewhere in Egypt?
- Is TE receiving the routes 75.2.0.0/20 and 99.83.144.0/20 (or more specific ones) over that peering connection?
- Are those routes via RDH preferred over the equivalent (or more specific) routes received from elsewhere, such as via or from GTT in Milan, Italy, or other locations?
If an engineer from AWS support happens to notice this discussion, they might choose to check if a local, low-latency peering connection exists in Giza or elsewhere in Egypt between Telecom Egypt's AS8452 and AWS's AS16509. If there isn't one, that would clearly explain why there's no low-latency path. But if the peering connection is up, TE's NOC would have to check which peers they are receiving the routes from and why a physically distant one in Italy is preferred over the local one in Egypt.
I posted A post on GB On Facebook Community and they reached me And NOC should call me in 2-5 hours But i hope that he be educated enough and just does not want to end the call
I suggest you still insist with them that you get NOC's email address and send the questions including the specifics there. It's much easier to discuss when there are just a few simple questions for their technicians to answer.
Could you still try running traceroutes to repost.aws and docs.aws.amazon.com from Telecom Egypt's network?
Both the sites are in CloudFront, so if Telecom Egypt has a local BGP peering connection with the AWS edge location in Cairo, you should be seeing response times of around 10 ms. If that is so, then the Global Accelerator IPs either wouldn't be advertised from the Cairo edge location, which might suggest a change on AWS's side, or the routes specific to Global Accelerator wouldn't be preferred over more distant ones by TE, while routes for CloudFront would be.
https://www.peeringdb.com/fac/9616 shows that Telecom Egypt is hosting the peering location called Regional Data Hub (RDH) in Giza, so it should be very familar to their technical people. They should check:
- Whether they have a BGP peering connection up with AWS's network, AS16509, at that location.
- If they do, then check if they are receiving the routes
75.2.0.0/20and99.83.144.0/20over that peering connection. - If they are, check if those routes are preferred for those destinations by TE's AS, or if they are preferring the same routes received via GTT in Milan, Italy, or other locations.
If the answer to any of those questions is no, then that's almost certainly the source of the problem.
Im going To switch To Vodafone I lost the hope in TE
and this is the trace-route for Vodafone
is there a BGP connection between vodafone and aws
answered 2 years ago
It does look likely TE might not have a direct peering connection. The only things that seemed to point in that direction were that performance was better before and the fact that TE is running the public peering location RDH where both TE and AWS are present. I found the IPs of a few CloudFront servers located in Cairo. If you'd still like to test, it'd be interesting to see how traceroutes look like to some of these destinations via TE: 108.159.116.156, 108.159.117.19, 108.159.118.16, 108.159.120.30.
SURE 1 second and i will post it
so My isp TE will have the same routing i used to get before should i wait untill they finish their rdh
BTW someone Told me Before That Telecom Egypt is updating their RDH but im not sure if this true But we Said that before 2025 They will reach to 18 Submarine cable now i think we have like 15
i talked to them and they Told me They can not help But They will Make Datacenter Manger Call me in 2-5 Hours if there is more QA i can Ask To them Because this won't Happen Again XD
answered 2 years ago
Alright, that sounds promising. The NOC (network operations centre) at TE certainly knows about all the routing specifics, and they have direct access to their BGP sessions and route tables. If the questions I listed just arrive at TE's NOC, they should have no trouble at all answering them. Doing this type of troubleshooting is quite commonplace between operators, even if they seem unusual for regular users, so NOC will certainly know what to look for.
i hope so im waiting for their call
Global Accelerator is based on BGP anycasting, meaning advertising its IP networks towards the general internet from multiple physical locations on AWS's global network. This leaves it mostly up to your ISP's peering locations and potential route preferences which of the physical locations from which AWS is advertising the IPs ends up being the closest in a routing sense to your ISP and their potential transit providers.
In your case, Global Accelerator's static IPs for your service should be getting advertised from the me-south-1 region or possibly one of the more nearby edge locations, like the CloudFront edge locations in Cairo or Tel Aviv, and if they are, your ISP should have a reasonably direct physical route there. From your traceroutes, it seems your ISP is routing the anycast IP instead to a different region about 4,500-4,800 km from you (in terms of cable routes), so possibly one of the regions in Europe.
What round-trip times do you see if you ping a resource that is definitely physically in me-south-1, such as ec2.me-south-1.amazonaws.com?
it gives me 130 ms when i use telecom egypt isp when i use vodafone isp it gives me 40 the problem is there is no any teaming bettwen Telecom Egypt which is the main isp In egypt and Aws
answered 2 years ago
Would you be able to run this same traceroute via Vodafone? And could you run traceroutes over both operators to the both the Global Accelerator IPs?
i will try to reach them but i do not think this will happen but That problem is only while using aws servers when i traceroute any other servers it does not give me gtt Servers
answered 2 years ago
The hops in the traceroute output at GTT aren't servers, they are network routers, which just pass packets through. The issue is that TE's network is now configured to think that the shortest path to AWS is via Milan, while it should see that there is a shorter physical path available at Giza. If the connection is technically operational and just not being seen as a short-distance local route, TE's network operators may be able to fix it very quickly just by adjusting their configuration.
it gives me 130 ms when i use telecom egypt isp when i use vodafone isp it gives me 40
answered 2 years ago
answered 2 years ago
sure here is the traceroute
answered 2 years ago
answered 2 years ago
here is the traceroute
The problem is back again After it got fixed But cloudfront gives me 4 ping
The Problem is the aws Global accelerator is not getting rerouting From the Cloudfront As the others
answered 2 years ago
Relevant content
asked 2 years ago
when i ping to that ip i get 8 Ping and dircet connection in tracert
i just do not want to Switch but i have But do u think That it might just time till the problem can get fixed or this will for ever ?
151.148.8.93 responds with a round-trip time of 8 ms? That seems to indicate that the physical interconnection between TE and AWS still exists but that neither Global Accelerator nor CloudFront traffic are routed over it. It comes back to TE having to check what I asked earlier, but this does strongly suggest that the physical connection exists (probably at RDH) and that it's the BGP peering that is no longer active between TE and AWS.
as i told before Someone Told me That they are updating Their RDH at the moment but he was not sure But if i do not have a direct connection how do i still get 8 ms on that aws ip ?
should i just wait that it might get fix or i should switch instant ?