LINUX.ORG.RU
ФорумAdmin

quagga openvpn


0

0

Конфигурю квагу через туннель tun и вот появилась странная ситуация, как будто один из серваков отказывается быть мастером, а другой упорно не хочет им становится.
Вот кусок лога:

2008/11/24 17:49:16 OSPF: Packet[DD]: Neighbor 169.255.0.1: Initial DBD from Slave, ignoring.
2008/11/24 17:49:21 OSPF: Packet[DD]: Neighbor 169.255.0.1: Initial DBD from Slave, ignoring.
2008/11/24 17:49:26 OSPF: Packet[DD]: Neighbor 169.255.0.1: Initial DBD from Slave, ignoring.
2008/11/24 17:49:31 OSPF: Packet[DD]: Neighbor 169.255.0.1: Initial DBD from Slave, ignoring.

Но стоит перезапустить квагу как все начинает работать:

2008/11/24 17:49:32 OSPF: OSPFd 0.99.10 starting: vty@2604
2008/11/24 17:49:32 OSPF: interface 169.255.100.2 [7] join AllSPFRouters Multicast group.
2008/11/24 17:49:32 OSPF: Packet[DD]: Neighbor 169.255.0.1: Initial DBD from Slave, ignoring.
2008/11/24 17:49:32 OSPF: Packet[DD]: Neighbor 169.255.0.1 Negotiation done (Master).
2008/11/24 17:49:32 OSPF: nsm_change_state(169.255.0.1, Loading -> Full): scheduling new router-LSA origination

Тип инетрфейса указан точка точка.

Вот конфиг:

interface tun0
description Office
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 my_key
ipv6 nd suppress-ra

router ospf
ospf router-id 169.255.30.1
passive-interface fxp0
passive-interface fxp1
passive-interface fxp2
network 169.255.30.0/24 area 169.255.30.0
network 169.255.100.0/30 area 169.255.30.0
area 169.255.30.0 authentication message-digest
area 169.255.30.0 range 169.255.100.0/30 cost 1

Конфиг бэкбона:

interface tun8
description Dzer
ip ospf authentication message-digest
ip ospf cost 1
ip ospf message-digest-key 1 md5 my_key
ipv6 nd suppress-ra

router ospf
ospf router-id 169.255.0.1
redistribute kernel
passive-interface em0
network 169.255.0.0/23 area 0.0.0.0
network 169.255.100.0/30 area 169.255.30.0
area 0.0.0.0 authentication message-digest
area 0.0.0.0 range 169.255.0.0/23
area 169.255.30.0 authentication message-digest
area 169.255.30.0 range 169.255.100.0/30 cost 1

С фаерволом вроде все впоряде...


похоже на квага-баг, так как router-id оба конца видят, поэтому все чтобы выбрать master-slave отношения у них есть.
попробуй обновить квагу...

может где-то на сети есть задвоение router-id?

chocholl ★★
()

вот еще выдержка из RFC
This problem is quite rare, but tantalizing enough to warrant mentioning: OSPF neighbors are forever stuck in EXSTART state (occasionally going to DOWN and back to EXSTART).

I've actually stumbled across it accidentally in my lab and have luckily seen it before, so I knew immediately what it was.
The moment you start suspecting that something might be wrong with the OSPF adjacencies and use debug ip ospf adj command, the problem becomes obvious: the Database Description packet contains an Interface MTU field and if the value received from the neighbor is higher than the IP MTU configured on the inbound interface, the DBD packet is rejected (section 10.6 of the RFC 2328). The router with the lower MTU complains that “Nbr x.x.x.x has larger interface MTU” and the other router moans about protocol violations (First DBD and we are not SLAVE).

As always, there are two ways to solve this problem:

* The correct one: fix the MTU issues;
* The other one: disable MTU checks with the ip ospf mtu-ignore interface configuration command (which might be OK as long as the hardware is able to receive oversized packets and the router is not using fixed-size input buffers).

chocholl ★★
()
Ответ на: комментарий от chocholl

Просмотрел все id, совпадений не было но были разные в оспф и просто router-id. После чего всплыла строчка в логах

2008/11/25 10:51:20 OSPF: Link State Update: Unknown Neighbor 169.255.0.1 on int: tun0:169.255.100.2

Тоесть он как бы долбится на машину с IP 169.255.0.1 на которую нет маршрута, так как он должен братся с нее, а связь должна быть между 169.255.100.1 на 169.255.100.2.

Как бы кваге сказать что бы она верный ип то использовала?

Spank
() автор топика
Ответ на: комментарий от Spank

Причем прописав маршрут статикой, все сразу заработало без проблемм. Вот тольком хотелось бы не прописывать его руками...

Spank
() автор топика
Ответ на: комментарий от Spank

может в кваге как-то связаны router-id и адрес с которого она шлет коммуникации ospf, попробуй поменять router-id.
в нормальной реализации так быть не должно, но на деле получается, что в кваге это есть.

chocholl ★★
()
Ответ на: комментарий от chocholl

Менять нельзя :(. Тама квага связанна еще с одиним сервом, тогда там работать перестанет )). Ща попробую помутить с ипишниками на tun0 интерфесе...

Spank
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.