Seems like the destination is in Hetzner, they could also raise it with
Twelve99 or prepend routes to use an alternate path.
On Fri, Jan 26, 2024 at 7:46 PM Phil Lavin via Outages
wrote:
> Thanks, ytti. I have raised a case with AWS but I expect it to be as
> unproductive as usual. In this type
The correct address for operational issues is peering...@amazon.com .
Have you tried checking http://ec2-reachability.amazonaws.com/ to see if
you see green ticks everywhere, specifically the prefixes covering the IP
you're having trouble accessing? If so, the endpoint is probably blocking
your re
https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-ipv6-only-subnets-and-ec2-instances/
> On 1 Apr 2022, at 06:44, Owen DeLong via NANOG wrote:
>
> In short:
> Amazon
> Alibaba
> Google Cloud
>
> And a few other laggards that are key destinations that a
Hi all,
We (Amazon) have made improvements over the last few years to significantly
improve our NOC and Peering response times, as well as the time it takes to
set up a peering session, whether over IX or direct PNI/SFI.
If you don't get a response from the respective Peering mailing address
list
Since you mentioned AWS, have you tried AWS Global Accelerator? You get a pair
of globally anycasted static IPs.
https://aws.amazon.com/global-accelerator/
Another alternative is to request a contiguous IP range of EIPs (/28 or /24
etc) that you can use for your EC2 instances or VPC resources.
AWS or S3 is not the only service where you will see a single IP returned
for a DNS query, www.microsoft.com and www.apple.com (via Akamai) do the
same - see further below.
When you look up .s3.amazonaws.com you get back an answer that
directs you to the correct region where the S3 bucket is locat
Could have been but that's why I tested with a lower MTU sending back ICMP
packet too big to prove that the packet sizes from the server decrease as a
result.
Andras
> On 21 Feb 2021, at 08:27, William Herrin wrote:
>
> On Fri, Feb 19, 2021 at 4:18 PM Andras Toth wrote:
>
Hey Michael,
Given the fact that the TCP 3-way handshake is established, sounds like
some Path MTU blackholing happening. Due to it happening during TLS
handshake it's likely from the server towards you.
2a04:4e42::272 and 2a04:4e42:2f::272 belong to Fastly (AS54113) as they
host a share of image
Hi Mehmet,
A traceroute would be particularly useful.
Have you tried accessing http://ec2-reachability.amazonaws.com/ to verify if
the green icons load? If not, any particular region that's broken? Could you
collect a traceroute towards some of the working and non-working IPs listed
there?
An
Hey Francois,
Including at least an ASN in the peering request usually helps to expedite the
process :)
Best regards,
Andras
> On 27 Jun 2019, at 19:01, Darin Steffl wrote:
>
> It took us over a year before peering was established. Just keep trying until
> they reply.
>
>> On Thu, Jun 27, 2
Traceroute on Linux/Unix boxes is generally using UDP by default. Try
using ICMP, by adding the -I (capital i) option to traceroute:
traceroute -I 52.74.124.136
On Fri, Aug 7, 2015 at 2:05 AM, Glen Kent wrote:
> I find this bizzare because even when the traceroute doesnt work, I am
> actually a
have the same 10-NET addresses"
Andras
On Sun, May 31, 2015 at 7:18 PM, Matt Palmer wrote:
> On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote:
>> Perhaps if that energy which was spent on raging, instead was spent on
>> a Google search, then all those words would've b
Perhaps if that energy which was spent on raging, instead was spent on
a Google search, then all those words would've been unnecessary.
As it turns out that IPv6 is already available on ELBs since 2011:
https://aws.amazon.com/blogs/aws/elastic-load-balancing-ipv6-zone-apex-support-additional-secur
13 matches
Mail list logo
