nerik Опубликовано 1 сентября, 2010 · Жалоба Добрый день. Вчера целый день гуглил так и не смог найти решение своей проблемы. Просил помощи на opennet - все глухо, поэтому обращаюсь тут. Может кто поможет. Во-общем дело такое: Есть два шлюза построенных на FreeBSD 7.2 (на них только нат на pf). Оба смотрят в сетку к циске (например 1.1.1.2 и 1.1.1.3, циска имеет 1.1.1.4) Хотел настроить ospf чтобы балансировать нагрузку трафика через два шлюза. На циске теминируются pppoe, а шлюзы указывают в инет. Сейчас схема такова - Абонент PPPoE (10.10.10.1) --> Cisco (1.1.1.4) --> Шлюз (1.1.1.2, pf из серого гонит в выделенный, у каждого шлюза своя сетка для ната) --> другая циска с bgp --> Интернет Такая схема работает. Поднимают ospf на шлюзах и циске На циске router ospf 10 router-id 1.1.1.4 log-adjacency-changes redistribute connected network 1.1.1.4 0.0.0.15 area 0 На шлюзе (1.1.1.2) стоит quagga (0.99.16) router ospf ospf router-id 1.1.1.2 network 1.1.1.2/28 area 0.0.0.0 default-information originate На шлюзе (1.1.1.3) стоит quagga (0.99.16) router ospf ospf router-id 1.1.1.3 network 1.1.1.3/28 area 0.0.0.0 default-information originate Сессии поднялись, все вроде работает, клиент видит инет. Но на циске почему-то меняются шлюзы PPPoE_Test#show ip route ospf O*E2 0.0.0.0/0 [110/10] via 1.1.1.2, 00:00:15, GigabitEthernet0/0.12 PPPoE_Test#show ip route ospf O*E2 0.0.0.0/0 [110/10] via 1.1.1.3, 00:00:15, GigabitEthernet0/0.12 В логах шлюзах такое: 2010/08/31 18:32:39 OSPF: nsm_change_state(1.1.1.4, Exchange -> Full): scheduling new router-LSA origination 2010/08/31 18:33:19 OSPF: nsm_change_state(1.1.1.4, Full -> Deleted): scheduling new router-LSA origination 2010/08/31 18:33:19 OSPF: DR-Election[1st]: Backup 1.1.1.2 2010/08/31 18:33:19 OSPF: DR-Election[1st]: DR 1.1.1.2 2010/08/31 18:33:19 OSPF: DR-Election[2nd]: Backup 0.0.0.0 2010/08/31 18:33:19 OSPF: DR-Election[2nd]: DR 1.1.1.2 2010/08/31 18:33:19 OSPF: DR-Election[1st]: Backup 0.0.0.0 2010/08/31 18:33:19 OSPF: DR-Election[1st]: DR 1.1.1.2 2010/08/31 18:33:19 OSPF: DR-Election[1st]: Backup 0.0.0.0 2010/08/31 18:33:19 OSPF: DR-Election[1st]: DR 1.1.1.4 2010/08/31 18:33:19 OSPF: DR-Election[2nd]: Backup 1.1.1.2 2010/08/31 18:33:19 OSPF: DR-Election[2nd]: DR 1.1.1.4 2010/08/31 18:33:19 OSPF: Packet[DD]: Neighbor 1.1.1.4 Negotiation done (Slave). 2010/08/31 18:33:19 OSPF: nsm_change_state(1.1.1.4, Exchange -> Full): scheduling new router-LSA origination Соседи на циске отображаются вот так PPPoE_Test#show ip ospf neighborNeighbor ID Pri State Dead Time Address Interface 1.1.1.2 1 FULL/DROTHER 00:00:30 1.1.1.2 GigabitEthernet0/0.12 1.1.1.3 1 FULL/BDR 00:00:32 1.1.1.3 GigabitEthernet0/0.12 PPPoE_Test#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.2 1 FULL/DROTHER 00:00:39 1.1.1.2 GigabitEthernet0/0.12 1.1.1.3 1 FULL/BDR 00:00:31 1.1.1.3 GigabitEthernet0/0.12 PPPoE_Test#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.2 1 FULL/BDR 00:00:37 1.1.1.2 GigabitEthernet0/0.12 1.1.1.3 1 FULL/DROTHER 00:00:39 1.1.1.3 GigabitEthernet0/0.12 На первом шлюзе Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL1.1.1.4 1 Full/DR 2.380s 1.1.1.4 em1:1.1.1.2 0 0 0 На втором шлюзе Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL1.1.1.4 1 Full/DR 34.791s 1.1.1.4 bge1:1.1.1.3 1 0 0 Странно, что шлюзы не отображают у себя в neighbor друг друга. Мож и не должны)) Сейчас отключил quagga на одном из шлюзов, такая же канитель. Понять не могу почему на cisco каждые 40-60 сек. стирается маршрут 0.0.0.0 и добавляется новый. Таймауты менял на одинаковые на обоих шлюзах и на cisco 7301. Стали быстрее меняться шлюзы. Вернул обратно таймауты. Голову уже сломал. С OSPF разбираюсь в первые. Помогите пожалуйста. Спасибо. P.S. Под балансировкой имеется ввиду, чтобы трафик равномерно распределялся между шлюзами сам. Потом будет задача регулирования, сейчас надо просто два шлюза объединить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dead_moroz Опубликовано 1 сентября, 2010 · Жалоба на циске: router ospf 10 maximum-paths 2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nerik Опубликовано 1 сентября, 2010 · Жалоба Ничего не изменилось Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dead_moroz Опубликовано 1 сентября, 2010 · Жалоба Ничего не изменилось show ip route 0.0.0.0 на циске чего говорит? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nerik Опубликовано 1 сентября, 2010 · Жалоба PPPoE_Test#show ip route 0.0.0.0Routing entry for 0.0.0.0/0, supernet Known via "ospf 10", distance 110, metric 10, candidate default path, type extern 2, forward metric 1 Last update from 1.1.1.2 on GigabitEthernet0/0.12, 00:00:06 ago Routing Descriptor Blocks: * 1.1.1.2, from 1.1.1.2, 00:00:06 ago, via GigabitEthernet0/0.12 Route metric is 10, traffic share count is 1 PPPoE_Test#show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "ospf 10", distance 110, metric 10, candidate default path, type extern 2, forward metric 1 Last update from 1.1.1.3 on GigabitEthernet0/0.12, 00:00:00 ago Routing Descriptor Blocks: * 1.1.1.3, from 1.1.1.3, 00:00:00 ago, via GigabitEthernet0/0.12 Route metric is 10, traffic share count is 1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nerik Опубликовано 1 сентября, 2010 · Жалоба PPPoE_Test#show ip route 0.0.0.0Routing entry for 0.0.0.0/0, supernet Known via "ospf 10", distance 110, metric 10, candidate default path, type extern 2, forward metric 1 Last update from 1.1.1.3 on GigabitEthernet0/0.12, 00:00:15 ago Routing Descriptor Blocks: * 1.1.1.3, from 1.1.1.3, 00:00:15 ago, via GigabitEthernet0/0.12 Route metric is 10, traffic share count is 1 1.1.1.2, from 1.1.1.2, 00:00:15 ago, via GigabitEthernet0/0.12 Route metric is 10, traffic share count is 1 PPPoE_Test#show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "ospf 10", distance 110, metric 10, candidate default path, type extern 2, forward metric 1 Last update from 1.1.1.3 on GigabitEthernet0/0.12, 00:00:00 ago Routing Descriptor Blocks: * 1.1.1.3, from 1.1.1.3, 00:00:00 ago, via GigabitEthernet0/0.12 Route metric is 10, traffic share count is 1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dead_moroz Опубликовано 1 сентября, 2010 (изменено) · Жалоба PPPoE_Test#show ip route 0.0.0.0Routing entry for 0.0.0.0/0, supernet Known via "ospf 10", distance 110, metric 10, candidate default path, type extern 2, forward metric 1 Last update from 1.1.1.3 on GigabitEthernet0/0.12, 00:00:15 ago Routing Descriptor Blocks: * 1.1.1.3, from 1.1.1.3, 00:00:15 ago, via GigabitEthernet0/0.12 Route metric is 10, traffic share count is 1 1.1.1.2, from 1.1.1.2, 00:00:15 ago, via GigabitEthernet0/0.12 Route metric is 10, traffic share count is 1 вот так правильно.попробуйте завести оспф сессии по очереди, сначала на одном шлюзе, потом на другом. Изменено 1 сентября, 2010 пользователем dead_moroz Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nerik Опубликовано 1 сентября, 2010 · Жалоба Положил квагу на обоих шлюзах и на циске сделал clear ip ospf process. Поднял квагу на одном шлюзе и все тоже самое, маршруты сбрасываются и заново поднимаются. В логах шлюза 1.1.1.2: 2010/09/01 10:18:54 OSPF: Packet[DD]: Neighbor 1.1.1.4 Negotiation done (Slave).2010/09/01 10:18:54 OSPF: nsm_change_state(1.1.1.4, Exchange -> Full): scheduling new router-LSA origination 2010/09/01 10:19:34 OSPF: nsm_change_state(1.1.1.4, Full -> Deleted): scheduling new router-LSA origination 2010/09/01 10:19:34 OSPF: DR-Election[1st]: Backup 1.1.1.2 2010/09/01 10:19:34 OSPF: DR-Election[1st]: DR 1.1.1.2 2010/09/01 10:19:34 OSPF: DR-Election[2nd]: Backup 0.0.0.0 2010/09/01 10:19:34 OSPF: DR-Election[2nd]: DR 1.1.1.2 2010/09/01 10:19:34 OSPF: DR-Election[1st]: Backup 0.0.0.0 2010/09/01 10:19:34 OSPF: DR-Election[1st]: DR 1.1.1.2 2010/09/01 10:19:34 OSPF: DR-Election[1st]: Backup 0.0.0.0 2010/09/01 10:19:34 OSPF: DR-Election[1st]: DR 1.1.1.4 2010/09/01 10:19:34 OSPF: DR-Election[2nd]: Backup 1.1.1.2 2010/09/01 10:19:34 OSPF: DR-Election[2nd]: DR 1.1.1.4 2010/09/01 10:19:34 OSPF: Packet[DD]: Neighbor 1.1.1.4 Negotiation done (Slave). 2010/09/01 10:19:34 OSPF: nsm_change_state(1.1.1.4, Exchange -> Full): scheduling new router-LSA origination Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nerik Опубликовано 1 сентября, 2010 · Жалоба Перевел интерфейсы на шлюзе и циске в режим non-broadcast и указал друг другу neighbor. Все поднялось и не сбрасывает теперь маршруты. Видимо точно проблема в прохождении мультикаста. Главное в коммутаторе, котором подключена вся схема нет ничего блокирующего по мультикасту. Пробовал заменить коммутатор на другой ситуация та же. Может проблема в кваге. Во-общем щас на режиме non-broadcast все работает. Если можно то ещё вопрос: Можно ли как-нибудь через ospf заставить принудительно отправить траффик на один из шлюзов? Например подключился абонент с айпи 10.10.10.10, а ospf его трафик шлет только на 1.1.1.2 (а так он шлет и на 1.1.1.2 и на 1.1.1.3). А все остальные работали бы так как было. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
applx Опубликовано 1 сентября, 2010 · Жалоба Проблема не в мультекасте ибо нейборы видны, из дебага видно что постоянно меняется ДР/БДР, попробуй сделать цыску ДР: ip ospf priority 255 на интерфэисе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dead_moroz Опубликовано 1 сентября, 2010 · Жалоба Если можно то ещё вопрос:Можно ли как-нибудь через ospf заставить принудительно отправить траффик на один из шлюзов? Например подключился абонент с айпи 10.10.10.10, а ospf его трафик шлет только на 1.1.1.2 (а так он шлет и на 1.1.1.2 и на 1.1.1.3). А все остальные работали бы так как было. PBR на циске. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nerik Опубликовано 1 сентября, 2010 (изменено) · Жалоба Проблема не в мультекасте ибо нейборы видны, из дебага видно что постоянно меняется ДР/БДР, попробуй сделать цыску ДР: ip ospf priority 255 на интерфэисе. Ставил ситуация не менялась. На мультикаст натолкнуло то, что когда я циску вырубил, то шлюзы не видели в нейборах друг друга, по tcpdump видно было что они просто отсылали мультикаст hello-пакетами. В итоге когда сделал non-broadcast то все заработало, так как шлюзы стали отсылать helo пакеты напрямую друг другу и они подключились. PBR на циске. Не получится, так как в cisco asr с ним проблема при использовании pppoe. Может все таки есть выход (без pwr)? Изменено 1 сентября, 2010 пользователем nerik Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dead_moroz Опубликовано 1 сентября, 2010 · Жалоба 1. покажите zebra.conf 2. отдельный VRF не подойдет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...