[Comm] M2.2 choosing of routing daemon

[Comm] M2.2 choosing of routing daemon

[Slava Garelin]

Привет всем!

Не посоветует-ли уважаемое сообщество, что пользовать в качестве
рутинг-демона?
Насколько я понимаю, есть выбор между routed, gated и zebra.

Если все верно понял - routed - пыль веков, zebra - современный
модульный рут-менеджер. 
gated в M2.2 я вообще не обнаружил. Стало быть -
особой альтернативы zebra - нет?

-- 
Slava Garelin

Re: [Comm] M2.2 choosing of routing daemon

[Dmitry Nechaev]

В сообщении от Пятница 05 Декабрь 2003 14:43 Slava Garelin написал(a):

> Не посоветует-ли уважаемое сообщество, что пользовать в качестве
> рутинг-демона?
> Насколько я понимаю, есть выбор между routed, gated и zebra.
>
> Если все верно понял - routed - пыль веков, zebra - современный
> модульный рут-менеджер.
> gated в M2.2 я вообще не обнаружил. Стало быть -
> особой альтернативы zebra - нет?
А ядерный роутинг не устраивает? Нужен именно daemon?

-- 
2.4.20-alt5-up GNU/Linux

Re: [Comm] M2.2 choosing of routing daemon

[Slava Garelin]

On Fri, 5 Dec 2003 14:54:56 +0300
Dmitry Nechaev <dima@academy.cap.ru> wrote:

> > Если все верно понял - routed - пыль веков, zebra - современный
> > модульный рут-менеджер.
> > gated в M2.2 я вообще не обнаружил. Стало быть -
> > особой альтернативы zebra - нет?

> А ядерный роутинг не устраивает? Нужен именно daemon?

А как дефолт тягать с мертвых каналов на живые и назад, по воскрешению?

-- 
Slava Garelin

Re: [Comm] M2.2 choosing of routing daemon

[Dmitry Nechaev]

В сообщении от Пятница 05 Декабрь 2003 14:56 Slava Garelin написал(a):

> > > Если все верно понял - routed - пыль веков, zebra - современный
> > > модульный рут-менеджер.
> > > gated в M2.2 я вообще не обнаружил. Стало быть -
> > > особой альтернативы zebra - нет?
> >
> > А ядерный роутинг не устраивает? Нужен именно daemon?
>
> А как дефолт тягать с мертвых каналов на живые и назад, по воскрешению?

Можно скриптами. Первое, что приходит в голову - пинговать дефолтный гейт, и 
если он не отвечает - ip route replace default ethX via yyy.yyy.yyy.yyy, а 
как стал отвечать - то вертаем взад - ip route replace default ethY via 
zzz.zzz.zzz.zzz
ethX - интерфейс backup-канала, yyy.yyy.yyy.yyy - его IP
ethY - соответственно интерфейс основного канала, zzz.zzz.zzz.zzz - его IP

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

-- 
2.4.20-alt5-up GNU/Linux

Re: [Comm] M2.2 choosing of routing daemon

[Dmitry Nechaev]

В сообщении от Пятница 05 Декабрь 2003 15:04 Dmitry Nechaev написал(a):
> В сообщении от Пятница 05 Декабрь 2003 14:56 Slava Garelin написал(a):
> > > > Если все верно понял - routed - пыль веков, zebra - современный
> > > > модульный рут-менеджер.
> > > > gated в M2.2 я вообще не обнаружил. Стало быть -
> > > > особой альтернативы zebra - нет?
> > >
> > > А ядерный роутинг не устраивает? Нужен именно daemon?
> >
> > А как дефолт тягать с мертвых каналов на живые и назад, по воскрешению?
>
> Можно скриптами. Первое, что приходит в голову - пинговать дефолтный гейт,
> и если он не отвечает - ip route replace default ethX via yyy.yyy.yyy.yyy,
> а как стал отвечать - то вертаем взад - ip route replace default ethY via
> zzz.zzz.zzz.zzz
> ethX - интерфейс backup-канала, yyy.yyy.yyy.yyy - его IP
> ethY - соответственно интерфейс основного канала, zzz.zzz.zzz.zzz - его IP
>
> Если хорошенько погуглить - верю, что найдётся не одно готовое решени такой
> проблемы.
Сорри, ошибочка в синтаксисе.
ip route replace default via yyy.yyy.yyy.yyy dev ethX
ip route replace default via zzz.zzz.zzz.zzz dev ethY
можно добавить в конце каждой строки src aaa.aaa.aaa.aaa - исходящие пакеты 
будут иметь этот адрес (адрес, соответственно, должен существовать на этом 
хосте).
-- 
2.4.20-alt5-up GNU/Linux

Re: [Comm] M2.2 choosing of routing daemon

[Slava Garelin]

On Fri, 5 Dec 2003 15:09:53 +0300
Dmitry Nechaev <dima@academy.cap.ru> wrote:

> В сообщении от Пятница 05 Декабрь 2003 15:04 Dmitry Nechaev
> написал(a):
> > В сообщении от Пятница 05 Декабрь 2003 14:56 Slava Garelin
> > написал(a):
> > > > > Если все верно понял - routed - пыль веков, zebra -
> > > > > современный модульный рут-менеджер.
> > > > > gated в M2.2 я вообще не обнаружил. Стало быть -
> > > > > особой альтернативы zebra - нет?
> > > >
> > > > А ядерный роутинг не устраивает? Нужен именно daemon?
> > >
> > > А как дефолт тягать с мертвых каналов на живые и назад, по
> > > воскрешению?
> >
> > Можно скриптами. Первое, что приходит в голову - пинговать дефолтный
> > гейт, и если он не отвечает - ip route replace default ethX via
> > yyy.yyy.yyy.yyy, а как стал отвечать - то вертаем взад - ip route
> > replace default ethY via zzz.zzz.zzz.zzz
> > ethX - интерфейс backup-канала, yyy.yyy.yyy.yyy - его IP
> > ethY - соответственно интерфейс основного канала, zzz.zzz.zzz.zzz -
> > его IP
> >
> > Если хорошенько погуглить - верю, что найдётся не одно готовое
> > решени такой проблемы.
> Сорри, ошибочка в синтаксисе.
> ip route replace default via yyy.yyy.yyy.yyy dev ethX
> ip route replace default via zzz.zzz.zzz.zzz dev ethY
> можно добавить в конце каждой строки src aaa.aaa.aaa.aaa - исходящие
> пакеты будут иметь этот адрес (адрес, соответственно, должен
> существовать на этом хосте).

Даже не знаю что сказать... :)

Оптимальный маршрут! Во.

Нет, руками таблицу по определенным критериям - то можно править, спору
нет. Из шелла-ли из бинарника... Думается просто универсальным решением
все-же является коллегиальное ( в смысле с другими рутерами ) решение
кому куда ходить. Нет?

-- 
Slava Garelin

Re: [Comm] M2.2 choosing of routing daemon

[Dmitry Nechaev]

В сообщении от Пятница 05 Декабрь 2003 15:24 Slava Garelin написал(a):

> > > > > > Если все верно понял - routed - пыль веков, zebra -
> > > > > > современный модульный рут-менеджер.
> > > > > > gated в M2.2 я вообще не обнаружил. Стало быть -
> > > > > > особой альтернативы zebra - нет?
> > > > >
> > > > > А ядерный роутинг не устраивает? Нужен именно daemon?
> > > >
> > > > А как дефолт тягать с мертвых каналов на живые и назад, по
> > > > воскрешению?
> > >
> > > Можно скриптами. Первое, что приходит в голову - пинговать дефолтный
> > > гейт, и если он не отвечает - ip route replace default ethX via
> > > yyy.yyy.yyy.yyy, а как стал отвечать - то вертаем взад - ip route
> > > replace default ethY via zzz.zzz.zzz.zzz
> > > ethX - интерфейс backup-канала, yyy.yyy.yyy.yyy - его IP
> > > ethY - соответственно интерфейс основного канала, zzz.zzz.zzz.zzz -
> > > его IP
> > >
> > > Если хорошенько погуглить - верю, что найдётся не одно готовое
> > > решени такой проблемы.
> >
> > Сорри, ошибочка в синтаксисе.
> > ip route replace default via yyy.yyy.yyy.yyy dev ethX
> > ip route replace default via zzz.zzz.zzz.zzz dev ethY
> > можно добавить в конце каждой строки src aaa.aaa.aaa.aaa - исходящие
> > пакеты будут иметь этот адрес (адрес, соответственно, должен
> > существовать на этом хосте).
>
> Даже не знаю что сказать... :)
>
> Оптимальный маршрут! Во.
>
> Нет, руками таблицу по определенным критериям - то можно править, спору
> нет. Из шелла-ли из бинарника... Думается просто универсальным решением
> все-же является коллегиальное ( в смысле с другими рутерами ) решение
> кому куда ходить. Нет?
BGP, OSPF - тогда, наверное, да, это к зебре. А действительно нужно выбирать 
оптимальный маршрут пакетов? Или на самом деле есть просто два провайдера, 
считающих пакеты на интерфейсах? Прошел пакет - копейка провайдеру, 
назависимо от того, как и куда пакет пойдёт дальше (это забота провайдера)...
-- 
2.4.20-alt5-up GNU/Linux

Re: [Comm] M2.2 choosing of routing daemon

[Slava Garelin]

On Fri, 5 Dec 2003 15:33:16 +0300
Dmitry Nechaev <dima@academy.cap.ru> wrote:

> > Даже не знаю что сказать... :)
> >
> > Оптимальный маршрут! Во.
> >
> > Нет, руками таблицу по определенным критериям - то можно править,
> > спору нет. Из шелла-ли из бинарника... Думается просто универсальным
> > решением все-же является коллегиальное ( в смысле с другими рутерами
> > ) решение кому куда ходить. Нет?
> BGP, OSPF - тогда, наверное, да, это к зебре. А действительно нужно
> выбирать оптимальный маршрут пакетов? Или на самом деле есть просто
> два провайдера, считающих пакеты на интерфейсах? Прошел пакет -
> копейка провайдеру, назависимо от того, как и куда пакет пойдёт дальше
> (это забота провайдера)...-- 
> 2.4.20-alt5-up GNU/Linux

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


-- 
Slava Garelin