ip route get recognizes address as anycast

Question

# ip route get 1.2.3.4
anycast 1.2.3.4 dev eth0  src 5.6.7.8

and the question is how does it know the address is an anycast ? (which apparently is true).

UPDATED:

Present as anycast route:

root@hv2 ~ # ip route get 1.2.3.4
anycast 1.2.3.4 dev eth0  src 5.6.7.8 
    cache

but not visible in list:

root@hv2 ~ # ip route list|grep 1.2.3.4|wc -l
0

but it's possible to delete it, and than it back to normal (no anycast anymore):

root@hv2 ~ # ip route del anycast 1.2.3.4 dev eth0
root@hv2 ~ # ip route get 1.2.3.4
1.2.3.4 via 5.6.7.8 dev eth0  src 9.10.11.12 
    cache

Unicast and anycast addresses are not allocated separately. This address can be used as either depending on how you configure it. But how did you end up with one IP address belonging in Australia and another belonging in Germany? That's like opposite sides of the planet. — kasperd, Jul 09 '14 at 16:01
I can tell you how but.. can you tell me first where the **anycast** word came from on the `ip route get` output ? — pawel7318, Jul 09 '14 at 18:31

score 4 · Accepted Answer · answered Jul 11 '14 at 21:20

4

If you look at the iproute2 gitweb, you'll see it's showing the status of the RTN_ANYCAST bit set on the kernel routing structure. If you cross-reference that with the kernel source (rtnetlink.h) you'll see the following comment:

    RTN_ANYCAST,            /* Accept locally as broadcast,
                               but send as unicast */

If you check the manual page, you'll see the anycast status of an address is determined by configuration (in particular, adding the anycast keyword when you specify the address to be added). According to man 8 ip:

   IFADDR := PREFIX | ADDR peer PREFIX [ broadcast ADDR ] [ anycast ADDR ]
           [ label STRING ] [ scope SCOPE-ID ]

   ...
           anycast   -   _not  implemented_  the  destinations are anycast
           addresses assigned to this host.  They are mainly equivalent to
           local with one difference: such addresses are invalid when used
           as the source address of any packet.

From the first part of the manual, it states that when you specify the address, you can instruct the stack that it's an anycast address. Without checking the kernel source code, I imagine that when you add an anycast address, the anycast bit gets propagated to a corresponding routing table entry that would be created when the address is added.

I'm not sure if the "not implemented" part is entirely correct, because it looks like iproute2 is indeed passing the anycast flags into the system calls. So it seems like if anycast is supported by the kernel, it should work. But I haven't tested it, so I don't know about that.

answered Jul 11 '14 at 21:20

mpontillo

924
6
23

The address was added by my teammate, than he asked me to look at it as it didn't worked and I'm pretty sure he didn't used `anycast` keyword with `ip addr add`. Because we had to make it work we moved to another IP and from that time `1.2.3.4` from the example is not presend on `ip addr`, `ip route` or config file and the `ip route get` still give us same output with the `anycast` in it. Please tell me if I should extend the question with some command's outputs to provide more details. – pawel7318 Jul 12 '14 at 11:27
@pawel7318 it might be helpful to show the full output of `ip -4 route` and `ip -4 addr` in your question. And clarify what you mean when you say the address "doesn't work". (What, specifically, isn't working? What troubleshooting steps have you tried? Also, what Linux distribution are you using?) – mpontillo Jul 13 '14 at 04:33
it didn't reply for any SYN package but.. as it was recognized as anycast it could be that "such addresses are invalid when used as the source address of any packet" rule applied to it. As I said the address it not set on any interface or route now. We don't own the address anymore and still `ip route get` shows me that it's an anycast. – pawel7318 Jul 16 '14 at 08:28
@pawel7318, it seems like the address is marked `anycast` but you didn't intend that. Is that correct? what Linux distribution are you using? Can you post your network configuration files? If you restart your networking subsystem (or use the supported way to bounce your interfaces) does the problem go away? As a last resort, does rebooting affect the problem? – mpontillo Jul 16 '14 at 19:36
It's Debian. We have dedicated servers at Hetzner.de and we ordered 'faillover address' which can be easily moved from one box to another via web-based mgmt. panel or trigered via their API. Than we placed it on the box with simple `ip addr add`. We had some problems to make it work (as I described above) but as we've noticed that we'll need more we ordered another subnet that works same way. From that point we don't own that IP and it was **never** added to `/etc/network/interfaces` or any other file. Even after `ip addr del 1.2.3.4/32 dev eth0` I still have that magic puzzle. – pawel7318 Jul 16 '14 at 21:09
@pawel7318 If you don't want it any more, you should be able to remove it with `ip route del anycast 1.2.3.4 dev eth0`. I was just experimenting with this on Ubuntu 14.04, and it looks like there are some bugs here. For example, I don't see the anycast route when I just type `ip -4 route`... – mpontillo Jul 16 '14 at 21:17
You're right. Looks like some bug. Check **UPDATE** part at the question. I'll leave the question as unanswered as maybe someone will be able to add something to the subject. I still don't know where that route came from. – pawel7318 Jul 17 '14 at 17:36
Eureka ! I know how it happened: probably my teammate run `ip route a a` instead of `ip route a` (note double `a`) :). Anyway it's still weird that it's not listed by `ip route list`. Maybe there's some argument to list anycast routes, but I can't find any. – pawel7318 Jul 17 '14 at 17:50

score 1 · Answer 2 · answered Jul 17 '14 at 18:34

From the man page for ip-route, under the "ip route get" section:

Note that this operation is not equivalent to ip route show. show shows existing routes. get resolves them and creates new clones if necessary. Essentially, get is equivalent to sending a packet along this path

You can show anycast routes with the command ip route show type anycast.

ip route get recognizes address as anycast

2 Answers2