On this page
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:
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 automatical segmentation
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.
Tree offers no redundancy. Any failed Object makes its children unavailable. Following example shows failed MO3 makes MO8 and MO9 unavailable.
NOC performs auto-layout of Tree segment maps and proper RCA
Forest is common case with two-or-more independ trees. Like a Tree
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
Ring offers protection against single node failure. Following example shows MO3 failure not affects other objects
Though additional failure of MO6 leads to MO4 unavailability
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
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).
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.
Network topology may change over time. Consider typical scheme of broadband access network:
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:
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.
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 distingueisher 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.
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 appropriative VLAN border.
NOC consider any implicit VLAN passing stops at VLAN border. Though it possible to propagate VLAN further via VLAN Translation Rules. Consider scheme:
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: 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
Or extended (rewritten to same tag)
Push rule appends additional 802.1Q tag in top of existing 802.1Q tag, allowing Q-in-Q tunneling.
VLAN Allocation Group¶
Describe VLAN allocation group
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 mac for details.
Segmentation may be performed automatically during box discovery. See segmentation for details
Ring and 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.
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
|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
|1500||Common untagged ethernet packet|
|1504||802.1Q VLAN tagged packet|
|1536||MPLS packet with up to 3 labels|
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.
Automatic detection of segment’s L2 MTU is work-in-progress See #624 for details
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
|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.