9 messages, 3 authors, 2009-10-18 · open the first message on its own page
From: jamal <hidden>
Date: 2009-10-12 21:09:36
ping by mark, example to use firewall mark decimal 10 (which hopefully maps to something meaningful with policy routing): ping -m 10 10.0.0.1 cheers, jamal
From: Rob Townley <hidden>
Date: 2009-10-16 21:12:29
On Mon, Oct 12, 2009 at 4:05 PM, jamal [off-list ref] wrote:
ping by mark, example to use firewall mark decimal 10 (which hopefully maps to something meaningful with policy routing): ping -m 10 10.0.0.1 cheers, jamal
Would this make it easier to ping multiple gateways so if one goes down, it is taken almost out of the routing table until it comes back up.
From: jamal <hidden>
Date: 2009-10-17 12:33:37
On Fri, 2009-10-16 at 16:05 -0500, Rob Townley wrote:
Would this make it easier to ping multiple gateways
yes. You need to set your policy routing accordingly to have a different gateway for the same destination and then use the -m to select the routing table..
so if one goes down, it is taken almost out of the routing table until it comes back up.
I am not sure i followed or see any relation to the first part of your question. Ive never heard of routing table entries automagically being taken down until something comes up. You could do it probably by writting a user space daemon. cheers, jamal
From: Maciej Żenczykowski <hidden>
Date: 2009-10-17 18:54:53
This patch requires the currently being suggested/reviewed/written 'fix SO_MARK' patches, some of which have already been committed. On Sat, Oct 17, 2009 at 05:30, jamal [off-list ref] wrote:
On Fri, 2009-10-16 at 16:05 -0500, Rob Townley wrote:quoted
Would this make it easier to ping multiple gatewaysyes. You need to set your policy routing accordingly to have a different gateway for the same destination and then use the -m to select the routing table..quoted
so if one goes down, it is taken almost out of the routing table until it comes back up.I am not sure i followed or see any relation to the first part of your question. Ive never heard of routing table entries automagically being taken down until something comes up. You could do it probably by writting a user space daemon. cheers, jamal -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: jamal <hidden>
Date: 2009-10-17 23:07:53
On Sat, 2009-10-17 at 11:54 -0700, Maciej Żenczykowski wrote:
This patch requires the currently being suggested/reviewed/written 'fix SO_MARK' patches, some of which have already been committed.
Elucidate please. SO_MARK has been in for at least a year. This patch has worked fine in 2.6.31 and pre-31 where i tested. What patches and what are they fixing in this regard to get this working? cheers, jamal
From: jamal <hidden>
Date: 2009-10-17 23:37:46
On Sat, 2009-10-17 at 19:04 -0400, jamal wrote:
This patch has worked fine in 2.6.31 and pre-31 where i tested.
Ok, just to be sure - here's a simple test i just did on my laptop...
------
hadi@dogo:~$ uname -a
Linux dogo 2.6.31-rc7-00001-g6da17c5-dirty #7 PREEMPT Thu Oct 15
16:35:13 EDT 2009 i686 GNU/Linux
hadi@dogo:~$ ip a ls dev eth0
11: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UNKNOWN qlen 1000
link/ether 00:0b:97:97:4d:6a brd ff:ff:ff:ff:ff:ff
inet 10.0.0.31/24 brd 10.0.0.255 scope global eth0
inet 10.0.0.2/32 scope global eth0
inet6 fe80::20b:97ff:fe97:4d6a/64 scope link
valid_lft forever preferred_lft forever
hadi@dogo:~$ ip ru ls
0: from all lookup local
15: from all fwmark 0xf lookup 15
16: from all fwmark 0x10 lookup 16
32766: from all lookup main
32767: from all lookup default
hadi@dogo:~$ ip r ls table 15
208.67.217.231 via 10.0.0.1 dev eth0 src 10.0.0.31
hadi@dogo:~$ ip r ls table 16
208.67.217.231 via 10.0.0.1 dev eth0 src 10.0.0.2
hadi@dogo:~$
One ping with -m 15 -c1 to 208.67.217.231, tcpdump:
19:22:09.467555 IP 10.0.0.31 > 208.67.217.231: ICMP echo request, id
34328, seq 1, length 64
19:22:09.535429 IP 208.67.217.231 > 10.0.0.31: ICMP echo reply, id
34328, seq 1, length 64
repeat ping with -m 16 and watch tcpdump
19:23:19.731592 IP 10.0.0.2 > 208.67.217.231: ICMP echo request, id
50712, seq 1, length 64
19:23:19.790672 IP 208.67.217.231 > 10.0.0.2: ICMP echo reply, id 50712,
seq 1, length 64
------
I have also tried it with udp (hacked netcat) and i dont see any problem
either
What did i miss?
cheers,
jamal
From: Maciej Żenczykowski <hidden>
Date: 2009-10-18 01:46:08
Try it with a udp packet or a tcp connection - so_mark and ip rule fwmark only work for raw sockets (and maybe some other special cases), unless you're lucky and the ip(6)tables mangle module just happens to rerun the routing decision (because it mangles the packet in some other way...). The problem is that the SO_MARK mark is not used for the initial routing decision for most protocols (it _is_ used for raw sockets). There have been a few patches lately from atis@mikrotik.com that have fixed some of the outstanding problems. I have not had the opportunity to take a look at the current state of the breakage. 2009/10/17 jamal [off-list ref]:
On Sat, 2009-10-17 at 19:04 -0400, jamal wrote:quoted
This patch has worked fine in 2.6.31 and pre-31 where i tested.Ok, just to be sure - here's a simple test i just did on my laptop... ------ hadi@dogo:~$ uname -a Linux dogo 2.6.31-rc7-00001-g6da17c5-dirty #7 PREEMPT Thu Oct 15 16:35:13 EDT 2009 i686 GNU/Linux hadi@dogo:~$ ip a ls dev eth0 11: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:0b:97:97:4d:6a brd ff:ff:ff:ff:ff:ff inet 10.0.0.31/24 brd 10.0.0.255 scope global eth0 inet 10.0.0.2/32 scope global eth0 inet6 fe80::20b:97ff:fe97:4d6a/64 scope link valid_lft forever preferred_lft forever hadi@dogo:~$ ip ru ls 0: from all lookup local 15: from all fwmark 0xf lookup 15 16: from all fwmark 0x10 lookup 16 32766: from all lookup main 32767: from all lookup default hadi@dogo:~$ ip r ls table 15 208.67.217.231 via 10.0.0.1 dev eth0 src 10.0.0.31 hadi@dogo:~$ ip r ls table 16 208.67.217.231 via 10.0.0.1 dev eth0 src 10.0.0.2 hadi@dogo:~$ One ping with -m 15 -c1 to 208.67.217.231, tcpdump: 19:22:09.467555 IP 10.0.0.31 > 208.67.217.231: ICMP echo request, id 34328, seq 1, length 64 19:22:09.535429 IP 208.67.217.231 > 10.0.0.31: ICMP echo reply, id 34328, seq 1, length 64 repeat ping with -m 16 and watch tcpdump 19:23:19.731592 IP 10.0.0.2 > 208.67.217.231: ICMP echo request, id 50712, seq 1, length 64 19:23:19.790672 IP 208.67.217.231 > 10.0.0.2: ICMP echo reply, id 50712, seq 1, length 64 ------ I have also tried it with udp (hacked netcat) and i dont see any problem either What did i miss? cheers, jamal
From: jamal <hidden>
Date: 2009-10-18 11:40:50
On Sat, 2009-10-17 at 18:46 -0700, Maciej Żenczykowski wrote:
Try it with a udp packet or a tcp connection - so_mark and ip rule fwmark only work for raw sockets (and maybe some other special cases), unless you're lucky and the ip(6)tables mangle module just happens to rerun the routing decision (because it mangles the packet in some other way...).
It works fine with tcp and udp and to emphasize: i have never seen it broken. Above you mention iptables - I dont use it and that maybe the missing part in our discussion. I should note though that rpf is broken with policy routing;-> Now that you got me going on this, I will post a patch. cheers, jamal
From: Maciej Żenczykowski <hidden>
Date: 2009-10-18 22:57:14
It works fine with tcp and udp and to emphasize: i have never seen it broken.
Really? Ok, so we're doing something very differently... My testing was done on a 2.6.26 kernel (but AFAICT from browsing the code, the behaviour in question should not have changed till the last few patches posted in the last 2-3 weeks).