LINUX.ORG.RU
ФорумAdmin

SIOCADDRT: No such process (ну как так-то, ну)

 


0

2

job# ping 192.168.2.10
PING 192.168.2.10 (192.168.2.10) 56(84) bytes of data.
64 bytes from 192.168.2.10: icmp_req=1 ttl=64 time=10.8 ms
64 bytes from 192.168.2.10: icmp_req=2 ttl=64 time=7.54 ms
64 bytes from 192.168.2.10: icmp_req=3 ttl=64 time=13.1 ms
^C
--- 192.168.2.10 ping statistics —-
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 7.545/10.513/13.141/2.297 ms
job#
job#
job#
job# route add -net 10.0.0.0/8 gw 192.168.2.10
SIOCADDRT: No such process

что я провтыкал? хост, который предполагается использовать как шлюз пингуется, но как роут не ставится (фаер на нём разрешает forward, форвардинг также включён, сорри за тофтологию)
театр военных действий: dl-804hv. этот самый job - во внутренней сети 192.168.0.199, а 192.168.2.10 - vpn клиент (настроен через pptp-linux) со своей локалкой 10.0.0.0/8
варианты типа route add -net 10.0.0.0/8 gw 192.168.2.10 dev eth0 тоже перепробовал...

★★★

ifconfig покажи может ты в другой подсети и пытаешься source-based routing поднять, кто ж тебя знает? и да, плюсую предыдущего оратора насчет iproute вместо route

Pinkbyte ★★★★★
()
Ответ на: комментарий от pyatak123

Ты ловишь на лету, прям, братиш, держи 3.14 респекта, смотри не потеряй.
Я бы например не понял, что идея в опускании нулевых октетов.
Команда ping 127.1 какбэ намекает нам что это не специфичное для ip поведение.
Мм...надо rfc кстати найти будет, чтобы более лучше понтоваться

zolden ★★★★★
()
Ответ на: комментарий от zolden

Не знаю относительно rfc, но к «ping 127.1» относится «man inet_aton». А указании сети без лишних нулей это что-то другое.

mky ★★★★★
()
Ответ на: комментарий от beastie

А что не так-то с этим ip? Вполне кошерный интерфейс для управления сетевыми девайсами, его команды понятны и логичны, легко сокращаются и запоминаются. Всяко лучше, чем ваши древние ифконфиги, роуты.

anonymous
()
Ответ на: комментарий от pyatak123

вряд ли... нам про эту фичу рассказывал в универе препод по сетям ещё лет 12 назад, тогда IPv6 был ещё в стадии ранних чёрновиков, думаю

zolden ★★★★★
()
Ответ на: комментарий от pyatak123

Вполне возможно что, да.

Вот в rfc1918 «Address Allocation for Private Internets», февраль 1996, уже использовано 10/8, 172.16/12 и 192.168/16, причём без объяснения записи. Хотя в более ранних rfc, где объяснялась что такое «бесклассовая» сеть и маска, такой записи не видно.

А первые стандарты по ipv6 (rfc1883, rfc1884) вышли в декабре 1995.

mky ★★★★★
()
Ответ на: комментарий от anonymous

а то, что это очередной линуксячий велосипед-комбайн в стиле «а давайте напишем ещё один кривой интерфейс к тому, что уже есть и хорошо работает».

beastie ★★★★★
()
Ответ на: комментарий от mky

Немного смущает, что «бесклассовое» rfc более раннее... А так, да, с точки зрения privete nets такие записи даже лучше выглядят.

pyatak123
()
Ответ на: комментарий от pyatak123

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
link/ether 00:01:6c:ad:de:fd brd ff:ff:ff:ff:ff:ff
inet 192.168.0.199/24 brd 192.168.0.255 scope global eth0
inet6 fe80::201:6cff:fead:defd/64 scope link
valid_lft forever preferred_lft forever

flant ★★★
() автор топика
Ответ на: комментарий от pyatak123

потому что это впн клиент. он логически не в сети, а физически-то длинк всем даёт доступ друг для друга. или ложно утверждение «шлюзом можно назначить любой хост в зоне прямой видимости»?

flant ★★★
() автор топика
Ответ на: комментарий от flant

Что это такое за утверждение??? Прямой видимости, если я вижу из окна соседский д-линк, что я могу его адрес, шлюзом прописать что ле? Если вы привели весь выхлоп

ip a
то адресом шлюза может быть хост с подсети 192.168.0.0/24.

pyatak123
()
Ответ на: комментарий от pyatak123

ну ок, почему тогда я не могу его установить как шлюз, если я его пингую и могу подключаться, взаимодействовать, как если бы между нами был кроссовый кабель...?

flant ★★★
() автор топика
Ответ на: комментарий от flant

Потому что ты делаешь это через шлюз, который видать у тебя в качестве дефолтонго. Для того что бы общаться с хостом из другой подсети тебе необходим маршрутизатор. Да, и, кроссовый кабель это канальный уровень, а маршрутизация - сетевой. Не путай.

pyatak123
()
Ответ на: комментарий от pyatak123

Вся магия в статической арп записи
изначально это мы обсуждали маршрут для хоста с интерфейсом в /32 сети, но ты ловишь на лету, так что сам проведёшь аналогии

1-ый хост:
ip addr add 192.168.67.50/32 dev eth0
ip neigh add 192.168.67.30 lladdr xx:xx:xx:xx:xx:xx nud permanent dev eth0
ip route add 192.168.67.30/32 dev eth0
2-ой хост:
ip addr add 192.168.67.30 dev eth0
ip neigh add 192.168.67.50 lladdr xx:xx:xx:xx:xx:xx nud permanent dev eth0
ip route add 192.168.67.50/32 dev eth0

zolden ★★★★★
()
Ответ на: комментарий от zolden

Круто! А ты сам пробовал такое замутить? Я вот добавил в таблицу hw address хоста не входящего в подсеть интерфейса, а при добавлении рутинга получил no such process.

pyatak123
()
Ответ на: комментарий от zolden

Да работает, заинтересовал ты меня. Сделал как написано, получилось.

pyatak123
()
Ответ на: комментарий от zolden

zolden крутой чел! Хорошие штуки посонам рассказывает!!

pyatak123
()
Ответ на: комментарий от flant

а про ТС мы то и забыли...
Думаю будет работать, но всё-таки это скорее хак и для коммерческой эксплуатации я бы его не рекомендовал.
Лучше всё-таки сделать по стандартам, когда хост и шлюз торчат в одной подсети

zolden ★★★★★
()

когда ты создаёшь ppp vpn, то у тебя должны быть два конца ppp0 с одной и сдругой стороны и оба эти адреса должны быть /32, так вот ты свой и укажи в качестве шлюза.

dimon555 ★★★★★
()
Ответ на: комментарий от flant

Тут обсуждается прописывание маршрута на тот случай, когда ip-адреса не в одной ip-сети, но в одной ethernet-сети. Если у вас работает аrping до вашего желаемого шлюза, то поедет.

Вобще можно писать маршрут на любой хост:

ip route add 1.2.3.4 dev eth0

но если 1.2.3.4 не отвечает на arp-запросы, тогда нужно прописывать запись в arp-таблицу через «ip neigh». Ещё можно добавлять магическое слово «onlink»:

ip route add 1.2.3.0/24 via 4.5.6.7 dev eth0 onlink

или ложно утверждение «шлюзом можно назначить любой хост в зоне прямой видимости»?

Что в это утверждении подразумевается (на ваш взгляд) под «прямой видимостью»?

mky ★★★★★
()
Ответ на: комментарий от mky

под прямой видимостью, думаю, имеется в виду связность на L3
мне честно говоря до сих пор кажутся нелогичными ограничения на дефолтный шлюз, и раз в год я всё пытаюсь назначить адрес из другой сети...

zolden ★★★★★
()
Ответ на: комментарий от mky

прямая видимость это когда доходят пинги. согласен, что это достаточно кривое определение, но прсто так выразился )
кстати, мне тут посоветовали, что можно воспользоваться и vlan'ами

flant ★★★
() автор топика
Ответ на: комментарий от zolden

onlink означает, что шлюз, через который прописывается маршрут в одной «физической» сети, допустим в одном сегменте ethernet, не смотря на то, что в другой ip-подсети.

На примере ethernet это означает, что шлюз ответит на arp-запрос. Допустим в одном сегменте ethernet компьютеру назначен адрес 10.1.1.1/32, а шлюз имеет адрес 10.5.1.1, за ним сеть 192.168.2.0/24, то прописываем маршрут с опцией onlink:

ip route add 192.168.2.0/24 via 10.5.1.1 onlink

Маршрут пропишется и когда нужно будет отправить пакет в сеть 192.168.2.0, будет отправлен arp-запрос, определён mac-адрес 10.5.1.1 и пакет будет отправлен по этому mac-адресу.

Пример тут высосан из пальца, «серых» ip-адресов много. Реально это может пригодится, когда провайдер дал маленькую подсетку «белых» ip-адресов прямо на порту своего маршрутизатора и лишних ip-адресов нет, а хочется весь internet трафик пустить через свой шлюз.

mky ★★★★★
()
Ответ на: комментарий от flant

Нет, пинги ведь доходят куда угодно, до DNS-серверов googla, допустим. Под прямой видимостью подразумевалось когда два хоста могут взаимодействовать (пересылать пакеты) без помощи третьего хоста.

Когда прописывается ip-маршрут, то ip-адрес шлюза это вобще лишняя сущность. В задаче маршрутизации, в случае соединения точка-точка (например, ppp) нужно определить интерфейс, через который отправить пакет и не важно, какой ip-адрес с другой стороны линка. В случае ethernet нужно просто узнать mac-адрес шлюза и оправить ip-пакет на этот mac-адрес. В теории, в случае ethernet в маршруте можно было бы указывать не ip-адрес шлюза, а его mac-адрес, но это неудобно.

можно воспользоваться и vlan'ами

Я не знаю конфигурацию вашей сети, может vlan'ами, может тунелями (gre).

mky ★★★★★
()
Ответ на: комментарий от mky

плюс, может заодно расскажешь про опцию pervasive? она упоминается рядом с onlink в мане, но смысл вообще не описан

zolden ★★★★★
()
Ответ на: комментарий от zolden

Это история, покрытая мраком. Эта опция должна ставить у маршрута (в ядре) флаг RTNH_F_PERVASIVE, который был добавлен в экспериментальных ядрах 2.1.x с комментарием «Do recursive gateway lookup», то есть что-то связанное с multilink'ом.

Активизация кода ядра по обработке таких маршрутов подразумевалась опцией сборки ядра CONFIG_IP_ROUTE_PERVASIVE, которая существовала только в исходном коде ядра, но не была доступна через make confing/make menuconfig. Да и кода самого не было, заглушка и всё, хотя, может если просмотреть все ядра 2.1.x, то может какой код и найдётся. Где то в середине ветки 2.6.x CONFIG_IP_ROUTE_PERVASIVE из ядра убрали.

mky ★★★★★
()
Ответ на: комментарий от zolden

Статический arp будет нужен, если тот хост настроен так, что отвечает на arp-запросы только от своей посети. Насколько я помню, по умолчанию Линукс отвечает на любые arp-запросы, а вот Cisco только на запросы от своей подсети.

Хотя может есть возможность настроить от какого ip-адреса отправлять arp-запросы.

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.