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

route add  -net 10.0.0.0 netmask 255.0.0.0 dev eth0

А вообще

ip route add 10.0.0.0/8 via 192.168.2.10

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

ip route add 10.0.0.0/8 via 192.168.2.10

ты ненастоящий хакир, смотри, как экономят байты тру перцы
ip r a 10/8 via 192.168.1.128

а вот, тому, кто придумал ip я бы лично censored.

Насчет 10/8 это хорошо! Буду знать!

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

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

Это ipv6 )

На самом деле это похоже на классовую адресацию, но скорее всего ipv6 way.

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

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

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

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

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

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

Хороший у вас универ.

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

job# ip r a 10/8 via 192.168.2.10
RTNETLINK answers: No such process

замена на поле (

ip a

что напишет?

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

Красава Вован

Что же ты gw назначаешь, который не в сети твоего интерфейса????

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

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

ip a

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

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

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

а что спорим, что не обязательно :)

А давай!)

Вся магия в статической арп записи
изначально это мы обсуждали маршрут для хоста с интерфейсом в /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

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

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

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

то есть вот эта история поедет и с /24, то есть в моём случае?

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

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

Тут обсуждается прописывание маршрута на тот случай, когда 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

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

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

расскажи плз про onlink, из мана не очень догоняю смысл

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

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

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 трафик пустить через свой шлюз.

т.е. получается можно не париться со статическими arp?

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

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

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

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

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

Это история, покрытая мраком. Эта опция должна ставить у маршрута (в ядре) флаг 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 из ядра убрали.

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

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