Project

General

Profile

Actions

Bug #8167

closed

FRR OSPF6 range problem (subnet not advertized)

Added by Andrew Webster about 7 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
FRR
Target version:
-
Start date:
12/05/2017
Due date:
% Done:

100%

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

Description

The range statement inside the router ospf6 clause seems to have the opposite effect of what is expected.

FRR docs seem to indicate area support isn't implemented...yet, and the FRR docs example was imported directly from Quagga with no context around it, so unsure where exactly this lies, but if the config script didn't generate a range statement it would work as expected (ie: subnet is advertised). As it stands this is not the case.

In the below example, with the area ... range ... commented out, the subnets fd33...3100/64 and fd33...3200/64 are advertised as expected.

router ospf6
  router-id 10.125.240.87
  interface em0 area 0.0.0.0
  interface em1 area 100.64.31.0
  interface em2 area 100.64.32.0
  area 0.0.0.0 range xxxx:xxxx:xxxx:28f0::/64 cost 1
  area 0.0.0.0 export-list dnr6-list
#  area 100.64.31.0 range fd33:3e94:8260:3100::/64 cost 1
  area 100.64.31.0 export-list dnr6-list
#  area 100.64.32.0 range fd33:3e94:8260:3200::/64 cost 1
  area 100.64.32.0 export-list dnr6-list
ipv6 prefix-list dnr6-list permit any
route-map DNR6 permit 10
  match ipv6 address prefix-list dnr6-list

From neighboring pfsense with FRR 0.0.7, we can see the subnets advertised only if area ... range ... is commented out.

*N IE fd33:3e94:8260:3100::/64       fe80::20c:29ff:fe74:8efb     em0 00:09:26
*N IE fd33:3e94:8260:3200::/64       fe80::20c:29ff:fe74:8efb     em0 00:09:26

As a work-around, if I enable redistribute connected subnets, then it also advertises the connected networks, regardless of the interface's settings, but they appear as external-1 type with a metric of 10 (E1 in 2nd column) as opposed to Inter-Area above with a metric of 20. (You can only see the metric in the detailed output).

*N E1 fd33:3e94:8260:3100::/64       fe80::20c:29ff:fe74:8efb     em0 00:01:20
*N E1 fd33:3e94:8260:3200::/64       fe80::20c:29ff:fe74:8efb     em0 00:01:20

In looking at the detailed output of the OSPF6 routes, in both cases, they do indeed appear to all be associated with area 0.0.0.0 which would lend credence to FRR's statement that the area function isn't yet implemented.

Actions #1

Updated by Jim Pingle over 5 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

Disabled area..range statements in FRR pkg version 0.5.0
Doesn't look like they are supported even on FRR 7.

Actions #2

Updated by Jim Pingle over 5 years ago

  • Status changed from Feedback to Resolved

Ended up adding this back, AFAIR it was an issue with the ordering of the statements. It's been fixed (properly) for a while now.

Actions

Also available in: Atom PDF