Project

General

Profile

Actions

Bug #5732

closed

Qagga: Different output in ospfd.conf based on order of interfaces.

Added by Anonymous over 8 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Quagga OSPF
Target version:
-
Start date:
01/04/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
2.2.5
Affected Plus Version:
Affected Architecture:

Description

if last interface in ospfd.conf defined as (note the area 0.0.0.0 authentication):

interface ovpns10
ip ospf authentication-key password

then:
router ospf
ospf router-id 192.168.40.1
log-adjacency-changes detail
passive-interface em1
passive-interface ovpns5
passive-interface em2
network 192.168.40.0/24 area 0.0.0.0
network 172.16.41.0/30 area 0.0.0.0
network 172.16.43.0/30 area 0.0.0.0
network 172.16.40.0/30 area 0.0.0.0
network 172.16.44.0/30 area 0.0.0.0
network 172.16.45.0/30 area 0.0.0.0
network 172.16.13.0/30 area 0.0.0.0
network 192.168.42.0/30 area 0.0.0.0
network 172.16.46.0/30 area 0.0.0.0
network 192.168.41.0/24 area 0.0.0.0
network 172.16.47.0/30 area 0.0.0.0
area 0.0.0.0 authentication
network 172.16.41.1/32 area 0.0.0.0
network 172.16.43.1/32 area 0.0.0.0
network 172.16.40.1/32 area 0.0.0.0
network 172.16.44.1/32 area 0.0.0.0
network 172.16.45.1/32 area 0.0.0.0
network 172.16.13.2/32 area 0.0.0.0
network 172.16.46.1/32 area 0.0.0.0
network 172.16.47.1/32 area 0.0.0.0

but if last interface is (note no authentication):
interface ovpns10

then:
router ospf
ospf router-id 192.168.40.1
log-adjacency-changes detail
passive-interface em1
passive-interface ovpns5
passive-interface em2
network 192.168.40.0/24 area 0.0.0.0
network 172.16.41.0/30 area 0.0.0.0
network 172.16.43.0/30 area 0.0.0.0
network 172.16.40.0/30 area 0.0.0.0
network 172.16.44.0/30 area 0.0.0.0
network 172.16.45.0/30 area 0.0.0.0
network 172.16.13.0/30 area 0.0.0.0
network 192.168.42.0/30 area 0.0.0.0
network 172.16.46.0/30 area 0.0.0.0
network 172.16.47.0/30 area 0.0.0.0
network 192.168.41.0/24 area 0.0.0.0
network 172.16.41.1/32 area 0.0.0.0
network 172.16.43.1/32 area 0.0.0.0
network 172.16.40.1/32 area 0.0.0.0
network 172.16.44.1/32 area 0.0.0.0
network 172.16.45.1/32 area 0.0.0.0
network 172.16.13.2/32 area 0.0.0.0
network 172.16.46.1/32 area 0.0.0.0
network 172.16.47.1/32 area 0.0.0.0

At least for me, this makes communication between daemons which doesn't have md5 configured stop working. In any case, I wouldn't expect a different order of the interfaces to solve things (If it's not supposed to work in the first place). I have omitted some of the early parts of the ospfd.conf, but would be happy to provide if needed.

Actions #1

Updated by Anonymous about 8 years ago

  • Subject changed from different output in ospfd.conf based on order of interfaces. to Qagga: Different output in ospfd.conf based on order of interfaces.
Actions #2

Updated by Kill Bill over 7 years ago

The description here makes no sense. I'd suggest to post some configuration screenshots with the interfaces configuration shown for both cases if you are having issues with the package in 2.3.x; packages for pfSense 2.2.x are not maintained any more.

Actions #3

Updated by Jim Pingle over 4 years ago

  • Status changed from New to Closed

One of many issues that are handled better in the FRR package. If you still have problems, migrate to FRR.

Actions

Also available in: Atom PDF