Project

General

Profile

Feature #4521

gbproxy: Redundancy between NS-VCs (SGSN Side)

Added by laforge 9 months ago. Updated 2 days ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Start date:
05/01/2020
Due date:
% Done:

50%

Spec Reference:

Description

Each Server running osmo-gbproxy features multiple Ethernet Interfaces which can be connected to redundant Switches of a highly-available IP interconnect to the SGSN. The normal Gb/IP interface procedures of the IP-SNS ensure redundant NS-VCs are established via all of the Gb-Proxy side IP addresses.

We need to ensure that we continue to operate without interruption even when some of the NS-VCs to the SGSN are becoming unavailable.


Related issues

Related to osmo-gbproxy - Bug #4959: Problems on NS-VC recoveryNew01/19/2021

History

#1 Updated by laforge 2 months ago

  • Status changed from New to In Progress
  • Assignee set to laforge
  • Priority changed from Normal to High

#2 Updated by laforge 3 days ago

  • % Done changed from 0 to 50

IP-SNS allows us to establish NS-VCs to multiple IP endpoints of each SGSN. In theory there is redundancy between those NS-VCs. We just need to test that this actually works.

Also, there are of course link-layer redundancy mechanisms on L2 or L3 such as STP, VRRP, OSPF, RIP, etc. that can be used to facilitate redundancy on the transport level between gbproxy and SGSN.

We'll lleave this ticket to extend our automatic tests to cover situations where some NSVCs are dying and traffic shall continue over other NS-VCs.

#3 Updated by laforge 3 days ago

  • Status changed from In Progress to New
  • Priority changed from High to Normal

#4 Updated by laforge 2 days ago

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/22315 introduces the capability to temporarily disable and re-enable NSVSs in TTCN3.

#5 Updated by laforge 2 days ago

  • Related to Bug #4959: Problems on NS-VC recovery added

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)