The campus network WiFi Network Billing System is online, and the real testing of the information sector is just beginning. The network is a continuous operation, not an option."If you're ready, don't worry about it."The campus network is especially faced with tens of thousands of students who use unpredictable methods and have a random breakdown in their network equipment. Without a robust system of security, the operator is there."Waiting for an accident."Not."Network management"。
First, we'll separate the three levels of surveillance.
Transport surveillance is not a general concept, and there are at least three levels to be distinguished in the WiFi network billing system on campus.
The first level is network infrastructure monitoring. This includes AP online status, AC (wire controller) active status, switch port flow, and export bandwidth usage. Most of these data come from the SNMP or Telemory interfaces of the network equipment itself. They are not directly related to the billing system, but they can help you to quickly judge if there's a problem with the billing system."Network faults"Or..."Applied fault.". For example, the student WiFi report is not connected; if surveillance shows that all APs on the corresponding floor are offline, it's a problem with the network level.
The second level is the monitoring of certification services. This is at the heart of a system: CPU and memory usage for authentication servers, success rates and response times for RADIUS requests, trends in online users, and distribution of error types for authentication failures. These indicators can tell you whether the system is healthy today or near its carrying limits.
The third level is business anomaly surveillance. For example, a sudden increase in the failure rate of certification over a given period of time, a continuous overtime of an operator’s authentication chain, and an unusually low number of online users in one dormitory building. These anomalies may not be equipment failures but are caused by changes in configuration, operator network fluctuations, or student batch switching numbers.
Where did the surveillance come from?
Most APs and ACs support SNMP v2c or v3, and you can attach their IP, community string to the monitoring system, automatically collecting indicators of CPU use, memory usage, customer-end connections, etc. Export bandwidth controls can be used to sample port traffic on core switches or firewalls.
The monitoring data for the certification service level are derived mainly from the system itself. A good billing system should provide a surveillance API or at least expose key indicators through the log. If there is no available API, it can be analysed by logging.——The method is not as accurate as the direct API call, but it is more common.
The control data for the operating anomaly level are scattered: user complaints records (from help desk worksheet systems), failure notices from operator feedback, automated inspection scripts. These data cannot be collected by a single tool and require a carrier to have one."Information Gathering"It's a habit.——Whether by nailing, flying books or mail, unusual signals are concentrated in one place to facilitate rapid judgement.
How do you tell the police?"The wolf's here."
The security is good, and if the alarm is bad, the result is that the carrier shieldes all alerts and then the surveillance system becomes a virtual vacuum. There are two most common warning problems in the campus web site: too many warnings (a reboot of one device produces dozens of related alerts) and less specific warnings (only to tell you)."Certification service abnormal"But I don't know if it's RADIUS that is overtime or the database that doesn't connect.
The solution to the alarm surge is to create a warning aggregation and hierarchy. Apologize is to combine multiple alerts from the same root into one.——Like 20 APs under a certain AC that are offline at the same time, should send one."AC-X malfunctions resulted in 20 APs being offline"Not 20."AP offline"The classification is based on the severity of the P0 to P3: P0 affects a large number of users (e.g., export links are broken), and must be dealt with immediately; P1 is affecting some users (e.g., an AC anomaly in one floor) and must respond within 30 minutes; and P2 and P3 are small or non-emergency and can be handled during working hours.
The channel for warning is also the same as that used to be. P0 should call and text duty personnel, P1 send micro-mails/crack messages, P2 and P3 e-mails. Please don't use P0 to notify.——The carrier does not read the micro-mail when he sleeps.
Visualized Dashboard is not a face project.
A lot of the transporters think Dashboard is."To the leader."But in the campus web scene, Dashboard's worth is not good-looking but efficiency.
Imagine a scene: late at 11:00 p.m., the duty teacher got a call from the student saying"The dorm's not connected."If there is a Dashboard, he opens it and sees if the total number of online users is normal at present, what has been the certification success rate for the last hour, whether the AP on the corresponding floor is online and whether the export bandwidth is full. If all this is normal, then it's probably the student's own equipment that doesn't have to check in the engine room in the middle of the night. If Dashboard shows that a large area of AP on one floor is offline, he can bring the tools directly to the site.
Dashboard will at least show this information: real-time online users (line map), authentication success rate (most recently 1 hour/6 hours/24 hours), certification chain status of operators (red light), AP online ratio (by region). Data updates should not be less frequently than once per minute.——The campus network changed rapidly, and the Dashboard was not as good as it had been five minutes earlier.
Regular inspections can't be avoided.
Automation controls detect most of the malfunctions, but some problems are slowly deteriorating and do not trigger thresholds. For example, RADIAUS servers have disk space that is becoming more full in a few months, the volume of certified logsheet data increases causing slower inquiries, and an average operator’s authentication chain response time has risen from 500 ms to 2000ms, but it is not yet above the threshold.
These questions are subject to regular inspection. It is recommended that an automated weekly inspection be conducted: check the server disk space, database table size, SSL certificate validity, and the number of Warning and Error in system logs."Low cost, low frequency"The tests will help you find a problem before the problem breaks out.
You have to write the transport document, but don't write too much.
Finally, a less technical but important thing: the transport document. What's your campus network WiFi's configuration, how the modules are connected, what are the routine check steps, how the operator connects to the host, and how the equipment manages IP and passwords?——If these items are only found in the brain of a particular carrier, it will be very painful for others to take over once he leaves or takes leave.
The principle of working on a transport document is"It's good enough.". There is no need to write a dozen pages of an operation manual, but at least the four things that are structured, key configurations, contacts, common trouble management are sorted out and placed where the entire team can access (Wiki, shared files, even group top-heating messages). A simple and efficient document may be the most reliable help when there is a two-hour malfunction in the morning and people on duty are not familiar with the system.