The network of new campuses in a provincial undergraduate college last October, Authentication & Billing system, which has not finished its first semester, has accumulated over 1,500 complaints. Network centre technicians say this is the most intense centralized complaint they have ever experienced, and why the system has been approved so bad? One month of screening, clustering problems, found that most of the problems were buried at the design stage of the system, only because the test scenes before the visit were not sufficiently comprehensive to be detected.
These seven types of issues are organized for peer reference in similar projects.
AP reoriented handshake failed
The basic process of wireless access to the campus network is: students connect SSID, AP redirects uncertified terminals to a certified page, students enter account passwords for certification and send policies to allow access. This process is not problematic in standard settings, but during actual deployment there are different models of AP equipment, inconsistent solid versioning, and some old APs have incompletely supported the re-orientation of HTTPS, resulting in students loading or directly reporting errors over time after the authentication pages have been completed with their code."Authentication failed"。
The difficulty of checking such problems is that some students in the same dormitory can certify success and others fail. Excluding the account number, differences often fall on the equipment type and solid version.
The simultaneous release of authentication limit streams failed to focus the peak time period
The first night of school starts with a typical and peaking campus network certification, where thousands of students are connected at the same time, and when authentication and certification server co-processing capabilities are actually tested. If the system is designed to configure the authentication server according to routine and volume levels, without any reserve for peak redundancy, the server will directly trigger the limit flow, and some students’ requests for accreditation have been denied."The code is right, but it's not going up."。
More subtle is the low-level, unaltered, server not collapsing but slow-tracking of certification."It's slow to certify."Not."Authentication failed"and often by"The net is slow."The real reason is hidden, as the name reflects.
Delay in sync of billing status with the Internet policy
The certification and billing are two separate modules, normally delayed at the second level, but when system loads rise or there is a lock-up competition, the delay extends to the minute level or even longer. As a result: students have just completed their full time, account balances have been updated, but the online strategy has not been updated in time, and students remain in a state of unaffordable stoppage until the next active validation.
This delay is a high-voltage period within five minutes of the charging date, since the full value is usually charged after the non-connection, and immediately after the filling, the connection is restored, waiting for more than five minutes is sufficient to make the student impatient to repeat the test, multiple retest requests are concentrated to add to the system load and snowballs roll larger.
Multi-equipment miscalculations result in forced delinking
Multi-equipment binding strategy is a common requirement for campus networks, with an account number allowing two to three devices to be used simultaneously."Same account online."Technology options vary.——Some are based on the MAC address, others on the IP address, or on device fingerprints, and different scenarios vary greatly in the logic of the equipment switching and abnormal logout.
Seen a case where students switch to laptops after certification on their mobile phones, and the notes are shown at the end of the book."Account is already in other devices"The reason is that the certificate status was not written off in time, although the cell phone end had broken WiFi. The system was judged to be a conflict of equipment. In fact, it was not a student problem at all."De-linking equipment"The determination conditions were not reasonable.
The boundaries between the visitor's account and the student's account are blurred.
Visitors WiFi usually use temporary accounts or SMS authentication codes, but in practice the boundaries of rights between visitors and students’ accounts are blurred, which may lead to students bypassing their billings directly via the visitor's access. At the system level, a strict distinction is made between two accounts, including IP segment segregation, access target limits, and fee strategy differences, not simply separate from the certification entrance.
These problems are usually concentrated during training of outside personnel or major events, with a large number of visitors' accounts active at the same time. If there is no rigid restrictions on the bandwidth of the visitor's access route, students will notice that the network of dormitories next to the event site is suddenly slow and complaints will be directed"Network malfunction"Not."Misuse of visitor accounts"The line-up was off the road from the start.
Ghost account number due to incomplete migration of old account numbers
The system switches with the migration of historical accounts as part of a high-frequency problem. Incomplete migrations include: graduates’ accounts are not cleared in time, new students’ accounts lack initial password settings and school leavers’ accounts are not updated. More problematic are those who have dropped out but have kept their accounts, who may find discrepancies between account numbers and actual academic status at the next school year's resumption, and the balance of the billing system is not known if they should be retained.
The processing of such problems often requires matching the full account list with the school-based management system, and it is unrealistic to verify data when they are larger by manual means, and must be verified and automated during the migration phase rather than driven by complaints.
The lack of logs and alarm mechanisms leads to delays in the discovery of problems
Most of these types of problems, if accompanied by a well-developed logbook and alarm mechanism, can be discovered at an early stage by system administrators rather than waiting for students to file complaints. But in actual projects, incomplete log records, unreasonable warning threshold setting, and poor alert notification channels are common to many schools’ NATSHEL_AUTH_BILLING systems.
A specific scenario: one day between 2:00 and 4:00 a.m., the certification success rate dropped from a normal 99% to 72%, lasting almost two hours, but the daily paper next day did not have this dimension in statistics until the student came back after school."It was off last night."If there is a certified success rate, the carrier can at least know about the anomaly and check it out first, not then push it back from the complaint.
The failure of authentication is sometimes a single cause, and sometimes AP re-directing plus capping flow plus three times the same time. The root causes are found when checking from network to certification to billing to layer by layer.