Проблема маршрутизации в Ubuntu

Может нужно добавить маршрут на 10.0.100.35?

up route add -net 10.0.0.0 netmask 255.255.0.0 gw 10.10.0.254 dev eth0

По идее должна показать где искать хост, но даже если оставить только

up route add -net 10.0.100.35 netmask 255.255.255.255 gw 10.10.0.254 dev eth0
up route add -net 0.0.0.0 netmask 255.255.255.255 gw 10.0.100.35 dev eth0

то выдает такую же фигню SIOCADDRT: No such process

Если ты пропишешь поднятие этих маршрутов для другого интерфейса, то все заработает. Был такой баг и у меня когда-то. Заметил только одну закономерность, что если при установке системы не назначать интерфейсу статический адрес, а получать через DHCP, то после смены с DHCP на статику, при прописывании этому интерфейсу post и post-up команд, была такая же ошибка при поднятии интерфейса. Так как на машине было несколько интерфейсов, разбираться сильно не стал, и прописал маршруты при поднятии другого интерфейса - все заработало.

Пропиши эти маршруты при поднятии lo интерфейса.

Спасибо, но все равно не помогло. Если указать гейт по умолчанию до инициализации eth0, то в таблице роутов вообще ниче не будет, если после, то ошибка No such process.

>up route add -net 0.0.0.0 netmask 255.255.255.255 gw 10.0.100.35 dev eth0

А маска для дефолтного маршрута не должна быть 0.0.0.0?

Я и так пробовал
up route add default gw 10.0.100.35 dev eth0

Тогда, помимо маски на дефолтный маршрут, попробуй везде заменить up на post-up - может, поможет.

И попробуй один раз перед тем, как делать invoke-rc.d networking start, выполнить ifconfig eth0 down - иногда, при изменении настройки интерфейсов, помогает. Потом, если нормально запустится, будет не нужно.

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

route add default gw 10.0.100.35
не помогает?

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

Уже попробовал вручную :(

Результат тот же, что у автора треда.

Запостил на форумы убунты - может там чего подскажут:

http://ubuntuforums.org/showthread.php?t=1158036

>up route add -net 10.10.0.0 netmask 255.255.255.0 gw 10.10.0.254 dev eth0
>up route add -net 10.0.0.0 netmask 255.255.0.0 gw 10.10.0.254 dev eth0
>up route add -net 0.0.0.0 netmask 255.255.255.255 gw 10.0.100.35 dev eth0

так писать нельзя. а что, на 10.10.0.254 настроить маршрутизацию нельзя?
короче, без карты твоей сети и решений по дизайну, которые заставили так сделать, ничем помочь не могу. есть серьезное подозрение, что ты лезешь за гландами через жопу.
кстати, default gateway это 0.0.0.0/0

Немного почти оффтопа:

val-amart, вот пример из жизни (чего я собственно так и заинтересовался этим тредом):

Есть машина в подсети А. Для всех машин в этой подсети есть дефолтный шлюз а1. Для него в свою очередь дефолтный шлюз - б1 в подсети Б. Для б1 дефолт гейтвей где-то в сети провайдера 1.

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

Теперь мы хотим для нескольких машин из подсети А устроить тестовую эксплуатацию нового линка. Менять настройки шлюза а1 (а тем более б1, через который в инет ходит десятка два подсетей) нам не с руки - это только тест, и если линк упадет (в жизни он действительно падал, и не раз :) ), мы помешаем работе большого количества пользователей.

Стало быть, надо тестовым машинам в подсети А указать в настройках новый дефолт шлюз - б2 из подсети Б, и играться новым линком сколько влезет. Дык вот, для машин под оффтопичной системой этот фокус прошел на ура, а с Убунтой были проблемы. В конце концов, новый линк таки потестили как хотели - но это уже совсем другая история. А вопросы про Убунту остались.

Теперь по теме:

Лазанье по форуму Убунты навело на мысль (хоть прямых указаний на это и не было), что отказ добавлять шлюз по умолчанию из другой подсети может быть связан с активностью замечательной тулзы NetworkManager.

matyas13,

Если ты планируешь использовать только статические настройки сети - попробуй удалить из системы NetworkManager, и посмотреть, как оно будет. Я до машин под 8.04, с которых он был снесен за ненадобностью, раньше вторника не доберусь - потому сам проверить сейчас не могу.

тут у вас проблемы не с убунту, а с оффтопиком, по рфц так делать нельзя.
корректные решения:
настроить дефолтгейт через б2 на а1 только для тестовых машин из сети А, остальных дальше пускать через б1. таким образом, конфигурировать надо только а1, а не десятки машин
Перенести тестовые машины из сети А в Б. физически, вланами, впном, да как угодно.
перенести б2 в сеть А. например, просто дополнительным портом с адресом из сети А.

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

>Перенести тестовые машины из сети А в Б. физически, вланами, впном, да как угодно.

Так и сделали. Настроили соотв. порты на свичах в vlan для подсети Б. Но все равно - абыдна, да.

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

Пробовали и так и так. Поимели ряд небольших, но неприятных глюков - а1 и б1 достаточно нагруженные и не очень новые. В общем, не стоило оно колупаний - нам всего несколько машин погонять надо было, так что вариант с вланом все успешно решил.

P.S. А какой РФЦ (номер) запрещает настройку дефолтного шлюза в другой подсети, если путь к ней известен? Хочу почитать, дабы впредь так не морочиться.

> Пробовали и так и так. Поимели ряд небольших, но неприятных глюков - а1 и б1 достаточно нагруженные и не очень новые. В общем, не стоило оно колупаний - нам всего несколько машин погонять надо было, так что вариант с вланом все успешно решил.
Так бы и написал - ниасилили настроить роутер.

> P.S. А какой РФЦ (номер) запрещает настройку дефолтного шлюза в другой подсети, если путь к ней известен? Хочу почитать, дабы впредь так не морочиться.
internet host requirements, в секции про роутинг (1122, если память мне не изменяет).
похоже, ты вообще слабо представляешь, как работает routing algorithm, и путаешь routing table с routing cache. поэтому читай также 823.
дело в том, что роутер (по рфц) проходит по таблице маршрутов только однажды. ну, вот нашел он маршрут в сеть Z через маршрутизатор b2 (он находится в другой подсети, за другим ротером). дальше он попытается разрешить этот ip в mac, и конечно будет fail и ICMP type 3 code 1. Кстати, еще один вариант решения проблемы - настроить прозрачный арп-прокси на роутере а1, т.е. заставить его отзываться на арп-запросы к ип б2 и форвардить такие пакеты ему. но это еще больший изврат, и на многих современных НОС (убунте тоже, хаха) работать не будет.

>Так бы и написал - ниасилили настроить роутер.

Вай, дарагой. Даже отвечать на такое не хочется. Так и я могу сказать: "да ты рутеры только на картинках видел" - но это ж будет неправда. А в моем случае - как было, так и написал. Конкретно а1 и б1 - это L3 свичи cat4507, на каждом из которых проц загружен примерно на 60%. Если ты думаешь, что идеальная операционка IOS (точно версию, извини, не скажу - в отпуске сейчас) в таких условиях работает замечательно, и аж побежала тебе слать пакеты от хоста Зю через шлюз Кю, как только ты ей роут-мэп прописал и щелкнул пальцами - значит, у тебя впереди еще много увлекательных открытий :) В нашем случае это выглядело так: с тестовых хостов около 90% пакетов шло через новый шлюз, а около 10% - через старый. И не в моих или моих коллег кривых руках тут дело, да.

>похоже, ты вообще слабо представляешь, как работает routing algorithm, и путаешь routing table с routing cache. поэтому читай также 823.

Дядьку телепат, опять я рад за тебя безумно :) А за РФЦ 1122 - пасиб, почитаю.

>дело в том, что роутер (по рфц) проходит по таблице маршрутов только однажды. ну, вот нашел он маршрут в сеть Z через маршрутизатор b2 (он находится в другой подсети, за другим ротером). дальше он попытается разрешить этот ip в mac, и конечно будет fail и ICMP type 3 code 1.

Ясно. Пошел читать.

Ишшо раз благодарю за РФЦ. Еще б разобраться, как Виндоуз работает в подобной ситуации - ведь работает же, блин - а никакого подобия арп-прокси у нас 100% нету. Выйду на работу - буду глядеть.

очень просто - он совмещает route table и route cache в одной таблице, и ходит по ней трижды (!)

ну что ж, рад признать, что и ты не дурак. просто ранее оснований полагать иначе небыло, ты уж извини, больно наивно и по-детски твои выглядели предыдущие посты.
а конкретно по твоей проблеме могу сказать только, что роут мап вроде как отлично работает на л3 свитчах от цисок, правда с головы ни версию иоса, ни железа не скажу, но точно работает, в нормальных условиях. а какие у вас там были сложности мне ведь неизвестно. не думаю, что 60% загрузки основного цп (ты ведь про него?) сильно мешали. бюджетки 93 года отлично работают и при 90%. иос далеко не идеален, но инженеры циско не зря получают зарплату.
еще раз сорри если чем обидел.

> up route add -net 10.10.0.0 netmask 255.255.255.0 gw 10.10.0.254 dev eth0
> up route add -net 10.0.0.0 netmask 255.255.0.0 gw 10.10.0.254 dev eth0

Подсети перекрываются по IPv4-адресам?

> up route add -net 0.0.0.0 netmask 255.255.255.255 gw 10.0.100.35 dev eth0

>> up route add -net 10.10.0.0 netmask 255.255.255.0 gw 10.10.0.254 dev eth0
>> up route add -net 10.0.0.0 netmask 255.255.0.0 gw 10.10.0.254 dev eth0
> Подсети перекрываются по IPv4-адресам?
сам-то понял, что сказал?

> еще раз сорри если чем обидел.

Все нормально. Я по-началу здесь действительно здорово протупил.