Skip to content

Network Segment

Large networks tend to be hierarchical by nature, separating to various layers. i. e. core, aggregation, access e.t.c. Therefore the network can be considered as hierarchy of interconnected parts, called Network Segments

Network Segment is a group of Managed Objects taking specific part in network hierarchy. Each Managed Object MUST belong to one Network Segment. Typical Network Segment hierarchy:

graph TB CORE(Core) AGG1(Aggregation #1) AGG2(Aggregation #2) ACC11(Access #1-1) ACC12(Access #1-2) ACC21(Access #2-1) ACC22(Access #2-2) CORE --- AGG1 CORE --- AGG2 AGG1 --- ACC11 AGG1 --- ACC12 AGG2 --- ACC21 AGG2 --- ACC22


NOC considers that is Managed Object belongs to segment, not the link. So in terms of network separation NOC uses IS-IS approach, not OSPF one.

Each segment except top-level ones has exactly one Parent and has zero-or-more Children segments. So segment provides connectivity between its children and the rest of network.

Proper segmentation is the key concept for various areas:

  • Root-Cause Analysis (RCA) for Fault Management
  • Network Maps
  • VLAN management
  • Configuration generation and checking


NOC considers that proper segmentation is performing during network design and planning stage. Sometimes it's not true and segmentation is implicit or ad-hoc. Despite it considered Bad Practice NOC offers various methods for Automatic Segmentation

Group Settings

Group settings for Network Segments are contained in Network Segment Profiles

Segment Topology

Segment is the set of Managed Objects and links between them so it can be considered a Graph. NOC extends Graph with all Managed Objects from adjacent segments, connected to given segment to build Segment Topology. NOC automatically recognizes following topologies


Tree topology contains exactly one path between any Object.

graph TB MO1 --- MO2 MO1 --- MO3 MO1 --- MO4 MO2 --- MO5 MO2 --- MO6 MO6 --- MO7 MO3 --- MO8 MO3 --- MO9 MO4 --- MO10 MO4 --- MO11 MO10 --- MO12

Tree offers no redundancy. Any failed Object makes its children unavailable. Following example shows failed MO3 makes MO8 and MO9 unavailable.

graph TB style MO3 fill:#c0392b style MO8 fill:#7f8c8d style MO9 fill:#7f8c8d MO1 --- MO2 MO1 --- MO3 MO1 --- MO4 MO2 --- MO5 MO2 --- MO6 MO6 --- MO7 MO3 --- MO8 MO3 --- MO9 MO4 --- MO10 MO4 --- MO11 MO10 --- MO12

NOC performs auto-layout of Tree segment maps and proper RCA


Forest is common case with two-or-more independent trees. Like a Tree

graph TB MO1 --- MO4 MO1 --- MO5 MO5 --- MO6 MO2 --- MO7 MO2 --- MO8 MO3 --- MO9 MO3 --- MO10 MO9 --- MO11

Forest offers no redundancy. Any failed Object makes its children unavailable. NOC performs auto-layout of Forest segment maps and proper RCA


Forest segments should be split to several Tree segment unless you have explicit reason to use Forest


Common Ring topology considers each object connected with exactly two neighbors

graph TB MO1 --- MO2 MO1 --- MO5 MO2 --- MO3 MO3 --- MO4 MO5 --- MO6 MO6 --- MO4

Ring offers protection against single node failure. Following example shows MO3 failure not affects other objects

graph TB style MO3 fill:#c0392b MO1 --- MO2 MO1 --- MO5 MO2 --- MO3 MO3 --- MO4 MO5 --- MO6 MO6 --- MO4

Though additional failure of MO6 leads to MO4 unavailability

graph TB style MO3 fill:#c0392b style MO6 fill:#c0392b style MO4 fill:#7f8c8d MO1 --- MO2 MO1 --- MO5 MO2 --- MO3 MO3 --- MO4 MO5 --- MO6 MO6 --- MO4

Pure Ring topology is rather expensive, as any Object must be capable of forwarding all ring's traffic and is not very flexible to expanding port space. So real networks tends to use combined Ring and Tree topology, while segment's backbone is the common Ring combined with small expansion trees, attached to Ring nodes. Port expansion is performed with cheap switches contained within same PoP with backbone nodes.


Show Ring-and-Tree topology and describe fault propagation

NOC performs neat auto-layout of Ring segment maps and proper RCA


Mesh is the common graph which is not Tree, Forest or Ring

graph TB MO1 --- MO2 MO1 --- MO3 MO2 --- MO3 MO3 --- MO4 MO4 --- MO5 MO1 --- MO5

NOC performs probabilistic spring layout for mesh networks which may require manual correction and performs proper RCA in most cases

Except in rare cases Managed Objects should have one or more Paths to upper levels of network (to establish Connectivity with all network) or to the NOC's probes (to be monitored and managed at all).

Those paths are called Uplink Paths and all direct Neighbors on the Uplink Paths are called Uplinks. The role of Uplink is to provide Connectivity for its Downlink. For reserved topologies object's Uplink may be its Downlink at the same time.

Uplinks are key concept for RCA. Managed Object with all unavailable uplinks looses Connectivity and problem lies somewhere on the Uplink Paths.

NOC perform automatic uplinks calculation on topology changes. The proccess can be configured via Network Segment Profiles Uplink Policy setting.

It is advised to avoid very large segments (>100 Objects)

Segment Uplinks is the objects providing Connectivity for any of Segment's objects. Segment Uplinks can belong to segment itself, or may belong to any neighbor segment

Horizontal Transit

Sometimes network segments of same level connected together for backup purposes. So in case of uplink failure one segment can use other as temporary uplink (S2 - S3 dotted link).

graph TB S1 --- S2 S1 --- S3 S2 -.- S3

NOC offers additional Network Segment setting to specify whether such horizontal traffic flow is acceptable. Horizontal Transit Policy configured on per-segment and per- Network Segment Profile basis via Horizontal Transit Policy setting. Possible values are:

  • Profile (default): Use Horizontal Transit Policy from Network Segment Profile.
  • Always Enable: Horizontal Transit is always enabled.
  • Disable: Horizontal Transit is always disabled.
  • Calculate: Horizontal Transit is enabled if horizontal link is present

NOC adjust RCA behavior in according to Horizontal Transit Policy, considering neighbor segment as additional Uplink Path.

Sibling Segments

Network topology may change over time. Consider typical scheme of broadband access network:

graph TB subgraph Parent AGG1 end subgraph ODF P1 P2 P3 P4 end subgraph Segment1 MO11 MO12 MO13 end subgraph Segment2 MO21 MO22 MO23 end AGG1 --- P1 P1 --- MO11 AGG1 --- P2 P2 --- MO13 MO11 --- MO12 MO13 --- MO12 AGG1 --- P3 P3 --- MO21 AGG1 --- P4 P4 --- MO23 MO21 --- MO22 MO23 --- MO22

Two separate optic cables build two access ring and terminated on four ports on aggregation switch. Consider we'd overestimated demands on Segment1 or on Segment2 or on both of them and total load on segments remains relatively low. Then we became short of ports in AGG1. We'd decided to connect MO13 and MO21 directly bypassing AGG1, so we'd disconnected two ports on AGG1 and shorted ports P2 and P3 on ODF by optical patch-cord:

graph TB subgraph Parent AGG1 end subgraph ODF P1 P2 P3 P4 end subgraph Segment1 MO11 MO12 MO13 end subgraph Segment2 MO21 MO22 MO23 end AGG1 --- P1 P1 --- MO11 P2 -.- P3 P2 --- MO13 MO11 --- MO12 MO13 --- MO12 P3 --- MO21 AGG1 --- P4 P4 --- MO23 MO21 --- MO22 MO23 --- MO22

Technically, we'd merged Segment1 and Segment2 building larger segment. We can simple move MO21, MO22 and MO23 to Segment1 and eliminate Segment2. But sometimes is necessary to leave Segment1 and Segment2 separation (lots of printed documentation, maintenance service's habbits, reporting and direct links). NOC allows to declare Segment1 and Segment2 as the Sibling Segments. Sibling Segments considered as single segment in hierarchy, processed as one in Uplinks calculations and shown as a single map, though remaining two separate segments in database and reporting.

VLAN Domains

Network Segments are closely tied with VLAN concept. VLANs are not obliged to be network-wise, so VLAN 100 in one part of network may not be same VLAN 100 from other part so VLAN space may be overlapped. Unlike IPv4/IPv6 address space, which uses VRF to deal with address space overlaps, 802.1 set of standards do not introduce global distinguisher for VLAN space. So NOC uses concept of VLAN Domain. VLAN Domain, shortly, is an area with unique VLAN space. So VLAN 100 from different domains is not same VLAN 100, while VLAN 100 on differen Managed Objects from same VLAN domain may be considered same VLAN 100

For clearance and ease of maintenance NOC considers VLAN Domain as a part of segment hierarchy. NOC uses VLAN border mark on segment to split segments tree to VLAN Domain. VLAN Domain covers VLAN border segment and all its descendants until next VLAN border.

Consider example:

graph TB style S1 stroke-width:4px style S6 fill:#0f0,stroke-width:4px style S10 fill:#0f0 style S11 fill:#0f0 S1 --- S2 S1 --- S3 S1 --- S4 S2 --- S5 S2 --- S6 S3 --- S7 S3 --- S8 S4 --- S9 S6 --- S10 S6 --- S11

VLAN borders marked by thick frame: S1 and S6. First VLAN domain (blue) consist of S1, S2, S3, S4, S5, S7, S8 and S9. Second VLAN domain (green): S6, S10 and S11. Though S6 is descendant of S1 it is marked as VLAN border, so it starts its own domain.


Though VLAN domains are groups of Network Segments and VLAN domain is a set of Managed Object, empty network segments can be attached to Subinterfaces, so one Managed Object can still handle multiple VLAN domains

For ease of maintenance NOC automatically attaches all VLAN domain's VLANs to appropriate VLAN border.

VLAN Translation

NOC consider any implicit VLAN passing stops at VLAN border. Though it possible to propagate VLAN further via VLAN Translation Rules. Consider scheme:

graph TB style S1 stroke-width:4px style S2 fill:#0f0,stroke-width:4px S1 --- S2

S1 and S2 both VLAN borders. Managed Objects MO1 and MO2 belongs to S1 and S2 respectively.

VLAN Translation Rules are defined at VLAN border segments as a list of rules. Each rule contains following fields:

  • filter: :doc:/reference/vc-filter
  • rule: king of operation
  • parent_vlan: reference to VLAN from parent segment

Rules are processed in definition order. First matching rule wins.

NOC supports two kind of rules: Map and Push.


Map rule converts VLAN 802.1Q tag from target VLAN domain to 802.1Q tag from parent's segment.

VLANs can be either rewritten

sequenceDiagram MO1 ->> Border: Tag=100 Border ->> MO2: Tag=200


Or extended (rewritten to same tag)

sequenceDiagram MO1 ->> Border: Tag=100 Border ->> MO2: Tag=100



Push rule appends additional 802.1Q tag in top of existing 802.1Q tag, allowing Q-in-Q tunneling.

sequenceDiagram MO1 ->> Border: Tag=100 Border ->> MO2: Tag=300,100


VLAN Allocation Group

MAC Discovery

MAC topology discovery can be used as last resort when other methods are failed. Contrary to other per-object methods MAC discovery performed is per-segment basis using previously collected MAC addresses. See Discovery Segment MAC for details.


Segmentation may be performed automatically during box discovery. See Discovery Box Segmentation for details


Network Segment Topology Ring and Network Segment Topology Mesh offer path redundancy. NOC detects segment redundancy automatically. Outages in redundant segments can leave to Lost of Redundancy. Lost of Redundancy means that currently working services are left without proper redundancy and are at risk in case of following outage. During the outage NOC calculates affected services and services with Lost of Redundancy and provides information to escalated Trouble Tickets.

Object Settings

Segments can hold Managed Object's recommended settings for config generation and validation Settings can be either scalar (defined once) or list (can be declared multiple times). Omitted settings are inherited from parent segment, allowing to define global settings at top level and refine them on lower levels

Key Multi Description
domain_name No Default domain name
dns Yes DNS server's address
ntp Yes NTP server's address
default_gw No Default gateway for management network
syslog_collector Yes SYSLOG collector's address
snmp_collector Yes SNMP Trap collector's address
aaa_radius Yes RADIUS AAA server's address used for authentication
radius_collector Yes RADIUS collector's address
aaa_tacacs Yes TACACS+ AAA server's address used for authentication
tacacs_collector Yes TACACS+ collector's address
netflow_collector Yes NetFlow collector's address


Network Segment's L2 MTU is minimal ethernet payload size guaranteed to pass via Segment. MTU is accounted without 802.3 ethernet header (which is 14 bytes in length) but with all other encapsulation headers (802.1Q, MPLS, etc).

Common L2 MTU values:

L2 MTU Description
1500 Common untagged ethernet packet
1504 802.1Q VLAN tagged packet
1508 Q-in-Q packet
1536 MPLS packet with up to 3 labels
<1600 Baby giant
>1600 Jumbo

Understanding real segment's L2 MTU is viable part of providing effective| ethernet transit services. Transit interface with improper MTU may lead| to occasional packet drops. Such drops can lead to hard-to-diagnose| disruption of services.

Network Map Settings

NOC displays Network Map on per-segment basis. To provide seamless navigation along segment hierarchy in additional to segment's objects NOC shows all connected objects from adjacent segments. Sometimes is necessary to suppress displaying very large amount of downlinks on network map.

Network Segment has following settings for network map tuning

Name Default Description
max_shown_downlinks 1000 Collapse object's downlinks on network map when count is above the threshold


When Network Map contains over 300 objects "Too many objects" message will be shown. Larger maps may cause browser freeze or crash.