The time spent on a link before the deployment of the Authentication & Billing system is often seriously underestimated, namely,Compatibility screening of existing network equipment. When many projects are launched, attention is focused on the Authentication & Billing platform itself——Function list, performance indicators, deployment architecture——But it doesn't take time to figure out what equipment is on its campus network, whether it can be connected to the new system. It costs a lot when the system comes in and finds compatibility.
The first type of equipment to be checked isWireless controller ACAuthentication & Billing interface with AC is the key node for the entire authentication process——Portal re-directs, RADIAUS certifications go, and CoA's permissions go. But there are significant differences in the extent of support for RADIUS attributes from brands, models, software versions ACs. For example, the same RADIUS attribute, Ssession-Timeout (meeting time over), is not exactly the same way that aAC interprets as a CiscoAC. The more subtle problem is that some ACs have run for years old solids, and their manufacturers have long failed to maintain them, but certain features required by the Portal protocol of the new authentication system are not supported in these old fixes. If the AC model, solid version and configuration strategy are not fully collated before deployment, there will be a problem with the docking phase.
There are two easy to miss details when checking AC.Will the authentication strategy already available on AC be in conflict with the new system?——For example, the local MAC address white list was set up locally by AC and it is still in effect when the new system is online, which has led some users to verify processes that have gone out of their own strategy and not into the new system.AC's Portal URL configuration supports dynamic parameters——The new authentication system needs to carry some dynamic parameters (e.g., user ' s MAC address, access to SSID, AP location information) in the redirected URL of Portal, and if the AC ' s Portal configuration supports only writing a static URL, advanced functions such as 4W+B+S tactical push-over cannot be achieved.
The second category is to be checked.Core and assembly switchesThe most typical problem at the switchboard level is VLAN planning. After many years of building the campus network, VLAN can be very complicated to divide.——VLANs are available in different buildings, colleges, and functional areas. The new Authentication & Billing system requires different authentication strategies for different VLAN users (e.g. residential hopoE, teaching area Portal), which may be wrong if the VLAN configuration on the switchboard is not matched to the planning of certification strategies. More problematic is that some old switches do not support VLAN Tag's permeability or QinQ, which makes it impossible to link VLAN to the authentication strategy properly.
One thing to do when checking the switch:Get an updated web-based map and VLAN plan., check with the authentication system by paragraph. If the top-top was two years ago, it is recommended that time be taken to update the top-up and not to use old drawings as a direct solution. At least 20% of the switch port uses in real environments are not matched to the map.——This may be temporary, modified and not updated during the biennium.
The third type of equipment is...BRAS/Broadband access serverThe school dial-up gateways need to be connected with the operator Bras, but the company's BRAS equipment model, software version, RADIUS configuration code is not controlled by the school. The type and version of bras that connect and move in the same city may be completely different. If schools introduce three operators' proxy programs, they have to check compatibility with each other's BRAS.Operators often go through a much longer period than they thought.——Because the operator’s network transportation department has its own change flow and window period, not one day it can be measured. It is therefore necessary to reach an interface with the operator at least a month ahead of schedule.
The fourth category is easy to ignore.Campus Operations System interfaceAuthentication & Billing requires synchronizing with the teaching system (teachers and students account), a cartoon system (filling fees), and a single-point platform for identification. The technical state of these campus operating systems is uneven.——Some systems have been running for seven to eight years, interface documents are already lost and the original developers may not be able to locate anyone. If you need to retweet the interface format from zero, the development cycle will be at least two to three weeks longer. The check will confirm whether each system that needs to be connected has an accessible interface document, whether the interface supports the mode of deployment required by Authentication & Billing (LDAP synchronous frequency, API call speed limit, data field alignment).
Compatibility screening of these four types of equipment seems to be a technical exercise, but what's actually testing it is that the process is not going to be possible.Project management capacity and communication coordination capacityBecause the screening isn't done by sitting in the machine room.——If any of these links fail to work together, the screening cannot be carried forward. So when the overall project is planned, it is proposed that compatibility check be set aside for two to three weeks alone and that it be promoted from the first day of the project, rather than waiting until the NATSHEL_AUTH_BILLING system manufacturer has entered the site.
If, during the screening process, it is found that a certain type of equipment does not meet the docking requirements of the new system,The options for upgrading or replacement are discussed ahead of time, and not until a week or two before the system gets online.. The AC solid version does not support the required RADIUS properties——Upgraded solids may be done in two or three days, but if the existing wireless network configuration on AC is lost or parts of AP are not compatible after the upgrade has been discovered, then it will not be two or three days. The most basic and effective means of reducing delivery risk is to expose compatibility risks early in the project and develop a response.