Project

General

Profile

Actions
Copy link

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
Copy link

Also available in: Atom PDF