[туплю] iproute2 PBR пакетов с самого хоста

забыли ip route и ip rule показать :]

Так. Всё-таки туплю.

Обновлённая информация:
# traceroute -n ya.ru -s $vlan2_ip проходит нормально, как и должен.
# tcptracroute -n ya.ru -s $vlan2_ip -i $vlan2 один чёрт идёт через первый вилан, хотя и с src ip второго.
# ping -n ya.ru -s $vlan2_ip -I $vlan2 пытается найти яндекс во втором вилане на втором уровне.

# ip rou s
$vlan3_net dev $vlan3 proto kernel scope link src $vlan3_ip
$vlan2_net dev $vlan2 proto kernel scope link src $vlan2_ip
$vlan1_net dev $vlan1 proto kernel scope link src $vlan1_ip
192.168.0.0/16 via $vlan3_gw dev $vlan3 metric 1
127.0.0.0/8 dev lo scope link
default via $vlan1_gw dev $vlan1
#
# ip rou s table mytable
default via $vlan2_gw dev $vlan2 metric 1
#
# ip rule s
0: from all lookup local
32765: from $vlan2_ip lookup mytable
32766: from all lookup main
32767: from all lookup default
#

# ping -n ya.ru -s $vlan2_ip
без ручного указания интерфейса идёт через первый вилан

Итого: как задумано работают только traceroute и соединения, инициированные извне.

ip route add $vlan2_net dev $vlan2 src $vlan2_ip table mytable

# ip route add $vlan2_net dev $vlan2 src $vlan2_ip table mytable

Эквипенисуально.

Кстати, с пингом я немного обманул - без указания интерфейса он не только идёт через первый вилан, но и берёт себе IP адрес первого вилана.
При указании интерфейса уходит во второй уровень.


tcptraceroute пытается пробиться через первый вилан с src ip второго.

netcat тоже работает нормально.
# nc -s $vlan2_ip ya.ru 80

отлично отработал по нужному вилану с нужным src ip.

Нагуглил что-то из рассылок по linux-vserver.

http://www.mail-archive.com/vserver%40list.linux-vserver.org/msg00494.html

................

to our surprise, this is able to reach the
destination, and more surprisingly ...

# chbind --ip 192.168.0.2 --ip 192.168.0.3 ping -c 2 128.130.2.3
connect: Network is unreachable

will fail, as the 'original' attempt did.

what happened, is it a bug? can we use that?

basically, it isn't a bug, but it definitely
is unexpected behaviour ... the explanation
lies in the source, and the way ping works ...

ping first creates two socket()s one for ICMP
(a raw socket) and one for IP (UDP), to send
and receive the the packets ... the latter is
connect()ed with src=0.0.0.0 and the dest.
address used in the ping, which explains the
'Network is unreachable' cases, but not the
success of chbind/ping with one ip ...

.....................


Возможно, это личные проблемы пинга и tcptraceroute, а нас самом деле всё и так работает?

у меня на каждый аплинк по таблице как в мануале классическом описано
и трэйс и пинг ходит как надо :-\

Трейс и пинг с самого роутера, не с клиентов, сидящих за ним?
Аплинки на разных интерфейсах?

ping создаёт сокет для udp !? oO
эээ, а зачем? :-\

hizel@grouter ~ $ sudo ip rule sh
Password:
0:      from all lookup local
32764:  from 192.168.5.2 lookup eth1_table
32765:  from 192.168.2.2 lookup eth0_table
32766:  from all lookup main
32767:  from all lookup default
hizel@grouter ~ $ sudo ip route sh
192.168.5.0/24 dev eth1  proto kernel  scope link  src 192.168.5.2
192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.2
172.20.0.0/16 dev eth2  proto kernel  scope link  src 172.20.0.1
127.0.0.0/8 dev lo  scope link
default
        nexthop via 192.168.2.1  dev eth0 weight 1
        nexthop via 192.168.5.1  dev eth1 weight 1
hizel@grouter ~ $ sudo ip route sh table eth0_table
192.168.5.0/24 dev eth1  scope link
192.168.2.0/24 dev eth0  scope link  src 192.168.2.2
127.0.0.0/8 dev lo  scope link
default via 192.168.2.1 dev eth0
hizel@grouter ~ $ sudo ip route sh table eth1_table
192.168.5.0/24 dev eth1  scope link  src 192.168.5.2
192.168.2.0/24 dev eth0  scope link
127.0.0.0/8 dev lo  scope link
default via 192.168.5.1 dev eth1

hizel@grouter ~ $ sudo /usr/sbin/traceroute-nanog -s 192.168.5.2 ya.ru
traceroute to ya.ru (93.158.134.8) from 192.168.5.2, 64 hops max, 40 byte packets
 1  192.168.5.1 (192.168.5.1)  1 ms  2 ms  2 ms
 2  hizel (192.168.1.1)  2 ms  2 ms  2 ms
 .....
 6  aurora-spb-ix.yandex.net (194.85.177.90)  13 ms  10 ms  8 ms
 7  apollo-vlan304.yandex.net (213.180.208.101)  16 ms  16 ms  17 ms
 8  grechko-vlan121.yandex.net (87.250.233.109)  20 ms  18 ms  19 ms
 9  odin-vlan4.yandex.net (213.180.210.187)  22 ms^C
hizel@grouter ~ $ sudo /usr/sbin/traceroute-nanog -s 192.168.2.2 ya.ru
traceroute to ya.ru (213.180.204.8) from 192.168.2.2, 64 hops max, 40 byte packets
 1  192.168.2.1 (192.168.2.1)  2 ms  1 ms  2 ms
 2  hizel (192.168.1.1)  2 ms  2 ms  2 ms
  .....
 6  aurora-spb-ix.yandex.net (194.85.177.90)  7 ms  8 ms  9 ms
 7  plutonium-vlan934.yandex.net (213.180.208.14)  21 ms  21 ms  19 ms
 8  ya.ru (213.180.204.8)  21 ms  20 ms  19 ms

Теперь туплю я. Поясни плз физический смысл первых трех записей в "интерфейсных" таблицах, например
>192.168.5.0/24 dev eth1  scope link
>192.168.2.0/24 dev eth0  scope link  src 192.168.2.2
>127.0.0.0/8 dev lo  scope link

Я, конечно, не спец по iproute2, но разве там не достаточно только дефолтного шлюза?

Для полноты картины поставил traceroute-nanog и mtr. traceroute-nanog тоже плюёт на мои таблицы маршрутизации и идёт по дефолту, а вот mtr работает как задумано..


Сделал подобие вот этого:

> default
> nexthop via 192.168.2.1 dev eth0 weight 1
> nexthop via 192.168.5.1 dev eth1 weight 1

правильно заработал пинг..
по прежнему правильно работают netcat, traceroute, mtr.
А traceroute-nanog и tcptraceroute начали проивзольно выбирать себе маршрут.

Чудеса какие-то.

Правильно. Это балансировка блин!
Для того трафика, который по рулезам не прошел, т.е. транзитного.

Полагаю, тебе прежде всего нужно добавить рулезы для обоих исходящих айпишников. На примере выше
>32764: from 192.168.5.2 lookup eth1_table
>32765: from 192.168.2.2 lookup eth0_table

Ну и роуты по аналогии с тем примером.