Project

General

Profile

Actions

Bug #5018

closed

neighbor config broken: need separate neighbor section, but 'write file' puts the config back inline

Added by neels about 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
02/11/2021
Due date:
% Done:

100%

Spec Reference:

Description

when reading the config OsmoBSC resolves the neighbor relations between cells immediately.
So when writing 'neighbor bts 23', that cell must already exist and be configured.

Same for identifying a neighbor by Cell Global ID / LAC-CI etc:
the config parsing immediately resolves the id, and classifies it as local or remote BTS.
Hence a local neighbor BTS must already be configured beforehand.

A consequence of this is that the config file must first configure all cells,
and in another section below configure only the neighbor relations:

network
 # first set up all cells
 bts 0
  description my test BTS 0
  type sysmobts
  band GSM-1800
  ip.access unit_id 0 0
  location_area_code 23
  [...]
 bts 1
  description my test BTS 1
  type sysmobts
  band GSM-1800
  ip.access unit_id 1 0
  location_area_code 42
  [...]

 # neighbor relations
 bts 0
  neighbor bts 1
 bts 1
  neighbor bts 0

However, the 'write file' feature puts the neighbor relations back inline,
combining the two "config sections" and hence breaks the resulting config.

One solution would be to change 'write file' so that it puts neighbor relations in a separate section.
However, having to put neighbor config separately also potentially confuses users.
So a nicer solution would be to allow putting a neighbor relation in the config before that neighbor is configured.

Actions #1

Updated by neels about 3 years ago

Actions #2

Updated by neels about 3 years ago

Actions #3

Updated by neels about 3 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 80
Actions #5

Updated by neels almost 3 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

Patches merged, issue should be fixed now.

Neighbor configuration should be permitted in any order, before or after the neighbor target cells are configured in the config file.
Also, neighbor configuration should be written back to the config file exactly as it was originally configured.

If there are neighbor configuration errors (like non-existing BTS number; non-existing local cell identity etc), osmo-bsc should refuse to start up.

When configuring neighbors on the live VTY console, that error checking does not happen; errors will still be logged as osmo-bsc resolves neighbors and encounters config errors. One possible pitfall: when such an erratic config from live VTY is written to file and osmo-bsc is restarted, the startup will complain about neighbor config errors and osmo-bsc will not start.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)