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

NE40E V800R010C10SPC500 Configuration Guide - User Access 01

This is NE40E V800R010C10SPC500 Configuration Guide - User Access
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).
Adjusting DHCPv4 Service Parameters

Adjusting DHCPv4 Service Parameters

You can adjust DHCPv4 service parameters to enhance the security of the DHCPv4 service.

Usage Scenario

After configuring a DHCPv4 server, you need to configure the security function of the DHCPv4 service. This enhances security of the DHCPv4 service and prevents other unauthorized DHCPv4 servers from assigning invalid IP addresses to clients. By viewing logs, the administrator determines whether there are unauthorized DHCPv4 servers assigning invalid IP addresses to clients.

Pre-configuration Tasks

Before adjusting DHCPv4 parameters, complete the following task:

  • Configuring a DHCPv4 server

(Optional)Configuring Global DHCPv4 Parameters

Global DHCPv4 parameters include the maximum number of DHCPv4 access users allowed for a specified board and the limit on the packet transmission rate of a DHCPv4 server group.

Context

Perform the following steps on the router:

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dhcp slot-id max-sessions user-number

    The maximum number of DHCPv4 access users allowed for a specified board is set.

  3. Run dhcp check-client-packet strict

    The function of router strictly checks packets from a DHCP client is enabled.

  4. Run dhcp-server ip-address [ vpn-instance vpn-instance ] send-discover-speed packet-number time

    The limit on the packet transmission rate of a DHCPv4 server group is set.

  5. Run dhcp server identifier dest-ip

    The destination IP address of a packet forwarded by a DHCP relay as the identifier of the DHCP server is set.

    After the dhcp server identifier dest-ip command is configured, the DHCP response packet forwarded by the NE40E carries the destination IP address of the request packet as the DHCP server identifier.

    The command only applies to a scenario in which the NE40E is the non-first PE router and functions as the DHCP server.

  6. Run dhcp request-ip-address check { enable | disable }

    Check of DHCP request packets with option 50 fields is disabled or enabled.

    After a user sends a DHCP request packet with option 50, the NE40E authenticates the user. If the requested IP address has been assigned to another user, the NE40E replies an NAK packet to the user. If a large number of users resend DHCP Discover packets to apply for IP addresses, the NE40E authenticates the users again, causing high CPU usage. To resolve this problem, run the dhcp request-ip-address check enable command to enable check of DHCP request packets with option 50 fields. After that, if the request IP addresses have been assigned to other users, the NE40E replies NAK packets without authenticating users again. In this manner, high CPU usage is prevented.

  7. Run access-line-id attach

    The BRAS is enabled to send Option 82 information to the RADIUS server if user packets do not carry the Option 82 field or the BRAS does not trust the Option 82 field in user packets.

  8. (Optional) Run dhcp rebind no-user action keep-silence

    The device is disabled from sending an NAK message in response to a client's DHCP Rebind message if no corresponding user entry exists on the device.

  9. (Optional) Run dhcp rebind no-user action nak server-ip server-ip

    The device is enabled to send an NAK message in response to a client's DHCP Rebind message if no corresponding user entry exists on the device.

  10. Run commit

    The configuration is committed.

Configuring a DHCP Option

DHCP provides a framework for parameter transmission over the TCP/IP network. The DHCP client and the server can transmit the negotiated parameters and the control information to each other through the option codes.

Context

When a terminal device, such as the set top box of the digital TV, accesses the network, the NE40E cannot identify its domain according to its user name. Therefore, the NE40E cannot allocate IP address to the device. In this case, the terminal device uses Option 60 to carry the domain information when initiating the DHCP request. After receiving the DHCP request, the NE40E allocates the IP address to the device according to the domain information contained in Option 60.

Option 121 allows a DHCP server to allocate static routes to DHCP clients.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dhcp option-60 [ cn | [ offset offset ] { length length | sub-option sub-option-code [ sub-offset sub-offset ] [ sub-length sub-length ] } ] { domain-included | included-in-domain } { exact-match | partial-match } [ encrypt ]

    The Option 60 attribute is set for DHCP packets. This attribute allows the device to allocate IP addresses from a corresponding address pool based on the domain name. Option 60 can be configured to contain the domain name. Partial match or exact match of the domain name can be configured. You can configure encrypt to encrypt the Option 60 attribute.

    If user domain information is obtained from the vendor-class information, the character string following the domain name delimiter (defaulting to @) in the vendor-class field is used as the domain name. If no user domain information is obtained from the vendor-class information, the NE40E performs the following procedure to continue searching for the information. If there is no domain name delimiter in the field, the NE40E performs a fuzzy or exact match of the domain name information based on the configured mode. The procedure will stop if user domain information is obtained.
    1. Check if the dhcp option-60 command is configured in the system view. If the command is configured, obtain user information from the command configuration.
    2. Use the authorization domain configured on the BAS interface as the user domain.

  3. Run aaa

    The AAA view is displayed.

  4. Run domain domain-name

    A domain is created and the domain view is displayed.

  5. Run dhcp option121 route ip-address mask-length gateway-address

    Static routes are allocated to domain users.

  6. Run commit

    The configuration is committed.

(Optional) Configuring the Format for Encapsulating the Option 82 Attribute into DHCP Messages

This section describes how to enable a device to insert Sub-option 2 (remote ID) into the Option 82 attribute or replace Sub-option 2 carried in the Option 82 attribute of a message to be sent to the DHCP server based on a fixed format.

Context

When IP addresses are assigned from a remote address pool to Layer 2 access users, the DHCP server identifies a carrier based on the remote ID carried in the Option 82 attribute of a DHCP message. Therefore, you need to configure a device to insert Sub-option 2 (remote ID) into the Option 82 attribute or replace Sub-option 2 carried in the Option 82 attribute of a message to be sent to the DHCP server based on a fixed format. Self-defined character strings can be encapsulated into Sub-option 2.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run interface interface-type interface-number [ .subinterface-number ]

    The interface view is displayed.

  3. Run bas

    The BAS interface view is displayed.

  4. Configure the format for encapsulating the Option 82 attribute into DHCP messages. Perform the following steps as required. The following commands are mutually exclusive.

    • Run dhcp option82 rebuild version3 send-to-server [ remote-id { neba | vula } ]

      The device is enabled to encapsulate the Option 82 attribute into a message to be sent to the DHCP server in a fixed format. In this format, self-defined contents cannot be encapsulated into the Option 82 attribute.

      The dhcp option82 rebuild version3 send-to-server command has a higher priority than the dhcp option-82 agent-remote-id strip command.

    • Run dhcp option82 rebuild version4 send-to-server

      The device is enabled to encapsulate the Option 82 attribute in the format of sysname:interface-name:svlan-cvlan into a message to be sent to the DHCP server.

    • Run dhcp option82 rebuild self-define { circuit-id circuit-id-value | out-vlan out-vlan-value | inner-vlan inner-vlan-value | remote-id remote-id-value } * send-to-server

      The device is enabled to encapsulate the Option 82 attribute into a message to be sent to the DHCP server based on the fixed OSP format. In this format, self-defined contents can be encapsulated into the Option 82 attribute.

    NOTE:

    The dhcp option82 rebuild send-to-server command takes effect only after DHCP proxy is enabled on the BAS interface.

(Optional) Shortening the User Address Lease Before a DHCPv4 Server Restarts

The user address lease can be shortened before a DHCPv4 server restarts. This change allows DHCP users to get online a short period of time after the DHCPv4 server restarts due to an upgrade without restarting the terminal.

Context

When the NE40E is being upgraded, DHCP users cannot detect that the link goes Down and dial-up again like PPP users. Therefore, these users do not redial to get online. Instead, the terminal must be restarted to trigger a DHCP request so that the users can obtain IP addresses to get online again. In the current upgrade solution, the address pool lease time is shortened at the lease renewal time before the upgrade date. For example, if the address pool lease renewal time is 1.5 days, the address pool lease is changed to 30 minutes and the lease renewal time is changed to 15 minutes 1.5 days before the upgrade. This solution ensures that the terminal can send lease renewal packets in a shorter period of time after the device is upgraded to allow DHCP users to get online again.

This upgrade solution has two disadvantages:
  • Changing the address pool lease takes effect only for users that obtain addresses from local address pools. The address lease delivered by a RADIUS server is not changed. The users that have obtained addresses from the RADIUS server have to wait a comparatively long period of time to get online again.

  • The address pool lease is configured in the address pool view. Manually changing the lease configurations of all the address pools brings a huge workload.

Using the dhcp upgrade command in the system view to change the address lease for all DHCP users attached to the device solves these problems.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dhcp upgrade lease day [ hour [ minute ] ] [ renewal-time day [ hour [ minute ] ] ] [ rebinding-time day [ hour [ minute ] ] ]

    The address lease for all DHCPv4 users attached to the device is configured.

    After the dhcp upgrade command is used, the lease configured in the system view takes effect for new users, online users that need to renew the lease, users using addresses in local address pools, and users using addresses delivered by a RADIUS server.

    No configuration file will be generated after the dhcp upgrade command is used. To view the configuration result, run the display dhcp upgrade command. The dhcp upgrade command becomes invalid after the device restarts.

    If a short lease is configured, a large number of users will renew their lease at the same time, causing high CPU usage. Therefore, configuring a short lease is not recommended unless the device needs to be upgraded.

  3. Run commit

    The configuration is committed.

Configuring Transparent Transmission of DHCPv4 Packets

You need to configure transparent transmission of DHCPv4 packets when STB users send only one DHCPv4 Discover packet after they restart.

Context

When a user shuts down the STB and then restarts it immediately, the NE40E cannot detect that the user goes offline and retains the user entry. When receiving the DHCPv4 Discover packet that the STB sends after restart, the NE40E forces the user to go offline and waits until the user sends a DHCPv4 Discover packet to obtain the address through DHCPv4.

Some STBs, however, send only one DHCPv4 Discover packet after they restart. In this case, the users cannot go online after shutting down their STBs.

You can configure the function of transparently transmitting DHCPv4 packets to solve this problem. Perform the following steps on the router:

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dhcp through-packet

    The function of transparently transmitting DHCPv4 packets is configured.

(Optional) Enabling the BRAS to Transparently Transmit NAK Messages to DHCP Clients

This section describes how to enable a BRAS to transparently transmit NAK messages sent by the DHCP server in response to the Discover messages to DHCP clients in DHCP remote address pool scenarios.

Context

In scenarios where IP addresses are assigned from a DHCP remote address pool, if a DHCP client sends a Discover message to the DHCP server through a BRAS and the BRAS receives a NAK message from the DHCP server, the BRAS discards the NAK message by default. After the BRAS is enabled to transparently transmit NAK messages to clients, the clients can be informed of login failures if parsing of NAK messages is supported on the client terminals.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dhcp through-nak

    The BRAS is enabled to transparently transmit NAK messages sent by the DHCP server in response to the Discover messages to DHCP clients in DHCP remote address pool scenarios.

Enabling a DHCPv4 Server to Detect Unauthorized DHCPv4 Servers

Enabling a DHCPv4 server to detect unauthorized DHCPv4 servers help prevent unauthorized DHCPv4 servers from allocating invalid IP addresses to clients.

Context

If a private DHCPv4 server exists on the network, clients cannot obtain correct IP addresses and thus cannot log in to the network because this private DHCPv4 server will interact with the DHCPv4 clients during address application. Such a private DHCPv4 server is an unauthorized DHCPv4 server.

The logs contain IP addresses of all the DHCPv4 servers that allocate IP addresses to clients. By viewing these logs, the administrator can determine whether an unauthorized DHCPv4 server exists.

Perform the following steps on the NE40E that functions as a DHCPv4 server:

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dhcp invalid-server-detecting [ interval ]

    The interval at which unauthorized DHCPv4 servers are detected is configured.

    If the interval at which unauthorized DHCPv4 servers are detected is 0, the NE40E does not detect unauthorized DHCPv4 servers.

    NOTE:

    You can perform this function on only the devices at the BAS side.

Enabling the Detection of an IP Address Conflict

The DHCPv4 server sends ping packets to detect the usage of an IP address to prevent an IP address conflict.

Context

Before assigning an IP address to a client, the DHCPv4 server needs to detect whether the IP address is used by another client. This prevents an IP address conflict.

NOTE:

Detection of an IP address conflict can be configured on only network-side devices.

Perform the following steps on the NE40E that functions as a DHCPv4 server:

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dhcp server ping timeout milliseconds

    The longest time for the DHCPv4 server to wait for a ping response is configured.

  3. Run dhcp server ping packets number

    The maximum number of ping packets sent by the DHCPv4 server is configured.

  4. Run commit

    The configuration is committed.

Follow-up Procedure

The ping command is used to check whether there is a ping response from the IP address to be assigned to a client within a specific time. If there is no response after a specific time, the DHCPv4 server re-sends a ping packet to this IP address until the allowed maximum number of ping packets are sent. If there is still no response, the DHCPv4 server considers that the IP address is not in use. This ensures that a unique IP address is assigned to the client.

Saving DHCPv4 Data

After DHCPv4 data is saved to the storage device, the data can be restored from the storage device when the NE40E fails.

Context

Perform the following steps on the NE40E that functions as a DHCPv4 server:

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dhcp server database enable

    Saving DHCPv4 data to the hard disk is enabled.

  3. (Optional) Run dhcp server database write-delay interval

    The delay for saving the data is set.

  4. Run commit

    The configuration is committed.

Follow-up Procedure

The NE40E can save the current DHCPv4 data to the storage device and restore the data from the storage device when the NE40E fails.

DHCPv4 data is saved with a fixed file name on the storage device. Normally, the IP leasing information is saved in the lease.txt file and the address conflict information is saved in the conflict.txt file. Back up these two files to other directories because information in these files is replaced regularly.

Restoring DHCPv4 Data

Information about the address lease and address conflict can be restored.

Context

Perform the following steps on the NE40E that functions as a DHCPv4 server:

NOTE:

Only the saved DHCP data can be restored.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dhcp server database recover

    DHCPv4 data is restored from the storage device.

  3. Run commit

    The configuration is committed.

(Optional) Configuring the NE40E to Log Out an Online User and Deny Access of a New User After Detecting an IPv4 Address Conflict

You can configure the NE40E to log out an online user and deny access of a new user if it detects that the IP address assigned to the new user from a remote address pool or by the RADIUS server is the same as the IP address of the online user.

Context

To implement authentication, authorization, and accounting for users separately, users must use different IP addresses to go online. This requires the NE40E to detect whether the IP address assigned to a new user conflicts with that of an online user. By default, if the NE40E detects that the IP address assigned to a new user is the same as the IP address of an online user, it sends a DHCP Decline message to the DHCP server. Then the new user cannot go online, but the online user is not affected.

In scenarios in which IP addresses are assigned based on the Option 82 field that carries physical location information of users and ARP probe is not configured, the online user is required to go offline to allow the new user to go online. For example, if a CPE is replaced, users attached to the old CPE will switch to the new CPE to go online. As their physical location information remains the same, they will be assigned the same IP addresses as before. However, if the previous IP address lease has not expired, the user information is retained. Therefore, the NE40E considers that the users are already online and discards the user packets sent from the new CPE. Subsequently, the users fail to go online through the new CPE. To allow the users to go online through the new CPE, configure the NE40E to delete the previous user information and deny new user access so that the users can be triggered to go online again.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dhcp conflict-ip-address offline user [ include framed-ip ]

    The NE40E is configured to log out an online user and deny access of a new user if it detects that the IP address assigned to the new user from a remote address pool or by the RADIUS server is the same as the IP address of the online user.

    When both the dhcp conflict-ip-address offline and dhcp conflict-ip-address offline user commands are run, and a new user is assigned the IP address of an online user from a remote address pool and the two users are both IPv4/IPv6 dual-stack users, the dhcp conflict-ip-address offline command configuration takes effect. Specifically, the NE40E will log out the online user only from the IPv4 address after detecting the IPv4 address conflict.

  3. Run commit

    The configuration is committed.

(Optional) Configuring the Device to Log out a Dual-Stack User from Both IPv4 and IPv6 Stacks When a Zero Lease Is Delivered in a CoA message for the User's IPv4 Address

This section describes how to configure the device to log out a dual-stack user from both IPv4 and IPv6 stacks and sends a DHCPv4 NAK message to the user when the RADIUS server delivers a zero lease for the user's IPv4 address in a CoA message and the user sends a Request message to renew the lease.

Context

By default, a device logs out a dual-stack user from only the IPv4 stack and sends a DHCPv4 NAK message to the user when the RADIUS server delivers a zero lease for the user's IPv4 address in a CoA message and the user sends a Request message to renew the lease. To enable the device to logout a dual-stack user from both IPv4 and IPv6 stacks, run the dhcp coa-zero-lease dual-cut command.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run aaa

    The AAA view is displayed.

  3. Run domain domain-name

    The AAA domain view is displayed.

  4. Run dhcp coa-zero-lease dual-cut

    The device is enabled to log out a dual-stack user from both IPv4 and IPv6 stacks and sends a DHCPv4 NAK message to the user when the RADIUS server delivers a zero lease for the user's IPv4 address in a CoA message and the user sends a Request message to renew the lease.

  5. Run commit

    The configuration is committed.

Verifying the DHCPv4 Parameter Configuration

After adjusting DHCPv4 parameters, you can view information about a DHCPv4 server and the storage path of the DHCPv4 data.

Prerequisites

Adjustment of DHCPv4 parameters has been configured.

Procedure

  • Run the display dhcp-server item ip-address [ vpn-instance vpn-instance ] command to check information about a DHCPv4 server.
  • Run the display dhcp server database command to check the storage path and file information of the DHCPv4 data.
  • Run the display dhcp upgrade command to check the lease configuration for DHCPv4 users to determine the time when the NE40E restarts.

Example

Run the display dhcp-server item ip-address command, and you can view information about a DHCPv4 server.

<HUAWEI> display dhcp-server item 1.2.3.4
  IPAddress   : 1.2.3.4
  State       :  UP
  Speed Limit : 0 packets / 0 seconds
  Dead Count  : 0
  Timeout     : 25(Sec)
  Dead Time   : 3(Min)
  Nak Count   : 10  
  Vpn Instance: yl

Run the display dhcp server database command, and you can view the saved path of the DHCPv4 data.

<HUAWEI> display dhcp server database
 Status: disable
 Recover from files after reboot: disable
 File saving lease items: cfcard:/dhcp/lease.txt
 File saving conflict items: cfcard:/dhcp/conflict.txt
 Save interval: 300 (seconds)

Run the display dhcp upgrade command, and you can view the configuration to determine the time when the NE40E restarts.

<HUAWEI> display dhcp upgrade
DHCP upgrade: enable.
Lease time: 0days 0hours 30minutes
Renew time: 0days 0hours 15minutes
Rebind time:0days 0hours 22minutes
Access DHCP user count of new lease: 100 
Access DHCP user count of old lease: 100
Access DHCP user count of infinite lease: 10
Max interval from current for old lifetime DHCP user renew: 0 days 0 hours 15 minutes
Translation
Download
Updated: 2019-01-03

Document ID: EDOC1100055031

Views: 19461

Downloads: 89

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