Skip to content

Network engineering

A network that does not stop when one link goes

L2/L3 design, BGP and OSPF policy, MPLS core, wireless access and migrations — every change proven on a digital twin before it reaches production.

The problem

The network grew; the design stayed where it started

Every new site went into the nearest free port, VLANs are numbered by tradition, and the routing policy was written during incidents. Nobody can answer "what happens if we lose the core switch?" — and the MTU mismatch shows up only once traffic has already broken.

  • The edge sits on a single device
  • Policy grew; nobody ever reviewed it
  • The L2 domain is larger than it should be
  • Changes go in without a lab

What we deliver

A network that does not stop when one link goes

Topology map

A physical and logical diagram with the SPOFs listed and the cost of each one.

L2 domain plan

VLAN scheme, QinQ, MSTP/RSTP, LACP and MTU brought into one standard.

Routing policy

OSPF areas, iBGP/eBGP, communities, filters and BFD — with the intent documented.

Edge and upstreams

A second upstream, RPKI ROAs, max-prefix limits and route-leak filtering.

Migration plan

Steps, windows, rollback and acceptance criteria — tested on the digital twin.

Wiring into monitoring

Interfaces, BGP sessions, optical levels and flow — the new design is visible from day one.

Architecture

Architecture

  1. 01Transit / IXPMultiple upstreams
    • Full view
    • IXP peering
  2. 02Edge routersRedundant, with BFD
    • ASR 9000
    • MX
    • CCR
  3. 03PolicyPrefix control
    • RPKI
    • max-prefix
    • communities
  4. 04Core / MPLS
    • OSPF
    • MP-BGP
    • L3VPN
  5. 05AccessSubscriber termination
    • PPPoE/IPoE
    • RADIUS
Dual edge: transit, peering, policy and RPKI validation

Operator consoles

Operator consoles

These exact systems run on the group's own infrastructure — the screenshots are processed before publication.

Blurred AS Upstream analyser showing a per-prefix visibility table across three transits.

BGP visibility per upstream

Each prefix and how visible it is through each transit — which upstream propagates which prefix, and in what share. This is how a route leak, a missing announcement or a mis-built policy becomes visible before it becomes an incident. The tool is public on noc.com.ge.

BGPper-prefixRPKIpublic tool
A network map of wireless links — each node showing client count, CCQ, noise floor, airMAX quality and capacity, distance and frequency; hostnames removed.

One map — MikroTik, Ubiquiti and Cambium together

A small or mid-sized operator's network is rarely single-vendor: MikroTik in the core, Ubiquiti on the wireless links, Cambium at the access layer. This map carries, per link, what operations actually runs on — wireless clients on the sector, CCQ, noise floor, airMAX quality and capacity, distance, frequency, Rx/Tx and uptime. The tower power nodes sit on the same map: battery voltage is a metric like any other here, and it explains half of the night-time outages.

MikroTikUbiquitiCambiumairMAXSNMP
The phpIPAM dashboard — aggregate statistics for subnets, VLANs and addresses, with usage charts.

IPAM — the address space in one system

A live phpIPAM deployment: subnet hierarchy, VLAN domains, VRFs, devices and locations in one searchable database. Only the aggregate statistics are public — customer names, individual subnets and locations are not on the frame, and should not be.

phpIPAMIPv4 / IPv6VLANVRF
Blurred EVE-NG topology showing routers, switches, peerings and management network links.

The digital twin — the lab that comes before production

A topology built from real network operating systems: border routers, IXP and CDN peerings, the aggregation layer, VLANs and the management network — production, replicated in the lab. Migration, failure and rollback run here first; only then does anyone touch the live network.

EVE-NGIOS XRBGPpre-production

Capabilities

Capabilities

Every item is marked: verified production experience, or engineering capability.

Multi-homed BGP edge

Proven

The group's own AS203136 runs on three upstream operators — on the same principles we deploy on a client edge.

  • BGP
  • BFD
  • Communities

RPKI and prefix filtering

Proven

ROAs published and valid, verifiable in the RIPE registry; max-prefix and leak filters are part of every edge.

  • RPKI
  • ROA
  • Routinator

OSPF and internal routing

Proven
  • OSPF
  • iBGP
  • BFD

L2 design and Metro Ethernet

Proven
  • VLAN
  • QinQ
  • MSTP
  • LACP

Subscriber termination and AAA

Proven

PPPoE and IPoE termination with RADIUS and accounting — in a live access network.

  • PPPoE
  • IPoE
  • RADIUS
  • DHCP

Wireless access networks

Proven

Sector and point-to-point links managed from central consoles — in daily operation on our own access network.

  • UISP
  • cnMaestro
  • 802.11ax

MPLS core and L3VPN

Capability
  • MPLS
  • MP-BGP
  • VRF

EVPN-VXLAN fabric

Capability
  • EVPN
  • VXLAN
  • Arista
  • FRR

SD-WAN for branch sites

Capability
  • SD-WAN
  • IPsec
  • Overlay

IPv6 plan and dual-stack

Capability
  • IPv6
  • Dual-stack
  • rDNS

Process

Process

  1. 01

    Audit

    Topology, configurations and what the traffic actually does.

  2. 02

    Design

    Target architecture and policy, with the reasoning.

  3. 03

    Validate

    The same topology in EVE-NG: failure and rollback.

  4. 04

    Migrate

    In stages, inside agreed windows.

  5. 05

    Observe

    The new design in monitoring and flow.

  6. 06

    Handover

    Diagrams, runbooks and training for your team.

Technology stack

Technology stack

Edge and core
CiscoJuniper MXMikroTik CCRAristaFRR
Access
Metro EthernetGPONUISPcnMaestro
Protocols
BGPOSPFMPLSVRRPBFDLACP
Subscriber
PPPoEIPoERADIUSDHCP
Validation
EVE-NGiperfRFC 2544
Monitoring
LibreNMSZabbixPrometheusAkvorado

Engagement model

Engagement model

Project

A one-off scope: audit, migration or implementation with a fixed outcome.

Retainer

Monthly engineering hours — specialist access on demand.

Co-managed

NetWizard and your in-house team together, with split responsibility.

Use cases

Use cases

Adding a second upstream

One transit means their outage is your outage. We add the second, write the policy with communities and prove it in the lab before the session comes up in production.

Breaking up a flat network

One large L2 domain where a broadcast storm reaches everyone. We split it into segments, tidy the addressing and join it at L3 — in stages, without stopping the service.

Replacing the hardware

Support is ending or the platform is changing. The configuration is rewritten from the new design, proven on the digital twin, and only an approved plan goes into the night window.

FAQ

FAQ

Do you run a network yourselves?

Yes. The group holds AS203136, announces 185.143.176.0/22 with a valid RPKI ROA and connects to three upstream operators — independently checkable in the RIPE registry.

Will you take on a multi-vendor network?

Yes — most of them are. Cisco, Juniper, MikroTik and Arista in one network is the normal case; what has to be uniform is the policy and the documentation, not the hardware.

How long does a migration take?

It depends on the size of the network and how many windows are available. We give the schedule after the audit and the lab test — a number offered before that would be a guess.

Tell us about your infrastructure