маршртизация. Need help.

[Tolka]

День добрый!

 

Вообщем столкнулся с такой задачей.

 

Есть территориально-распределенная сеть. К каждому узлу сети (показаны, как маршрутизаторы) подходит 2 линка, интерфейс G.703.1 (поток в 64 кбит/с). Сеть закольцована. На каждом узле сети крутиться процесс, которому необходим доступ к Database (mysql). К каждому узлу сети подключена небольшая локалка, максимум на 16 адресов (хотя если необходимо, то можно отвести всю сетку C). Интерфейс локалки - Ethernet. Каждый компьютер из локалки должен видеть Database.

 

При падении линка между двумя маршртизаторами, информация должна передаваться по существующему маршруту.

 

Что сделано:

1. линк между маршртизаторами поднимается с помощью pppd, интерфейс G.703 выглядит в системе, как обычный последовательный порт (/dev/serX или /dev/ttySX).

2. между двумя узлами работает протокол bgp. Увязать более 2-ух узлов пока не дошли ручки. какие ещё протоколы возможно использовать? или оптимальней?

 

Возможно ли, чтоб сети 192.168.1.X1, 192.168.1.X2, 192.168.1.X3... находились в одной подсети? т.е. узлы сети работали как мост? какие у этого решения подводные камни?

 

С Уважением, Анатолий.

 

ps: картинка сети в файле

[ingress]

BGP зачем? RIPv2 или OSPF сойдёт.

 

мост не надо, лучше оставить с маршрутизацией. 64 килобита убить броадкастом можно :)

[SergeiK]

Хм. А бюджет решения?

В общем, согласен с ingress.

Мост сделать технически можно но категорически не надо.

Для таких скоростей синхра много лучше. Какое-то железо уже есть?

В целом - оптимальное решение - роутеры с 2-ми сихронными портами (хоть G.703.1, хоть через конверторы V.35|V.24), динамической маршрутизаций (OSPF, RIPv2 или EIGRP) и QoS-ом.

[Tolka]

с мостом согласен...

 

железо - промышленный комп (проц. Pentium 266, Advantech PCA-6751), в качестве ОС - QNX, интерфейс G.703.1 поднимаю с использованием карточек Миг-2Р (НПП Пульсар). В качестве софта Quagga (пересобрали под QNX). Одна из задач стенда - проверить загрузку процессора при маршрутизаци данных.

 

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

[SergeiK]

У-у, какая экзотика!!! Супер! Но помочь трудно.

[Tolka]

не говори, сам в шоке...

 

можешь подсказать, какое оборудование может работать с G.703.1 ? В сети смотрел, нашел только Миг-2Р (да и было 3 карточки, 2 живые), конвертеры Зелакс К-713 по 500 зеленых за порт.

[SergeiK]

Я, как бы, в основном кошковод.

Но из нового дешево не будет.

http://www.cronyx.ru/price/#pcm64

У зелакса есть роутеры и конверторы, можно подобрать решение.

Типа ММ-201R-UNI + что-то вроде MIM-G703 или MIME2xG703L.

У кого еще есть разумная синхра и g.703.1 - я даже не знаю.

Редкая вещь! Может NAG что имеет в архивах...

 

Да, эта quagga - оказывается клон зебры, так что конфиг пришли, можно посмотреть, что ей не нравиться.

[ingress]

а зачем QNX? поток в 128 килобит может обработать и Линукс на этом же железе.

 

неизвестно вообще поддерживается ли мультикаст через ppp в QNX? (даже в гугле неохота набирать)

[Tolka]

QNX необходим, т.к. на данном железе крутиться ещё несколько приложений, и это уже не моя задача. Моя задача - обеспечить связь этого приложения с БД по существующим каналам связи.

 

судя по всему, Multicast на ppp поддерживается:

 

sv1:/root# ifconfig

lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33212

capabilities=7<IP4CSUM,TCP4CSUM,UDP4CSUM>

enabled=0<>

inet 127.0.0.1 netmask 0xff000000

en0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500

address: 00:0b:ab:09:0a:cc

inet 192.168.0.35 netmask 0xffffff00 broadcast 192.168.0.255

ppp2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500

inet 192.168.1.3 -> 192.168.1.4 netmask 0xffffff00

ppp0: flags=8050<POINTOPOINT,RUNNING,MULTICAST>

 

к тому же на пинг адресов 224.0.0.Х получаю ответ от всех машин, подключенных в локальную сеть.

 

похоже проблема в другом:

 

2007/01/22 20:07:12 OSPF: ospf_recv_packet short read. ip_len 11284 bytes read 64

 

а это кусок программы в исходном коде:

 

...

if (ret != ip_len)

{

zlog_warn ("ospf_recv_packet short read. "

"ip_len %d bytes read %d", ip_len, ret);

stream_free (ibuf);

return NULL;

}

 

return ibuf;

}

[ShumBor]

А если квагу заставить работать не по мультикасту а прописать соседей

я там боролся с каналом через adsl. Ни вкакую не хотело по мультикасту работать.. даже пакетов с другой стор не приходили эти.

прописал маршрутизаторы в neighbor все заработало

[Tolka]

А если квагу заставить работать не по мультикасту а прописать соседей

я там боролся с каналом через adsl. Ни вкакую не хотело по мультикасту работать.. даже пакетов с другой стор не приходили эти.

прописал маршрутизаторы в neighbor все заработало

если использовать BGP протокол, то запускается... OSPF работает через мультикаст и вроде нельзя прямо указать соседей. ripV2 использовать не хочу.

[IbZ]

OSPF работает через мультикаст и вроде нельзя прямо указать соседей. ripV2 использовать не хочу.

ip ospf network point-to-point (ну или ip ospf network non-broadcast) в описании интерфейса и neighbor х.х.х.х в описании процесса - router ospf не поможет ли?

[Tolka]

OSPF работает через мультикаст и вроде нельзя прямо указать соседей. ripV2 использовать не хочу.

ip ospf network point-to-point (ну или ip ospf network non-broadcast) в описании интерфейса и neighbor х.х.х.х в описании процесса - router ospf не поможет ли?

попробовал... не помогло... собрали посл. версию квагги, при запуске в лог пишется следующее:

 

2007/01/23 20:28:56 OSPF: OSPFd 0.99.6 starting: vty@2604

2007/01/23 20:28:56 OSPF: interface 192.168.0.35 [2] join AllSPFRouters Multicast group.

2007/01/23 20:29:02 OSPF: ospf_recv_packet read length mismatch: ip_len is 11284, but recvmsg returned 64

2007/01/23 20:29:12 OSPF: ospf_recv_packet read length mismatch: ip_len is 11284, but recvmsg returned 64

2007/01/23 20:29:22 OSPF: ospf_recv_packet read length mismatch: ip_len is 11284, but recvmsg returned 64

2007/01/23 20:29:36 OSPF: DR-Election[1st]: Backup 192.168.0.35

2007/01/23 20:29:36 OSPF: DR-Election[1st]: DR 192.168.0.35

2007/01/23 20:29:36 OSPF: DR-Election[2nd]: Backup 0.0.0.0

2007/01/23 20:29:36 OSPF: DR-Election[2nd]: DR 192.168.0.35

2007/01/23 20:29:36 OSPF: interface 192.168.0.35 [2] join AllDRouters Multicast group.

[Tolka]

2007/01/23 20:29:12 OSPF: ospf_recv_packet read length mismatch: ip_len is 11284, but recvmsg returned 64

2007/01/23 20:29:22 OSPF: ospf_recv_packet read length mismatch: ip_len is 11284, but recvmsg returned 64

с этой ошибкой разобрались, причина: Byte Order. В заголовке IP пакета под Len отводится 2 байта, при разборе пакета старший байт вставал место младшего и наоборот. Если интересны подробности - велкам в приват или аську.

 

Теперь вопрос по настройке OSPF:

 

На сколько я понял, в OSPF есть BackBone Area (0 или 0.0.0.0) предназначеная для обмена траффика между другими Area (1 - n). Как в данном случае, будут расположены area? Как вариант, на каждой станции будет своя area 192.168.x.y + по одной на каждый ppp? так? траффик через Area (1 - n) до Area 0 (получается транзитный) пройдет нормально?

[SergeiK]

area используй, если планируешь сеть на 20+роутеров. Или если много часто падающих линков и роутеров от 10-ка.

[Tolka]

вот конфигурация ospf.conf:

 

на 1 компьютере:

 

router ospf

ospf router-id 192.168.0.35

 

network 192.168.1.5/32 area 100

network 192.168.0.0/24 area 1

 

redistribute kernel

redistribute connected

redistribute static

 

на 2 компьютере:

 

router ospf

ospf router-id 192.168.12.1

 

network 192.168.1.6/32 area 100

network 192.168.12.0/24 area 1

 

redistribute kernel

redistribute connected

redistribute static

 

между комп. 1 и 2 - ppp (192.168.1.5 < - > 192.168.1.6)

 

ospfd видят друг друга но маршруты не прописывают в соседние сети.

[SergeiK]

Обмен маршрутами между area только через area 0.

Но лучше для начала вообще не мудрить с area.

Это требует хорошего понимания OSFP в целом и тщательного планирования адресации.

[Tolka]

Хорошо... в первом посте в этой теме есть карта сети. Какая должна быть конфигурация на маршрутизаторах?

[SergeiK]

На cisco - проще так:

router ospf 1

network 192.168.0.0 0.0.255.255 area 0

redistirbute connected

 

И, в целом все, наврено.

Есть конечно варианты, но лучше потом.

 

Про зебру не знаю.

Edited January 24, 2007 by SergeiK

[Tolka]

Прописал данный конфиг на каждом маршрутизаторе. Вроде всё заработало, огромной спасибо...

 

Осталось несколько вопросов:

 

кусок таблицы маршрутизации:

 

192.168.1.5 192.168.1.6 UGH1 0 0 - ppp0

192.168.1.6 192.168.1.5 UH 4 1012 - ppp0

 

а это ifconfig

 

ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500

inet 192.168.1.5 -> 192.168.1.6 netmask 0xffffffff

 

пока ospfd не запущен, ип адрес 192.168.1.5 доступен через интерфейс lo0. Видимо спустя какое то время, ospf видит, что ИП 192.168.1.5 доступен с 192.168.1.6, что вообщем то и правильно, и изменяет таблицу маршрутизации. Т.е. к локальному ИП 192.168.1.5 траффик пойдет через туннель до 192.168.1.6. Как это можно побороть? Указанием стоиомсть интерфейса?

[Tolka]

и второй вопрос:

 

в кольцо соединены 3 компьютера, один из которых, подключен в общую локалку по езернету. из общей локалки, пингуются все 3 компьютера и замечательно работает SSH и прочие приложения, а вот 2 компьютера, которые не включены в общую сеть по езернету, не видят компьютры локальной сети. При том из локалки пинги до них идут.

[SergeiK]

Не понятна топология. Но скорее всего нет маршрута на них где-то. Надо проверить, прописать и redistributе-ить.

static или kernel, это уж не знаю.

Такая же беда может быть и с ptp адресами.

Прописать их строго на себя.

Но вообще, у cisco для обращений к железкам рекомендуют ставить адреса /32 на loopback.

[Tolka]

Такая же беда может быть и с ptp адресами.

Прописать их строго на себя.

Но вообще, у cisco для обращений к железкам рекомендуют ставить адреса /32 на loopback.

т.е. если я с компьютера создаю peer, скажем 192.168.1.1/32 -> 192.168.1.2, то в маршрутизации жестко прописать, что 192.168.1.1/32 доступен через lo0? Я правильно понял? Когда peer устанавливается, это видно в таблице маршрутизации.

 

с пингами разобрались, не был указан маршрут в локальной сети на ptp (Point to Point) адреса, локалки прописали. сам болван, что тут скажешь...

[Tolka]

вообщем итог убитой недели:

 

OSPF на QNX встал, происходит обмен маршрутной информацией...

 

теперь негатив:

 

очень не стабильная работа при падении/добавлении линков, обычно - это падение процеса.

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

 

2SergeiK:

 

как решение будет выгляеть на кошках? т.е. на каждую станцию надо кошку с 2 портами, к которым цепляются конвертеры в G.703.1, и, как минимум, один портом Езернет? на кошках поднимается маршрутизация. так? какую кошку в этом случае лучше использовать? при падении линка между ними, как быстро будет обновлена таблица маршрутизации?

[SergeiK]

Да, примерно так. Бюджет известен? Из новых 1841. +WIC, его модель от нюансов зависит. Или конверторы+синхра (типа 2A/S) или 2E1 - сразу принмиать E1 и вырезать один timeslot. Но это не дешевого будет.

Переключение - ну, секунды, как правило.

 

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

Пингуется адрес соседа, если не доступен, удалаем default, ставим в другую сторону! Без балансинга, зато просто как 3 копейки.