[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quagga-users
Subject:    [quagga-users 9880]  OSPFD gone wild ...
From:       Joe Greco <jgreco () ns ! sol ! net>
Date:       2008-09-03 22:24:43
Message-ID: 200809032224.m83MOhM6085864 () aurora ! sol ! net
[Download RAW message or body]

We're another FreeBSD site having trouble with Quagga and FreeBSD 7, but
we are also seeing some strangeness with legacy installs that used to work
just fine.

For example, this is a FreeBSD 6 box running Quagga 0.98.2.  We've been
seeing a strange failure mode where Quagga will "go insane".  For ex:

# sho ip osp
 OSPF Routing Process, Router ID: 206.55.65.149
 Supports only single TOS (TOS0) routes
 This implementation conforms to RFC2328
 RFC1583Compatibility flag is enabled
 OpaqueCapability flag is disabled
 SPF schedule delay 1 secs, Hold time between two SPFs 1 secs
 Refresh timer 10 secs
 Number of external LSA 0. Checksum Sum 0x00000000
 Number of opaque AS LSA 0. Checksum Sum 0x00000000
 Number of areas attached to this router: 1

 Area ID: 0.0.1.0
   Shortcutting mode: Default, S-bit consensus: ok
   Number of interfaces in this area: Total: 9, Active: 9
   Number of fully adjacent neighbors in this area: 0
   Area has simple password authentication
   Number of full virtual adjacencies going through this area: 0
   SPF algorithm executed 2 times
   Number of LSA 1
   Number of router LSA 1. Checksum Sum 0x0000b85b
   Number of network LSA 0. Checksum Sum 0x00000000
   Number of summary LSA 0. Checksum Sum 0x00000000
   Number of ASBR summary LSA 0. Checksum Sum 0x00000000
   Number of NSSA LSA 0. Checksum Sum 0x00000000
   Number of opaque link LSA 0. Checksum Sum 0x00000000
   Number of opaque area LSA 0. Checksum Sum 0x00000000

# sho ip osp nei

Neighbor ID     Pri   State           Dead Time   Address         Interface           RXmtL RqstL DBsmL
# sho ip osp ro
============ OSPF network routing table ============
[...]
N    206.55.68.160/27      [30020] area: 0.0.1.0
                           directly attached to fxp0
N    206.55.69.160/27      [30010] area: 0.0.1.0
                           directly attached to fxp1

============ OSPF router routing table =============

============ OSPF external routing table ===========

# sho ip osp da

       OSPF Router with ID (206.55.65.149)

                Router Link States (Area 0.0.1.0)

Link ID         ADV Router      Age  Seq#       CkSum  Link count
206.55.65.149   206.55.65.149   1499 0x80000114 0xd697 9

# sho ip osp int
fxp0 is up
  Internet Address 206.55.68.172/27, Broadcast 206.55.68.191, Area 0.0.1.0
  Router ID 206.55.65.149, Network Type BROADCAST, Cost: 30020
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 206.55.65.149, Interface Address 206.55.68.172
  No backup designated router on this network
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:10
  Neighbor Count is 0, Adjacent neighbor count is 0
fxp1 is up
  Internet Address 206.55.69.172/27, Broadcast 206.55.69.191, Area 0.0.1.0
  Router ID 206.55.65.149, Network Type BROADCAST, Cost: 30010
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 206.55.65.149, Interface Address 206.55.69.172
  No backup designated router on this network
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:10
  Neighbor Count is 0, Adjacent neighbor count is 0


Okay, which looks like neither of the attached networks are running OSPF.

Yet one of the FreeBSD routers that's responsible for the 206.55.68.160/27
 network:

# sho ip osp nei

Neighbor ID     Pri   State           Dead Time   Address         Interface           RXmtL RqstL DBsmL
[...]
206.55.65.173     1   2-Way/DROther   00:00:39    206.55.68.162   em3:206.55.68.161     0     0     0
206.55.73.10      1   Full/Backup     00:00:38    206.55.68.164   em3:206.55.68.161    32     0     0
206.55.73.11     10   Full/DR         00:00:30    206.55.68.165   em3:206.55.68.161    26     0     0
206.55.73.12      1   2-Way/DROther   00:00:32    206.55.68.168   em3:206.55.68.161     0     0     0
206.55.65.148     1   2-Way/DROther   00:00:38    206.55.68.171   em3:206.55.68.161     0     0     0
206.55.65.149     1   Init/DROther    00:00:34    206.55.68.172   em3:206.55.68.161     0     0     0
206.55.64.22      1   2-Way/DROther   00:00:36    206.55.68.189   em3:206.55.68.161     0     0     0
[...]
# sho ip osp int em3
em3 is up
  Internet Address 206.55.68.161/27, Broadcast 206.55.68.191, Area 0.0.1.0
  Router ID 206.55.64.21, Network Type BROADCAST, Cost: 1
  Transmit Delay is 1 sec, State DROther, Priority 1
  Designated Router (ID) 206.55.73.11, Interface Address 206.55.68.165
  Backup Designated Router (ID) 206.55.73.10, Interface Address 206.55.68.164
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:01
  Neighbor Count is 7, Adjacent neighbor count is 2

Now, notice the "Init/DROther" ...

So, if I turn on packet tracing on the afflicted box, I see that there is
no packet reception.

2008/09/03 17:07:17 debugging: OSPF: Hello sent to [224.0.0.5] via [fxp0:206.55.68.172].
2008/09/03 17:07:17 debugging: OSPF: Hello sent to [224.0.0.5] via [fxp1:206.55.69.172].
2008/09/03 17:07:27 debugging: OSPF: Hello sent to [224.0.0.5] via [fxp0:206.55.68.172].
2008/09/03 17:07:27 debugging: OSPF: Hello sent to [224.0.0.5] via [fxp1:206.55.69.172].

But they're there on the wire, visible via tcpdump.

17:21:02.701101 IP 206.55.68.165 > 224.0.0.5: OSPFv2, Hello, length: 72
17:21:02.901490 IP 206.55.68.161 > 224.0.0.6: OSPFv2, LS-Update, length: 1480
17:21:02.901504 IP 206.55.68.161 > 224.0.0.6: ospf
17:21:02.901511 IP 206.55.68.161 > 224.0.0.6: OSPFv2, LS-Update, length: 56
17:21:02.902419 IP 206.55.68.164 > 224.0.0.5: OSPFv2, LS-Update, length: 812
17:21:02.907621 IP 206.55.68.171 > 224.0.0.6: OSPFv2, LS-Update, length: 812
17:21:02.915266 IP 206.55.68.189 > 224.0.0.6: OSPFv2, LS-Update, length: 812
17:21:02.989948 IP 206.55.68.162 > 224.0.0.6: OSPFv2, LS-Ack, length: 584

So what should I be looking at here?  We're seeing this on a variety of
FreeBSD and Quagga versions, intermittently.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-users
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic