<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr">Since you mentioned AWS, have you tried AWS Global Accelerator? You get a pair of globally anycasted static IPs.</div><div dir="ltr"><a href="https://aws.amazon.com/global-accelerator/">https://aws.amazon.com/global-accelerator/</a></div><div dir="ltr"><br></div><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">Andras</div><div dir="ltr"><br><blockquote type="cite">On 28 Jul 2021, at 09:19, Daniel Corbe <daniel@corbe.net> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span></span><br><blockquote type="cite"><span>On Jul 27, 2021, at 17:20, Vimal <j.vimal@gmail.com> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Hi all, great replies. :) Let me clarify my initial question, and then respond one by one:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>My intention is to run a web-crawling service on a public cloud. This service is geographically distributed, and therefore will run in multiple regions around the world inside AWS... this means there will be multiple AWS VPCs, each with their own NAT gateway, and traffic destined to websites that we crawl will appear to come from this NAT gateway's IP address.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The reason I want a predictable IP is to communicate this IP to website owners so they can allow access from these IPs into their networks.  I chose IP as an example; it can also be a subnet, but what I don't want to provide is a list of 100 different IP addresses without any predictability.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I understand that this is not perfect, and would frankly not be my preferred approach to solve the problem.... but we've had requests of this nature from websites to create an allowlist of a limited number of predictable IPs so it doesn't trip their IDSs/other systems they might have... so we're trying to see how well it would work in practice.  For the moment, let's set aside the issue as to whether AWS will even let me advertise the same IP on all my VPC NAT gateways, and just look at whether it's technically feasible.  My gut feeling is that this wouldn't work well in practice, but I wanted to ask the experts here...</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Also, pointers on what the best practices for solving this issue are most welcome, so I can reference those who ask for IP addresses to this discussion and follow recommendations here.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Onto the responses:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>@owen@delong.com and @woody@pch.net athompson@merlin.mb.ca</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Because there’s no good/reliable way to get the replies back to the correct initiating host. </span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>When my clients make connections outbound to anycast addresses, the destination is more-or-less stable, and the replies come back to the client's unique IP, so anycast works in that direction.  The guarantees are not present in the reverse direction.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Yes, this makes sense as the destination can be anywhere around the world, and that routing is asymmetric as others mentioned.  However, if the destination service is "close" (in the routing metric sense) to the initiating host, anycast return IP ought to work well, right?  I understand this is a very important caveat and impractical to implement correctly in the real world.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>We use our IGP (IS-IS) for our Anycast services. We find it to be very</span><br></blockquote></blockquote><blockquote type="cite"><span>basic, and as such, very predictable.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This is interesting... I wonder whether Anycast will still have some failure modes and break TCP connections if routing (configuration) were to change?  I checked the PDF linked by Bill Woodcock... while the methodology is the same from 20y ago, would the data still be the same (order of magnitude)? :)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>https://www.pch.net/resources/Tutorials/anycast/Anycast-v10.pdf (p38)</span><br></blockquote><blockquote type="cite"><span>"Limited operational data shows underlying instability to be on</span><br></blockquote><blockquote type="cite"><span>the order of one flow per ten thousand per hour of duration."</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>@daniel@corbe.net, @matt@netfire.net, </span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Unless you’re twisting knobs, egress traffic should already exit your network at the closest possible egress point to its origin.  Is your intention to carry the traffic for longer than that?</span><br></blockquote></blockquote><blockquote type="cite"><span>No, but I hope my intention is more clear in this email.  It's to have a predictable egress IP to simplify firewall rules.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>thanks all!!</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>On Tue, Jul 27, 2021 at 12:25 PM Adam Thompson <athompson@merlin.mb.ca> wrote:</span><br></blockquote><blockquote type="cite"><span>Without any sarcasm: to make it harder to block.</span><br></blockquote><blockquote type="cite"><span>If, say, Google, always crawled your site from 8.8.1.2 (random made-up example) then you would see a not-insignificant number of hosts and networks null-routing that IP.  I have no idea why someone would do so, but I've seen it done many times.  Mostly by people who don't understand how un-special they are on the internet.  Also it would trigger IDS/IPS systems all over the place, having gobs and gobs of connections coming from a single IP.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>That's setting aside the technical issues involved; routing is often asymmetric, i.e. the return packet takes a different path than the inbound packet.  So it would, as Owen implied, be nearly impossible to ensure the reply packets got back to the correct TCP stack.  As an example, I'm multi-homed and use path-prepending, so if a packet claiming to be from 8.8.8.8 arrived on one of my commercial links, I would send the reply out the cheapest link, which in my case is a flat-rate R&E network (that has a path to Google), thus ensuring the reply does not get to the originating anycast node.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>When my clients make connections outbound to anycast addresses, the destination is more-or-less stable, and the replies come back to the client's unique IP, so anycast works in that direction.  The guarantees are not present in the reverse direction.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The logical extremity of this is that it would be nearly impossible for two anycast addresses to establish a TCP connection to each other.  (In general.  There will be lots of local cases where it does happen to work, by coincidence.)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>You'll find that even anycast nodes do not make connections outbound using their anycast address, pretty much for these reasons.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>-Adam</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Adam Thompson</span><br></blockquote><blockquote type="cite"><span>Consultant, Infrastructure Services</span><br></blockquote><blockquote type="cite"><span><Outlook-1593169877.png></span><br></blockquote><blockquote type="cite"><span>100 - 135 Innovation Drive</span><br></blockquote><blockquote type="cite"><span>Winnipeg, MB, R3T 6A8</span><br></blockquote><blockquote type="cite"><span>(204) 977-6824 or 1-800-430-6404 (MB only)</span><br></blockquote><blockquote type="cite"><span>athompson@merlin.mb.ca</span><br></blockquote><blockquote type="cite"><span>www.merlin.mb.ca</span><br></blockquote><blockquote type="cite"><span>From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> on behalf of Vimal <j.vimal@gmail.com></span><br></blockquote><blockquote type="cite"><span>Sent: July 27, 2021 12:54</span><br></blockquote><blockquote type="cite"><span>To: nanog@nanog.org <nanog@nanog.org></span><br></blockquote><blockquote type="cite"><span>Subject: Anycast but for egress</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>(Unsure if this is the right forum to ask this question, but here goes:)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>From what I understand, IP Anycast can be used to steer traffic into a server that's close to the client.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I am curious if anyone here has/encountered a setup where they use anycast IP on their gateways... to have a predictable egress IP for their traffic, regardless of where they are located?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>For example, a search engine crawler could in principle have the same IP advertised all over the world, but it looks like they don't...  I wonder why?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>-- </span><br></blockquote><blockquote type="cite"><span>Vimal</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>-- </span><br></blockquote><blockquote type="cite"><span>Vimal</span><br></blockquote><span></span><br><span>If I were in your shoes, I’d pick a VPS provider that assigns external, globally routable IPs to their customers.  Linode, Vultr, Digital Ocean, etc.  </span><br><span></span><br><span>You may be able to do something on AWS with Elastic IPs but I don’t know enough about Amazon’s infrastructure to give you a qualified answer.  </span><br><span></span><br><span></span><br><span></span><br></div></blockquote></body></html>