> On Jul 27, 2021, at 10:54 AM, Vimal <j.vi...@gmail.com> wrote: > > (Unsure if this is the right forum to ask this question
Sure, why not… There isn’t anywhere more appropriate, really. > From what I understand, IP Anycast can be used to steer traffic into a server > that's close to the client. That’s the net effect, as it’s normally used. But anycast is really very simple, and has no concept of client/server… An IP address is assigned to multiple devices or processes, in locations which the routing topology views as diverse. In practice, that means that services are bound to a common shared address (an “anycast service address”) as those services are deployed on servers in different locations. The service address is advertised into the BGP routing infrastructure. Clients send packets to the service address, and the BGP routing infrastructure routes each packet on the shortest path to its destination, without knowing that there are multiple destinations. > 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? > > 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? I think you’re going to need to construct a clearer and more precise explanation of what you’re imagining, because my reading of these two lines is that they’re saying different things; I don’t see the connection between them that you see. That said, a few reactions: Anycast is often thought to _reduce_ predictability, since it offers multiple exclusive possible termination points for each packet, whereas unicast, multicast or broadcast would each have predictable outcomes by comparison: a specific node would receive the packet, a specific set of nodes would receive the packet, or all (in-scope broadcast domain) nodes would receive the packet. If you’re asking whether it would make sense for border routers, which have access to full-table transit, to advertise that accessibility as an anycasted service, that’s what the special “default route” 0.0.0.0/0 is. Many people configure full-transit BGP routers to redistribute a 0.0.0.0/0 default route into their IGP, their internal routing protocol (albeit that may well be iBGP, nowadays) in order to accommodate routers which haven’t the resources to hold or use full routes. A search engine crawler depends upon a unicast return path in order to establish a TCP session with the web sites it’s crawling, and see the return traffic from them. If a search engine crawler shared an anycast service address with other instances of itself in other locations, the outbound queries would head to web sites (which might be unicast or might be anycast, doesn’t matter), which would then try to reply. If the source address of the query is an anycast service address, the reply will go to the nearest instance of that shared address, rather than to the specific instance which originated the query. It’s for this reason that one normally assigns unique unicast addresses to network-facing interfaces which will originate packets, and anycast addresses to internal loopback interfaces, to which services are bound… The server can receive packets addressed to the anycast shared address, but will originate packets using its unique address. Here’s a tutorial from twenty years ago (when this was all less than fifteen years old!) that explains in some detail… Things haven’t really changed since then: https://www.pch.net/resources/Tutorials/anycast/Anycast-v10.pdf -Bill
signature.asc
Description: Message signed with OpenPGP
