URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 72223
[ Назад ]

Исходное сообщение
"Баг или фича iproute2 и что тогда делать?"

Отправлено besarg , 15-Фев-07 10:50 
Привет. Буду краток, суть будет ясна:
схема
<192.168.0.0/24> - <eth1-192.168.0.1 шлюз eth0-10.0.0.2>-<10.0.0.1 пров>
естественно default gw 10.0.0.1

пров добавляет gw 10.10.10.1 для обслуживания сети 192.168.1.0/24
делаем подобную схему:
<192.168.1.0/24> - <eth2-192.168.1.1 шлюз eth0:1-10.10.10.2>-<10.10.10.1 пров>
пишем правила для iproute2 в итоге имея:
0:      from all lookup 255
32763:  from 10.10.10.0/30 lookup T2
32764:  from 192.168.14.0/24 lookup T2
32766:  from all lookup main
32767:  from all lookup default
$ ip route list table T2
10.10.10.0/30 via 10.10.10.2 dev eth0
192.168.1.0/24 via 192.168.1.1 dev eth2
default via 10.10.10.1 dev eth0

обратите внимание на название интерфейса eth0, должен быть eth0:1 забиваемый правилом:
ip route add default via 10.10.10.1 dev eth0:1 table T2
(об этом ниже)

в данной схеме все запросы из сети 192.168.1.0/24 всё равно продолжают идти по default gw  10.0.0.1, хотя правила чётко говорят что нужно идти по 10.10.10.1

Подключаем ещё один физический интерфейс eth3, и на него сажаем 10.10.10.2 поменяв в таблице роутинга на default via 10.10.10.1 dev eth3. Тут всё приходит в норму, все запросы идут туда, куда им сказано.

iproute2 не умеет оперировать с разными таблицами, если они указывают на единый _физический_ интерфейс? Это баг или фича?

Что мне тогда делать в этой ситуации, если связь с провом только через 1 канал и один физический интерфейс?


Содержание

Сообщения в этом обсуждении
"Баг или фича iproute2 и что тогда делать?"
Отправлено besarg , 15-Фев-07 10:51 
да опять опечатка! :(
>32764:  from 192.168.14.0/24 lookup T2
тут конечно
32764:  from 192.168.1.0/24 lookup T2

"Баг или фича iproute2 и что тогда делать?"
Отправлено pavel_simple , 15-Фев-07 11:07 
Это баг или фича? -- тут подсказать не смогу -- так ли оно вообще или нет.
А как насчёт создать виртуальный интерфейс другого рода (dummy, tap , vlan) и посадить их через бридж на eth0

"Баг или фича iproute2 и что тогда делать?"
Отправлено besarg , 15-Фев-07 11:51 
>Это баг или фича? -- тут подсказать не смогу -- так ли
>оно вообще или нет.
>А как насчёт создать виртуальный интерфейс другого рода (dummy, tap , vlan)
>и посадить их через бридж на eth0

не получается с бриджем. вкратце вот так:
$ ip route add 0/0 via 10.10.10.1 dev br0 table T2
RTNETLINK answers: Network is unreachable
где br0 бридж из eth2 и eth0:1
мне кажется требует наличие точной связки ip - interface.


"Баг или фича iproute2 и что тогда делать?"
Отправлено s_dog , 15-Фев-07 12:19 
В качестве эксперимента добавил на интерфейс алиас (eth0:1)
в /sbin/ip route list table all eth0:1  не появился, просто добавились записи
~ /sbin/ip route list table all | grep 192.168
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.1
local 192.168.1.1 dev eth0  table local  proto kernel  scope host  src 192.168.1.1
broadcast 192.168.1.0 dev eth0  table local  proto kernel  scope link  src 192.168.1.1
broadcast 192.168.1.255 dev eth0  table local  proto kernel  scope link  src 192.168.1.1

Получается надо указывать физический интерфейс.


"Баг или фича iproute2 и что тогда делать?"
Отправлено besarg , 15-Фев-07 12:27 
>В качестве эксперимента добавил на интерфейс алиас (eth0:1)
>в /sbin/ip route list table all eth0:1  не появился, просто добавились
>записи
>~ /sbin/ip route list table all | grep 192.168
>192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.1
>
>local 192.168.1.1 dev eth0  table local  proto kernel  scope
>host  src 192.168.1.1
>broadcast 192.168.1.0 dev eth0  table local  proto kernel  scope
>link  src 192.168.1.1
>broadcast 192.168.1.255 dev eth0  table local  proto kernel  scope
>link  src 192.168.1.1
>
>Получается надо указывать физический интерфейс.


то есть средствами iproute2 запланированное мероприятие сделать невозможно?
прелестно.. а какие ещё пути задания маршрутов в linux есть?


"Баг или фича iproute2 и что тогда делать?"
Отправлено besarg , 15-Фев-07 12:53 
>>В качестве эксперимента добавил на интерфейс алиас (eth0:1)
>>в /sbin/ip route list table all eth0:1  не появился, просто добавились
>>записи
>>~ /sbin/ip route list table all | grep 192.168
>>192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.1
>>
>>local 192.168.1.1 dev eth0  table local  proto kernel  scope
>>host  src 192.168.1.1
>>broadcast 192.168.1.0 dev eth0  table local  proto kernel  scope
>>link  src 192.168.1.1
>>broadcast 192.168.1.255 dev eth0  table local  proto kernel  scope
>>link  src 192.168.1.1
>>
>>Получается надо указывать физический интерфейс.
>
>
>то есть средствами iproute2 запланированное мероприятие сделать невозможно?
>прелестно.. а какие ещё пути задания маршрутов в linux есть?

пока не спорол горячку с установкой другой ОС, поинтересуюсь, возможно ли исполнить вышеуказанную схему с одним физическим интерфейсом на 2-а и более маршрутов например в freebsd? в принципе с бсд я знаком, но в нюансах, как например вышеописанный, опасаюсь аналогичной ситуации.

p.s. покупать нормальный роутер циско нет денег


"Баг или фича iproute2 и что тогда делать?"
Отправлено s_dog , 15-Фев-07 12:56 
Давно не занимался таким, интуиция подсказывает что это возможно ;))

На закуску:
http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html


"Баг или фича iproute2 и что тогда делать?"
Отправлено s_dog , 15-Фев-07 13:02 
ip route default table T2 via 10.10.10.1
Не поможет?

"Баг или фича iproute2 и что тогда делать?"
Отправлено besarg , 15-Фев-07 13:16 
>ip route default table T2 via 10.10.10.1
>Не поможет?

$ ip route add default table T2 via 10.10.10.1
RTNETLINK answers: File exists
не поможет.

читаю доку по вашей ссылке, пока ничего путного додумать немогу :(


"Баг или фича iproute2 и что тогда делать?"
Отправлено s_dog , 15-Фев-07 13:54 
>>ip route default table T2 via 10.10.10.1
>>Не поможет?
>
>$ ip route add default table T2 via 10.10.10.1
>RTNETLINK answers: File exists
>не поможет.
>
>читаю доку по вашей ссылке, пока ничего путного додумать немогу :(


ip route del default table T2
ip route add default table T2 via 10.10.10.1

http://www.lartc.org/lartc.pdf
http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html


"Баг или фича iproute2 и что тогда делать?"
Отправлено besarg , 15-Фев-07 14:24 
>>>ip route default table T2 via 10.10.10.1
>>>Не поможет?
>>
>>$ ip route add default table T2 via 10.10.10.1
>>RTNETLINK answers: File exists
>>не поможет.
>>
>>читаю доку по вашей ссылке, пока ничего путного додумать немогу :(
>
>
>ip route del default table T2
>ip route add default table T2 via 10.10.10.1

да я к тому что такая запись уже присутствует, нет смысла удалять, чтобы потом вставить.
default via 10.10.10.1 dev eth0

>http://www.lartc.org/lartc.pdf
>http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html

но вот хоть убей не понимаю, что не работает. задачу уже просто сминимизировал:
необходимо чтобы со шлюза, где default gw 10.0.0.1, пакеты с адреса 10.10.10.2 шли через 10.10.10.1:

ip addr add 10.10.10.2/30 dev eth0 brd +
ip rule add from 10.10.10.2 table T2
ip route add 10.10.10.0/30 via 10.10.10.2 table T2
ip route add default table T2 via 10.10.10.1
#или сути не меняет такая запись ip route add 0/0 via 10.10.10.1 table T2
ip route flush cache

ну вот всё ведь верно

ip route list table T2
10.10.10.0/30 via 10.10.10.2 dev eth0
default via 10.10.10.1 dev eth0

ip rule ls            
0:      from all lookup 255
32765:  from 10.10.10.2 lookup T2
32766:  from all lookup main
32767:  from all lookup default

однако:
$ traceroute -n ya.ru -s 10.10.10.2
traceroute to ya.ru (213.180.204.8) from 10.10.10.2, 30 hops max, 40 byte packets
1  10.0.0.1  2.057 ms  0.867 ms  1.653 ms

аааа, я щас лопну :(


"Баг или фича iproute2 и что тогда делать?"
Отправлено s_dog , 15-Фев-07 14:56 
Поковыряй
http://linux-ip.net/gl/ip-cref/node101.html

что даёт
ip route get 10.10.10.1 from 10.10.10.2 iif eth1
ip route get 10.10.10.1 from 10.10.10.2 iif eth0
?

Бывает так что ошибка на поверхности, или в мелком нюансе, а ты её не замечаешь ;)
Don't worry.

Попробуй начать с начала. Ведь у людей работает же ;)


"Баг или фича iproute2 и что тогда делать?"
Отправлено perece , 15-Фев-07 17:05 
>но вот хоть убей не понимаю, что не работает. задачу уже просто
>сминимизировал:
>необходимо чтобы со шлюза, где default gw 10.0.0.1, пакеты с адреса 10.10.10.2
>шли через 10.10.10.1:
>
>ip addr add 10.10.10.2/30 dev eth0 brd +
>ip rule add from 10.10.10.2 table T2
>ip route add 10.10.10.0/30 via 10.10.10.2 table T2
>ip route add default table T2 via 10.10.10.1
>#или сути не меняет такая запись ip route add 0/0 via 10.10.10.1
>table T2
>ip route flush cache
а можно ли это так сокращать? я всегда пишу 'flush table cache'
и без этого не заработает.
>
>ну вот всё ведь верно
>
>ip route list table T2
>10.10.10.0/30 via 10.10.10.2 dev eth0
>default via 10.10.10.1 dev eth0
>
>ip rule ls
>0:      from all lookup 255
>32765:  from 10.10.10.2 lookup T2
>32766:  from all lookup main
>32767:  from all lookup default
>
>
>однако:
>$ traceroute -n ya.ru -s 10.10.10.2
>traceroute to ya.ru (213.180.204.8) from 10.10.10.2, 30 hops max, 40 byte packets
>
> 1  10.0.0.1  2.057 ms  0.867 ms  1.653
>ms

вы вообще в курсе, как traceroute работает? если 10.10.10.1 и 10.0.0.1 - одна и та же железка физически, то она имеет право (и лево) так отвечать, даже если пакет ушел от вас с dst MAC отрезолвенным по 10.10.10.1
и кста... о MAC: а они отличаются вообще?
arp -n | grep eth0
?

\^P^/


"Баг или фича iproute2 и что тогда делать?"
Отправлено besarg , 16-Фев-07 05:34 
>>но вот хоть убей не понимаю, что не работает. задачу уже просто
>>сминимизировал:
>>необходимо чтобы со шлюза, где default gw 10.0.0.1, пакеты с адреса 10.10.10.2
>>шли через 10.10.10.1:
>>
>>ip addr add 10.10.10.2/30 dev eth0 brd +
>>ip rule add from 10.10.10.2 table T2
>>ip route add 10.10.10.0/30 via 10.10.10.2 table T2
>>ip route add default table T2 via 10.10.10.1
>>#или сути не меняет такая запись ip route add 0/0 via 10.10.10.1
>>table T2
>>ip route flush cache
>а можно ли это так сокращать? я всегда пишу 'flush table cache'

в документации так и пишут, возьму ваш совет на вооружение

>
>и без этого не заработает.
>>
>>ну вот всё ведь верно
>>
>>ip route list table T2
>>10.10.10.0/30 via 10.10.10.2 dev eth0
>>default via 10.10.10.1 dev eth0
>>
>>ip rule ls
>>0:      from all lookup 255
>>32765:  from 10.10.10.2 lookup T2
>>32766:  from all lookup main
>>32767:  from all lookup default
>>
>>
>>однако:
>>$ traceroute -n ya.ru -s 10.10.10.2
>>traceroute to ya.ru (213.180.204.8) from 10.10.10.2, 30 hops max, 40 byte packets
>>
>> 1  10.0.0.1  2.057 ms  0.867 ms  1.653
>>ms
>
>вы вообще в курсе, как traceroute работает? если 10.10.10.1 и 10.0.0.1 -
>одна и та же железка физически, то она имеет право (и

да, это порт на циске у прова.

>лево) так отвечать, даже если пакет ушел от вас с dst
>MAC отрезолвенным по 10.10.10.1

то есть, в моём случае 10.10.10.1 не видать как следующих hop? или как мне посмотреть более внятно чем traceroute? ( ещё использую mtr-tiny)

>и кста... о MAC: а они отличаются вообще?
>arp -n | grep eth0
>?
естеcтвенно совпадает, я же делал (выше описано) так:

ip addr add 10.10.10.2/30 dev eth0 brd +

но ваша мысль о том, что мне необходимо назначить другой mac?

>
>\^P^/
я сделал ip route add default via 10.10.10.1 для table main , а не для конкретной T2, и результат меня удивил, следующий hop всегда 10.0.0.1  и обратно ничего не возвращается.
Похоже что пров просто заворачивает с 10.10.10.1 на 10.0.0.1
Так что проблема не в iproute2, а в недоделанной настройке прова. Но это пока лишь догадки, продолжаю изучение.



"Баг или фича iproute2 и что тогда делать?"
Отправлено besarg , 16-Фев-07 08:22 
Всем спасибо, тема закрыта. Проблема была в неправильно настроенном интерфейсе у прова. Впрочем это дало мне кучу знаний по iproute2 :) Всё что не делается всё к лучшему.