Neighboe detection only works oneway

[klyne]

Here is another example of OSPF not wanting to setup relationships with its neighboes. The setup is like this:

Cisco3620____cisco2912____StarosAP

__ Ethernet

The 2912 has 7 other accesspoints plugged into it, and they are fairly reliable running OSPF, but they have had problems in the past, they are now on UPS and have not rebooted for awhile, but they seem stable.

The 3620 holds the gateway and also originates the default route.

The 3620 sees the AP, but it is in INIT mode, but if i check the AP, it does not see the 3620. Here is an output from the AP.

OSPF hlo (a=0 r=10.2.5.57) (64 bytes) from 10.1.5.8 to 224.0.0.5 on eth0
OSPF hlo (a=0 r=10.2.5.57) (68 bytes) from 10.2.5.57 to 224.0.0.5 on eth0
OSPF hlo (a=0 r=10.2.5.58) (68 bytes) from 10.2.5.58 to 224.0.0.5 on eth0

10.1.5.8 is the Ethernet port faceing the cisco
10.2.5.57 is the Atheros interface faceing a "backhaul" client
10.2.5.58 is the "backhaul" client

So there are no hello's from the 3620 (at least the AP does not see them)
All hello's (even the ones from the wireless client) are looking like they are coming in on eth0, which makes no sense to me.

It seems like the board (VIA, w/mPCI slot) does not listen on all interfaces only the wireless one, which would explain the problem, but no interfaces are passive, and the area is defined right (like on all the boards that are working)

Could this be the problem that ospf does not listen on all interfaces, but has no problem transmitting on all that it should? This would explain the instabillity that ppl are reporting.

Regards,

Martin Madsen
Bel Air Internet

if you need access to the board, let me know

[lonnie]

Are you sure the 2912 does not filter on the port you have the AP into? The Ethernet is listened to and is a broadcast segment. We have never had to even declare neighbors on the Ethernet since they are found by broadcast. It is automatic, so my suspicion is the extra hardware you have. A managed switch can have many options, some good and some not so good if they are selected.

[klyne]

Hi lonnie,

Nope there is no such thing, as you can see below.

xxxxxxxxx_RooSwitch#show run
Building configuration...

Current configuration:
!
version 12.0
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname xxxxxx_RooSwitch
!
enable secret 5 xxxxxxxx
!
!
!
!
!
!
ip subnet-zero
!
!
!
interface FastEthernet0/1
!
interface FastEthernet0/2
!
interface FastEthernet0/3
!
interface FastEthernet0/4
!
interface FastEthernet0/5
!
interface FastEthernet0/6
!
interface FastEthernet0/7
!
interface FastEthernet0/8
!
interface FastEthernet0/9
!
interface FastEthernet0/10
!
interface FastEthernet0/11
!
interface FastEthernet0/12
!
interface VLAN1
ip address 10.10.5.2 255.255.255.248
no ip directed-broadcast
no ip route-cache
!
ip default-gateway 10.10.5.1
snmp-server engineID local 0000000902000003E355EF40
snmp-server community xxxxxx RO
!
line con 0
transport input none
stopbits 1
line vty 0 4
password xxxxxx
login
line vty 5 15
password xxxxxx
login
!
end

[lonnie]

Can you tcpdump and see what hellos are being sent?

[klyne]

Lonnie,

Here is the dump using 224.0.0.0/24 as filter:

tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0
19:39:27.584798 10.2.5.58 > 224.0.0.5: OSPFv2-hello 48: backbone dr 10.2.5.58 bdr 10.2.5.57 [tos 0xc0] [ttl 1]
19:39:27.585166 10.1.5.8 > 224.0.0.5: OSPFv2-hello 44: rtrid 10.2.5.57 backbone dr 10.1.5.8 [tos 0xc0] [ttl 1]
19:39:27.585237 10.2.5.57 > 224.0.0.5: OSPFv2-hello 48: backbone dr 10.2.5.58 bdr 10.2.5.57 [tos 0xc0] [ttl 1]
19:39:37.590273 10.1.5.8 > 224.0.0.5: OSPFv2-hello 44: rtrid 10.2.5.57 backbone dr 10.1.5.8 [tos 0xc0] [ttl 1]
19:39:37.590357 10.2.5.57 > 224.0.0.5: OSPFv2-hello 48: backbone dr 10.2.5.58 bdr 10.2.5.57 [tos 0xc0] [ttl 1]
19:39:37.591264 10.2.5.58 > 224.0.0.5: OSPFv2-hello 48: backbone dr 10.2.5.58 bdr 10.2.5.57 [tos 0xc0] [ttl 1]
19:39:47.595175 10.2.5.58 > 224.0.0.5: OSPFv2-hello 48: backbone dr 10.2.5.58 bdr 10.2.5.57 [tos 0xc0] [ttl 1]
19:39:47.595639 10.1.5.8 > 224.0.0.5: OSPFv2-hello 44: rtrid 10.2.5.57 backbone dr 10.1.5.8 [tos 0xc0] [ttl 1]
19:39:47.595712 10.2.5.57 > 224.0.0.5: OSPFv2-hello 48: backbone dr 10.2.5.58 bdr 10.2.5.57 [tos 0xc0] [ttl 1]
19:39:57.600224 10.1.5.8 > 224.0.0.5: OSPFv2-hello 44: rtrid 10.2.5.57 backbone dr 10.1.5.8 [tos 0xc0] [ttl 1]
19:39:57.600304 10.2.5.57 > 224.0.0.5: OSPFv2-hello 48: backbone dr 10.2.5.58 bdr 10.2.5.57 [tos 0xc0] [ttl 1]
19:39:57.601229 10.2.5.58 > 224.0.0.5: OSPFv2-hello 48: backbone dr 10.2.5.58 bdr 10.2.5.57 [tos 0xc0] [ttl 1]

Regards,

Martin Madsen
Bel Air Internet

[tony]

The hellos look Ok, however the interface you dumped on (ether1 / eth0) does not have an IP, which is required for OSPF to function. Is this the right interface, or is there another one you can tcpdump on, to see if there are communications between your other systems.

Thanks!

[klyne]

This interface does have an ip: 10.1.5.8/28
I was wondering about that too. This interface is the one that communicates with the cisco3620 and it is this interface that is a problem.

Regards,

Martin Madsen
Bel Air Internet

[tony]

Can you look into your system report, and tell me if any IPs are listed in the eth0 interface?

[klyne]

I feel like a rookie now :(, tied to br0, i never disabled the bridge from when they where in testing...

Should have been tipped off by the hellos from the wireless side on eth0.

The problem persists though, but ill go through the config again just to make sure, before i post again.

Sorry to have wasted your time..

Regards,

Martin Madsen
Bel Air Internet