Subscribe to GEN
Login to GEN
A network fails at the worst moment and usually gives plenty of warning first. GEN support the network and watch it, 24 hours a day, so the warning reaches somebody who can act on it and the fault reaches an engineer who knows what they are looking at.
We actively support thirteen families of network kit, from data centre switching to industrial gateways and the router in a branch office, and our engineers are UK based and in-house. If yours is not on the list, ask anyway.
Most network support starts when somebody notices a problem, by which time the problem has been running for a while. Our Oversight monitoring service reads your switches, routers and firewalls continuously from several vantage points, and only raises the alarm when the evidence agrees.
When it does, escalation runs the way you set it. If nobody acknowledges an alarm in time it moves on to the next step, whether or not anyone answered, so a missed call at three in the morning does not end the matter. Where the last step is our HelpDesk, the ticket arrives with the charts and the poll log from before the failure, and our engineers pick it up under your support agreement, at any hour.
Configuration, firmware, fault finding and technical consultancy on all of these. Oversight talks SNMP and REST, so whatever answers either can be watched, and we build the sensors around the kit you actually have, because the best route to a reading differs from one vendor to the next.
RouterOS routers and CRS switches, watched over SNMP and REST. A primary third line platform for us, with a page of its own.
Catalyst, ISR, ASR and Nexus. Supplies, fans, temperatures, stack members, BGP peers and uplinks over SNMP, with RESTCONF on IOS-XE and NX-API on Nexus as a second route.
EX, SRX, MX and QFX, now part of HPE. Junos raises its own red and yellow chassis alarms, and reading those covers a failed supply, a stopped fan or overheating at a stroke. The Mist console has an API that the REST sensor can read.
Switching supported alongside the HPE servers it connects, watched over SNMP, with port and link events from syslog.
EOS through eAPI, the switch's own JSON interface, so supplies, fans, temperature, MLAG, BGP and err-disabled ports come back as plain words. MLAG has no SNMP MIB, so this is the only way to watch it.
Spectrum switches running Onyx, Cumulus Linux or SONiC. The same hardware can run any of the three, and how it is watched depends on which, so that is the first thing we establish.
UniFi through the console's Network API, EdgeRouter and EdgeSwitch over SNMP, and airMAX radios over SNMP or the UISP API.
Vigor routers, watched over SNMP and ping for what matters on a Vigor, which is whether its internet connections are up.
Open source firewalls and routers, supported on your hardware or ours and watched over SNMP and syslog.
FortiGate firewalls, watched over SNMP, with the events that matter picked out of syslog.
Firebox appliances, watched over SNMP, with the events that matter picked out of syslog.
Cellular routers and gateways, watched over SNMP and syslog, with echo sensors to show whether the uplink itself is sound.
Industrial Ethernet switches and device servers, watched over SNMP, with the events that matter picked out of syslog.
Anything else is best efforts, and those are good efforts. If a device answers SNMP or a REST API, Oversight can read it, and our MIB library takes new vendors as data.
When a provider fails, a conventional monitor tells you about every switch, router and server behind it, and the one message that matters is lost among the rest. In Oversight you describe the network as it is: the provider or uplink sits above the site as a dependency, so its failure raises one alarm and everything it has cut off is shown as held.
Held is not the same as silenced. A device that can still be reached goes on reporting, and a real alarm from it still comes through. Held time is not counted as downtime against the device either, so the availability figures show where the outage really was.
A threshold tells you something has broken. Most network failures spend weeks not breaking any threshold anybody set, and then claim a crisis on a Friday afternoon. Oversight's behaviour analysis compares a sensor with its own history, by the day, the week and the same weekday, and says so when it is going somewhere or is not where it usually is.
It is your estate, so you choose which sensors it watches. It needs a few weeks of history before it says anything, because a baseline built from a few days is a guess.
A normal site produces hundreds of thousands of syslog lines a day, nearly all of it firewall logging and routine chatter. A small sender on your LAN keeps the full record locally and ships only the lines that matter: the loop warning, the switch that rebooted itself, the port flapping between 10M and 1G. They reach Oversight within five minutes, and it only ever connects out.
Echo sensors test one leg of a network: a LAN link, a leased line, a 4G or Starlink uplink, a tunnel between two sites. They measure loss, jitter, round trip and throughput in each direction, and whether the loss is scattered, as with weather or a failing cable, or one outage, as with a handover. It settles the argument about whose end it is.
GEN actively support Arista, Cisco, Juniper, HPE Aruba, NVIDIA (formerly Mellanox), Ubiquiti, DrayTek, pfSense and OPNsense, Fortinet, WatchGuard, Teltonika, Moxa and MikroTik. Anything else is taken on a best efforts basis, and those are good efforts: ask before assuming we cannot help.
They are separate services that work together. Support can be bought without monitoring, and Oversight is charged per read rather than per device. Used together, an alarm can raise a ticket on the GEN HelpDesk with its charts and poll log attached, so the engineer starts with the evidence.
Not all of it. Oversight talks SNMP and REST, so anything that answers either can be watched, but some platforms have sensors and templates already and others are built when a customer needs them. Once a check works on one device it is saved as a template and applied to the rest.
It moves on to the next step when its time is up, whether or not anyone answered. A typical chain tells your own staff, then calls your on-call, then raises a ticket with GEN. You choose the steps, the people and the timings per rule.
No, provided the provider or uplink sits above the site as a dependency in Oversight. It then raises one alarm, and what cannot be reached behind it is held rather than failed. Anything that can still be reached goes on reporting, so a real fault elsewhere still comes through.
No inbound ports are needed. Probes connect out to Oversight over HTTPS, and nothing connects in to them. Probes run in GEN's locations, and on your own network where a device can only be reached from inside it.
No. There is no support contract, no minimum term and no notice period. Customers buy hours at published rates and use them as they need them, or take a fixed price annual maintenance plan if they prefer a predictable cost.
Our engineers are UK based and in-house, with no offshore outsourcing: the specialist who takes your case is the specialist who works it, and they hold the production experience to match the equipment in front of them. Risk is assessed before anything is changed, the SAPR method is applied to every fault, and five shifts a day mean an overnight handover is a conversation between two engineers rather than a note left in a ticket. Our AI runs on our own hardware in our own data centres, and it never writes a word you read.
There is no support contract, no minimum term and no notice period. You buy hours at our published rates, use them when you need them, and what you do not use carries over. How GEN support works sets all of it out in full.