< Home

Free Mobility Deployment in Campus Access Scenarios

In campus access scenarios, free mobility controls users' access rights based on accounts, terminal types, and access modes to ensure consistent access rights regardless of users' locations.

Interworking with Agile Controller-Campus

In a campus access scenario shown in Figure 1, it is recommended that the aggregation switch be used as both the authentication device and policy enforcement device. After you configure security groups and access control policies on Agile Controller-Campus, it delivers the configuration to the aggregation switch.

Figure 1 Free mobility deployment in a campus access scenario
  1. You can configure security groups, authorization rules, access control policies, and a pre-authentication domain on Agile Controller-Campus. Agile Controller-Campus will deliver the access control policies along with specified security groups and the pre-authentication domain to network-wide devices.
    • Plan the employee group, outsourcing group, and BYOD group for employees who log in from PCs, contractors who log in from PCs, and employees who log in from mobile terminals, respectively. In addition, plan the email group and Internet group that are bound to the email server IP address and Internet address, respectively.
    • Define authorization rules to map employees logging in through PCs, contractors logging in through PCs, and employees logging in through mobile terminals to the employee group, outsourcing group, and BYOD group, respectively.
    • Define authorization rules to map employees, contractors, and visitors to the employee group, outsourcing group, and visitor group, respectively.
    • Define access control policies to permit or deny access among security groups.
  2. A user sends an authentication request to the Agile Controller-Campus. After successful authentication, the Agile Controller-Campus adds the user to the specified user group based on an authorization rule and sends the authentication result to the aggregation switch. The aggregation switch permits or denies access from the security group to which the user belongs based on access control policies.

Access control policies for security groups can control communication between users connected to the same aggregation switch. So how can the terminals connected to different aggregation switches in Figure 2 communicate with each other?

By default, a switch only saves information of users authenticated on it, and cannot send a user's IP address to Agile Controller-Campus to query the security group to which the user belongs.

Figure 2 Control of communication between user groups on different authentication devices

In this case, you are advised to create two security groups and bind them to network segments of Aggregation SW_1 and Aggregation SW_2 respectively.

  • Security group 1: is bound to 10.10.20.0/24 and contains network resources managed by the aggregation switch SW_1.
  • Security group 2: is bound to 10.10.10.0/24 and contains network resources managed by the aggregation switch SW_2.

Then, permit access from User A's security group to Security group 2 and access from User B's security group to Security group 1. This is an example of how you can allow communication between the two users connected to different aggregation switches.

Interworking with iMaster NCE-Campus

When Agile Controller-Campus is used, free mobility can be implemented on only one authentication device. However, when iMaster NCE-Campus is used, free mobility can be implemented on multiple authentication devices. On the network shown in Figure 3, wired and wireless users connect to the network through aggregation switches. It is recommended that the aggregation switches be used as authentication devices and the core switch be used as the policy enforcement device. After you configure security groups and access control policies on iMaster NCE-Campus, it delivers the configuration to the aggregation switches and core switch.

In contrast to Agile Controller-Campus, iMaster NCE-Campus delivers security group information to the authentication devices and policy enforcement device after delivering security groups and access control policies to them. A user then initiates authentication. After the user is authenticated, iMaster NCE-Campus sends the authorization result to the policy enforcement device based on the configured authorization rules. The policy enforcement device then permits or denies access from the security group to which the user belongs based on access control policies.

Figure 3 Free mobility deployment in a campus access scenario
Copyright © Huawei Technologies Co., Ltd.
Copyright © Huawei Technologies Co., Ltd.
Next topic >