OSPF not detecting neighbors

[Marlow]

Hi,

i've got a problem with a single node, that doesn't seem to detect it's neighbors at all after it moved from Debian to Star-OS.

Here the configuration file:
!
hostname mbkap
password 1234
log syslog
!
!
!
interface beacon
!
interface cbq
!
interface ecb
!
interface eth0
!
interface gre0
!
interface ipacct
!
interface lo
!
interface tunl0
!
interface wlanbr
!
interface wpcm0
!
interface wpcm1
!
router ospf
ospf router-id 10.7.67.3
network 10.7.65.0/24 area 0.0.0.0
network 10.7.67.0/24 area 0.0.0.0
network 10.7.128.0/23 area 0.0.0.0
area 0.0.0.0 range 10.7.0.0/16
!
access-list vtylist permit 127.0.0.1/32
access-list vtylist deny any
!
line vty
access-class vtylist
!

Now, this has been tested with 2.01.7 and 2.10.0 and it's the same result, output of "sh ip ospf database" would result in:

OSPF Router with ID (10.7.67.3)

Router Link States (Area 0.0.0.0)

Link ID ADV Router Age Seq# CkSum Link count
10.7.67.3 10.7.67.3 410 0x80000002 0x9db5 3

And that's it, no other ospf nodes. I've tried to set the neighbors, set the interfaces to point-to-multipoint and the like and I can not figure out, why this not works.

If i remove Star-OS and plug the Debian Sarge installation, running quagga 0.98.3-7 it'll all be happy and replicating routes.

The box has the neighbors 10.7.65.1 (ID 10.7.64.1) and 10.7.129.1 (ID 10.7.128.1), which both are on wireless links using ruby pc-cards.

Logfile output is this:
Oct 12 23:09:32 mbkap zebdog: ospfd has been started
Oct 12 23:09:32 mbkap ospfd[27193]: OSPFd 0.98.5 starting: vty@2604
Oct 12 23:09:32 mbkap ospfd[27193]: interface 10.7.67.3 join AllSPFRouters Multicast group.
Oct 12 23:09:32 mbkap ospfd[27193]: interface 10.7.129.219 join AllSPFRouters Multicast group.
Oct 12 23:09:32 mbkap ospfd[27193]: interface 10.7.65.17 join AllSPFRouters Multicast group.
Oct 12 23:09:53 mbkap kernel: wpcm0: LinkStatus: 5 (Access Point In Range) - bss: XX:XX:XX:XX:XX:XX (po
rt status: 4)
Oct 12 23:09:53 mbkap kernel: wpcm0: 00:02:2d:49:8e:45 name [ ]
Oct 12 23:10:12 mbkap ospfd[27193]: DR-Election[1st]: Backup 10.7.67.3
Oct 12 23:10:12 mbkap ospfd[27193]: DR-Election[1st]: DR 10.7.67.3
Oct 12 23:10:12 mbkap ospfd[27193]: DR-Election[2nd]: Backup 0.0.0.0
Oct 12 23:10:12 mbkap ospfd[27193]: DR-Election[2nd]: DR 10.7.67.3
Oct 12 23:10:12 mbkap ospfd[27193]: interface 10.7.67.3 join AllDRouters Multicast group.
Oct 12 23:10:12 mbkap ospfd[27193]: DR-Election[1st]: Backup 10.7.129.219
Oct 12 23:10:12 mbkap ospfd[27193]: DR-Election[1st]: DR 10.7.129.219
Oct 12 23:10:12 mbkap ospfd[27193]: DR-Election[2nd]: Backup 0.0.0.0
Oct 12 23:10:12 mbkap ospfd[27193]: DR-Election[2nd]: DR 10.7.129.219
Oct 12 23:10:12 mbkap ospfd[27193]: interface 10.7.129.219 join AllDRouters Multicast group.
Oct 12 23:10:12 mbkap ospfd[27193]: DR-Election[1st]: Backup 10.7.65.17
Oct 12 23:10:12 mbkap ospfd[27193]: DR-Election[1st]: DR 10.7.65.17
Oct 12 23:10:12 mbkap ospfd[27193]: DR-Election[2nd]: Backup 0.0.0.0
Oct 12 23:10:12 mbkap ospfd[27193]: DR-Election[2nd]: DR 10.7.65.17
Oct 12 23:10:12 mbkap ospfd[27193]: interface 10.7.65.17 join AllDRouters Multicast group.

and that's about it. Nothing else happens and no routes are discovered. Any other box in the network, be it Debian, Star-OS, ME2000 or something else runs a similar configuration and has no troubles beyond this one.

Input on, how to solve this problem would be gladly appreciated.

/Marlow

[bairdc]

You need to set your wireless interfaces to NBMA, as they will not pass multicast packets:

interface wpcm0
ip ospf network non-broadcast
!
interface wpcm1
ip ospf network non-broadcast


It's interesting that your Debian box does not require this. Makes me wonder if the problem with StarOS not passing multicast packets is a driver issue. The stock Linux driver obviously has no problem with it...

Anyway, it's not a show-stopper. Just configure your interfaces to use unicast, as above, and it will work. This is a requirement for Agere and Prism cards, I think. Atheros supposedly handles it okay, but I've got a couple of links that wouldn't behave until I set them to non-broadcast.

Craig

[Marlow]

I've tried to configure it this way also:

!
hostname mbkap
password 1234
log syslog
!
!
!
interface beacon
!
interface cbq
!
interface ecb
!
interface eth0
!
interface gre0
!
interface ipacct
!
interface lo
!
interface tunl0
!
interface wlanbr
!
interface wpcm0
ip ospf network non-broadcast
!
interface wpcm1
ip ospf network non-broadcast
!
router ospf
ospf router-id 10.7.67.3
network 10.7.65.0/24 area 0.0.0.0
network 10.7.67.0/24 area 0.0.0.0
network 10.7.128.0/23 area 0.0.0.0
area 0.0.0.0 range 10.7.0.0/16
neighbor 10.7.65.1
neighbor 10.7.129.1
!
access-list vtylist permit 127.0.0.1/32
access-list vtylist deny any
!
line vty
access-class vtylist
!
end

Still no joy. It's isolated and not talking.

Besides, the cards on it is connecting to are a CM9 on 10.7.65.1 and a hermes card on 10.7.129.1. I tried to move the hermes at 10.7.129.1 to non-broadcast, too, specified neighbor, still not working.

/Marlow

[lonnie]

On the wireless config make sure you allow interBSS Relay. This is how the neighbours will communicate.

[Marlow]

Both cards are configured out of the box, only switched to infrastructure mode and essid configured.

No AP stealth mode, Intra-BSS relay is enabled, tried with "Use fw" switch or not, Mor is not enabled.

The machine is a PC, Router Edition 2.10.0 (Server License), PC-Card to PCI converters, 2 ruby PCMCIA cards (1 Buffalo, 1 Dell TrueMobile 1150).

One link connects to a Wrap, CM9, Star-OS
Other link connects to a PC, PCMCIA hermes card (Dell TrueMobile 1150), Star-OS

Traffic will flow without problems over the links, given static routes in place.

Intra-BSS is also enabled on the neighbors, since there are multiple links on each of them, some of which are OSPF enabled, some not and they of course talk. We have a network with ruby, hermes (ruby and hermes are either Lucent WaveLan, Dell TrueMobile 1150 or Buffalo AirStation, usually all at newest firmware), prism 2.5 (Senao), 5212 (Senao) and 5213 (CM9, supplied by Valemount or pcengines) cards, currently 21 boxes running ospf with a mixture of Star-OS (all upgraded to 2.10.0, but as i said .. problem also exists in earlier version) and Debian running quagga. This is the only box, that acts this way.

The box in question is the only one having "ruby" cards though, so I will try tomorrow, if i can sort some hermes or prism pcmcia cards somewhere, and see if that makes the difference.

Whenever I switch back to the harddisk with Debian in this box, ospf will work.

/Marlow

[Marlow]

Well,

I've made progress on this, kind of. It is odd indeed.

This only seems to work when I make the interface on the other side talk non-broadcast.

current configuration for node with ruby cards:
!
hostname mbkap
password 1234
log syslog
!
!
!
interface beacon
!
interface cbq
!
interface ecb
!
interface eth0
!
interface gre0
!
interface ipacct
!
interface lo
!
interface tunl0
!
interface wlanbr
!
interface wpcm0
!
interface wpcm1
!
router ospf
ospf router-id 10.7.67.3
network 10.7.65.0/24 area 0.0.0.0
network 10.7.67.0/24 area 0.0.0.0
network 10.7.129.0/24 area 0.0.0.0
!
access-list vtylist permit 127.0.0.1/32
access-list vtylist deny any
!
line vty
access-class vtylist
!
end

Now, we have this configuration:

AP1 (hermes) <--> AP2 (ruby/ruby)(mbkap) <--> AP3 (CM9)

setting AP1 to non-broadcast and specifying neighbor will make AP2 learn the routes from the network connected to AP1.

setting AP3 to non-broadcast and specifying neighbor will NOT make AP2 learn the routes from the network connected to AP3.

Even worse, AP2 will not pass the routes from AP1 to AP3.

Setting AP2 to non-broadcast and specifying neighbors or not doesn't make any difference.

/Marlow

[lonnie]

You have to make the device non broadcast by setting it.
Login, enable, config term, interface, ospf network non-broadcast, write, exit, etc.

interface wpcm0
ip ospf network non-broadcast
!
interface wpcm1
ip ospf network non-broadcast
!

[Marlow]

You have to make the device non broadcast by setting it.
Login, enable, config term, interface, ospf network non-broadcast, write, exit, etc.

interface wpcm0
ip ospf network non-broadcast
!
interface wpcm1
ip ospf network non-broadcast
!

Well .. if you read my earlier posts, you would have realised, that i've tried that earlier .. it doesn't make a difference. It does not work. I finally got it working on one of the two ruby interfaces now, but not on the other.

And matter of fact is, that if I shut the box down and boot the old Debian installation, it WILL WORK, everytime, using broadcast.

/Marlow

[lonnie]

I did read your earlier post and others as well. What I see in your current config is that you do NOT have non broadcast set. If you are using neighbors you MUST have non broadcast set. If the device works in broadcast mode it does not require a neighbor statement, since it finds all neighbors by broadcasting.

I realize that you might have tried all settings, but maybe in the confusion of trying to get it working you did not try with the proper combinations on all systems at the same time.

Setting to non broadcast and declaring neighbors works, plus it must be done on all systems that are neighbors.

Since there are a lot of changes required to be made, on multiple systems, it is real easy to miss one or change it before the others have been set properly.

As for the Debian, well it uses a different wireless driver, and maybe it supports broadcasts. I don't know, since we don't use it. I am glad it works, but it has nothing to do with your current situation.


Well .. if you read my earlier posts, you would have realised, that i've tried that earlier .. it doesn't make a difference. It does not work. I finally got it working on one of the two ruby interfaces now, but not on the other.

And matter of fact is, that if I shut the box down and boot the old Debian installation, it WILL WORK, everytime, using broadcast.

/Marlow

[Marlow]

I did read your earlier post and others as well. What I see in your current config is that you do NOT have non broadcast set. If you are using neighbors you MUST have non broadcast set. If the device works in broadcast mode it does not require a neighbor statement, since it finds all neighbors by broadcasting.

I realize that you might have tried all settings, but maybe in the confusion of trying to get it working you did not try with the proper combinations on all systems at the same time.

Setting to non broadcast and declaring neighbors works, plus it must be done on all systems that are neighbors.

Since there are a lot of changes required to be made, on multiple systems, it is real easy to miss one or change it before the others have been set properly.

As for the Debian, well it uses a different wireless driver, and maybe it supports broadcasts. I don't know, since we don't use it. I am glad it works, but it has nothing to do with your current situation.

Well .. setting non broadcast works on a link that has a ruby/hermes/prism 2.5 card on the other side, but not for a CM9. Even with specified neighbors on both sides, it wouldn't bring the routes over. Once i replaced the ruby card with a prism 2.5, everything was fine.

/Marlow

[klyne]

I switched a CM9 in one of our servers tonight and all the sudden the server could not see any neighboes, it linked fine and i could ping the other side, but ospf did not see any peers. I configured the AP on the other side to non-broadcast and 15 sec later everything was fine, the client does not have non-broadcast set.

mind you the CM9 i configured for non broadcast was the other side of the link..... the one i dident replace. stange.

I believe the CM9 i switched to on the other end of the link was a older version (still 5213, but the sticker looked like it was a older model w/ same chipset)

very odd, any guesses

Martin Madsen
Bel Air Internet

[lonnie]

Also make sure to allow interBSS relay on the AP. That is the only way that neighbour clients can communicate.

[bminish]

Also make sure to allow interBSS relay on the AP. That is the only way that neighbour clients can communicate.

You only need interBSS Relay turned on if your neighbour clients are on the same subnet. we use a different subnet per client when we have more than one OSPF client an an AP

.brendan