From: Alexander Duyck <alexander.duyck@gmail.com>
To: Brian Rak <brak@vultr.com>, netdev@vger.kernel.org
Subject: Re: Missing IPv4 routes
Date: Fri, 23 Oct 2015 15:32:24 -0700 [thread overview]
Message-ID: <562AB578.9090107@gmail.com> (raw)
In-Reply-To: <562AA7D3.9030905@vultr.com>
On 10/23/2015 02:34 PM, Brian Rak wrote:
> I've got a weird situation here. I have a route that the kernel knows
> about, but won't display via the general RTM_GETROUTE call, but will
> display if I query for that particular route:
>
> # ip -4 route show | grep 108.61.171.x
The use of 'x' here is going to make things confusing. I assume you are
using a value of 0 here, or is this a route to a specific IP address
that you have. If not you should be using a 0 for all bits that would
be outside of your subnet mask.
> # ip route get 108.61.171.x
> 108.61.171.x dev MYIF
> cache
The 'x' being the actual value here should work as this will perform a
lookup as I recall.
> # cat /proc/net/route | grep 108.61.171.x
The IPs are in network order and as just hex so this won't work.
> # cat /proc/net/route | grep -i 6c3dac
The byte ordering you are using is backwards here from what I can tell.
So it should be ac3d6c you are checking for, not the other way around.
So for example if I was using 192.168.1.x I would want to look for 01A8C0.
> # ip route add 108.61.171.x dev MYIF
> RTNETLINK answers: File exists
> # ip route del 108.61.171.x <---- it deletes successfully once
> # ip route del 108.61.171.x
> RTNETLINK answers: No such process
>
So at least we have the routes in the FIB. It looks like this just
might be a display issue.
> This is on a machine running 4.1.3, but I have seen it on earlier
> versions in the past.
>
> I don't have great reproduction steps here, I've seen this 4-5 times in
> the past few months (on different hardware). So far, I haven't really
> found any way of fixing it (deleting and readding the route has no
> effect). I thought at first this might be related to
> e55ffaf457bcc8ec4e9d9f56f955971f834d65b3, but as far as I can tell that
> only relates to /proc/net/route.
>
> Any suggestions on further troubleshooting here? I'm all out of ideas
> (and since I can't easily reproduce it yet, I can't reboot to a newer
> kernel to see if it goes away)
How many routes do you have on your system? I'm just wondering if it
might be possible that the route could be at a boundary for the dump
call and if it might be possibly losing the data there. Although I
would expect
Also have you tried double checking to verify that grep isn't somehow
missing the line?
- Alex
next prev parent reply other threads:[~2015-10-23 22:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-23 21:34 Missing IPv4 routes Brian Rak
2015-10-23 22:32 ` Alexander Duyck [this message]
2015-10-24 13:32 ` Brian Rak
2015-10-26 15:28 ` Alexander Duyck
2015-10-26 16:57 ` Brian Rak
2015-10-27 20:01 ` Brian Rak
2015-10-27 20:29 ` Alexander Duyck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=562AB578.9090107@gmail.com \
--to=alexander.duyck@gmail.com \
--cc=brak@vultr.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.