advanced routing.... :) (zebra)
Привет, народ.
У меня тоже выросла сеть.... решил завести вышеуказанную зверюшку. Подвил
OSPF.
поставил на потате. Пока ничего не редистрибьючу. Все круто: роутеры друг
друга увидели. Разобрались, кто ведомый. В s ip o n и пр. записали.
Прихожу утром -- все также, только друг друга не слышат: Каждый думает что
он главный и единственный DR, а BR и в помине нет....
Вылечилось это сборкой зебры 0.93b, в которой уже есть
router ospf
neighbour <IP>
Но это лишний геморой мне на голову. Да и ихнем листе не говорится, что
все настолько плохо.
Смотрел tcpdump -- пакеты приходят, но ospfd на них кладет.
mcast-routing где есть,где нет (пробовал на двух разных линках)
дистрибутив -- потата.
ядра -- самосборные 2.2.2[1pre2...], практически вся сеть
включена. файервол -- впускает всех бесплатно. Выпускает тоже. (Пуст).
Алиасы... да порой их больше экрана
/sbin/ip ad
...
4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:60:1d:f2:fa:e1 brd ff:ff:ff:ff:ff:ff
inet 192.168.255.105/30 brd 192.168.255.107 scope global eth2
inet GLO.BAL.IP.251/32 scope global eth2
маршруты...
типа
192.168.8.0/24 via 192.168.255.9 dev eth0 src GLO.BAL.IP.251
default via 192.168.255.106 dev eth2 src GLO.BAL.IP.251
GLO.BAL.IP.251 -- это чтобы traceroute снаружи до машины клиентов
GLO.BAL.IP.ХХХ, которая за 192.168.8.5, показал не * * *
по словам местного спеца такого даже фря не может! :)
В логах:
2002/12/13 09:54:41 OSPF: OSPFd (0.93b) starts
2002/12/13 09:54:41 OSPF: interface 192.168.255.105 join AllSPFRouters
Multicast group.
2002/12/13 09:54:50 OSPF: DR-Election[1st]: Backup 192.168.255.105
2002/12/13 09:54:50 OSPF: DR-Election[1st]: DR 192.168.255.106
2002/12/13 09:54:50 OSPF: DR-Election[2nd]: Backup 192.168.255.105
2002/12/13 09:54:50 OSPF: DR-Election[2nd]: DR 192.168.255.106
2002/12/13 09:54:50 OSPF: interface 192.168.255.105 join AllDRouters
Multicast group.
2002/12/13 09:54:50 OSPF: DR-Election[1st]: Backup 192.168.255.105
2002/12/13 09:54:50 OSPF: DR-Election[1st]: DR 192.168.255.106
2002/12/13 09:55:20 OSPF: DR-Election[1st]: Backup 192.168.255.105
2002/12/13 09:55:20 OSPF: DR-Election[1st]: DR 192.168.255.105
2002/12/13 09:55:20 OSPF: DR-Election[2nd]: Backup 0.0.0.0
2002/12/13 09:55:20 OSPF: DR-Election[2nd]: DR 192.168.255.105
2002/12/13 09:55:21 OSPF: DR-Election[1st]: Backup 0.0.0.0
2002/12/13 09:55:21 OSPF: DR-Election[1st]: DR 192.168.255.106
2002/12/13 09:55:21 OSPF: DR-Election[2nd]: Backup 192.168.255.105
2002/12/13 09:55:21 OSPF: DR-Election[2nd]: DR 192.168.255.106
2002/12/13 09:55:21 OSPF: Packet[DD]: Negotiation done (Slave).
2002/12/13 09:55:22 OSPF: nsm_change_state(): scheduling new router-LSA
origination
2002/12/13 10:14:33 OSPF: nsm_change_state(): scheduling new router-LSA
origination
2002/12/13 10:14:33 OSPF: DR-Election[1st]: Backup 192.168.255.105
2002/12/13 10:14:33 OSPF: DR-Election[1st]: DR 192.168.255.105
2002/12/13 10:14:33 OSPF: DR-Election[2nd]: Backup 0.0.0.0
2002/12/13 10:14:33 OSPF: DR-Election[2nd]: DR 192.168.255.105
линк загружен... но не настолько же, чтобы не договориться....
в связи с чем вопрос: было ли что-то подобное (с зеброй) у кого и как
лечилось на мультикастах? Что еще можно подергать для борьбы с траблой?
Про /dev/hands знаю. Поврос в том в какую сторону их
гнуть... э... выпрямлять.
Второй вопрос:
Может ли IPSEC не шифровать, а только подписывать даже не пакет, а только
заголовок, а лучше только srcip
Третий:
есть ли "штука" к зебре типа /sbin/mii-tool которая при пропадании
коннекта на данном интерфейсе говорила ospfd, что его redistribute
connected -- злая неправда и его надо сократить на соответственно.
(поставить там еще машину и с ЕЕ помощью гонять OSPF не получается)
Третий с половиной:
есть сеть 192.168.8.0/24 территориально длинная на куче хобов и тупых
свитчей. Потому часто рвется. Редкий пингвин залетит... Восновной
9х-клиенты. Поэтому даже RDP под вопросом.
На ее концах стоят 2 машины которые умеют default gateway. Эти машины
имеют линки (радио) в Центр, из которого можно дойти до интернета. В
Центре каждому линку дан свой роутер. Которые объеденены локалкой
192.168.255.0/24.
Надо от всего этого:
1. Минимум гемороя с зоопарком пользователей (заставлять их ставить
ничего хитрого типа ospfd не хочется))
2. Пользователи должны ходить в иет, даже если какой-то из
роутеров исчезает.
3. если роутеров много, они должны балансировать нагрузку (восновном
download)
4. Если сеть 8.0/24 рвется где-то посередине, Центр должен знать, в какой
половине остался клиент. И вообще организовывать мост между 2
половинами. Типа redistribute arp. :)
Есть какие идеи или мне надо вправлять /dev/head?
Reply to: