Basic IPv4 Configuration
You can configure IPv4 addresses on network devices to implement data communications between network devices. In addition, you can improve network security by controlling ICMP packets and IP packets carrying route options.
- Overview of IPv4
- Limitations for Basic IPv4
- Configuring IP Addresses on an Interface
- Configuring IP Address Negotiation on Interfaces
- Configuring IP Address Unnumbered on an Interface
- Configuring IPv4 Protocol Stack Security
- Configuring TCP
- Disabling the IP Address Conflict Detection Function and Configuring the Preemption Function
- Configuring the Policy for Sending and Receiving Host Packets
- Configuring Forced IPv4 Packet Fragmentation
- Enabling the Sending of FibMiss Packets to the Interface Board's CPU
- Configuring Fast ICMP Reply
- Configuring Fast Refreshing of Routes with Single Next Hops
- (Optional) Enabling Hardware Copy
- Maintaining IPv4
- Configuration Examples for IPv4
Overview of IPv4
Internet Protocol version 4 (IPv4) is the core protocol of the TCP/IP protocol suite. All TCP, UDP, IGMP, and ICMP data is carried in IP packets. Devices on different networks use IP addresses for communication. In addition, to ensure the security of the TCP/IP protocol suite, you can defend against network attacks by controlling ICMP packets and IP packets carrying options.
The network ID uniquely identifies a network segment or the summarized network segment of multiple network segments. The IP address and subnet mask are converted to be binary numbers. The network ID is obtained after the bit-by-bit AND operation is performed.
The host ID uniquely identifies a specific device on a network segment. The IP address and subnet mask are converted to be binary numbers. Taking the reverse of the subnet mask, the host ID is obtained after the bit-by-bit AND operation is performed.
If multiple devices on the same network segment have the same network ID, they belong to the same network, regardless of their physical locations.
Limitations for Basic IPv4
Limitations for Basic IPv4 on NE40E-M2H
Restrictions |
Guidelines |
Impact |
---|---|---|
IP Fast Reroute (FRR) does not take effect on static routes imported between VPN and public network instances. |
None |
IP FRR fails to take effect. |
1. If the preemption function for conflicting IP addresses is disabled, the same IP address may take effect on a different interface after a device restart. 2. The preemption function for conflicting IP addresses does not take effect for VRRP virtual addresses. 3. If the IP address of the source interface specified for a service takes effect on another interface with a higher priority, the protocol status of the source interface is Down, which may cause service interruption. 4. After a conflicting IP address takes effect on an interface with a higher priority, traffic may be temporarily interrupted due to interface switchover. |
None |
Traffic forwarding is affected. |
Limitations for Basic IPv4 on NE40E-M2K
Restrictions |
Guidelines |
Impact |
---|---|---|
IP Fast Reroute (FRR) does not take effect on static routes imported between VPN and public network instances. |
None |
IP FRR fails to take effect. |
1. If the preemption function for conflicting IP addresses is disabled, the same IP address may take effect on a different interface after a device restart. 2. The preemption function for conflicting IP addresses does not take effect for VRRP virtual addresses. 3. If the IP address of the source interface specified for a service takes effect on another interface with a higher priority, the protocol status of the source interface is Down, which may cause service interruption. 4. After a conflicting IP address takes effect on an interface with a higher priority, traffic may be temporarily interrupted due to interface switchover. |
None |
Traffic forwarding is affected. |
Limitations for Basic IPv4 on NE40E-M2K-B
Restrictions |
Guidelines |
Impact |
---|---|---|
IP Fast Reroute (FRR) does not take effect on static routes imported between VPN and public network instances. |
None |
IP FRR fails to take effect. |
1. If the preemption function for conflicting IP addresses is disabled, the same IP address may take effect on a different interface after a device restart. 2. The preemption function for conflicting IP addresses does not take effect for VRRP virtual addresses. 3. If the IP address of the source interface specified for a service takes effect on another interface with a higher priority, the protocol status of the source interface is Down, which may cause service interruption. 4. After a conflicting IP address takes effect on an interface with a higher priority, traffic may be temporarily interrupted due to interface switchover. |
None |
Traffic forwarding is affected. |
Configuring IP Addresses on an Interface
This section describes how to configure IP addresses for a device so that the device can communicate with other devices on the network.
Usage Scenario
To run IP services on an interface, configure an IP address for the interface. Each interface on a device can be configured with multiple IP addresses. If IP addresses are configured in primary or secondary mode, one primary and multiple secondary IP addresses can be configured on an interface. If the primary or secondary status of IP addresses is ignored, the device does not differentiate primary IP addresses from secondary IP addresses.
If IP addresses are configured in primary or secondary mode, you need to configure only one primary IP address for an interface. In some special cases, you need to configure one or more secondary IP addresses for an interface. For example, a device connects to a physical network through one of its interfaces. Hosts on the physical network belong to two different Class C networks. To allow the device to communicate with all the hosts on the physical network, configure a primary IP address and a secondary IP address for the interface on the device.
If the device ignores the primary or secondary status of IP addresses, you need to configure only one IP address for an interface. In some special cases, you need to configure multiple IP addresses for an interface. For example, multiple IP addresses need to be configured on an interface to differentiate user services. To delete an IP address on an interface without affecting other IP addresses during a service cutover, enable the device to ignore the primary or secondary status of IP addresses so that any IP address configured on the interface can be deleted.
By default, IP addresses are configured in primary or secondary mode.
- For IP addresses in primary or secondary mode:
- One primary IP address and multiple secondary IP addresses can be configured on an interface.
- If a secondary IP address exists, the primary IP address cannot be deleted.
- If both primary and secondary IP addresses are configured on an interface of a device, the device cannot be enabled to ignore the primary or secondary status of IP addresses.
- For IP addresses whose primary or secondary status is ignored:
- Multiple IP addresses can be configured on an interface.
- Any IP address configured on an interface can be deleted.
- If multiple IP addresses are configured on an interface of a device, the device cannot be configured to differentiate primary IP addresses from secondary IP addresses.
- The ip address ignore primary-sub enable and ip address conflict check disable commands are mutually exclusive.
Pre-configuration Tasks
Before configuring IP addresses on an interface, configure link layer protocol parameters for the interface and ensure that the link layer protocol of the interface is Up.
Procedure
- For IP addresses whose primary or secondary status is ignored:
Run system-view
The system view is displayed.
Run ip address ignore primary-sub enable
The device is enabled to ignore the primary or secondary status of IP addresses.
Run commit
The configuration is committed.
Run interface interface-type interface-number
The interface view is displayed.
Run ip address ip-address { mask | mask-length }
An IP address is configured for the interface.
Run this command multiple times on the interface to configure multiple IP addresses for the interface.
A maximum of 256 IP addresses can be configured for each interface.
Run commit
The configuration is committed.
- For IP addresses in primary or secondary mode:
Run system-view
The system view is displayed.
(Optional) Run undo ip address ignore primary-sub enable
The device is configured to differentiate primary IP addresses from secondary IP addresses.
Run interface interface-type interface-number
The interface view is displayed.
Run ip address ip-address { mask | mask-length }
A primary IP address is configured.
An interface can have only one primary IP address. If the ip address ip-address { mask | mask-length } command is run more than once to configure a primary IP address for an interface, the latest configuration overrides the previous one.
(Optional) Run ip address ip-address { mask | mask-length } sub
A secondary IP address is configured for the interface.
To save the IP address space, you can configure secondary IP addresses with 31-bit masks for an interface.
A maximum of 255 secondary IP addresses can be configured for each interface.
Run commit
The configuration is committed.
Configuring IP Address Negotiation on Interfaces
PPP access users can use PPP address negotiation to apply to a server for IP addresses.
Usage Scenario
If devices are connected through PPP links, client interfaces can obtain IP addresses from the server through negotiation. This is applicable when the client accesses the Internet by connecting to the Internet Service Provider (ISP) through PPP links (for example by dial-up). In this case, the ISP device assigns an IP address to the client through negotiation.
As shown in Figure 9-1, after the interfaces that directly connect Device A on the server side to Device B on the client side are encapsulated with PPP, the client can obtain an IP address from the server through negotiation.
When configuring IP address negotiation on interfaces, note the following points:
IP address negotiation can be configured only on PPP-encapsulated interfaces. If the PPP status is Down, the IP address generated during negotiation is deleted.
After IP address negotiation is configured for an interface, you do not need to configure any IP address for the interface. If the interface already has an IP address, the original IP address is deleted.
After an interface obtains an IP address through negotiation, you cannot configure secondary IP addresses for this interface.
If you configure IP address negotiation for an interface that has already has this function enabled, the originally generated IP address is deleted, and the interface obtains a new IP address through negotiation.
After the IP address generated through negotiation for the interface is deleted, the interface becomes an addressless interface.
Pre-configuration Tasks
Before configuring IP address negotiation on interfaces, complete the following tasks:
Configure IP addresses for server interfaces to ensure that the link layer protocol status of the interfaces is Up.
Configure physical parameters and the link layer protocol PPP for interfaces on client interfaces.
Configuring a Server to Assign an IP Address to a Client Through Negotiation
After an IP address is specified on a server, the server can assign this IP address to a client.
Context
The IP address to be assigned to a client cannot be the same as the IP address of the server.
Procedure
- Run system-view
The system view is displayed.
- Run interface interface-type interface-number
The view of the interface that directly connects to the client is displayed.
IP address negotiation can be configured only on PPP-encapsulated interfaces.
- Run remote address ip-address
An IP address is specified to be assigned to a client.
The IP address to be assigned to a client cannot be the same as the IP address of the server.
- Run shutdown
The interface is shut down.
- Run commit
The configuration is committed.
- Run undo shutdown
The interface is enabled.
- Run commit
The configuration is committed.
Configuring a Client to Obtain an IP Address Through Negotiation
After interface IP address negotiation is enabled on a client, the client can obtain an IP address from the server.
Procedure
- Run system-view
The system view is displayed.
- Run interface interface-type interface-number
The view of the interface that directly connects to the server is displayed.
IP address negotiation can be configured only on PPP-encapsulated interfaces.
- Run ip address ppp-negotiate
IP address negotiation is enabled on the interface.
- Run commit
The configuration is committed.
Configuring IP Address Unnumbered on an Interface
IP address unnumbered allows an interface that is not assigned an IP address to borrow an IP address from another interface.
Usage Scenario
To save IP address resources, you can configure an interface to borrow an IP address from another interface. For example, if an interface is only occasionally used, it is unnecessary to configure an IP address for it. Instead, you can configure the interface to borrow an IP address of another interface.
When configuring IP address unnumbered on an interface, note the following points:
The IP address of the numbered interface cannot be a borrowed IP address.
The IP address of the numbered interface can be lent to multiple interfaces.
If the numbered interface has multiple IP addresses, the unnumbered interface borrows only the primary IP address.
If the numbered interface is not configured with an IP address, the unnumbered interface borrows the IP address 0.0.0.0.
The IP address of the virtual loopback interface can be borrowed by other interfaces, but the virtual loopback interface cannot borrow an IP address from another interface.
Configuring the Primary IP Address for a Numbered Interface
Only the primary IP address of an interface can be borrowed.
Context
Configuring IP address unnumbered saves IP address resources. You can configure an interface that is occasionally used to borrow an IP address, instead of configuring a new IP address for the interface.
Procedure
- Run system-view
The system view is displayed.
- Run interface interface-type interface-number
The view of the numbered interface is displayed.
- Run ip address ip-address { mask | mask-length }
A primary IP address is configured for the numbered interface.
The IP address of a numbered interface can be configured using the ip address command or obtained through negotiation.
- Run commit
The configuration is committed.
Configuring an Unnumbered Interface to Borrow an IP Address from Another Interface
An Ethernet interface can borrow the IP address of another interface.
Context
Configuring IP address unnumbered saves IP address resources. You can configure an interface that is occasionally used to borrow an IP address, instead of configuring a new IP address for the interface.
The configuration procedure described in this section involves only configuring an interface to borrow an IP address. The unnumbered interface has no IP address, and therefore dynamic routing protocols cannot run on this interface. To allow this interface to communicate with a remote device, you must configure a static route from this interface to the network segment of the remote device.
Procedure
- Run system-view
The system view is displayed.
- Run interface interface-type interface-number
The view of the unnumbered interface is displayed.
- Run ip address unnumbered interface interface-type interface-number
The unnumbered interface is configured to borrow an IP address from a specified interface.
- Run commit
The configuration is committed.
Configuring IPv4 Protocol Stack Security
By controlling ICMP packets and IP packets carrying route options, you can effectively defend against attacks by sending these packets on the network.
Usage Scenario
The route options in an IP packet can be used to diagnose link faults and temporarily transmit special services. Network attackers may use packets carrying route options to probe the network structure and launch attacks. Therefore, by configuring whether to process IP packets carrying route options, you can effectively defend against attacks by sending these packets.
Network attackers perform scanning by using various types of packets, and devices reply to these packets with ICMP packets. Network attackers then obtain network information from these received ICMP packets and launch attacks on the network. In addition, the devices are busy sending ICMP packets, affecting transmission of normal service packets. By controlling the sending and receiving of ICMP packets, you can effectively defend against attacks by sending these packets.
Controlling the Processing of IP Packets Carrying Route Options
By disabling devices from processing IP packets carrying route options, you can effectively defend networks against attacks by sending these packets.
Context
Route alert option
Record route option
Source route option
Timestamp option
These options are used to diagnose link faults and temporarily transmit special services. These options may also be utilized by network attackers to probe the network structure and launch attacks. Therefore, you need to run this command to enable the system to process or disable the system from processing IP packets with route options.
By default, routers process IP packets carrying route options. To defend networks against attacks by sending IP packets carrying route options, disable the system from processing these IP packets.
Procedure
- Run system-view
The system view is displayed.
- Run any of the following commands based on the route options:
Run undo ip option route-alert enable
The system is disabled from processing IP packets carrying the route alert option.
Run undo ip option route-record enable
The system is disabled from processing IP packets carrying the record route option.
Run undo ip option source-route enable
The system is disabled from processing IP packets carrying the source route option.
Run undo ip option time-stamp enable
The system is disabled from processing IP packets carrying the timestamp option.
- Run commit
The configuration is committed.
Controlling ICMP Packets
By controlling the sending and receiving of ICMP packets, you can effectively defend against attacks by sending these packets.
Context
In the case of heavy traffic on a network, if hosts or ports frequently become unreachable, routers receive a large number of ICMP packets. As a result, the network is more heavily burdened, and router performance deteriorates. In addition, most attackers use ICMP packets to launch attacks, such as sending a large number of packets with the TTL value 1, packets carrying options, and ICMP packets whose destination addresses are broadcast addresses.
Perform the following configurations to reduce traffic burdens over the network and defend against ICMP packet attacks:
Procedure
Control the sending and receiving of ICMP packets.
Run system-view
The system view is displayed.
Run undo icmp receive or undo icmp send
The sending or receiving of ICMP packets is disabled.
Run commit
The configuration is committed.
Control the source IP address of ICMP Port Unreachable or Time Exceeded messages in the loopback interface view.
Run system-view
The system view is displayed.
Run interface loopback loopback-number
The loopback interface view is displayed.
Run ip icmp { ttl-exceeded | port-unreachable } source-address
The source IP address of ICMP Port Unreachable or Time Exceeded messages is configured.
Run commit
The configuration is committed.
Setting the Timeout Period for the Reassembly Queue
To improve the router performance and prevent against network attacks, configure a proper reassembly timeout period so that reassembly queues that have waited for all fragments to be reassembled for a long period can be aged in time.
Procedure
- Run system-view
The system view is displayed.
- Run ipv4 reassembling timeout time
The timeout period of IPv4 fragment reassembly is set.
time ranges from 5 to 120, in seconds. Using the default value 30 seconds is recommended.
- (Optional) Run reset ip reassembly
The fragment and assembly data are initialized.
Configuring IP Source Address Check
This section describes how to configure IP source address check to prevent routers from network attacks.
Usage Scenario
By default, an interface does not perform source address validity check on the received packets. The reason for this is that broadcast or multicast addresses may be used as the source address in actual situations. However, hackers may use a broadcast or multicast address as the source address to launch a network attack. You can enable source address validity check to filter this type of illegitimate packets with the purpose of improving device security.
Configuring TCP
Configuring TCP Timers
You can control the TCP connection time by setting the SYN-Wait timer and FIN-Wait timer.
Context
Two TCP timers are available:
SYN-Wait timer: TCP starts the SYN-Wait timer when sending SYN packets. If no replies in response to SYN packets are received before the SYN-Wait timer expires, the TCP connection is terminated. The SYN-Wait timer ranges from 2 to 600 seconds, and the default value is 75 seconds.
FIN-Wait timer: When the TCP connection status turns from FIN_WAIT_1 to FIN_WAIT_2, the FIN-Wait timer starts. If no FIN packets are received before the FIN-Wait timer expires, the TCP connection is terminated. The FIN-Wait timer ranges from 76 to 3600 seconds, and the default value is 675 seconds.
Perform the following steps on the Router:
Specifying the Size of a TCP Sliding Window
By setting the sliding window size for TCP, you can set the sizes of the receiving buffer and transmitting buffer in the socket. This improves network performance.
Setting the MSS Value for a TCP Connection
Verifying the TCP Configuration
After configuring TCP, verify the configuration.
Procedure
- Run the display tcp status [ local-ip ipv4-address ] [ local-port local-port-number ] [ remote-ip ipv4-address ] [ remote-port remote-port-number ] [ cid cid ] [ socket-id socket-id ] command to check the TCP connection status.
- Run the display tcp statistics command to check TCP traffic statistics.
Disabling the IP Address Conflict Detection Function and Configuring the Preemption Function
This section describes how to configure conflicting IP addresses for different interfaces after the IP address conflict detection function is disabled as well as to configure the preemption function so that conflicting IP addresses take effect on the interfaces with higher priorities.
Usage Scenario
In scenarios of upgrade and capacity expansion on the live network, existing interfaces need to be replaced. If a customer has limited IP address resources and therefore is unwilling to assign new IP addresses for replacement interfaces, disable the IP address conflict detection function so that conflicting IP addresses can be configured on different interfaces. Configure IP addresses of the to-be-replaced interfaces for new interfaces. The IP addresses take effect on the new interfaces after the to-be-replaced interfaces are shut down or their IP addresses are deleted.
If the IP address or broadcast address of an interface is the same as that of another interface, IP address conflict occurs. After the IP address conflict detection function is disabled and the preemption function for conflicting IP addresses is enabled, conflicting IP addresses take effect on the interfaces with higher priorities.
Procedure
- Run system-view
The system view is displayed.
- Run ip address conflict check disable
The IP address conflict detection function is disabled.
- Run ip address conflict preempt enable
The preemption function for conflicting IP addresses is enabled.
After the preemption function for conflicting IP addresses is enabled, IP addresses take effect on the interfaces with higher priorities in IP address conflict scenarios.
If the primary IP address of an interface does not take effect due to IP address conflict, its secondary IP address also becomes invalid. If the primary IP address of an interface takes effect, its secondary IP address takes effect only when no duplicate IP address exists on the network.
- Run commit
The configuration is committed.
Configuring the Policy for Sending and Receiving Host Packets
You can configure the policy for sending and receiving host packets to control the selection of tunnels and the forwarding mode for transmitting host packets.
Usage Scenario
By default, when a device is configured with multiple TE tunnels with various priorities, the device randomly selects a TE tunnel in load balancing mode to send host packets. To configure the device to send host packets over the TE tunnel with the highest priority, run the host-packet send service-class te enable command.
If a sub-interface on the local device has been configured with a VLAN priority for host packets using the 8021p 8021p-value command, a sub-interface on the peer device has been configured with the same VLAN priority and a VLAN ID using the dot1q termination vid low-pe-vid 8021p { 8021p-value1 [ to 8021p-value2 ] } &<1-8> command, and the IP addresses of the two sub-interfaces are on the same network segment, the local and peer devices fail to communicate with each other and the BGP peer relationship fails to be established between the local and peer devices. To disable fast reply of host packets based on the service type configured on the interface, run the host-packet fast-reply disable command.
A device proactively sends a large number of host packets during interface route switching. To relieve the CPU usage of the host module, run the host-packet fast-send enable command to enable fast reply of host packets based on the service type configured on the interface.
Procedure
- Run system-view
The system view is displayed.
- Run host-packet send service-class te enable
The device is configured to send host packets over a TE tunnel with the highest priority.
- Run host-packet fast-reply { tcp | udp | rawip } disable
Fast reply of host packets is disabled.
- Run host-packet fast-send { tcp | udp | rawip } enable
Fast reply of host packets is enabled.
Configuring Forced IPv4 Packet Fragmentation
Configuring forced IPv4 packet fragmentation prevents long packets from being discarded in specific scenarios.
Usage Scenario
By default, forced IPv4 packet fragmentation is disabled. If the length of an IPv4 packet received by an interface is greater than the MTU of the interface and the Don't Fragment (DF) flag in the IPv4 packet is set to 1, indicating no fragmentation, the NE40E discards this packet and sends an ICMP packet to its upstream device. If you want the NE40E to fragment the packet before sending it, enable forced IPv4 packet fragmentation on the NE40E.
In VS mode, this configuration process is supported only by the admin VS.
Enabling the Sending of FibMiss Packets to the Interface Board's CPU
Usage Scenario
Figure 9-2 shows the process in which the NE40E processes an IP packet that has the destination address not being the local device address and does not match any entry in the FIB table.
If the destination IP address of a packet received by an interface board on a device from a peer device is not the local device address and does not match any FIB entry on the local device and no CAR operation is performed, the interface board determines whether to send a FibMiss packet to the CPU.
After receiving a FibMiss packet, the CPU parses the source IP address of the packet and determines whether to generate an ICMP network unreachable packet and send it to the peer device.
Run the undo fib-miss-report enable command to disable the interface board from sending FibMiss packets to the CPU.
Run the undo icmp name net-unreachable send command to disable the CPU of the interface board from generating and replying with ICMP network unreachable packets.
In VS mode, this configuration process is supported only by the admin VS.
Configuring Fast ICMP Reply
Configuring Fast Refreshing of Routes with Single Next Hops
Fast refreshing routes with single next hops speeds up route convergence and reduces packet loss.
Usage Scenario
If routes have only single next hops, a link switchover takes a long time due to slow route convergence. To solve this problem, configure fast refreshing of routes with single next hops to speed up route convergence and reduce packet loss.
In VS mode, this configuration process is supported only by the admin VS.
(Optional) Enabling Hardware Copy
The hardware copy function allows a device to forward the protocol packets to be broadcast through hardware instead of sending them to the CPU, achieving fast forwarding.
Usage Scenario
If a lot of VLANs are configured on a super VLANIF interface, a dot1q VLAN tag termination sub-interface, or a QinQ VLAN tag termination sub-interface, the protocol packets to be forwarded will be broadcast to all the configured VLANs, which burdens the CPU. The hardware copy function allows the protocol packets to be broadcast through hardware, which reduces CPU performance consumption.
Procedure
- Run system-view
The system view is displayed.
- Enable hardware copy either globally or on an interface. This command is applicable only to the super VLANIF interface, dot1q VLAN tag termination sub-interface, and QinQ VLAN tag termination sub-interface.
To enable hardware copy globally in the system view, run broadcast-copy fast enable
- To enable hardware copy on an dot1q VLAN tag termination sub-interface or a QinQ VLAN tag termination sub-interface, run the following commands:
Run interface interface-type interface-number . subinterface-number
The sub-interface view is displayed.
- Run either of the following commands:
To configure the sub-interface as a dot1q VLAN tag termination sub-interface, run encapsulation dot1q-termination
To configure the sub-interface as a QinQ VLAN tag termination sub-interface, run encapsulation qinq-termination
Run broadcast-copy fast enable
The hardware copy function is enabled.
- To enable hardware copy on a super VLANIF interface, run the following commands:
Run system-view
The interface view is displayed.
Run vlan vlan-id
The VLAN view is displayed.
Run aggregate-vlan
The VLAN is configured as a super VLAN.
Run interface vlanif vlanif-id
The VLANIF interface view is displayed.
Run broadcast-copy fast enable
The hardware copy function is enabled.
- Run commit
The configuration is committed.
Maintaining IPv4
This section describes how to clear IPv4 statistics and monitor the IPv4 operating status.
Monitoring the IPv4 Operating Status
You can monitor the IPv4 operating status.
Context
You can run the following commands in any view to check the IPv4 operating status in routine maintenance.
Procedure
- Run the display interface brief command in any view to check the interface summary.
- Run the display ip statistics command in any view to check IP traffic statistics.
- Run the display icmp statistics [ interface interface-type interface-num ] command in any view to check ICMP traffic statistics.
- Run the display ip socket command in any view to check information about created IPv4 sockets.
- Run the display rawip status command in any view to check information about IPv4 RawIP connections.
- Run the display rawlink status command in any view to check information about IPv4 Rawlink connections.
- Run the display forward-statistics packet discard [ mac | mtu ] [ ipv4 | ipv6 ] { interface interface-type interface-number | slot slot-id } command to view statistics about packets that have been discarded because the packets' destination MAC addresses are different from an interface's MAC address or the packets' sizes exceed the interface's MTU.
Clearing IPv4 Statistics
You can delete IPv4 statistics.
Context
ICMP or IP traffic statistics cannot be restored after they are cleared. Exercise caution when running a reset command.
Procedure
- Run the reset ip statistics command in the user view to clear IP and ICMP traffic statistics.
- To clear statistics about packets that have been discarded because the packets' destination MAC addresses are different from an interface's MAC address or the packets' sizes exceed the interface's MTU, run the reset forward-statistics packet discard [ mac | mtu ] ipv4 { interface [ interface-type interface-number ] | slot slot-id } command.
Configuration Examples for IPv4
This section provides IPv4 configuration examples.
Example for Configuring Primary and Secondary IP Addresses for an Interface
This section provides an example for configuring a primary IP address and a secondary IP address for an interface.
Networking Requirements
As shown in Figure 9-3, GE 0/1/1 of the device connects to a LAN in which computers belong to one of the two network segments: 172.16.1.0/24 and 172.16.2.0/24. It is required that the device can communicate with the two network segments. At the same time, the hosts of the two network segments can communicate with each other.
Configuration Roadmap
The configuration roadmap is as follows:
Analyze the addresses of the network segments to which the interface connects.
Configure a primary IP address for the interface and then one or more secondary IP addresses for the interface.
The primary and secondary IP addresses of an interface can have overlapped network segments but cannot be the same. The secondary IP addresses of an interface must belong to different network segments.
Data Preparation
To complete the configuration, you need the following data:
Primary IP address and subnet mask of the interface
Secondary IP address and subnet mask of the interface
Procedure
- Configure the device.
# Configure primary and secondary IP addresses for GE 0/1/1.
<HUAWEI> system-view
[~HUAWEI] interface gigabitethernet 0/1/1
[~HUAWEI-GigabitEthernet0/1/1] ip address 172.16.1.1 255.255.255.0
[*HUAWEI-GigabitEthernet0/1/1] ip address 172.16.2.1 255.255.255.0 sub
[*HUAWEI-GigabitEthernet0/1/1] undo shutdown
[*HUAWEI-GigabitEthernet0/1/1] commit
[~HUAWEI-GigabitEthernet0/1/1] quit
- Verify the configuration.
# Ping the hosts on the network segment 172.16.1.0 from Device. The ping operation is successful.
[~HUAWEI] ping 172.16.1.2
PING 172.16.1.2: 56 data bytes, press CTRL_C to break
Reply from 172.16.1.2: bytes=56 Sequence=1 ttl=255 time=614 ms
Reply from 172.16.1.2: bytes=56 Sequence=2 ttl=255 time=16 ms
Reply from 172.16.1.2: bytes=56 Sequence=3 ttl=255 time=2 ms
Reply from 172.16.1.2: bytes=56 Sequence=4 ttl=255 time=3 ms
Reply from 172.16.1.2: bytes=56 Sequence=5 ttl=255 time=2 ms
--- 172.16.1.2 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 25/26/27 ms
# Ping the hosts on the network segment 172.16.2.0 from Device. The ping operation is successful.
[~HUAWEI] ping 172.16.2.2
PING 172.16.2.2: 56 data bytes, press CTRL_C to break
Reply from 172.16.2.2: bytes=56 Sequence=1 ttl=255 time=13 ms
Reply from 172.16.2.2: bytes=56 Sequence=2 ttl=255 time=2 ms
Reply from 172.16.2.2: bytes=56 Sequence=3 ttl=255 time=2 ms
Reply from 172.16.2.2: bytes=56 Sequence=4 ttl=255 time=2 ms
Reply from 172.16.2.2: bytes=56 Sequence=5 ttl=255 time=2 ms
--- 172.16.2.2 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 25/25/26 ms
# The hosts on the two network segments cannot ping each other.
Example for Configuring IP Address Negotiation on an Interface
This section provides an example for configuring IP address negotiation on an interface so that the interface can obtain an IP address..
Networking Requirements
As shown in Figure 9-4, Device A functions as a PPP server, and Device B functions as a PPP client. To allow Device A to assign an IP address to POS 0/1/0 on Device B through PPP negotiation, configure IP address negotiation on POS 0/1/0.
Configuration Roadmap
The configuration roadmap is as follows:
Configure an IP address for the local interface.
Assign an IP address to the interface on the client.
Configure the client to obtain an IP address through negotiation.
Data Preparation
To complete the configuration, you need the following data:
IP address and subnet mask of the local interface
The IP address to be assigned to the client
Procedure
- Configure DeviceA.
# Configure an IP address for POS 0/1/0.
<HUAWEI> system-view
[~HUAWEI] sysname DeviceA
[*HUAWEI] commit
[~DeviceA] interface pos0/1/0
[~DeviceA-Pos0/1/0] link-protocol ppp
[*DeviceA-Pos0/1/0] ip address 192.168.1.1 255.255.255.0
# Assign an IP address to the interface on the client.
[*DeviceA-Pos0/1/0] remote address 192.168.1.2
[*DeviceA-Pos0/1/0] shutdown
[*DeviceA-Pos0/1/0] commit
[~DeviceA-Pos0/1/0] undo shutdown
[*DeviceA-Pos0/1/0] commit
[~DeviceA-Pos0/1/0] quit
- Configure DeviceB.
# Configure the interface to obtain an IP address through negotiation.
<HUAWEI> system-view
[~HUAWEI] sysname DeviceB
[*HUAWEI] commit
[~DeviceB] interface pos0/1/0
[~DeviceB-Pos0/1/0] link-protocol ppp
[*DeviceB-Pos0/1/0] ip address ppp-negotiate
[*DeviceB-Pos0/1/0] undo shutdown
[*DeviceB-Pos0/1/0] commit
[~DeviceB-Pos0/1/0] quit
- Verify the configuration.
# Ping POS 0/1/0 on DeviceA from DeviceB. The ping operation is successful.
[~DeviceB] ping 192.168.1.1
PING 192.168.1.1: 56 data bytes, press CTRL_C to break
Reply from 192.168.1.1: bytes=56 Sequence=1 ttl=255 time=156 ms
Reply from 192.168.1.1: bytes=56 Sequence=2 ttl=255 time=63 ms
Reply from 192.168.1.1: bytes=56 Sequence=3 ttl=255 time=62 ms
Reply from 192.168.1.1: bytes=56 Sequence=4 ttl=255 time=63 ms
Reply from 192.168.1.1: bytes=56 Sequence=5 ttl=255 time=63 ms
--- 192.168.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 62/81/156 ms
# Display the status of POS 0/1/0 on Device B.
[~DeviceB] display interface pos0/1/0
Pos0/1/0 current state : UP Line protocol current state : UP Last line protocol up time : 2007-12-07, 17:12:39 Description : HUAWEI, Pos0/1/0 InterfaceRoute Port,The Maximum Transmit Unit is 4470, Hold timer is 10(sec) Internet Address is negotiated, 192.168.1.2/32 Link layer protocol is PPP LCP opened, IPCP opened The Vendor PN is FTRJ1321P1BTL Port BW: 2.5G, Transceiver max BW: 2.5G, Transceiver Mode: SingleMode WaveLength: 1310nm, Transmission Distance: 5km Rx Power: -2.81dBm, Tx Power: -1.91dBm Physical layer is Packet Over SDH Scramble enabled, clock master, CRC-32, loopback: none Flag J0 "NetEngine " Flag J1 "NetEngine " Flag C2 22(0x16) SDH alarm: section layer: none line layer: none path layer: none SDH error: section layer: B1 61575 line layer: B2 12002824 REI 16835916 path layer: B3 65535 Statistics last cleared:never Last 300 seconds input rate 16 bits/sec, 0 packets/sec Last 300 seconds output rate 40 bits/sec, 0 packets/sec Input: 3510 packets, 57372 bytes Input error: 0 shortpacket, 0 longpacket, 4 CRC, 0 lostpacket Output: 7270 packets, 344198 bytes Output error: 0 lostpackets Output error: 0 overrunpackets, 0 underrunpackets
The command output shows "Internet Address is negotiated, 192.168.1.2/32", meaning that IP address negotiation is successful.
Configuration Files
DeviceA configuration file
#
sysname DeviceA
#
interface pos0/1/0
undo shutdown
link-protocol ppp
ip address 192.168.1.1 255.255.255.0
remote address pool 192.168.1.2
#
return
DeviceB configuration file
#
sysname DeviceB
#
interface pos0/1/0
undo shutdown
link-protocol ppp
ip address ppp-negotiate
#
return
Example for Configuring IP Address Unnumbered on an Interface
This section provides an example for configuring IP address unnumbered on an interface.
Networking Requirements
As shown in Figure 9-5, an enterprise builds its intranet through an integrated services digital network (ISDN). DeviceA and DeviceB connect to a local LAN through GE 0/1/0 and connect to each other over the ISDN through dialing interfaces GE 0/2/0. To save IP address resources, the dialing interfaces are configured to borrow IP addresses from GE 0/1/0.
Configuration Roadmap
The configuration roadmap is as follows:
Configure IP addresses to be borrowed.
Configure interfaces to borrow IP addresses from other interfaces.
Data Preparation
To complete the configuration, you need the following data:
IP addresses of the numbered interfaces
Numbers of the numbered interfaces
Procedure
- Configure DeviceA.
# Configure an IP address for GE 0/1/0.
<HUAWEI> system-view
[~HUAWEI] sysname DeviceA
[*HUAWEI] commit
[~DeviceA] interface gigabitethernet 0/1/0
[~DeviceA-GigabitEthernet0/1/0] ip address 172.16.10.1 255.255.255.0
[*DeviceA-GigabitEthernet0/1/0] undo shutdown
[*DeviceA-GigabitEthernet0/1/0] quit
# Configure GE 0/2/0 to borrow the IP address from GE 0/1/0.
[*DeviceA] interface GigabitEthernet 0/2/0
[*DeviceA-GigabitEthernet0/2/0] ip address unnumbered interface gigabitethernet 0/1/0
[*DeviceA-GigabitEthernet0/2/0] undo shutdown
[*DeviceA-GigabitEthernet0/2/0] quit
- Configure DeviceB.
# Configure an IP address for GE 0/1/0.
<HUAWEI> system-view
[~HUAWEI] sysname DeviceB
[*HUAWEI] commit
[~DeviceB] interface gigabitethernet 0/1/0
[~DeviceB-GigabitEthernet0/1/0] ip address 172.16.20.1 255.255.255.0
[*DeviceB-GigabitEthernet0/1/0] undo shutdown
[*DeviceB-GigabitEthernet0/1/0] quit
# Configure GE 0/2/0 to borrow the IP address from GE 0/1/0.
[*DeviceB] interface GigabitEthernet 0/2/0
[*DeviceB-GigabitEthernet0/2/0] ip address unnumbered interface gigabitethernet 0/1/0
[*DeviceB-GigabitEthernet0/2/0] undo shutdown
[*DeviceB-GigabitEthernet0/2/0] quit
# Configure a route to the Ethernet network segment of Device B.
[*DeviceB] ip route-static 172.16.10.0 255.255.255.0 GigabitEthernet 0/2/0
[*DeviceB] commit
- Verify the configuration.
# Ping the IP address of DeviceB's interface that directly connects to DeviceA from DeviceA. The ping operation is successful.
[~DeviceA] ping 172.16.20.1
PING 172.16.20.2: 56 data bytes, press CTRL_C to break
Reply from 172.16.20.2: bytes=56 Sequence=1 ttl=255 time=25 ms
Reply from 172.16.20.2: bytes=56 Sequence=2 ttl=255 time=25 ms
Reply from 172.16.20.2: bytes=56 Sequence=3 ttl=255 time=26 ms
Reply from 172.16.20.2: bytes=56 Sequence=4 ttl=255 time=26 ms
Reply from 172.16.20.2: bytes=56 Sequence=5 ttl=255 time=26 ms
--- 172.16.20.2 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 25/25/26 ms
Configuration Files
DeviceA configuration file
#
sysname DeviceA
#
interface GigabitEthernet0/1/0
undo shutdown
ip address 172.16.10.1 255.255.255.0
#
interface GigabitEthernet0/2/0
undo shutdown
ip address unnumbered interface GigabitEthernet0/1/0
#
ip route-static 172.16.20.0 255.255.255.0 GigabitEthernet0/2/0
#
return
DeviceB configuration file
#
sysname DeviceB
#
interface GigabitEthernet0/1/0
undo shutdown
ip address 172.16.20.1 255.255.255.0
#
interface GigabitEthernet0/2/0
undo shutdown
ip address unnumbered interface GigabitEthernet0/1/0
#
ip route-static 172.16.10.0 255.255.255.0 GigabitEthernet0/2/0
#
return
Example for Configuring Address Overlapping
This section provides an example for configuring IP address overlapping on a device.
Networking Requirements
As shown in Figure 9-6, Network A and Network B are independent of each other. They access the Internet through different paths. Network A and Network B access each other through the same Layer 2 network provided by ISP1.
To allow Network A and Network B to connect to the Layer 2 network provided by ISP1 through DeviceB by using IP addresses 192.168.1.11/24 and 192.168.1.12/24 respectively on the same network segment, configure address overlapping on DeviceB.
Procedure
- Configure a VPN instance.
# On DeviceB, create a VPN instance for Network A, and bind the VPN instance to the upstream interface GE 0/1/0 and the downstream interface GE 0/2/0.
<HUAWEI> system-view
[~HUAWEI] sysname DeviceB
[*HUAWEI] commit
[~DeviceB] ip vpn-instance r1
[*DeviceB-vpn-instance-r1] route-distinguisher 100:1
[*DeviceB-vpn-instance-r1] quit
[*DeviceB] interface gigabitethernet 0/1/0
[*DeviceB-GigabitEthernet0/1/0] ip binding vpn-instance r1
[*DeviceB-GigabitEthernet0/1/0] ip address 192.168.1.11 24
[*DeviceB-GigabitEthernet0/1/0] undo shutdown
[*DeviceB-GigabitEthernet0/1/0] quit
[*DeviceB] interface GigabitEthernet 0/2/0
[*DeviceB-GigabitEthernet0/2/0] ip binding vpn-instance r1
[*DeviceB-GigabitEthernet0/2/0] ip address 10.1.1.1 24
[*DeviceB-GigabitEthernet0/2/0] undo shutdown
[*DeviceB-GigabitEthernet0/2/0] quit
# On DeviceB, create a VPN instance for Network B, and bind the VPN instance to the upstream interface GE 0/3/0 and the downstream interface GE 0/1/8.
[*DeviceB] ip vpn-instance r2
[*DeviceB-vpn-instance-r2] route-distinguisher 100:2
[*DeviceB-vpn-instance-r2] quit
[*DeviceB] interface gigabitethernet 0/3/0
[*DeviceB-GigabitEthernet0/3/0] ip binding vpn-instance r2
[*DeviceB-GigabitEthernet0/3/0] ip address 192.168.1.12 24
[*DeviceB-GigabitEthernet0/3/0] undo shutdown
[*DeviceB-GigabitEthernet0/3/0] quit
[*DeviceB] interface GigabitEthernet 0/1/8
[*DeviceB-GigabitEthernet0/1/8] ip binding vpn-instance r2
[*DeviceB-GigabitEthernet0/1/8] ip address 10.2.1.1 24
[*DeviceB-GigabitEthernet0/1/8] undo shutdown
[*DeviceB-GigabitEthernet0/1/8] quit
# On Device B, configure static routes for the two VPN instances.
[*DeviceB] ip route-static vpn-instance r1 0.0.0.0 0 192.168.1.1
[*DeviceB] ip route-static vpn-instance r2 0.0.0.0 0 192.168.1.1
[*DeviceB] commit
- Establish EBGP neighbor relationships between DeviceA and the two upstream interfaces on DeviceB.
# Configure Device B.
[~DeviceB] bgp 200
[*DeviceB-bgp] router-id 100.1.1.1
[*DeviceB-bgp] ipv4-family vpn-instance r1
[*DeviceB-bgp-r1] peer 192.168.1.1 as-number 100
[*DeviceB-bgp-r1] import-route direct
[*DeviceB-bgp-r1] quit
[*DeviceB-bgp] ipv4-family vpn-instance r2
[*DeviceB-bgp-r2] peer 192.168.1.1 as-number 100
[*DeviceB-bgp-r2] import-route direct
[*DeviceB-bgp-r2] commit
[~DeviceB-bgp-r2] quit
# Configure DeviceA.
<HUAWEI> system-view
[~HUAWEI] sysname DeviceA
[*HUAWEI] commit
[~DeviceA] interface gigabitethernet 0/1/0
[~DeviceA-GigabitEthernet0/1/0] ip address 192.168.1.1 24
[*DeviceA-GigabitEthernet0/1/0] undo shutdown
[*DeviceA-GigabitEthernet0/1/0] quit
[*DeviceA] bgp 100
[*DeviceA-bgp] peer 192.168.1.11 as-number 200
[*DeviceA-bgp] peer 192.168.1.12 as-number 200
[*DeviceA-bgp] commit
[~DeviceA-bgp] quit
- Configure IP addresses and static routes for DeviceC and DeviceD on the local network.
# Configure an IP address and a static route for DeviceC.
<HUAWEI> system-view
[~HUAWEI] sysname DeviceC
[*HUAWEI] commit
[~DeviceC] interface GigabitEthernet 0/2/0
[~DeviceC-GigabitEthernet0/2/0] ip address 10.1.1.2 24
[*DeviceC-GigabitEthernet0/2/0] undo shutdown
[*DeviceC-GigabitEthernet0/2/0] quit
[*DeviceC] ip route-static 0.0.0.0 0 10.1.1.1
[*DeviceC] commit
# Configure an IP address and a static route for Device D.
<HUAWEI> system-view
[~HUAWEI] sysname DeviceD
[*HUAWEI] commit
[~DeviceD] interface GigabitEthernet 0/1/8
[~DeviceD-GigabitEthernet0/1/8] ip address 10.2.1.2 24
[*DeviceD-GigabitEthernet0/1/8] undo shutdown
[*DeviceD-GigabitEthernet0/1/8] quit
[*DeviceD] ip route-static 0.0.0.0 0 10.2.1.1
[*DeviceD] commit
- Verify the configuration.
# After the configuration is complete, check the VPN routing table on DeviceB. The command output shows that the routes of the two local networks connected to DeviceB belong to two VPN instances r1 and r2, respectively. The routes are isolated.
[~DeviceB] display ip routing-table vpn-instance r1
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole route ------------------------------------------------------------------------------ Routing Tables: r1 Destinations : 6 Routes : 6 Destination/Mask Proto Pre Cost Flags NextHop Interface 0.0.0.0/0 Static 60 0 RD 192.168.1.1 GigabitEthernet0/1/0 10.1.1.0/24 Direct 0 0 D 10.1.1.1 GigabitEthernet0/2/0 10.1.1.1/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/2/0 10.1.1.2/32 Direct 0 0 D 10.1.1.2 GigabitEthernet0/2/0 192.168.1.0/24 Direct 0 0 D 192.168.1.11 GigabitEthernet0/1/0 192.168.1.11/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/1/0
[~DeviceB] display ip routing-table vpn-instance r2
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole route ------------------------------------------------------------------------------ Routing Tables: r2 Destinations : 6 Routes : 6 Destination/Mask Proto Pre Cost Flags NextHop Interface 0.0.0.0/0 Static 60 0 RD 192.168.1.1 GigabitEthernet0/3/0 10.2.1.0/24 Direct 0 0 D 10.2.1.1 GigabitEthernet0/1/8 10.2.1.1/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/1/8 10.2.1.2/32 Direct 0 0 D 10.2.1.2 GigabitEthernet0/1/8 192.168.1.0/24 Direct 0 0 D 192.168.1.12 GigabitEthernet0/3/0 192.168.1.12/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/3/0
# Run the display ip routing-table command on DeviceA. The command output shows that the IP routing table on DeviceA contains the routes to the two local networks.
[~DevicerA] display ip routing-table
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole route ------------------------------------------------------------------------------ Routing Tables: Public Destinations : 8 Routes : 8 Destination/Mask Proto Pre Cost Flags NextHop Interface 10.1.1.0/24 BGP 255 0 D 192.168.1.11 GigabitEthernet0/1/0 10.1.1.2/32 BGP 255 0 D 192.168.1.11 GigabitEthernet0/1/0 10.2.1.0/24 BGP 255 0 D 192.168.1.12 GigabitEthernet0/1/0 10.2.1.2/32 BGP 255 0 D 192.168.1.12 GigabitEthernet0/1/0 127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0 127.0.0.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0 192.168.1.0/24 Direct 0 0 D 192.168.1.1 GigabitEthernet0/1/0 192.168.1.1/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/1/0
Devices on the two local networks, Network A and Network B, can ping each other.
Configuration Files
DeviceA configuration file
#
sysname DeviceA
#
interface GigabitEthernet0/1/0
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
bgp 100
peer 192.168.1.11 as-number 200
peer 192.168.1.12 as-number 200
#
ipv4-family unicast
undo synchronization
peer 192.168.1.11 enable
peer 192.168.1.12 enable
#
return
DeviceB configuration file
#
sysname DeviceB
#
ip vpn-instance r1
ipv4-family
route-distinguisher 100:1
#
ip vpn-instance r2
ipv4-family
route-distinguisher 100:2
#
interface GigabitEthernet0/1/0
undo shutdown
ip binding vpn-instance r1
ip address 192.168.1.11 255.255.255.0
#
interface GigabitEthernet0/3/0
undo shutdown
ip binding vpn-instance r2
ip address 192.168.1.12 255.255.255.0
#
interface GigabitEthernet0/2/0
undo shutdown
ip binding vpn-instance r1
ip address 10.1.1.1 255.255.255.0
#
interface GigabitEthernet0/1/8
undo shutdown
ip binding vpn-instance r2
ip address 10.2.1.1 255.255.255.0
#
bgp 200
router-id 100.1.1.1
#
ipv4-family unicast
undo synchronization
#
ipv4-family vpn-instance r1
import-route direct
peer 192.168.1.1 as-number 100
#
ipv4-family vpn-instance r2
import-route direct
peer 192.168.1.1 as-number 100
#
ip route-static vpn-instance r1 0.0.0.0 0.0.0.0 192.168.1.1
ip route-static vpn-instance r2 0.0.0.0 0.0.0.0 192.168.1.1
#
return
DeviceC configuration file
#
sysname DeviceC
#
interface GigabitEthernet 0/2/0
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 10.1.1.1
#
return
DeviceD configuration file
#
sysname DeviceD
#
interface GigabitEthernet 0/1/8
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 10.2.1.1
#
Return
Example for Configuring an IP Address with a 31-bit Mask
This section provides an example for configuring an IP address with a 31-bit mask.
Networking Requirements
As shown in Figure 9-7, Device A and Device B are directly connected through a PPP link. To allow Device A and Device B to communicate, configure IP addresses with a 31-bit mask for the interfaces that connect Device A and Device B.
Configuration Roadmap
The configuration roadmap is as follows:
Configure an IP address with a 31-bit mask for GE 0/1/0 on DeviceA.
Configure an IP address with a 31-bit mask for GE 0/1/0 on DeviceB.
Data Preparation
To complete the configuration, you need the following data:
IP address and subnet mask of GE 0/1/0 on DeviceA
IP address and subnet mask of GE 0/1/0 on DeviceB
Procedure
- Configure an IP address for each interface.
# Configure an IP address for GE 0/1/0 on DeviceA.
<HUAWEI> system-view
[~HUAWEI] sysname DeviceA
[*HUAWEI] commit
[~DeviceA] interface GigabitEthernet 0/1/0
[~DeviceA-GigabitEthernet0/1/0] ip address 10.1.1.1 31
[*DeviceA-GigabitEthernet0/1/0] undo shutdown
[*DeviceA-GigabitEthernet0/1/0] commit
[~DeviceA-GigabitEthernet0/1/0] quit
# Configure an IP address for GE 0/1/0 on DeviceB.
<HUAWEI> system-view
[~HUAWEI] sysname DeviceB
[*HUAWEI] commit
[~DeviceB] interface GigabitEthernet 0/1/0
[~DeviceB-GigabitEthernet0/1/0] ip address 10.1.1.0 31
[*DeviceB-GigabitEthernet0/1/0] undo shutdown
[*DeviceB-GigabitEthernet0/1/0] commit
[~DeviceB-GigabitEthernet0/1/0] quit
- Verify the configuration.
# After the configuration is complete, check the routing table on DeviceA. The command output shows that both the network address and the broadcast address of the network segment are used as host addresses.
[~DeviceA] display ip routing-table
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.1.1.0/31 Direct 0 0 D 10.1.1.1 GigabitEthernet0/1/0
10.1.1.0/32 Direct 0 0 D 10.1.1.0 GigabitEthernet0/1/0
10.1.1.1/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/1/0
127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0
127.0.0.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0
# After the configuration is complete, check the routing table on DeviceB. In the routing table, you can view that both the network address and the broadcast address of the network segment are used as host addresses.
[~DeviceB] display ip routing-table
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
Routing Tables: _public_
Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.1.1.0/31 Direct 0 0 D 10.1.1.0 GigabitEthernet0/1/0
10.1.1.0/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/1/0
10.1.1.1/32 Direct 0 0 D 10.1.1.1 GigabitEthernet0/1/0
127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0
127.0.0.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0
- Overview of IPv4
- Limitations for Basic IPv4
- Configuring IP Addresses on an Interface
- Configuring IP Address Negotiation on Interfaces
- Configuring IP Address Unnumbered on an Interface
- Configuring IPv4 Protocol Stack Security
- Configuring TCP
- Disabling the IP Address Conflict Detection Function and Configuring the Preemption Function
- Configuring the Policy for Sending and Receiving Host Packets
- Configuring Forced IPv4 Packet Fragmentation
- Enabling the Sending of FibMiss Packets to the Interface Board's CPU
- Configuring Fast ICMP Reply
- Configuring Fast Refreshing of Routes with Single Next Hops
- (Optional) Enabling Hardware Copy
- Maintaining IPv4
- Configuration Examples for IPv4