No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

CLI-based Configuration Guide - Security

AR500, AR510, and AR530 V200R007

This document describes the configurations of Security, including AAA, DAA,NAC, BRAS Access, ACL, Firewall, Deep Security Defense, Local Attack Defense;Attack Defense, Traffic Suppression, ARP Security, Port Security, DHCP Snooping, IPSG, URPF, PKI, SSL, HTTPS, Keychain, separating the management plane from the service plane, security risks.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Configuring 802.1x Authentication

Configuring 802.1x Authentication

You can configure 802.1x authentication to implement interface-based network access control. This means you can authenticate and control access users connected to an access control device interface.

NOTE:
  • Layer 3 Ethernet interfaces (including logical Layer 3 interfaces) do not support 802.1x authentication. In this document, 802.1x authentication enabled interfaces refer to Layer 2 Ethernet interfaces.

  • The device supports only 802.1x multicast packets.

Prerequisites

802.1x only provides a user authentication solution. To implement this solution, the AAA function must also be configured. Therefore, the following tasks must be complete before you configure 802.1x authentication:

  • Configuring the authentication domain and AAA scheme on the AAA client.
  • Configuring the user name and password on the RADIUS or HWTACACS server if RADIUS or HWTACACS authentication is used.
  • Configuring the user name and password manually on the network access device if local authentication is used.

For the configuration of AAA client, see AAA Configuration in the Huawei AR Series IOT Gateway Configuration Guide - Security.

Enabling 802.1x Authentication

Context

The 802.1x configuration takes effect on an interface only after 802.1x authentication is enabled globally and on the interface.

If there are online users who log in through 802.1x authentication on the interface, disabling the 802.1x authentication is prohibited.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    dot1x enable

    Global 802.1x authentication is enabled.

    By default, global 802.1x authentication is disabled.

  3. Enable 802.1x authentication on the interface in the system or interface view.

    • In the system view:

    1. Run:

      dot1x enable interface { interface-type interface-number1 [ to interface-number2 ] } &<1-10>

      802.1x authentication of the interface is enabled.

    • In the interface view:

    1. Run:

      interface interface-type interface-number

      The interface view is displayed.

    2. Run:

      dot1x enable

      802.1x authentication of the interface is enabled.

    By default, 802.1x authentication of an interface is disabled.

(Optional) Configuring the Authorization State of an Interface

Context

You can configure the authorization state of an interface to control whether an access user must be authenticated before accessing network resources. The interface supports the following authentication states:
  • Auto mode: The interface is initially in Unauthorized state and sends and receives EAPOL packets only. Users cannot access network resources. After a user passes the authentication, the interface turns to Authorized state. Users are allowed to access network resources in this state.
  • Authorized-force mode: The interface is always in Authorized state and allows users to access network resources without authentication.
  • Unauthorized-force mode: The interface is always in Unauthorized state and does not allow users to access network resources.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Configure the authorization state of an interface in the system or interface view.

    • In the system view:

    1. Run:

      dot1x port-control { auto | authorized-force | unauthorized-force } interface { interface-type interface-number1 [ to interface-number2 ] } &<1-10>

      The authorization state of the interface is configured.

    • In the interface view:

    1. Run:

      interface interface-type interface-number

      The interface view is displayed.

    2. Run:

      dot1x port-control { auto | authorized-force | unauthorized-force }

      The authorization state of the interface is configured.

    By default, the authorization state of an interface is auto.

(Optional) Configuring the Access Control Mode of an Interface

Context

After 802.1x authentication is enabled, the device supports two access control modes of an interface:
  • Interface-based mode: After the first user of the interface passes the authentication, other access users can access the network without being authenticated. However, when the authenticated user goes offline, other users can no longer access the network. The authentication scheme is applicable to group users.
  • MAC address-based mode: All users of the interface must be authenticated. When a user goes offline, other users can still access the network. The authentication mode is applicable to individual users.
NOTE:

When 802.1x authentication users are online, you cannot change the access control mode of an interface.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Configure the access control mode of an interface in the system or interface view.

    • In the system view:

    1. Run:

      dot1x port-method { mac | port } interface { interface-type interface-number1 [ to interface-number2 ] } &<1-10>

      The access control mode of the interface is configured.

    • In the interface view:

    1. Run:

      interface interface-type interface-number

      The interface view is displayed.

    2. Run:

      dot1x port-method { mac | port }

      The access control mode of the interface is configured.

    By default, an interface uses the MAC address-based mode.

(Optional) Configuring Methods Used to Process Authentication Packets

Context

In 802.1x authentication, EAP authentication packets can be processed in EAP termination or EAP relay mode. The PAP or CHAP protocol can also be used in EAP termination mode. CHAP is more secure than PAP.

If the authentication server has a higher processing capability and can parse a large number of EAP packets before authentication, the EAP relay mode is recommended. If the authentication server has a lower processing capability and cannot parse a large number of EAP packets before authentication, the EAP termination mode is recommended and the device parses EAP packets for the authentication server.

When the authentication packet processing method is configured, ensure that the client and server both support this method; otherwise, the users cannot pass authentication.

NOTE:
  • The authentication mode can be set to EAP relay for 802.1x authentication users only when the RADIUS authentication is used.

  • If the 802.1x client uses the MD5 encryption mode, the user authentication mode on the device can be set to EAP or CHAP; if the 802.1x client uses the PEAP authentication mode, the authentication mode on the device can be set to EAP. If the authentication mode for 802.1x users is set to EAP on the device, user names in packets sent from the device to the RADIUS server must contain domain names, and the device cannot be configured to send packets in which user names do not contain domain names to the RADIUS server using the undo radius-server user-name domain-included command.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. You can configure the authentication mode for 802.1x user in the system view or interface view.

    • In the system view:

      Run the dot1x authentication-method { chap | eap | pap } command to set the authentication mode for 802.1x users.

    • In the interface view:

      1. Run the interface interface-type interface-number command to enter the interface view.
      2. Run the dot1x authentication-method { chap | eap | pap } command to set the authentication mode for 802.1x users.

    By default, the global 802.1x user authentication mode is CHAP authentication and the 802.1x user authentication mode on interfaces is the same as the mode globally configured.

(Optional) Setting the Maximum Number of Concurrent Access Users for 802.1x Authentication on an Interface

Context

The administrator can set the maximum number of concurrent access users for 802.1x authentication on the interface. When the number of access users reaches the maximum number allowed, new users for 802.1x authentication cannot access networks through the interface.
NOTE:
  • If the number of current online users on an interface has exceeded the maximum number, online users are not affected but new access users are limited.
  • This function is effective only when the MAC address-based access mode is configured on the interface. When the interface-based access mode is configured on the interface, the maximum number of concurrent access users on the interface is automatically set to 1. In this case, after one user is authenticated on the interface, other users can go online without being authenticated.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Set the maximum number of concurrent access users on an interface in the system or interface view.

    • In the system view:

    1. Run:

      dot1x max-user user-number interface { interface-type interface-number1 [ to interface-number2 ] } &<1-10>

      The maximum number of concurrent access users is set for 802.1x authentication on the interface.

    • In the interface view:

    1. Run:

      interface interface-type interface-number

      The interface view is displayed.

    2. Run:

      dot1x max-user user-number

      The maximum number of concurrent access users is set for 802.1x authentication on the interface.

    By default, the number of 802.1x authentication users is the maximum number of 802.1x authentication users supported by the device.

(Optional) Configuring Timers for 802.1x Authentication

Context

During 802.1x authentication, multiple timers implement systematic interactions between access users, access devices, and the authentication server. You can change the values of timers by running the dot1x timer command to adjust the interaction process. This command is necessary in special network environments. It is recommended that you retain the default settings of the timers. You can configure the following types of timers in 802.1x authentication:
  • Client timeout timer (client-timeout): After sending an EAP-Request/MD5-Challenge request packet to the client, the device starts this timer. If the client does not respond within the period set by the timer, the device retransmits the packet.
  • Authentication request timeout timer (tx-period): This timer defines two intervals. After sending an EAP-Request/Identity request packet to the client, the device starts the timer. If the client does not respond within the first interval set by the timer, the device retransmits the authentication request packet. The device multicasts the EAP-Request/Identity request packet at the second interval to detect the client that does not actively send the EAPOL-Start connection request packet for compatibility. The timer defines the interval for sending the multicast packet.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    dot1x timer { client-timeout client-timeout-value | tx-period tx-period-value }

    The 802.1x timers are configured.

    By default, client-timeout is set to 5 seconds; tx-period is set to 30 seconds.

    NOTE:

    The client timeout timer, and the authentication request timeout timer are enabled by default.

(Optional) Configuring the Quiet Function in 802.1x Authentication

Context

After the quiet function is enabled, when the number of times that a user fails 802.1x authentication reaches the maximum number allowed, the device quiets the user, and during the quiet period, the device discards the 802.1x authentication requests from the user. This prevents the impact of frequent user authentications on the system.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    dot1x quiet-period

    The quiet function is enabled.

    By default, the quiet function is disabled.

  3. (Optional) Run:

    dot1x quiet-times fail-times

    The maximum number of authentication failures within 60 seconds before the device quiets the 802.1x authentication user is configured.

    By default, an 802.1x user enters the quiet state after three authentication failures within 60 seconds.

  4. (Optional) Run:

    dot1x timer quiet-period quiet-period-value

    The quiet timer is set.

    By default, the quiet timer is 60 seconds.

(Optional) Configuring Re-authentication for 802.1x Authentication Users

Context

If the administrator modifies user information on the authentication server, parameters such as the user access permission and authorization attribute are changed. If a user has passed 802.1x authentication, you must re-authenticate the user to ensure user validity.

After the user goes online, the device saves user authentication information. After re-authentication is enabled for 802.1x authentication users, the device sends the saved authentication information of the online user to the authentication server for re-authentication. If the user's authentication information does not change on the authentication server, the user is kept online. If the authentication information has been changed, the user is forced to go offline, and then re-authenticated according to the changed authentication information.

You can configure re-authentication for 802.1x authentication users using either of the following methods:
  • Re-authenticate all online 802.1x authentication users on a specified interface periodically.
  • Re-authenticate an online 802.1x authentication user once with a specified MAC address.
NOTE:

If periodic 802.1x re-authentication is enabled, a large number of 802.1x authentication logs are generated.

Procedure

  • Configure periodic re-authentication for all online 802.1x authentication users on a specified interface.
    1. Run:

      system-view

      The system view is displayed.

    2. Enable periodic re-authentication for all online 802.1x authentication users on the specified interface in the system or interface view.

      • In the system view:

      1. Run:
        dot1x reauthenticate interface { interface-type interface-number1 [ to interface-number2 ] } &<1-10>

        Periodic 802.1x re-authentication is enabled on the interface.

      • In the interface view:

      1. Run:
        interface interface-type interface-number

        The interface view is displayed.

      2. Run:
        dot1x reauthenticate

        Periodic 802.1x re-authentication is enabled on the interface.

      3. Run:
        quit

        The system view is displayed.

      By default, periodic 802.1x re-authentication is disabled on an interface.

    3. (Optional) Set the re-authentication interval for online 802.1x authentication users in the system or interface view.

      • In the system view:

      1. Run the dot1x timer reauthenticate-period reauthenticate-period-value command to set the re-authentication interval for online 802.1x authentication users.

      • In the interface view:

      1. Run the interface interface-type interface-number command to enter the interface view.
      2. Run the dot1x timer reauthenticate-period reauthenticate-period-value command to set the re-authentication interval for online 802.1x authentication users.
      3. Run the quit command to enter the system view.

      By default, the device re-authenticates online 802.1x authentication users at the interval of 3600 seconds.

  • Configure re-authentication for an online 802.1x authentication user with a specified MAC address.
    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      dot1x reauthenticate mac-address mac-address

      Re-authentication is enabled for the online 802.1x authentication user with the specified MAC address.

      By default, re-authentication for the online 802.1x authentication user with a specified MAC address is disabled.

(Optional) Configuring the Handshake Function for 802.1x Online Users

Context

You can configure the handshake function for online users to ensure that the users are online in real time. The device sends a handshake request packet at intervals to online users that pass the authentication. If the user does not respond to the handshake packet after the maximum number of retransmission times, the device disconnects the user.

If the 802.1x client cannot exchange the handshake packet with the device, the device does not receive any handshake response packet within the handshake period. You must disable the handshake function for online users to prevent the device from mistakenly disconnecting the users.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    dot1x handshake

    The handshake function is enabled for 802.1x online users.

    By default, the handshake function is disabled for 802.1x online users.

  3. (Optional) Run:

    dot1x timer handshake-period handshake-period-value

    The interval at which the device handshakes with 802.1x online users is set.

    By default, the interval for sending handshake packets is 15.

  4. (Optional) Run:

    dot1x retry max-retry-value

    The maximum number of times an authentication request can be sent to an 802.1x user is set.

    By default, the device sends an authentication request to an 802.1x user twice.

(Optional) Configuring the Guest VLAN Function

Context

After the guest VLAN function is enabled, the device allows users to access resources in the Guest VLAN without 802.1x authentication. For example, the users can obtain the client software, upgrade the client, or run other upgrade programs.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Configure the guest VLAN function in the system or interface view.

    • In the system view:

    1. Run:

      authentication guest-vlan vlan-id interface { interface-type interface-number1 [ to interface-number2 ] } &<1-10>

      The guest VLAN to which the interface is added is configured.

    • In the interface view:

    1. Run:

      interface interface-type interface-number

      The interface view is displayed.

    2. Run:

      authentication guest-vlan vlan-id

      The guest VLAN to which the interface is added is configured.

    By default, an interface is not added to the guest VLAN.

    NOTE:
    • Different interfaces can be configured with different guest VLANs.
    • After a guest VLAN is configured on an interface, the guest VLAN cannot be deleted.
    • A super VLAN cannot be configured as a guest VLAN.
    • The guest VLAN function can take effect only when the access control mode of the interface using 802.1x authentication is port.
    • The guest VLAN function can take effect only on hybrid or access interfaces that are added to VLANs in untagged mode. The guest VLAN function cannot take effect on the interfaces of other types.
    • The guest VLAN function takes effect only when a user sends untagged packets to the device.
    • If the authentication function of the built-in Portal server is enabled, the guest VLAN cannot be configured on interfaces.

(Optional) Configuring the Restrict VLAN Function

Context

You can configure the restrict VLAN function on the device interface to enable users who fail authentication to access some network resources (for example, to update the virus library). The users are added to the restrict VLAN when failing authentication and can access resources in the restrict VLAN. The user fails authentication in this instance because the authentication server rejects the user for some reasons (for example, the user enters an incorrect password) not because the authentication times out or the network is disconnected.

Similar to the guest VLAN, the restrict VLAN allows users to access limited network resources before passing 802.1x authentication. Generally, fewer network resources are deployed in the restrict VLAN than in the guest VLAN; therefore, the restrict VLAN limits access to network resources from unauthenticated users more strictly.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Configure the restrict VLAN function in the system or interface view.

    • In the system view:

    1. Run:

      authentication restrict-vlan vlan-id interface { interface-type interface-number1 [ to interface-number2 ] } &<1-10>

      A restrict VLAN where the interface is added is configured.

    • In the interface view:

    1. Run:

      interface interface-type interface-number

      The interface view is displayed.

    2. Run:

      authentication restrict-vlan vlan-id

      A restrict VLAN where the interface is added is configured.

    By default, an interface is not added to the restrict VLAN.

    NOTE:
    • A super VLAN cannot be configured as a restrict VLAN.
    • If the authentication function of the built-in Portal server is enabled, the restrict VLAN cannot be configured on interfaces.
    • The restrict VLAN function takes effect only when a user sends untagged packets to the device.
    • After a restrict VLAN is configured on an interface, the restrict VLAN cannot be deleted.
    • To make the VLAN authorization function take effect, the link type and access control mode of the authentication interface must meet the following requirements:
      • When the link type is hybrid in untagged mode, the access control mode can be based on the MAC address or interface.
      • When the link type is access or trunk, the access control mode can only be based on the interface.

(Optional) Configuring 802.1x-based Fast Deployment

Context

In the 802.1x network deployment, if the 802.1x client software is downloaded and upgraded for each access user, the administrator has huge workload when there are a large number of access users. You can configure a free IP subnet and a redirect-to URL for a user to implement fast deployment of the 802.1x client.

Before the access user passes the 802.1x authentication, the user can access the network resources in the free IP subnet if the free IP subnet is configured. If the redirect-to URL is configured for the 802.1x authentication user and the user accesses a network with a browser, the device redirects the URL that the user attempts to access to the configured URL (for example, to the 802.1x client download web page). In this way, the web page preset by the administrator is displayed when the user starts the browser. The server that provides the redirect-to URL must be located in the free IP subnet of the user.

NOTE:
  • 802.1x authentication has been enabled globally and on an interface using the dot1x enable command.

  • After the free-ip function is configured, the guest VLAN, and restrict VLAN are no longer effective.

  • The free IP subnet takes effect only when the interface authorization state is auto.

  • If a user who does not pass 802.1x authentication wants to obtain an IP address dynamically through the DHCP server, the network segment of the DHCP server needs to be configured to a free IP subnet so that the user can access the DHCP server.

  • The AR performing Layer 2 switching does not support free-ip function.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    dot1x free-ip ip-address { mask-length | mask-address }

    The free IP subnet is configured.

    By default, no free IP subnet is configured.

  3. Run:

    dot1x url url-string

    The redirect-to URL is configured in 802.1x authentication.

    By default, no redirect-to URL is configured in 802.1x authentication.

(Optional) Configuring 802.1x Authentication Triggered by a DHCP Packet

Context

In the 802.1x authentication network, if a user uses a built-in 802.1x client of a PC operating system (such as Windows), the user cannot enter the user name and password proactively to trigger authentication.

For such users, the administrator configures 802.1x authentication triggered by a DHCP packet. After 802.1x authentication triggered by a DHCP packet is enabled, the device triggers 802.1x authentication for a user upon receiving a DHCP packet from the user. A built-in 802.1x authentication page of the operating system is automatically displayed on the user terminal. The user enters the user name and password for authentication.

Alternatively, 802.1x authentication triggered by a DHCP packet enables the user to implement authentication using the built-in 802.1x client of the operating system. After being authenticated, the user accesses an 802.1x client download web page to download and install the 802.1x client software, which facilitates fast network deployment.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    dot1x dhcp-trigger

    802.1x authentication triggered by a DHCP packet is enabled.

    By default, 802.1x authentication triggered by a DHCP packet is disabled

(Optional) Configuring Web Push

Context

After a user is successfully authenticated, the device forcibly redirect the user to a web page when receiving the HTTP packet from the user who accesses web pages for the first time. In addition to pushing advertisement pages, the device can obtain user terminal information through the HTTP packets sent by the users, and apply the information to other services. There are two ways to push web pages:
  1. URL: pushes the URL corresponding to the web page.
  2. URL template: pushes the URL template. A URL template must be created. The URL template contains the URL of the pushed web page and URL parameters.

Procedure

  1. Configure the URL template.

    1. Run the system-view command to enter the system view.
    2. Run the url-template name template-name command to create a URL template and enter the URL template view.

      By default, no URL template exists on the device.

    3. Run the url [ push-only ] url-string [ ssid ssid ] command to configure the redirection URL corresponding to the Portal server.

      By default, no pushed URL is configured.

    4. Run the url-parameter { ac-ip ac-ip-value | ac-mac ac-mac-value | ap-ip ap-ip-value | ap-mac ap-mac-value | redirect-url redirect-url-value | ssid ssid-value | sysname sysname-value | user-ipaddress user-ipaddress-value | user-mac user-mac-value | user-vlan user-vlan-value} * command to set the parameters carried in the URL.

      By default, a URL does not carry parameters.

    5. Run the url-parameter mac-address format delimiter delimiter { normal | compact } command to set the MAC address format in the URL.

      By default, the MAC address format in URL is XXXXXXXXXXXX.

    6. Run the parameter { start-mark parameter-value | assignment-mark parameter-value | isolate-mark parameter-value } * command to set the characters in the URL.

      By default, the start character is ?, assignment character is =, and delimiter is &.

    7. Run the quit command to return to the system view.
    NOTE:

    If web pages are pushed in URL mode, this step can be skipped.

  2. Configure the Web push function.

    1. Run the aaa command to enter the AAA view.
    2. Run the domain domain-name command to create an AAA domain and enter the AAA domain view.

      The device has two default domains: default and default_admin. The default domain is used by common access users and the default_admin domain is used by administrators.

    3. Run the force-push { url-template template-name | url url-address } command to enable the forcible URL template or URL push function.

(Optional) Configuring the User Group Function

Context

In NAC applications, there are many access users, but user types are limited. You can create user groups on the device and associate each user group to an ACL. In this way, users in the same group share rules in the ACL.

After creating user groups, you can set priorities and VLANs for the user groups, so that users in different user groups have different priorities and network access rights. The administrator can then flexibly manage users.

NOTE:

The priority of the user group authorization information delivered by the authentication server is higher than that of the user group authorization information applied in the AAA domain. If the user group authorization information delivered by the authentication server cannot take effect, the user group authorization information applied in the AAA domain also cannot be used. For example, if only user group B is configured on the device and the group authorization information is applied in the AAA domain when the authentication server delivers authorization information about user group A, the authorization information about user groups A and B both cannot take effect. To make the user group authorization information delivered by the authentication server take effect, ensure that this user group is configured on the device. To make the user group authorization information applied in the AAA domain take effect, ensure that the authentication server does not deliver any user group attribute.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    user-group group-name

    A user group is created and the user group view is displayed.

  3. Run:

    acl-id acl-number

    An ACL is bound to the user group.

    By default, no ACL is bound to a user group.

    NOTE:
    • Before running this command, ensure that the ACL has been created using the acl (system view) or acl name command and ACL rules have been configured using the rule command.

    • If a user group contains online users, the ACL bound to the user group cannot be modified or deleted in the system view.

  4. Run:

    user-vlan vlan-id

    The user group VLAN is configured.

    By default, no user group VLAN is configured.

    NOTE:

    Before running this command, ensure that the VLAN has been created using the vlan command.

  5. Run:

    remark { 8021p 8021p-value | dscp dscp-value | exp exp-value | lp lp-value }*

    The user group priority is configured.

    By default, no user group priority is configured.

(Optional) Configuring the User Logout Delay Function When an Interface Link Is Faulty

Context

If a link is faulty, the interface is interrupted and users are directly logged out. To solve this problem, you can configure the user logout delay function. When the interface link is faulty, the users remain online within the delay. In this case, if the link is restored, the users do not need to be re-authenticated. If the users are disconnected after the delay and the link is restored, the users need to be re-authenticated.

NOTE:
  • This function takes effect only for wired users who go online on Layer 2 physical interfaces that have been configured with NAC authentication.

  • To make the function take effect, it is recommended that the configured interval be greater than the time during which the interface is in Up state.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface interface-type interface-number

    The interface view is displayed.

  3. Run:

    link-down offline delay { delay-value | unlimited }

    The user logout delay is configured when an interface link is faulty.

    The default user logout delay is 10 seconds when an interface link is faulty.

    If the delay is 0, users are logged out immediately when the interface link is faulty. If the delay is unlimited, users are not logged out when the interface link is faulty.

(Optional) Forcing Portal Authentication Users Offline When a 3G/LTE Link Is Disconnected

Context

When the router functioning as a mobile Internet gateway is deployed on a bus or metro, only the users who pass Portal authentication can connect to the vehicle-mounted Wi-Fi network and access external networks using the 3G/LTE interface. After the 3G/LTE link is disconnected, the users are not disconnected in real time while they cannot access any web page immediately. This had a negative effect on user experience.

After you configure Portal authentication users to be forcibly disconnected on a 3G/LTE interface, the device forces the Portal authentication users offline when the 3G/LTE link is disconnected. The disconnected users can still access internal network resources of the router, which improves user experience.

NOTE:

Currently, only the AR510 series routers can function as mobile Internet gateways.

Procedure

  1. Run:

    system-view

    The system view is displayed.

  2. Run:

    interface cellular interface-number

    The cellular interface view is displayed.

  3. Run:

    cut web-authentication-user [ domain domain-name | ssid ssid ]

    The device is configured to force Portal authentication users offline when the 3G/LTE link is disconnected.

    By default, the Portal authentication users are still online when the 3G/LTE link is disconnected.

Checking the Configuration

Context

You can run the commands to check the configured parameters after completing the 802.1x authentication configuration.

Procedure

  • Run the display dot1x [ statistics ] [ interface { interface-type interface-number1 [ to interface-number2 ] } &<1-10> ] command to check the 802.1x authentication configuration.
  • Run the display mac-address { authen | guest } [ interface-type interface-number | vlan vlan-id ] command to check the current authen or guest MAC address entries in the system.
  • Run the display user-group [ group-name ] command to check the user group configuration.
  • Run the display access-user user-group group-name command to check information about online users in a user group.
Translation
Download
Updated: 2019-05-25

Document ID: EDOC1000097287

Views: 13681

Downloads: 40

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next