i2i NetPulse
A network monitoring system (NMS) for ISPs that shows which customers a fault hits
Customer equipmentIllustrative| Serial | Model | Firmware | Signal |
|---|---|---|---|
| ZTEG-C8A1F2 | ONT · F670L | V9.0.11 | −19.8 dBm |
| HWTC-7B20E1 | ONT · HG8245H | V3R017 | −21.4 dBm |
| TPLK-40F3A9 | Router · EX220 | 1.2.3 | Online |
| ZTEG-C8B07D | ONT · F670L | V9.0.10 | −28.6 dBm |
Alarm Low optical power on ZTEG-C8B07D
Overview
i2i NetPulse is a network monitoring system (NMS) for ISPs. An edge probe on your own network polls switches, routers, OLTs, ONUs, servers and BGP peers, and the platform turns those readings into alerts, dashboards and reports. It is strongest on GPON and EPON fibre networks.
Its distinguishing feature is subscriber impact. NetPulse links ONUs to customers synced from your billing system, so a failed OLT or PON port shows the customers behind it rather than only a list of dead devices. Rules can suppress the flood of per-ONU alerts when a parent fault explains them, which keeps the NOC focused on the cause.
At a glance
- One probe polls switches, OLTs, servers and BGP peers
- Alert storms suppressed by parent and child rules
- Customers behind a failed OLT or PON port listed
- Fibre routes, splitters and drops kept in a GIS map
What is a network monitoring system (NMS) for an ISP?
Network monitoring is the continuous collection of measurements from network equipment and the analysis of those measurements to find faults early. Common sources are SNMP polling, command-line queries to devices that expose little over SNMP, ICMP ping and syslog messages that devices send when something changes.
Fibre access networks add their own signals. An OLT serves many ONUs over passive splitters, so the useful measures include optical power on each ONU, the state of each PON port and messages such as dying gasp, which an ONU sends when it loses power. A single cut can turn hundreds of ONUs offline at once, and a monitoring system that raises one alert per ONU buries the real cause.
Good monitoring therefore groups alerts by cause, watches for slow degradation as well as hard failure, and tells operators who is affected. It routes alerts to the responsible team, respects maintenance windows and keeps enough history to show trends. Because the equipment sits in many sites, collection often runs from a small probe on the local network that reports outward, so the operator does not open inbound firewall rules.
Capabilities
What i2i NetPulse does
Collection
- Edge probe using SNMP, telnet and SSH
- ICMP ping and syslog listener
- Agentless Linux and Windows host monitoring
- BGP peer and route sensors
Fibre access
- PON port and ONU sensors
- ONU state events from OLT syslog
- Optical power and drift insights
- Drivers for many OLT and switch vendors
Alerting
- Threshold, rate-of-change and status rules
- Mass-offline and ONU-flapping rules
- Parent and child inhibition, maintenance windows
- Escalation and bulk acknowledge or resolve
Notification
- Telegram, email, WhatsApp and webhook channels
- Recipient groups and quiet hours
- Daily summaries and digests
- Message templates per rule
Subscriber impact
- Customers synced from i2i billing
- ONU-to-customer MAC linking
- Customers listed behind a device or PON port
- Alert when subscribers online drop
Topology and GIS
- Topology from LLDP with cable-move detection
- Fibre routes, cables, joints and splitters
- Power-budget calculation on fibre paths
- Field capture with an approval workflow
Use cases
Where i2i NetPulse is used
Cut fibre on a PON
A fibre cut takes a whole PON port offline. The mass-offline rule raises one alert for the port and inhibits the alerts for each ONU beneath it. The operator opens the customer-impact view to see which subscribers are affected and passes the list to support.
Fibre degrading slowly
An optical link loses power a little each day and has not yet crossed a hard threshold. Optical drift insights flag ONUs trending the wrong way, so the field team can clean a connector or replace a splitter before the customer loses service.
One probe per site
An ISP with several POPs installs a probe on each management network. The probes poll switches, servers and BGP peers locally and send results outward over HTTPS, so no inbound firewall rule to the management network is needed.
Keeping the fibre map current
A field engineer records a new splice or customer drop using the field capture flow. A supervisor approves the change, and the GIS records for routes, joints and splitters stay accurate for planning power budgets.
FAQ
i2i NetPulse: frequently asked questions
Does i2i NetPulse collect traffic flow records?
No. NetPulse polls devices by SNMP and command line, listens for syslog and pings hosts, but it does not collect traffic flow records. If you need flow data for traffic analysis or record keeping, use a separate collector alongside it.
Can it predict which customers will leave?
No. NetPulse has one trained model, which predicts which online ONUs are likely to go offline in the next day. It also ranks customers for proactive support calls after network faults. It does not predict which customers will cancel service.
Which equipment can it monitor?
Drivers cover many GPON and EPON OLTs, including V-SOL, C-Data, ZTE, Huawei, Genexis and TP-Link families, plus Cisco, MikroTik, Huawei and Raisecom switches, and generic SNMP. Linux and Windows hosts are monitored without an agent. Ask us to confirm your exact models.
Does it need inbound firewall rules?
No. The probe registers with a one-time token and connects outward to the backend over HTTPS. It polls your devices from inside your network, so the management network is not exposed to the internet for monitoring.
How does it know which customer sits behind an ONU?
It syncs customers and session state from your billing system through a provider for i2i billing, then links ONUs to customers by MAC address. The sync is one-way. Where ONUs cannot be linked, they appear on an unlinked list for staff to resolve.
Does it run as a service or in our own data centre?
The same code runs as a shared multi-tenant service or as a dedicated instance for one operator. It is built from a web application, a probe, a database and a Python sidecar for the prediction model. There is no cluster design; ask us about sizing for your estate.
Is there an assistant for the NOC?
Yes, an operator assistant that answers questions using read-only tools over your monitoring data. The model provider is selectable per tenant. It reads data and does not change devices or configuration.