The last article on the selection and planning of a campus network billing system, which is about specific technology interfaces. Many schools have great ideas at the theoretical stage, and they're stuck when they do it because they don't know what's going on between the system and other network equipment.“Dialogue”Yeah.
Radius' agreement is not.“With an IP and a key”It's done.
The vast majority of cases are communicated through the Radius protocol between billing systems and authentication equipment. Many people think that having an IP with a Radius server will be finished, sharing keys, which is a lot of detail.
First, Radius has two separate channels: authentication and billing.“Let's get out of the Internet.”The billing route decides“How much did you use and how much did you charge?”Some schools only offer certifications without charge, and the result is that users have access to the Internet but no records are available in the system. The reconciliations did not match the data until the end of the month.
Second, the Radius properties match the equipment. The units of different manufacturers, which support the Radius properties, are not exactly identical. Each has private attributes expansion. The billing system must recognize and process them properly, otherwise they will be present.“It's authenticated, but not billed.”The problem.
I have encountered a case in which the school uses China for switchboard access, and the system of billing accounts for un-gallowed private attributes in its configuration, which leads to an irregular downlink test. Users actually cut off the network, and the system shows online, with continuous billing. It was only six months before the logbook was identified as missing Radius properties.
Portal authentication page, not default template
Portal certification is the first touch of the user’s Internet access, and experience directly affects the evaluation of school information levels.
A good Portal page should support self-services such as custom styles, mobile end adaptation, multi-operator selection (if any), balance query, self-help change password, and hanging.
On technology realization, Portal pages can be placed on either the side of a billing system or on an independent Web server. I suggest that they be on the side of a billing system because the authentication process is shorter and it is easier to sort out problems. If placed on an independent Web server, ensure that the billing system provides standard Portal protocol interfaces.
There is a further detail: Portal page access stability. If the billing system is disabled, Portal page should show friendly error hints instead of reporting 404 or connection timeout. This requires redundant design on network architecture.
Multi-operator dial, complex scenes unique to the campus network
This is one of the biggest differences between a campus network and an enterprise network.
Technology is on the way. It's usually through.“Substitute”Achieved: Users select operators on Portal pages and dial-up services (PPPOE or IPOE) at the end of the billing system help users to establish a connection with their operator.
There are a few technical difficulties in this:
First, the performance of the dial-up service. If hundreds of students log in simultaneously, the dial-up service must be able to handle it together and not one by one, otherwise the log-in experience will be very cardy.
Second, multi-operator route strategy. Users choose operator A and traffic has to go through operator A's exit without stringing it. This requires the right route policy in a billing system and alignment with core router configuration.
Third, the billing is accurate. Users may use Operator A in the morning and Operator B in the afternoon, and systems will be separately charged and billed.
I saw a school with multiple operator dialling problems, which led to a part of the user flow that went to the education network for export, and as a result the network was over-treated by tens of thousands of operators. When the problem was discovered, it was a failure of the route strategy and routers in the billing system to actually be configured.
IPOE and PPPoE, how do you choose the two sub-divisions?
The PPOE is a more traditional approach, with the advantages of technological maturity and equipment compatibility, which are less efficient and larger thanhead.
If the school is older, it is recommended that a PPoE be used to ensure stability.
There is also a compromise: core areas are IPOE, and marginal regions are PPPoE. This has both performance advantages and compatibility.
DHCP and fixed IP, address allocation to be included in the system of billing
The DHCP services and billing systems in many schools are managed separately, which leads to the problem of IP-account bindings that are not clear and problems can be traced back.
Good practice: DHCP services are either integrated with the billing system or synchronized in real time. When user certification is successful, the billing system informs DHCP of a specific IP allocation for its services, or sets up a binding relationship between an IP and an account number.
This would prevent IP conflicts and allow for rapid targeting of specific users in the event of unusual traffic.
NATHHEL_LOG_AUDIT, policy requirement not setting
The logs generated by the billing system (accreditation log, bill log, access log) must be complete, accurate and unalterable.
Technically, a log can be synchronized to an independent log server in real time and not only exists locally. If the billing system is wrong, the log cannot be lost.
I suggest keeping at least two copy logs: one in the local billing system, and one on the independent NATSHEL_LOG_AUDIT server. If possible, third offsite backup.
There is also a point that can be easily ignored: NAT logs. Campus web sites usually use private Internet addresses, and go out to make NAT.
High-capacity and disaster tolerance. We can't wait until something happens.
The system is the core of the campus network and has a great impact once it is shut down.
Server level: The costing system is deployed at least double-teleport and the main preset switch time is short (second phase). Database level: copying or clustering by master to ensure that data are not lost. Network level: there is redundancy in the network path between the billing system and authentication equipment.
I saw a school where the billing system was pre-prepared, but there were delays in data synchronization between the masters. One time, the main server was switched to the backup servers and it was found that the billing data for the last two hours had been lost. It was then changed to real-time sync + periodic checkup.
Summary
The campus network billing system is technically interfaced in much more detail than the surface. Radius configuration, Portal customization, multi-operator dialling, address management, Log Audit, high-availability design, each with a problem that could lead to large area failure.
My suggestion is that before technology can be implemented, a complete business process map and data flow chart will be drawn, each link will be clearly marked, and the configuration will begin.
The next one will be about routine peacekeeping failures of the billing system, including actual combat experience that is not included in the vendor manual.