All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike <ipso@snappymail.ca>
To: John Haxby <john.haxby@oracle.com>
Cc: netfilter@vger.kernel.org
Subject: Re: v2.6.16 to v2.6.38 breaks routing?
Date: Mon, 12 Sep 2011 07:59:18 -0700	[thread overview]
Message-ID: <4E6E1E46.1030504@snappymail.ca> (raw)
In-Reply-To: <4E6DCFBB.6060401@oracle.com>

I currently have rp_filter set to 0 on all interfaces, which is the same 
as I had it on the old server (v2.6.16). Would having it disabled 
completely still cause problems for my setup?

Thanks.

On 11-09-12 02:24 AM, John Haxby wrote:
> On 12/09/11 00:06, Mike wrote:
>> I'm in the process of upgrading an older Linux router from Mandriva
>> running kernel v2.6.16 to Ubuntu running v2.6.38 kernel, however my
>> moderately complex firewall/routing script doesn't quite work the same
>> way on the newer system. The basic idea is that I have three routes to
>> three different ISPs, and one to the internal network. I then mark
>> packets to go out a specific ISP depending on the type of traffic.
>> This all works fine if the packets are initiated from the router
>> itself or from a computer on the intenral network with packets
>> destined out the default ISP, but it fails completely if the packets
>> are initiated from a computer on the internal network destined out an
>> non-default route.
>>
>> What I don't understand is I diff'd the routing tables and all
>> iptables commands they are virtually identical between the two
>> servers, yet the newer server doesn't work as expected.
> You might be running afoul of the change in behaviour of rp_filter that
> happened around 2.6.32.
>
> Previously (as in your 2.6.16 kernel) setting
> net.ipv4.conf.default.rp_filter=1 in /etc/sysctl.conf (or wherever your
> distro puts that file would give you what is now termed "loose reverse
> path filtering".  Now, however, that value gives you strict reverse path
> filtering and 2 gives you loose reverse path filtering.
>
> Strict reverse path filtering discards incoming packets whose source
> address would not be routed to the interface that the packets originated
> from; loose reverse path filtering merely checks that the source address
> is routable.   In Documentation/networking/ip-sysctl.txt is says that
> you might want loose reverse path filtering for complicated routing set
> ups (like yours).
>
> In some cases you can mess with the routing tables dynamically so that a
> source address appearing on an interface will cause outgoing packets for
> that address to use that interface.   I haven't really looked into this
> yet: setting rp_filter=2 was enough to get over my immediate problem,
> although I would still like to get rid of the asymmetric routing at some
> stage.   If you do go down that path though, I would be very interested
> to see what you do.
>
> jch
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Mike


      reply	other threads:[~2011-09-12 14:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-11 23:06 v2.6.16 to v2.6.38 breaks routing? Mike
2011-09-12  4:13 ` v2.6.16 to v2.6.38 breaks routing? - Simplified Mike
2011-09-12  9:24 ` v2.6.16 to v2.6.38 breaks routing? John Haxby
2011-09-12 14:59   ` Mike [this message]

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=4E6E1E46.1030504@snappymail.ca \
    --to=ipso@snappymail.ca \
    --cc=john.haxby@oracle.com \
    --cc=netfilter@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.