[LARTC] Routing problem (RTNETLINK answers: Invalid argument) on

[LARTC] Routing problem (RTNETLINK answers: Invalid argument) on

[Paul Viney]

Hi all,

I'm trying to set up a computer with 2 routes to the internet, much as 
described at http://lartc.org/howto/lartc.rpdb.multiple-links.html .One of my 
interfaces (eth5, 192.168.2.2) is only used for traffic originating inside 
the network. The other (eth1, 192.168.1.2) is only used for a VPN, where all 
(udp) traffic originates from outside our network. I have created a second 
routing table for eth1, with its own default gateway, and selected it with
ip rule from 192.168.1.2 iif lo lookup 4. All this works fine.
My problem is that one of the udp ports is forwarded to another server using 
iptables:
/sbin/iptables -t nat -A PREROUTING -i eth1 -p udp -d 192.168.1.2 --dport 
4902 -j DNAT --to 192.168.12.5:4902

using tcpdump on eth1, I can see that the incoming packets receive an icmp 
rejection, and when I try something like

ip route get 192.168.12.5 from 64.233.183.103 iif eth1
I get "RTNETLINK answers: Invalid argument"

If I try 
ip route get 192.168.12.5 from 64.233.183.103 iif eth5
I get
192.168.12.5 from 64.233.183.103 dev eth3  src 192.168.2.2
    cache  mtu 1500 advmss 1460 metric 10 64 iif eth5

which leads me to conclude that the difference has something to do with the 
default route.
I've tried things like
ip rule add iif eth1 lookup 4   (4 being my custom routing table)
ip rule add from 192.168.1.2 lookup 4

and even
iptables -t nat -I PREROUTING -i eth1 -p udp -j MARK --set-mark 1
ip rule from all fwmark 0x1 lookup 4
ip route flush cache

I'm using linux 2.6.19.2 + grsecurity patches, every option I could find 
compiled in, on an up to date gentoo system.

Can anyone see what I'm missing?

Thanks,

Paul Viney


ip route show
192.168.2.0/24 dev eth5  proto kernel  scope link  src 192.168.2.2
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.2
192.168.12.0/24 dev eth3  proto kernel  scope link  src 192.168.12.1
127.0.0.0/8 dev lo  scope link
default via 192.168.2.1 dev eth5

ip route show table 4
192.168.2.0/24 dev eth5  proto kernel  scope link  src 192.168.2.2
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.2
192.168.12.0/24 dev eth3  proto kernel  scope link  src 192.168.12.1
127.0.0.0/8 dev lo  scope link
default via 192.168.1.1 dev eth1

ip rule show
0:      from all lookup local
9999:   from all fwmark 0x1 lookup 4
10000:  from 192.168.1.2 iif lo lookup 4
30000:  from all lookup main
30000:  from all lookup default
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Routing problem (RTNETLINK answers: Invalid argument) on

[Alex Samad]

[-- Attachment #1.1: Type: text/plain, Size: 4671 bytes --]

On Tue, Feb 13, 2007 at 02:50:13PM +0100, Paul Viney wrote:
> Hi all,
> 
> I'm trying to set up a computer with 2 routes to the internet, much as 
> described at http://lartc.org/howto/lartc.rpdb.multiple-links.html .One of my 
> interfaces (eth5, 192.168.2.2) is only used for traffic originating inside 
> the network. The other (eth1, 192.168.1.2) is only used for a VPN, where all 
> (udp) traffic originates from outside our network. I have created a second 
> routing table for eth1, with its own default gateway, and selected it with
> ip rule from 192.168.1.2 iif lo lookup 4. All this works fine.
> My problem is that one of the udp ports is forwarded to another server using 
> iptables:
> /sbin/iptables -t nat -A PREROUTING -i eth1 -p udp -d 192.168.1.2 --dport 
> 4902 -j DNAT --to 192.168.12.5:4902
> 
> using tcpdump on eth1, I can see that the incoming packets receive an icmp 
> rejection, and when I try something like
> 
> ip route get 192.168.12.5 from 64.233.183.103 iif eth1
> I get "RTNETLINK answers: Invalid argument"
> 
> If I try 
> ip route get 192.168.12.5 from 64.233.183.103 iif eth5
> I get
> 192.168.12.5 from 64.233.183.103 dev eth3  src 192.168.2.2
>     cache  mtu 1500 advmss 1460 metric 10 64 iif eth5
> 
> which leads me to conclude that the difference has something to do with the 
> default route.
> I've tried things like
> ip rule add iif eth1 lookup 4   (4 being my custom routing table)
> ip rule add from 192.168.1.2 lookup 4
> 
> and even
> iptables -t nat -I PREROUTING -i eth1 -p udp -j MARK --set-mark 1
> ip rule from all fwmark 0x1 lookup 4
> ip route flush cache
> 
> I'm using linux 2.6.19.2 + grsecurity patches, every option I could find 
> compiled in, on an up to date gentoo system.
> 
> Can anyone see what I'm missing?
> 
> Thanks,
> 
> Paul Viney
> 
> 
> ip route show
> 192.168.2.0/24 dev eth5  proto kernel  scope link  src 192.168.2.2
> 192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.2
> 192.168.12.0/24 dev eth3  proto kernel  scope link  src 192.168.12.1
> 127.0.0.0/8 dev lo  scope link
> default via 192.168.2.1 dev eth5
> 
> ip route show table 4
> 192.168.2.0/24 dev eth5  proto kernel  scope link  src 192.168.2.2
> 192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.2
> 192.168.12.0/24 dev eth3  proto kernel  scope link  src 192.168.12.1
> 127.0.0.0/8 dev lo  scope link
> default via 192.168.1.1 dev eth1
> 
> ip rule show
> 0:      from all lookup local
> 9999:   from all fwmark 0x1 lookup 4
> 10000:  from 192.168.1.2 iif lo lookup 4

if the ip address on eth1 is 64.233.183.103  then you need a rule
10001:  from 64.233.183.103 lookup 4

I don't think the fwmark rule will work with ip route get.

Plus your routing information in table 4, you are saying that the default
address is available via 192.168.1.1 ???? that doesn't match up with
64.233.183.103



this is my ip ru
0:      from all lookup local 
200:    from 144.132.147.156 lookup cable 
201:    from 60.241.248.86 lookup adsl 
32766:  from all lookup main 
32767:  from all lookup default


144.132.147.156 is one isp, 60.241.248.86 is the other one

ip r sh tab cable
192.168.8.248/29 dev tap0  scope link  src 192.168.8.249 
192.168.11.0/24 dev vlan0  scope link  src 192.168.11.1 
192.168.10.0/24 dev eth1  scope link  src 192.168.10.1 
default via 144.132.144.1 dev vlan2  proto static  src 144.132.147.156  metric
50 
prohibit default  proto static  metric 100


ip r sh tab adsl 
192.168.8.248/29 dev tap0  scope link  src 192.168.8.249 
192.168.11.0/24 dev vlan0  scope link  src 192.168.11.1 
192.168.10.0/24 dev eth1  scope link  src 192.168.10.1 
default via 10.20.20.168 dev ppp0  proto static  src 60.241.248.86  metric 20 
prohibit default  proto static  metric 100

ip r sh tab default
default  proto static  metric 5 
        nexthop via 144.132.144.1  dev vlan2 weight 1
        nexthop via 10.20.20.168  dev ppp0 weight 20
default via 10.20.20.168 dev ppp0  src 60.241.248.86  metric 20 
default via 144.132.144.1 dev vlan2  src 144.132.147.156  metric 30


The difference for you should be in the default table, you will not need 
default  proto static  metric 5
        nexthop via 144.132.144.1  dev vlan2 weight 1
        nexthop via 10.20.20.168  dev ppp0 weight 20


cause you want all your traffic to go out 1 link.

alex


> 30000:  from all lookup main
> 30000:  from all lookup default
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> 

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Routing problem (RTNETLINK answers: Invalid argument) on

[Paul Viney]

Thanks for the advice, Alex. I've been able to add both default routes - I 
hadn't considered using the metric to avoid using the VPN link. 
I guess I wasn't very clear with my use of 64.233.183.103, which was meant to 
be a random internet address coming in over the VPN link, not the default 
internet link.
what exactly does the " prohibit default  proto static  metric 100 " in your 
routing table do? Haven't you already had a default route which would trigger 
before reaching this rule?

I still seem to have much the same problem. I no longer get ICMP unreachable 
errors, but the packet just seems to disappear - I can't see it being 
forwarded on any interface, nor can I find any kind of reply - icmp or 
otherwise.

ip route get <random internet address> to 192.168.12.5      gives
192.168.12.5 dev eth3  src 192.168.12.1
    cache  mtu 1500 advmss 1460 metric 10 64

ip route get <random internet address> to 192.168.12.5 iif eth1   gives
RTNETLINK answers: Invalid argument

Am I not understanding how "ip route get" works? The man pages are fairly 
succinct in their explanation.

Thanks for your help,

Paul Viney


On Tuesday 13 February 2007 21:40, Alex Samad wrote:
> On Tue, Feb 13, 2007 at 02:50:13PM +0100, Paul Viney wrote:
> > Hi all,
> >
> > I'm trying to set up a computer with 2 routes to the internet, much as
> > described at http://lartc.org/howto/lartc.rpdb.multiple-links.html .One
> > of my interfaces (eth5, 192.168.2.2) is only used for traffic originating
> > inside the network. The other (eth1, 192.168.1.2) is only used for a VPN,
> > where all (udp) traffic originates from outside our network. I have
> > created a second routing table for eth1, with its own default gateway,
> > and selected it with ip rule from 192.168.1.2 iif lo lookup 4. All this
> > works fine.
> > My problem is that one of the udp ports is forwarded to another server
> > using iptables:
> > /sbin/iptables -t nat -A PREROUTING -i eth1 -p udp -d 192.168.1.2 --dport
> > 4902 -j DNAT --to 192.168.12.5:4902
> >
> > using tcpdump on eth1, I can see that the incoming packets receive an
> > icmp rejection, and when I try something like
> >
> > ip route get 192.168.12.5 from 64.233.183.103 iif eth1
> > I get "RTNETLINK answers: Invalid argument"
> >
> > If I try
> > ip route get 192.168.12.5 from 64.233.183.103 iif eth5
> > I get
> > 192.168.12.5 from 64.233.183.103 dev eth3  src 192.168.2.2
> >     cache  mtu 1500 advmss 1460 metric 10 64 iif eth5
> >
> > which leads me to conclude that the difference has something to do with
> > the default route.
> > I've tried things like
> > ip rule add iif eth1 lookup 4   (4 being my custom routing table)
> > ip rule add from 192.168.1.2 lookup 4
> >
> > and even
> > iptables -t nat -I PREROUTING -i eth1 -p udp -j MARK --set-mark 1
> > ip rule from all fwmark 0x1 lookup 4
> > ip route flush cache
> >
> > I'm using linux 2.6.19.2 + grsecurity patches, every option I could find
> > compiled in, on an up to date gentoo system.
> >
> > Can anyone see what I'm missing?
> >
> > Thanks,
> >
> > Paul Viney
> >
> >
> > ip route show
> > 192.168.2.0/24 dev eth5  proto kernel  scope link  src 192.168.2.2
> > 192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.2
> > 192.168.12.0/24 dev eth3  proto kernel  scope link  src 192.168.12.1
> > 127.0.0.0/8 dev lo  scope link
> > default via 192.168.2.1 dev eth5
> >
> > ip route show table 4
> > 192.168.2.0/24 dev eth5  proto kernel  scope link  src 192.168.2.2
> > 192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.2
> > 192.168.12.0/24 dev eth3  proto kernel  scope link  src 192.168.12.1
> > 127.0.0.0/8 dev lo  scope link
> > default via 192.168.1.1 dev eth1
> >
> > ip rule show
> > 0:      from all lookup local
> > 9999:   from all fwmark 0x1 lookup 4
> > 10000:  from 192.168.1.2 iif lo lookup 4
>
> if the ip address on eth1 is 64.233.183.103  then you need a rule
> 10001:  from 64.233.183.103 lookup 4
>
> I don't think the fwmark rule will work with ip route get.
>
> Plus your routing information in table 4, you are saying that the default
> address is available via 192.168.1.1 ???? that doesn't match up with
> 64.233.183.103
>
>
>
> this is my ip ru
> 0:      from all lookup local
> 200:    from 144.132.147.156 lookup cable
> 201:    from 60.241.248.86 lookup adsl
> 32766:  from all lookup main
> 32767:  from all lookup default
>
>
> 144.132.147.156 is one isp, 60.241.248.86 is the other one
>
> ip r sh tab cable
> 192.168.8.248/29 dev tap0  scope link  src 192.168.8.249
> 192.168.11.0/24 dev vlan0  scope link  src 192.168.11.1
> 192.168.10.0/24 dev eth1  scope link  src 192.168.10.1
> default via 144.132.144.1 dev vlan2  proto static  src 144.132.147.156 
> metric 50
> prohibit default  proto static  metric 100
>
>
> ip r sh tab adsl
> 192.168.8.248/29 dev tap0  scope link  src 192.168.8.249
> 192.168.11.0/24 dev vlan0  scope link  src 192.168.11.1
> 192.168.10.0/24 dev eth1  scope link  src 192.168.10.1
> default via 10.20.20.168 dev ppp0  proto static  src 60.241.248.86  metric
> 20 prohibit default  proto static  metric 100
>
> ip r sh tab default
> default  proto static  metric 5
>         nexthop via 144.132.144.1  dev vlan2 weight 1
>         nexthop via 10.20.20.168  dev ppp0 weight 20
> default via 10.20.20.168 dev ppp0  src 60.241.248.86  metric 20
> default via 144.132.144.1 dev vlan2  src 144.132.147.156  metric 30
>
>
> The difference for you should be in the default table, you will not need
> default  proto static  metric 5
>         nexthop via 144.132.144.1  dev vlan2 weight 1
>         nexthop via 10.20.20.168  dev ppp0 weight 20
>
>
> cause you want all your traffic to go out 1 link.
>
> alex
>
> > 30000:  from all lookup main
> > 30000:  from all lookup default
> > _______________________________________________
> > LARTC mailing list
> > LARTC@mailman.ds9a.nl
> > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Routing problem (RTNETLINK answers: Invalid argument) on

[Alex Samad]

[-- Attachment #1.1: Type: text/plain, Size: 6886 bytes --]

On Tue, Feb 13, 2007 at 10:54:51PM +0100, Paul Viney wrote:
> Thanks for the advice, Alex. I've been able to add both default routes - I 
> hadn't considered using the metric to avoid using the VPN link. 
> I guess I wasn't very clear with my use of 64.233.183.103, which was meant to 
> be a random internet address coming in over the VPN link, not the default 
> internet link.
> what exactly does the " prohibit default  proto static  metric 100 " in your 
> routing table do? Haven't you already had a default route which would trigger 
> before reaching this rule?
it been a while since I looked over this, but from memory, if the link goes
down, it stops the route table being used

> 
> I still seem to have much the same problem. I no longer get ICMP unreachable 
> errors, but the packet just seems to disappear - I can't see it being 
> forwarded on any interface, nor can I find any kind of reply - icmp or 
> otherwise.

sounds like a firewall issue!

> 
> ip route get <random internet address> to 192.168.12.5      gives
> 192.168.12.5 dev eth3  src 192.168.12.1
>     cache  mtu 1500 advmss 1460 metric 10 64
> 
> ip route get <random internet address> to 192.168.12.5 iif eth1   gives
> RTNETLINK answers: Invalid argument

try

ip r g <random internet address> from 192.168.12.5, I  seem to be getting the
same error as you

> 
> Am I not understanding how "ip route get" works? The man pages are fairly 
> succinct in their explanation.
> 
> Thanks for your help,
> 
> Paul Viney
> 
> 
> On Tuesday 13 February 2007 21:40, Alex Samad wrote:
> > On Tue, Feb 13, 2007 at 02:50:13PM +0100, Paul Viney wrote:
> > > Hi all,
> > >
> > > I'm trying to set up a computer with 2 routes to the internet, much as
> > > described at http://lartc.org/howto/lartc.rpdb.multiple-links.html .One
> > > of my interfaces (eth5, 192.168.2.2) is only used for traffic originating
> > > inside the network. The other (eth1, 192.168.1.2) is only used for a VPN,
> > > where all (udp) traffic originates from outside our network. I have
> > > created a second routing table for eth1, with its own default gateway,
> > > and selected it with ip rule from 192.168.1.2 iif lo lookup 4. All this
> > > works fine.
> > > My problem is that one of the udp ports is forwarded to another server
> > > using iptables:
> > > /sbin/iptables -t nat -A PREROUTING -i eth1 -p udp -d 192.168.1.2 --dport
> > > 4902 -j DNAT --to 192.168.12.5:4902
> > >
> > > using tcpdump on eth1, I can see that the incoming packets receive an
> > > icmp rejection, and when I try something like
> > >
> > > ip route get 192.168.12.5 from 64.233.183.103 iif eth1
> > > I get "RTNETLINK answers: Invalid argument"
> > >
> > > If I try
> > > ip route get 192.168.12.5 from 64.233.183.103 iif eth5
> > > I get
> > > 192.168.12.5 from 64.233.183.103 dev eth3  src 192.168.2.2
> > >     cache  mtu 1500 advmss 1460 metric 10 64 iif eth5
> > >
> > > which leads me to conclude that the difference has something to do with
> > > the default route.
> > > I've tried things like
> > > ip rule add iif eth1 lookup 4   (4 being my custom routing table)
> > > ip rule add from 192.168.1.2 lookup 4
> > >
> > > and even
> > > iptables -t nat -I PREROUTING -i eth1 -p udp -j MARK --set-mark 1
> > > ip rule from all fwmark 0x1 lookup 4
> > > ip route flush cache
> > >
> > > I'm using linux 2.6.19.2 + grsecurity patches, every option I could find
> > > compiled in, on an up to date gentoo system.
> > >
> > > Can anyone see what I'm missing?
> > >
> > > Thanks,
> > >
> > > Paul Viney
> > >
> > >
> > > ip route show
> > > 192.168.2.0/24 dev eth5  proto kernel  scope link  src 192.168.2.2
> > > 192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.2
> > > 192.168.12.0/24 dev eth3  proto kernel  scope link  src 192.168.12.1
> > > 127.0.0.0/8 dev lo  scope link
> > > default via 192.168.2.1 dev eth5
> > >
> > > ip route show table 4
> > > 192.168.2.0/24 dev eth5  proto kernel  scope link  src 192.168.2.2
> > > 192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.2
> > > 192.168.12.0/24 dev eth3  proto kernel  scope link  src 192.168.12.1
> > > 127.0.0.0/8 dev lo  scope link
> > > default via 192.168.1.1 dev eth1
> > >
> > > ip rule show
> > > 0:      from all lookup local
> > > 9999:   from all fwmark 0x1 lookup 4
> > > 10000:  from 192.168.1.2 iif lo lookup 4
> >
> > if the ip address on eth1 is 64.233.183.103  then you need a rule
> > 10001:  from 64.233.183.103 lookup 4
> >
> > I don't think the fwmark rule will work with ip route get.
> >
> > Plus your routing information in table 4, you are saying that the default
> > address is available via 192.168.1.1 ???? that doesn't match up with
> > 64.233.183.103
> >
> >
> >
> > this is my ip ru
> > 0:      from all lookup local
> > 200:    from 144.132.147.156 lookup cable
> > 201:    from 60.241.248.86 lookup adsl
> > 32766:  from all lookup main
> > 32767:  from all lookup default
> >
> >
> > 144.132.147.156 is one isp, 60.241.248.86 is the other one
> >
> > ip r sh tab cable
> > 192.168.8.248/29 dev tap0  scope link  src 192.168.8.249
> > 192.168.11.0/24 dev vlan0  scope link  src 192.168.11.1
> > 192.168.10.0/24 dev eth1  scope link  src 192.168.10.1
> > default via 144.132.144.1 dev vlan2  proto static  src 144.132.147.156 
> > metric 50
> > prohibit default  proto static  metric 100
> >
> >
> > ip r sh tab adsl
> > 192.168.8.248/29 dev tap0  scope link  src 192.168.8.249
> > 192.168.11.0/24 dev vlan0  scope link  src 192.168.11.1
> > 192.168.10.0/24 dev eth1  scope link  src 192.168.10.1
> > default via 10.20.20.168 dev ppp0  proto static  src 60.241.248.86  metric
> > 20 prohibit default  proto static  metric 100
> >
> > ip r sh tab default
> > default  proto static  metric 5
> >         nexthop via 144.132.144.1  dev vlan2 weight 1
> >         nexthop via 10.20.20.168  dev ppp0 weight 20
> > default via 10.20.20.168 dev ppp0  src 60.241.248.86  metric 20
> > default via 144.132.144.1 dev vlan2  src 144.132.147.156  metric 30
> >
> >
> > The difference for you should be in the default table, you will not need
> > default  proto static  metric 5
> >         nexthop via 144.132.144.1  dev vlan2 weight 1
> >         nexthop via 10.20.20.168  dev ppp0 weight 20
> >
> >
> > cause you want all your traffic to go out 1 link.
> >
> > alex
> >
> > > 30000:  from all lookup main
> > > 30000:  from all lookup default
> > > _______________________________________________
> > > LARTC mailing list
> > > LARTC@mailman.ds9a.nl
> > > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> 

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Routing problem (RTNETLINK answers: Invalid argument) on

[Paul Viney]

> > I still seem to have much the same problem. I no longer get ICMP
> > unreachable errors, but the packet just seems to disappear - I can't see
> > it being forwarded on any interface, nor can I find any kind of reply -
> > icmp or otherwise.
>
> sounds like a firewall issue!

It does sound like a firewall issue, but the only firewall rule I have at the 
moment is the one doing the DNAT. If I do 'iptables -t nat -L -v', then I can 
see the number of packets increasing. Once I remove the firewall rule, I get 
my "icmp unreachable" errors again. Funnily enough, if I then reinstate the 
firewall (dnat) rule, then I still get "icmp unreachable" errors and the 
packet count doesn't go up for the rule. It's almost as though the rule 
doesn't get consulted. 'ip route flush cache' doesn't make a difference. 
After about 5 minutes the "icmp unreachable" errors stop and the packet count 
starts going up, although I still can't find my packet on the next hop. (I do 
have forwarding switched on). The packet count on a iptables log rule on the 
forward table does not go up, giving me the impression that routing has 
failed. 
I also tried ip r get <random internet address> from 192.168.12.5, which did 
indeed give me the same "RTNETLINK answers: Invalid argument" error. I guess 
that means that my understanding of the purpose of 'ip r get' is indeed 
faulty. 

Thanks for all your help so far.

Paul Viney

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Routing problem (RTNETLINK answers: Invalid argument) on

[Paul Viney]

If I type

route add default gw 192.168.1.1
ip route flush cache

then my forwarding suddenly starts working again, although the rest of my 
routing obviously doesn't do what I want any more.
Weird.

Paul Viney

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Routing problem (RTNETLINK answers: Invalid argument)

[Torsten Luettgert]

On Tue, 2007-02-13 at 22:54 +0100, Paul Viney wrote:

> I still seem to have much the same problem. I no longer get ICMP unreachable 
> errors, but the packet just seems to disappear - I can't see it being 
> forwarded on any interface, nor can I find any kind of reply - icmp or 
> otherwise.

This is one of my favourites :-)

Usually that problem is caused by the rp_filter feature, which silently
drops packets that arrive on an interface answers wouldn't be routed to.

Just try

for i in /proc/sys/net/ipv4/conf/eth*/rp_filter; do
	echo 0 > $i
done

and see if that helps.
(indeed, you don't really need to switch it off for all of them, just
the uplink interfaces would be enough)

Hth,
Torsten

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Routing problem (RTNETLINK answers: Invalid argument) on

[Paul Viney]

Wow! That made a difference. One 
echo "0" > /proc/sys/net/ipv4/conf/eth1/rp_filter
and everything started working. 
Thanks a lot Torsten and Alex - I wouldn't have solved it without your 
suggestions.

Paul Viney


On Wednesday 14 February 2007 21:17, Torsten Luettgert wrote:
> This is one of my favourites :-)
>
> Usually that problem is caused by the rp_filter feature, which silently
> drops packets that arrive on an interface answers wouldn't be routed to.
>
> Just try
>
> for i in /proc/sys/net/ipv4/conf/eth*/rp_filter; do
> 	echo 0 > $i
> done
>
> and see if that helps.
> (indeed, you don't really need to switch it off for all of them, just
> the uplink interfaces would be enough)
>
> Hth,
> Torsten
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Routing problem (RTNETLINK answers: Invalid argument) on

[Alex Samad]

[-- Attachment #1.1: Type: text/plain, Size: 2025 bytes --]

On Wed, Feb 14, 2007 at 08:30:48AM +0100, Paul Viney wrote:
> > > I still seem to have much the same problem. I no longer get ICMP
> > > unreachable errors, but the packet just seems to disappear - I can't see
> > > it being forwarded on any interface, nor can I find any kind of reply -
> > > icmp or otherwise.
> >
> > sounds like a firewall issue!
> 
> It does sound like a firewall issue, but the only firewall rule I have at the 
> moment is the one doing the DNAT. If I do 'iptables -t nat -L -v', then I can 
> see the number of packets increasing. Once I remove the firewall rule, I get 
> my "icmp unreachable" errors again. Funnily enough, if I then reinstate the 
> firewall (dnat) rule, then I still get "icmp unreachable" errors and the 
> packet count doesn't go up for the rule. It's almost as though the rule 
> doesn't get consulted. 'ip route flush cache' doesn't make a difference. 
> After about 5 minutes the "icmp unreachable" errors stop and the packet count 
> starts going up, although I still can't find my packet on the next hop. (I do 
> have forwarding switched on). The packet count on a iptables log rule on the 
> forward table does not go up, giving me the impression that routing has 
> failed. 

This could be connection tracking, once you start a ping, connection tracking
will keep it in its cache, so even though you have placed it (the rule) back in
it doesn't count for the established link...

> I also tried ip r get <random internet address> from 192.168.12.5, which did 
> indeed give me the same "RTNETLINK answers: Invalid argument" error. I guess 
> that means that my understanding of the purpose of 'ip r get' is indeed 
> faulty. 

does 192.168.12.5 exist on your box, can up do an ip a
also do you have forwarding on ?

> 
> Thanks for all your help so far.
> 
> Paul Viney
> 
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> 

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Routing problem (RTNETLINK answers: Invalid argument)

[Brian J. Murrell]

[-- Attachment #1.1: Type: text/plain, Size: 2003 bytes --]

On Thu, 2007-02-15 at 00:30 +0100, Paul Viney wrote:
> Wow! That made a difference. One 
> echo "0" > /proc/sys/net/ipv4/conf/eth1/rp_filter
> and everything started working. 
> Thanks a lot Torsten and Alex - I wouldn't have solved it without your 
> suggestions.

But the question I have had about this subject is when one has two
default routes, load balanced, does this evaluation of which interface
would be used when the packet is reverse-path-tested test all of the
default routes or just the route that is currently active given the load
balancing algorithm?

If only the one, current default route is used in the evaluation it
seems to me even in the most straightforward
dual-load-balanced-default-route configuration there is a race between
the time a packet is assigned an outgoing address & sent out the then
current default route and the routing code re-balancing and switching
the active default route (i.e prior to the reply packet -- or even in
the middle of active tcp connections).

The situation gets even worse (not even just a race condition) when you
apply policy routing to force the use of a particular default route.

Thots?

b.

> 
> Paul Viney
> 
> 
> On Wednesday 14 February 2007 21:17, Torsten Luettgert wrote:
> > This is one of my favourites :-)
> >
> > Usually that problem is caused by the rp_filter feature, which silently
> > drops packets that arrive on an interface answers wouldn't be routed to.
> >
> > Just try
> >
> > for i in /proc/sys/net/ipv4/conf/eth*/rp_filter; do
> > 	echo 0 > $i
> > done
> >
> > and see if that helps.
> > (indeed, you don't really need to switch it off for all of them, just
> > the uplink interfaces would be enough)
> >
> > Hth,
> > Torsten
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> 
> 
-- 
My other computer is your Microsoft Windows server.

Brian J. Murrell

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc