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

List:       quagga-users
Subject:    [quagga-users 12035] Re: trouble with non-broadcast when starting
From:       Scott Lambert <lambert () lambertfam ! org>
Date:       2010-12-29 21:42:32
Message-ID: 20101229214232.GB76200 () sysmon ! tcworks ! net
[Download RAW message or body]

On Dec 16, 2010, Rudy wrote:
> Sometimes (not every time) when I stop and start OSPF, I have to 'kick'
> it...
> 
> I have one interface that works fine (em5) the other interface I can get
> working if I run these commands:
> 
> jejen-ospfd(config)# interface  vlan7
> jejen-ospfd(config-if)# no ip ospf network       
> jejen-ospfd(config-if)# ip ospf network non-broadcast
> 
> Here is the config for the interfaces:
> 
> interface em5
>  ip ospf authentication message-digest
>  ip ospf message-digest-key 1 md5 PackeyWhee
>  ip ospf cost 9
> !
> interface vlan7
>  ip ospf network non-broadcast
>  ip ospf authentication message-digest
>  ip ospf message-digest-key 2 md5 PacketWheeAgain
>  ip ospf cost 12
> 
> 
> Yes, the other OSPF routers all have there interfaces in vlan7 as
> 'non-broadcast'.
> 
> Anyone seen this before?  I am newish to OSPF, appreciate any insight.
> 
> 
> Rudy
> 
> ospfd version 0.99.17
> 8.1-STABLE FreeBSD amd64

I have a couple of problems which may be similar to this one.  I'll
post my problem here hoping it will be helpful and not a red herring
to distract from the OPs problem.

We have a 50 node network of StarOS, mikrotik, and ImageStream
routers.  The StarOS and ImageStream gear run Quagga on top of
embedded Linux kernels.  I have only seen this problem on the StarOS
boxes, but that could be because I have lots of StarOS and the other
two platform nodes can be counted on less than two hands worth of
fingers.

I have a couple of nodes where we have issues rebuilding neighbor
associations across the ethernet interfaces, usually after an
activate changes in StarOS which stops and restarts the Quagga
daemons. On one AP, we can pretty much guarantee that the problem
will reproduce.  

That LAN segment consists of two StarOS boxes mounted on the tower
outside with ethernet connected to a Linksys switch in the building.
There is a Mikrotik 750G in the building handling a backup DSL
connection in case we lose the wireless backhaul.  Those are the
only three things attached to that Linksys.  The OSPF network type
is broadcast.

However, if I ssh into the backhaul box, StarOS 1.5.14 with Quagga
0.99.15, then ssh into the 3 sector AP box, StarOS 1.4.22r with
Quagga 0.99.10, I sometimes have trouble getting into the OSPF vty.
If I console out to the shell and telnet 127.0.0.1 2604, telnet
launches but never goes anywhere.  Ctrl-C brings me back to the
prompt. I get the same reaction on 2601. I can stop and restart
OSPF in the StarOS UI then connect to the OSPF daemon.

On the AP, the neighbor association with the backhaul box shows as
2-Way/DROther and the association with the Mikrotik is Full/DR.
The backhaul box thinks the association with the AP is Full.  If I
remove the md5 key from the eth0 interface on the AP box and wait
the 20-30 seconds for the associations to time out, then re-add the
key, the association goes to Full before I can type "show ip ospf
neigh", at which point my routes are synchronized and all is well.

I believe we've always had this problem on this particular tower.
I don't have actual documentation of the first event. I think both
the AP and backhaul boxes were on StarOS 1.3.13, Quagga 0.99.9,
when we first converted our network to OSPF.  We did upgrade the
AP to StarOS 1.5.14, Quagga 0.99.15, at one point, but had issues
with wirelss clients and had to revert to StarOS 1.4.22r, Quagga
0.99.10.

On this tower, I have added static routes for the AP's subnets to
zebra on the backhaul box with a metric of 200 and added redistribute
static to the ospf config.  I also added a static default route
with metric 200 to the AP box pointing at the backhaul box.  I was
hoping those static routes could keep the AP and clients online
when OSPF had problems.

Unfortunately, those routes did not seem to take effect yesterday
or this morning when the wireless techs had to activate changes on
the AP, which restarts the OSPF daemons.

-- 
Scott Lambert                    KC5MLE                       Unix SysAdmin
lambert@lambertfam.org

_______________________________________________
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]