Привет, народ. У меня тоже выросла сеть.... решил завести вышеуказанную зверюшку. Подвил 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?