netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).