HP VPN Firewall Appliances

Transcription

1 HP VPN Firewall Appliances High Availability Configuration Guide Part number: Software version: F1000-A-EI/F1000-S-EI (Feature 3726) F1000-E (Release 3177) F5000 (Feature 3211) F5000-S/F5000-C (Release 3808) VPN firewall modules (Release 3177) 20-Gbps VPN firewall modules (Release 3817) Document version: 6PW

2 Legal and notice information Copyright 2013 Hewlett-Packard Development Company, L.P. No part of this documentation may be reproduced or transmitted in any form or by any means without prior written consent of Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this material. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

3 Contents High availability overview 1 Availability requirements 1 Availability evaluation 1 High availability technologies 2 Fault detection technologies 2 Protection switchover technologies 3 Configuring VRRP 4 VRRP overview 4 VRRP standard mode 5 Configuring IPv4 VRRP in the Web interface 10 Recommended configuration procedure 10 Creating a VRRP group 11 Configuring a VRRP group 12 Configuring IPv4 VRRP at the CLI 16 IPv4 VRRP configuration task list 16 Specifying the type of MAC addresses mapped to virtual IP addresses 16 Creating a VRRP group and assigning virtual IP address 17 Configuring router priority, preemptive mode and tracking function 18 Configuring VRRP packet attributes 19 Enabling the trap function for VRRP 20 Displaying and maintaining VRRP for IPv4 20 Configuring IPv6 VRRP at the CLI 21 VRRP for IPv6 configuration task list 21 Specifying the type of MAC addresses mapped to virtual IPv6 addresses 21 Creating a VRRP group and configuring a virtual IPv6 address 22 Configuring router priority, preemptive mode and tracking function 23 Configuring VRRP packet attributes 24 Displaying and maintaining VRRP for IPv6 24 IPv4 VRRP configuration examples 25 Single VRRP group configuration example (in the Web interface) 25 Single VRRP group configuration example (at the CLI) 28 VRRP interface tracking configuration example 31 Multiple VRRP groups configuration example (in the Web interface) 34 Multiple VRRP groups configuration example (at the CLI) 37 IPv6 VRRP configuration examples 40 Single VRRP group configuration example 40 VRRP interface tracking configuration example 43 Multiple VRRP groups configuration example 46 Troubleshooting VRRP 49 The screen frequently displays error prompts 49 Multiple masters appear in a VRRP group 49 Frequent VRRP state transition 50 Configuring stateful failover 51 Stateful failover overview 51 Operating procedure 51 Service backup 52 Configuration synchronization 52 Stateful failover states 52 i

4 Configuration guidelines 53 Configuring stateful failover in the Web interface 54 Configuring stateful failover 54 Stateful failover configuration example 56 Configuring stateful failover at the CLI 58 Stateful failover configuration task list 58 Enabling stateful failover 58 Enabling automatic configuration synchronization 59 Configuring a failover interface and a backup VLAN 59 Displaying and maintaining stateful failover 60 Stateful failover configuration example 60 Configuring IPC 62 Overview 62 Node 62 Link 62 Channel 62 Packet sending modes 63 Enabling IPC performance statistics 63 Displaying and maintaining IPC 64 Configuring Track 65 Overview 65 Collaboration fundamentals 65 Collaboration application example 66 Collaboration application example on an AC 66 Track configuration task list 67 Associating the Track module with a detection module 67 Associating Track with NQA 67 Associating Track with BFD 68 Associating Track with interface management 69 Associating the Track module with an application module 70 Associating Track with VRRP 70 Associating Track with static routing 71 Associating Track with PBR 72 Associating Track with interface backup 73 Displaying and maintaining track entries 74 Track configuration examples 74 VRRP-Track-NQA collaboration configuration example 74 Configuring BFD for a VRRP backup to monitor the master 78 Configuring BFD for the VRRP master to monitor the uplink 81 Static routing-track-nqa collaboration configuration example 85 VRRP-Track-interface management collaboration configuration example 90 Configuring a collaboration group 93 Overview 93 Configuring a collaboration group in the web interface 94 Assigning interfaces to a collaboration group 94 Viewing the status of a collaboration group and its member ports 95 Collaboration group configuration example 96 Configuring a collaboration group at the CLI 98 Configuring a collaboration group 98 Displaying and maintaining collaboration group 98 Collaboration group configuration example 99 ii

5 Configuring NQA 100 Overview 100 Collaboration 100 Threshold monitoring 101 NQA configuration task list 102 Configuring the NQA server 102 Configuring the NQA client 103 Enabling the NQA client 103 Configuring an ICMP echo operation 103 Configuring a DHCP operation 104 Configuring a DNS operation 105 Configuring an FTP operation 105 Configuring an HTTP operation 106 Configuring a UDP jitter operation 107 Configuring an SNMP operation 109 Configuring a TCP operation 109 Configuring a UDP echo operation 110 Configuring a voice operation 111 Configuring a DLSw operation 113 Configuring optional parameters for an NQA operation 114 Configuring the collaboration function 115 Configuring threshold monitoring 116 Configuring the NQA statistics function 119 Configuring NQA history records saving function 119 Scheduling an NQA operation 120 Displaying and maintaining NQA 121 NQA configuration examples 121 ICMP echo operation configuration example 121 DHCP operation configuration example 123 DNS operation configuration example 124 FTP operation configuration example 125 HTTP operation configuration example 127 UDP jitter operation configuration example 128 SNMP operation configuration example 130 TCP operation configuration example 132 UDP echo operation configuration example 133 Voice operation configuration example 135 DLSw operation configuration example 137 NQA collaboration configuration example 138 Configuring Ethernet link aggregation 141 Overview 141 Basic concepts 141 Aggregating links in static mode 144 Aggregating links in dynamic mode 145 Load sharing criteria for link aggregation groups 147 Configuration restrictions and guidelines 147 Configuring Ethernet link aggregation in the Web interface 147 Configuring a Layer 2 static aggregation group 147 Displaying information about a Layer 2 aggregate interface 148 Layer 2 static link aggregation configuration example 149 Configuring Ethernet link aggregation at the CLI 152 Ethernet link aggregation configuration task list 152 Configuring an aggregation group 153 Configuring an aggregate interface 156 iii

6 Configuring load sharing criteria for link aggregation groups 160 Displaying and maintaining Ethernet link aggregation 161 Ethernet link aggregation configuration examples 162 Configuring interface backup 173 Feature and hardware compatibility 173 Overview 173 Active and standby interfaces 174 How interface backup works 174 Interface backup configuration task list 175 Configuring interface backup 175 Configuring active/standby mode 175 Associating an interface with a track entry 176 Configuring load balancing 177 Displaying and maintaining interface backup 177 Interface backup configuration examples 178 Multi-interface backup configuration example 178 Multi-interface load balancing configuration example 179 Configuring load balancing 182 Feature and hardware compatibility 182 Overview 182 Working mechanism of server load balancing 183 NAT-mode server load balancing 183 DR-mode server load balancing 185 Working mechanism of firewall load balancing 186 Working mechanism of link load balancing 188 Outbound link load balancing 188 Inbound link load balancing 189 Configuring server/firewall load balancing 190 configuration considerations 190 Recommended configuration procedure 191 Configuring public parameters 192 Configuring a health monitoring method 192 Creating a real service group 195 Creating a real service 200 Stopping service or enabling slow-offline 201 Creating a virtual service for server load balancing 202 Displaying server load balancing statistics 205 Configuring link load balancing 206 Configuration considerations 206 Recommended configuration procedure 208 Configuring public parameters 209 Configuring a health monitoring method 210 Creating a physical link 212 Configuring the best performing link function 214 Creating a logical link group 217 Creating a logical link 219 Stopping service or enabling slow-offline 220 Stopping scheduling for a logical link 221 Creating a virtual service 222 Displaying link load balancing statistics 225 Configuring DNS redirection and DNS TTL 226 Configuring a DNS entry 227 Load balancing configuration examples 228 iv

7 Server load balancing configuration example 228 Firewall load balancing configuration example 232 Outbound link load balancing configuration example 236 Inbound link load balancing configuration example 241 Configuring BFD 246 Feature and hardware compatibility 246 Overview 246 How BFD works 247 BFD packet format 249 Supported features 250 Protocols and standards 251 Configuring BFD basic functions 251 Configuration prerequisites 251 Configuration procedure 251 Enabling trap 253 Displaying and maintaining BFD 253 Support and other resources 254 Contacting HP 254 Subscription service 254 Related information 254 Documents 254 Websites 254 Conventions 255 Index 257 v

8 High availability overview Because communication interruptions can seriously affect widely-deployed value-added services such as IPTV and video conference, basic network infrastructures must be able to provide high availability. The following are the effective ways to improve availability: Increasing fault tolerance. Speeding up fault recovery. Reducing impact of faults on services. Availability requirements Table 1 describes a typical availability model that divides availability requirements into different levels. Table 1 Availability requirements Level Requirement Solution Decrease system software and hardware faults Protect system functions from being affected if faults occur Enable the system to recover as fast as possible Hardware Simplified circuit design, enhanced production techniques, and reliability tests. Software Reliability design and test. Device and link redundancy and switchover. Performing fault detection, diagnosis, isolation, and recovery technologies. Consider level 1 availability requirements during the design and production processes of network devices. Consider level 2 availability requirements during network design. Consider level 3 availability requirements during network deployment, according to the network infrastructure and service characteristics. Availability evaluation MTBF MTTR Mean Time Between Failures (MTBF) and Mean Time to Repair (MTTR) are used to evaluate the availability of a network. MTBF is the predicted elapsed time between inherent failures of a system during operation. It is typically in the unit of hours. A higher MTBF means a high availability. MTTR is the average time required to repair a failed system. MTTR in a broad sense also involves spare parts management and customer services. 1

9 MTTR = fault detection time + hardware replacement time + system initialization time + link recovery time + routing time + forwarding recovery time. A smaller value of each item means a smaller MTTR and a higher availability. High availability technologies Increasing MTBF or decreasing MTTR can enhance the availability of a network. The high availability technologies described in this section meet the level 2 and level 3 high availability requirements in the aspect of decreasing MTTR. High availability technologies can be classified as fault detection technologies or protection switchover technologies. Fault detection technologies Fault detection technologies enable detection and diagnosis of network faults: BFD is a generic fault detection technology that can be used at any layer. NQA is used for diagnosis and evaluation of network quality. Collaboration group is used to implement fast link switchover based on correlated interface states. Track works along with other high availability technologies to detect faults through a collaboration mechanism. Table 2 Fault detection technologies Technology Introduction Reference BFD NQA Collaboration group Track BFD provides a single mechanism to quickly detect and monitor the connectivity of links or IP forwarding in networks. To improve network performance, devices must quickly detect communication failures to restore communication through backup paths as soon as possible. NQA analyzes network performance, services and service quality through sending test packets, and provides you with network performance and service quality parameters such as jitter, TCP connection delay, FTP connection delay and file transfer rate. A collaboration group is a group of ports that change their state to up or down in a synchronized way. For example, if one port in the group goes down, all the other ports go down to stop forwarding traffic. This feature enables the ports on a traffic path to adapt their up/down state to each other for fast link switchover. The Track module implements collaboration between different modules. The collaboration involves three sets of modules: application, Track, and detection. These modules collaborate with one another through collaboration entries. The detection modules trigger the application modules to perform certain operations through the Track module. The detection modules probe such items as link status and network performance, and inform the application modules of the detection result through the Track module. Once notified of network status changes, the application modules use the changes to avoid communication interruption and network performance degradation. "Configuring BFD" "Configuring NQA" "Configuring a collaboration group" "Configuring Track" 2

10 Protection switchover technologies Protection switchover technologies aim at recovering network faults. They back up hardware, link, routing, and service information for switchover in case of network faults to ensure continuity of network services. A single availability technology cannot solve all problems. You should use a combination of availability technologies, chosen on the basis of detailed analysis of network environments and user requirements, to enhance network availability. For example, access-layer devices should be connected to distribution-layer devices over redundant links, and core-layer devices should be fully meshed. Network availability should be considered during the planning stage. Table 3 Protection switchover technologies Technology Introduction Reference Interface backup Interface backup MSTP Stateful failover VRRP Interface backup allows interfaces on one device to back up one another. The main interface transmits services, and the backup interfaces are in the backup state. When the main interface fails or the link fails, a backup interface is brought up to transmit services, increasing network reliability. Interface backup allows interfaces on one device to back up one another. The main interface transmits services, and the backup interfaces are in the backup state. When the main interface fails or the link fails, a backup interface is brought up to transmit services, increasing network reliability. As a Layer 2 management protocol, MSTP eliminates Layer 2 loops by selectively blocking redundant links in a network, and in the meantime, allows for link redundancy. Two devices back up the services of each other to ensure that the services on them are consistent. If one device fails, the other device can take over the services by using VRRP or dynamic routing protocols. Because the other device has already backed up the services, service traffic can pass through the other device, avoiding service interruption. VRRP is an error-tolerant protocol, which provides highly reliable default links on multicast and broadcast LANs such as Ethernet, avoiding network interruption due to failure of a single link. "Configuring interface backup" "Configuring Ethernet link aggregation" Network Management Configuration Guide "Configuring stateful failover" "Configuring VRRP" 3

11 Configuring VRRP The interfaces that VRRP involves can be only Layer 3 Ethernet interfaces and subinterfaces, VLAN interfaces, and Layer 3 aggregate interfaces unless otherwise specified. VRRP cannot be configured on an interface of an aggregation group. The term "router" in this document refers to both routers and routing-capable firewalls and firewall modules. VRRP overview As shown in Figure 1, you can typically configure a default route with the gateway as the next hop for every host on a LAN. All packets destined to other network segments are sent over the default route to the gateway, which then forwards the packets. However, when the gateway fails, all the hosts that use the gateway as the default next-hop router fail to communicate with external networks. Figure 1 LAN networking Configuring a default route for network hosts facilitates your configuration, but also requires high performance stability of the device that acts as the gateway. Using more egress gateways is a common way to improve system reliability, but introduces the problem of routing among the egresses. Virtual Router Redundancy Protocol (VRRP) is designed to address this problem. VRRP adds a group of routers that can act as network gateways to a VRRP group, which forms a virtual router. Routers in the VRRP group elect a master through the VRRP election mechanism to act as a gateway, and hosts on a LAN only need to configure the virtual router as their default network gateway. VRRP is an error-tolerant protocol, which improves the network reliability and simplifies configurations on hosts. On a multicast and broadcast LAN such as Ethernet, VRRP provides highly reliable default links without configuration changes (such as dynamic routing protocols, route discovery protocols) when a router fails, and prevent network interruption due to a single link failure. VRRP can operate in only standard mode, which includes IETF VRRPv2 for IPv4 and VRRPv3 for IPv6. For more information, see "VRRP standard mode." 4

12 VRRP standard mode VRRP group VRRP combines a group of routers (including a master and multiple backups) on a LAN into a virtual router called VRRP group. A VRRP group has the following features: A virtual router has a virtual IP address. A host on the LAN only needs to know the IP address of the virtual router and uses the IP address as the next hop of the default route. Every host on the LAN communicates with external networks through the virtual router. Routers in the VRRP group elect a master that acts as the gateway according to their priorities. The other routers function as the backups. When the master fails, to make sure that the hosts in the network segment can communicate without interruption with the external networks, the backups in the VRRP group elect a new gateway to take the responsibility for the failed master. Figure 2 Network diagram As shown in Figure 2, Router A, Router B, and Router C form a virtual router, which has its own IP address. Hosts on the Ethernet use the virtual router as the default gateway. The router with the highest priority among the three routers is elected as the master to act as the gateway, and the other two are backups. The IP address of the virtual router can be either an unused IP address on the segment where the VRRP group resides or the IP address of an interface on a router in the VRRP group. In the latter case, the router is called the IP address owner. Only one IP address owner can be configured for a VRRP group. Statuses of a router in a VRRP group include master, backup, and initialize. 1. VRRP priority VRRP determines the role (master or backup) of each router in a VRRP group by priority. A router with a higher priority is more likely to become the master. VRRP priority is in the range of 0 to 255, and the greater the number, the higher the priority. Priorities 1 to 254 are configurable. Priority 0 is reserved for special uses and priority 255 is for 5

13 VRRP timers Packet format the IP address owner. The router acting as the IP address owner in a VRRP group always has the running priority 255 and acts as the master as long as it works correctly. 2. Working mode A router in a VRRP group operates in either of the following modes: Non-preemptive mode When a router in the VRRP group becomes the master, it stays as the master as long as it operates correctly, even if a backup is assigned a higher priority later. Preemptive mode When a backup finds its priority higher than that of the master, the backup sends VRRP advertisements to start a new master election in the VRRP group and becomes the master. Accordingly, the original master becomes a backup. 3. Authentication mode To avoid attacks from unauthorized users, VRRP member routers add authentication keys in VRRP packets to authenticate one another. VRRP provides the following authentication modes: simple Simple text authentication: The sender fills an authentication key into the VRRP packet, and the receiver compares the received authentication key with its local authentication key. If the two authentication keys are the same, the received VRRP packet is legitimate. Otherwise, the received packet is illegitimate. md5 MD5 authentication: The sender computes a digest for the packet to be sent by using the authentication key and MD5 algorithm and saves the result in the authentication header. The receiver performs the same operation by using the authentication key and MD5 algorithm, and compares the result with the content in the authentication header. If the results are the same, the received VRRP packet is legitimate. Otherwise, the received packet is illegitimate. On a secure network, you can choose to not authenticate VRRP packets. VRRP timers include VRRP advertisement interval and VRRP preemption delay timer. 1. VRRP advertisement interval The master in a VRRP group periodically sends VRRP advertisements to inform the other routers in the VRRP group that it operates correctly. You can adjust the interval for sending VRRP advertisements by setting the VRRP advertisement interval. If a backup receives no advertisements in a period three times the interval, the backup regards itself as the master and sends VRRP advertisements to start a new master election. 2. VRRP preemption delay timer To avoid frequent state changes among members in a VRRP group and provide the backups enough time to collect information (such as routing information), each backup waits for a period of time called the preemption delay time. The backup waits this period of time after it receives an advertisement with the priority lower than the local priority, then it sends VRRP advertisements to start a new master election in the VRRP group and becomes the master. The master periodically multicasts VRRP packets to declare its presence. VRRP packets are also used for checking the parameters of the virtual router and electing the master. VRRP packets are encapsulated in IP packets, with the protocol number being 112. Figure 3 shows the VRRPv2 packet format and Figure 4 shows the VRRPv3 packet format. 6

14 Figure 3 VRRPv2 packet format Figure 4 VRRPv3 packet format Version Type Virtual Rtr ID Priority Count IPv6 Addrs Auth Type Adver Int Checksum IPv6 address 1... IPv6 address n Authentication data 1 Authentication data 2 A VRRP packet comprises the following fields: Version Version number of the protocol, 2 for VRRPv2 and 3 for VRRPv3. Type Type of the VRRPv2 or VRRPv3 packet. It must be VRRP advertisement, represented by 1. Virtual Rtr ID (VRID) ID of the virtual router. It ranges from 1 to 255. Priority Priority of the router in the VRRP group, in the range 0 to 255. A greater value represents a higher priority. Count IP Addrs/Count IPv6 Addrs Number of virtual IPv4 or IPv6 addresses for the VRRP group. A VRRP group can have multiple virtual IPv4 or IPv6 addresses. Auth Type Authentication type. 0 means no authentication, 1 means simple text authentication, and 2 means MD5 authentication. VRRPv3 does not support MD5 authentication. Adver Int Interval for sending advertisement packets. For VRRPv2, the interval is in seconds and defaults to 1. For VRRPv3, the interval is in centiseconds and defaults to 100. Checksum 16-bit checksum for validating the data in VRRP packets. 7

15 VRRP principles VRRP tracking IP Address/IPv6 Address Virtual IPv4 or IPv6 address entry of the VRRP group. The Count IP Addrs or Count IPv6 Addrs field defines the number of virtual IPv4 or IPv6 addresses. Authentication Data Authentication key. This field is used only for simple authentication and is 0 for any other authentication mode. Routers in a VRRP group determine their roles by priority. The router with the highest priority is the master, and the others are the backups. The master periodically sends VRRP advertisements to notify the backups that it is working correctly, and each of the backups starts a timer to wait for advertisements from the master. In preemptive mode, when a backup receives a VRRP advertisement, it compares the priority in the packet with its own priority. If the priority of the backup is higher, the backup becomes the master. Otherwise, it remains as a backup. In preemptive mode, a VRRP group always has the router with the highest priority as the master for forwarding packets. In non-preemptive mode, a backup with higher priority than the master does not preempt the master if the master is correctly working. The non-preemptive mode avoids frequent switchover between the master and backups. If the timer of a backup expires but the backup still does not receive any VRRP advertisement, it considers that the master failed. In this case, the backup considers itself as the master and sends VRRP advertisements to start a new master election. When multiple routers in a VRRP group declare that they are the master because of inconsistent configuration or network problems, the one with the highest priority becomes the master. If two routers have the same priority, the one with the highest IP address becomes the master. When a backup router receives an advertisement, it compares its priority with the advertised priority. If its priority is higher, it takes over the master. To enable VRRP tracking, first configure the routers in the VRRP group to operate in preemptive mode, so that the router with the highest priority always operates as the master for forwarding packets. 1. Tracking a specified interface The interface tracking function expands the backup functionality of VRRP. It provides backup not only when the interface to which a VRRP group is assigned fails, but also when other interfaces (such as uplink interfaces) on the router become unavailable. If the uplink interface of a router in a VRRP group fails, usually the VRRP group cannot be aware of the uplink interface failure. If the router is the master of the VRRP group, hosts on the LAN are not able to access external networks because of the uplink failure. This problem can be solved by tracking a specified uplink interface. If the tracked uplink Layer 3 interface (configured with an IP address) is down or removed, the priority of the master is automatically decreased by a specified value and a higher priority router in the VRRP group becomes the master. 2. Tracking a track entry By monitoring a track entry, you can do the following: Monitor an uplink and change the priority of the router according to the uplink state. If the uplink fails, hosts in the LAN cannot access external networks through the router. The state of the monitored track entry is negative and the priority of the router decreases by a specified value. Then, a higher priority router in the VRRP group becomes the master to maintain the proper communication between the hosts in the LAN and external networks. Monitor the master on a backup. 8

16 When the master fails, the backup immediately takes over to maintain normal communication. For more information about track entries, see "Configuring Track." VRRP application (taking IPv4-based VRRP for example) 1. Master/backup In master/backup mode, only the master forwards packets. When the master fails, a new master is elected from the backups. This mode requires only one VRRP group, in which each router holds a different priority and the one with the highest priority becomes the master. Figure 5 VRRP in master/backup mode Assume that Router A is acting as the master to forward packets to external networks, and Router B and Router C are backups in listening state. When Router A fails, Router B and Router C elect a new master to forward packets for hosts on the LAN. 2. Load sharing More than one VRRP group can be created on an interface of a router to allow the router to be the master of one VRRP group but a backup of another at the same time. In load sharing mode, multiple routers provide services simultaneously. This mode requires two or more VRRP groups, each of which comprises a master and one or more backups. The masters of the VRRP groups are assumed by different routers. 9

17 Figure 6 VRRP in load sharing mode A router can be in multiple VRRP groups and hold a different priority in a different group. As shown in Figure 6, the following VRRP groups are present: VRRP group 1 Router A is the master. Router B and Router C are the backups. VRRP group 2 Router B is the master. Router A and Router C are the backups. VRRP group 3 Router C is the master. Router A and Router B are the backups. For load sharing among Router A, Router B, and Router C, hosts on the LAN need to be configured to use VRRP group 1, 2, and 3 as the default gateways, respectively. When configuring VRRP priorities, make sure that each router holds such a priority in each VRRP group so that it will take the expected role in the group. Configuring IPv4 VRRP in the Web interface Recommended configuration procedure Step Remarks Required. Create a VRRP group on a VRRP interface and configure the virtual IP address. 1. Creating a VRRP group IMPORTANT: Before creating a VRRP group on an interface, you should first configure an IP address for the interface and make sure that the virtual IP address to be configured is in the same network segment as the IP address of the interface. The maximum number of VRRP groups on an interface and the maximum number of virtual IP addresses in a VRRP group vary by devices. 10

18 Step 2. Configuring a VRRP group Remarks Optional. Configure router priority, preemption mode, authentication mode, packet attributes, and tracking function of the VRRP group. Creating a VRRP group 1. Select High Reliability > VRRP from the navigation tree. The VRRP interfaces page appears. Figure 7 VRRP interfaces page 2. Click the icon corresponding to the interface to be configured. The VRRP group page appears. Figure 8 VRRP group page On the VRRP group configuration page, Run Priority indicates current priority of the router, which changes according to the status of the tracked interface or track entry (if configured). Status indicates status of the router (master, backup, or initialize) in the VRRP group. 3. Click Add. The page for creating a VRRP group appears. 11

19 Figure 9 Creating a VRRP group 4. Enter the group number of the VRRP group (VRID). 5. Enter the virtual IP address of the VRRP group, and click Add to add the virtual IP address to the Virtual IP Members field. If the VRRP interface connects to multiple subnets, you can configure multiple virtual IP addresses for the VRRP group to implement router backup on different subnets. The virtual IP address cannot be all 0s ( ), a broadcast address ( ), a loopback address, any other invalid IP address (like ), or an address that does not belong to class A, B, or C. The virtual IP address can be either an unused IP address on the segment where the VRRP group resides or the IP address of an interface on a router in the VRRP group. In the latter case, the router is called the "IP address owner." Removal of the VRRP group on the IP address owner will cause IP address collision. Therefore, you can modify the IP address of the interface on the IP address owner to resolve the collision. The VRRP group can operate correctly only when the virtual IP address is valid and on the same network segment with the interface IP address. If the configured virtual IP address and the interface IP address do not belong to the same network segment, or the configured IP address is the network address or network broadcast address of the network segment to which the interface IP address belongs, the state of the VRRP group is not always initialize though you can perform the configuration successfully. VRRP does not take effect in this case. 6. Click Apply. Configuring a VRRP group 1. Select High Availability > VRRP from the navigation tree. The VRRP interfaces page appears. 2. Click the icon corresponding to the interface to be configured. The VRRP group page appears. 3. Click the icon corresponding to the VRRP group to be configured. The page for modifying the VRRP group configuration appears. 12

20 Figure 10 Modifying the VRRP group configuration 4. Configure the parameters as described in Table 4. Table 4 Configuration items Item VRID Description Display group number of the VRRP group. Configure the virtual IP address of the VRRP group. If an interface connects to multiple subnets, you can configure multiple virtual IP addresses for the VRRP group to implement router backup on different subnets. Virtual IP IMPORTANT: The virtual IP address cannot be , , a loopback address, any other invalid IP address (like ), or an address that does not belong to class A, B or C. The virtual IP address can be either an unused IP address on the segment where the VRRP group resides or the IP address of an interface on a router in the VRRP group. In the latter case, the router is called the "IP address owner." Removal of the VRRP group on the IP address owner will cause IP address collision. Therefore, you can modify the IP address of the interface on the IP address owner to resolve the collision. The VRRP group can operate correctly only when the configured virtual IP address and the interface IP address belong to the same segment and are valid host addresses. If the configured virtual IP address and the interface IP address do not belong to the same network segment, or the configured IP address is the network address or network broadcast address of the network segment to which the interface IP address belongs, the state of the VRRP group is not always initialize though you can perform the configuration successfully, that is, VRRP does not take effect in this case. 13

21 Item Description Set the priority of the routers in a VRRP group. The greater the value, the higher the priority. Priority Preempt Mode Delay Authentication Key IMPORTANT: VRRP determines the role (master or backup) of each router in the VRRP group by priority. A router with a higher priority has more opportunity to become the master. VRRP priority is in the range of 0 to 255. Priority 0 is reserved for special uses and priority 255 for the IP address owner. When a router acts as the IP address owner, its priority is always 255. That is, the IP address owner in a VRRP group acts as the master as long as it works correctly. Set the working mode of the VRRP group: Preemptive After setting the preempt mode to Preemptive, you need to configure the preemption delay time. Non-preemptive Non-preemptive mode. IMPORTANT: An IP address owner always operates in preemptive mode. Set the authentication mode and plain text authentication key of the VRRP group: Null No authentication and no authentication key. Simple Simple text authentication. In this case, you need to configure a plain text authentication key. MD5 MD5 authentication. In this case, you need to configure a plain text authentication key. IMPORTANT: You can configure different authentication modes and authentication keys for the VRRP groups on an interface. However, the members of the same VRRP group must use the same authentication mode and authentication key. Set the interval at which the master sends VRRP advertisements. Advertise Time Excessive traffic or different timer setting on routers can cause the Backup timer to time out abnormally and trigger a change of the state. To solve this problem, you can prolong the time interval to send VRRP packets. IMPORTANT: Routers in the same VRRP group must use the same setting of advertisement interval. 5. Click Display Track Config to expand the configuration items of the tracking function. 14

22 Figure 11 Modifying the VRRP group configuration 6. Configure the parameters as described in Table Click Apply. Table 5 Configuration items Item Track Object Object Reduced Priority Switchover Description Configure the track object function by adding the Track object to be monitored and the processing method: Object Specify the serial number of the Track object to be monitored. You can specify an uncreated object. Reduced Priority If the status of the monitored Track object changes to negative, the priority of the router decreases by a specified value. Switchover If the status of the monitored Track object changes to negative, the router immediately switches to the master. IMPORTANT: The configuration takes effect only when the router is not the IP address owner. When the status of the monitored Track object turns from negative to positive, the corresponding router automatically restores its priority. In the list box of added Track object, the Priority/Switchover column displays a value or the letter S, where the value represents the decreased value of the router priority, and S represents the switchover mode. 15

23 Item Track Interface Interface Reduced Priority Description Configure the track interface function by adding the specified interface to be monitored and the processing method. Interface Name of the interface to be tracked. Reduced Priority If the monitored interface state turns from up to down, the priority of the router decreases by a specified value. IMPORTANT: The configuration takes effect only when the router is not the IP address owner. When the status of the tracked interface turns from down or removed to up, the corresponding router automatically restores its priority. The specified interface can be a Layer 3 Ethernet interface, a VLAN interface, a Layer 3 aggregate interface, or an MP-group interface. Configuring IPv4 VRRP at the CLI IPv4 VRRP configuration task list To form a VRRP group, perform the following configurations on each firewall in the VRRP group. Complete these tasks to configure VRRP for IPv4: Task Specifying the type of MAC addresses mapped to virtual IP addresses Creating a VRRP group and assigning virtual IP address Configuring router priority, preemptive mode and tracking function Configuring VRRP packet attributes Enabling the trap function for VRRP Remarks Optional. Required. Optional. Optional. Optional. Specifying the type of MAC addresses mapped to virtual IP addresses You can configure VRRP in standard mode to map real or virtual MAC addresses to the virtual IP addresses of VRRP groups, so the master in a VRRP group uses the specified type of MAC address as the source MAC address for sending packets and answering ARP requests. Virtual MAC to virtual IP mapping By default, a virtual MAC address is automatically assigned when a VRRP group is created, and the virtual IP address of the VRRP group is mapped to the virtual MAC address. In this mapping method, the hosts do not need to update the gateway IP and MAC mapping entry when the master changes. Real MAC address of an interface If a VRRP group has an IP address owner, configure real MAC to virtual IP mapping to avoid the problem of one IP address mapped to two MAC addresses (the real and the virtual). In this method, the virtual IP address of the VRRP group is mapped to the real MAC address of the IP address owner, and all packets from hosts are forwarded to the IP address owner. 16

24 Specify the type of the MAC addresses mapped to the virtual IP addresses before creating a VRRP group. You cannot change the address mapping setting after a VRRP group is created. To specify the type of MAC addresses mapped to virtual IP addresses: Step Command Remarks 1. Enter system view. system-view N/A 2. Specify the type of MAC addresses mapped to virtual IP addresses. vrrp method { real-mac virtual-mac } Optional. Virtual MAC address by default. Creating a VRRP group and assigning virtual IP address Configuration guidelines You can configure multiple virtual IP addresses for the VRRP group on an interface that connects to multiple subnets for router backup on different subnets. The VRRP group is automatically created when you specify the first virtual IP address. If you later specify another virtual IP address for the VRRP group, the virtual IP address is added to the virtual IP address list of the VRRP group. The virtual IP address assigned to the VRRP group must be a legal host address and in the same subnet as the interface IP address. If not, the state of the VRRP group is always initialize and VRRP does not take effect. For example, although you can successfully configure a network address or broadcast address as the virtual IP address of a VRRP group, the group cannot work. The maximum number of virtual IP addresses in a VRRP group is 16. When VRRP operates in standard mode, the virtual IP address of a VRRP group can be either an unused IP address on the subnet where the VRRP group resides or the IP address of an interface on a router in the VRRP group. In the latter case, the router is called the IP address owner. When a router is the IP address owner in a VRRP group, HP recommends not configuring the network command on the interface to use the IP address of the interface, or the virtual IP address of the VRRP group, to establish a neighbor relationship with the adjacent router. For more information about the network command, see Network Management Command Reference. A VRRP group is removed after you remove all its virtual IP addresses, and all its configurations become invalid. Removal of the VRRP group on the IP address owner causes IP address collision. To avoid the collision, change the IP address of the interface on the IP address owner before you remove the VRRP group from the interface. The virtual IP address of a VRRP group cannot be , , loopback addresses, non-class A/B/C addresses or other illegal IP addresses such as Do not create VRRP groups in the VLAN interface of a super VLAN. Otherwise, network performance might be affected. Configuration prerequisites Before creating a VRRP group and configuring a virtual IP address on an interface, configure an IP address for the interface and make sure that it is in the same subnet as the virtual IP address. 17

25 Configuration procedure To create a VRRP group and configure a virtual IP address: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter the specified interface view. 3. Create a VRRP group and configure a virtual IP address for the VRRP group. interface interface-type interface-number vrrp vrid virtual-router-id virtual-ip virtual-address N/A VRRP group is not created by default. Configuring router priority, preemptive mode and tracking function Configuration guidelines The running priority of an IP address owner is always 255 and you do not need to configure it. An IP address owner always operates in preemptive mode. If you configure an interface to be tracked or a track entry to be monitored on a firewall that is the IP address owner in a VRRP group, the configuration does not take effect. If the firewall is not the IP address owner in the VRRP group later, the configuration takes effect. The tracked interface can be a Layer 3 Ethernet interface, a VLAN interface, a Layer 3 aggregate interface, or a dialer interface. The dialer interface must function as the PPPoE client and operate in the permanent online mode. If the state of a tracked interface changes from down or removed to up, the priority of the firewall where the interface resides is automatically restored. If the state of a track entry changes from negative or invalid to positive, the priority of the firewall where the track entry is configured is automatically restored. Configuration prerequisites Before you configure router priority, preemptive mode and tracking function, create a VRRP group on an interface and configure a virtual IP address for it. Configuration procedure By configuring router priority, preemptive mode, interface tracking, or a track entry, you can determine which firewall in the VRRP group serves as the master. To configure router priority, preemptive mode and the tracking function: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Configure router priority in the VRRP group. interface interface-type interface-number vrrp vrid virtual-router-id priority priority-value N/A Optional. The default is

26 Step Command Remarks 4. Configure the firewall in the VRRP group to operate in preemptive mode and configure preemption delay. 5. Configure the interface to be tracked. 6. Configure VRRP to track a specified track entry. vrrp vrid virtual-router-id preempt-mode [ timer delay delay-value ] vrrp vrid virtual-router-id track interface interface-type interface-number [ reduced priority-reduced ] vrrp vrid virtual-router-id track track-entry-number [ reduced priority-reduced switchover ] Optional. The firewall in the VRRP group operates in preemptive mode and the preemption delay is 0 seconds by default. Optional. By default, no interface is being tracked. Optional. By default, VRRP is not configured to track a specified track entry. Configuring VRRP packet attributes Configuration prerequisites Before you configure the relevant attributes of VRRP packets, create a VRRP group and configure a virtual IP address for it. Configuration guidelines You might configure different authentication modes and authentication keys for the VRRP groups on an interface. However, the members of the same VRRP group must use the same authentication mode and authentication key. Excessive traffic might cause a backup to trigger a change of its status because the backup does not receive any VRRP advertisements for a specified period of time. To solve this problem, increase the time interval to send VRRP advertisements. Configuring different intervals for sending VRRP advertisements on the firewalls in a VRRP group might cause a backup to trigger a change of its status. This is because the backup does not receive any VRRP advertisements for a specified period of time. To solve this problem, configure the same interval for sending VRRP advertisements on each firewall in the VRRP group. After you specify an interface as the source interface for sending VRRP packets, this interface, instead of the interface where the VRRP group resides, sends and receives VRRP packets. If you specify the interface where the VRRP group resides as the source interface for sending VRRP packets, the configuration does not take effect. Configuration procedure To configure VRRP packet attributes: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter the specified interface view. interface interface-type interface-number N/A 19

27 Step Command Remarks 3. Configure the authentication mode and authentication key when the VRRP groups send and receive VRRP packets. 4. Configure the time interval for the master in the VRRP group to send VRRP advertisements. vrrp vrid virtual-router-id authentication-mode { md5 simple } [ cipher ] key vrrp vrid virtual-router-id timer advertise adver-interval Optional. Authentication is not performed by default. Optional. 1 second by default. 5. Disable TTL check on VRRP packets. vrrp un-check ttl Optional. By default, TTL check on VRRP packets is enabled. You do not need to create a VRRP group before executing this command. Enabling the trap function for VRRP When the trap function is enabled for VRRP, VRRP generates traps with severity level errors to report its key events. The traps are sent to the information center of the device, where you can configure whether to output the trap information and the output destination. For information about configuring the information center, see System Management and Maintenance Configuration Guide. To enable the trap function for VRRP: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable the trap function for VRRP. snmp-agent trap enable vrrp [ authfailure newmaster ] Optional. By default, the trap function for VRRP is enabled. For more information about the command, see System Management and Maintenance Command Reference. Displaying and maintaining VRRP for IPv4 Task Command Remarks Display VRRP group status. Display VRRP group statistics. Clear VRRP group statistics. display vrrp [ verbose ] [ interface interface-type interface-number [ vrid virtual-router-id ] ] [ { begin exclude include } regular-expression ] display vrrp statistics [ interface interface-type interface-number [ vrid virtual-router-id ] ] [ { begin exclude include } regular-expression ] reset vrrp statistics [ interface interface-type interface-number [ vrid virtual-router-id ] ] Available in any view. Available in any view. Available in user view. 20

28 Configuring IPv6 VRRP at the CLI IPv6 VRRP can be configured only at the CLI. VRRP for IPv6 configuration task list Task Specifying the type of MAC addresses mapped to virtual IPv6 addresses Creating a VRRP group and configuring a virtual IPv6 address Configuring router priority, preemptive mode and tracking function Configuring VRRP packet attributes Remarks Optional. Required. Optional. Optional. Specifying the type of MAC addresses mapped to virtual IPv6 addresses After you specify the type of MAC addresses mapped to the virtual IPv6 address of VRRP groups and create a VRRP group, the master in the VRRP group uses the specified type of MAC address as the source MAC address for sending packets and uses the specified type of MAC address to answer ND requests from hosts so that the hosts in the internal network can learn the mapping between the IPv6 address and the MAC address. The following types of MAC addresses are available to be mapped to the virtual IPv6 address of a VRRP group: Virtual MAC address By default, a virtual MAC address is automatically created for a VRRP group when the VRRP group is created, and the virtual IPv6 address of the VRRP group is mapped to the virtual MAC address. When such a mapping is adopted, the hosts in the internal network do not need to update the mapping between the IPv6 address and the MAC address when the master changes. Real MAC address of an interface In case that an IP address owner exists in a VRRP group, if the virtual IPv6 address is mapped to the virtual MAC address, two MAC addresses are mapped to one IPv6 address. To avoid such as problem, map the virtual IPv6 address of the VRRP group to the real MAC address of an interface to forward the packets from a host to the IP address owner. Specify the type of the MAC addresses mapped to the virtual IPv6 addresses before creating a VRRP group. Otherwise, you cannot change the type of the MAC addresses mapped to virtual IPv6 addresses. To specify the type of MAC addresses mapped to virtual IPv6 addresses: Step Command Remarks 1. Enter system view. system-view N/A 2. Specify the type of MAC addresses mapped to virtual IPv6 addresses. vrrp ipv6 method { real-mac virtual-mac } Optional. Virtual MAC address by default. 21

29 Creating a VRRP group and configuring a virtual IPv6 address When creating a VRRP group, configure a virtual IPv6 address for the VRRP group. You can configure multiple virtual IPv6 addresses for a VRRP group. A VRRP group is automatically created when you specify the first virtual IPv6 address for the VRRP group. If you specify another virtual IPv6 address for the VRRP group later, the virtual IPv6 address is added to the virtual IPv6 address list of the VRRP group. Configuration prerequisites Before creating a VRRP group and configuring a virtual IPv6 address on an interface, configure an IPv6 address for the interface and make sure that it is in the same network segment as the virtual IPv6 address to be configured. Configuration guidelines When a router is the IP address owner in a VRRP group, HP recommends not using the IPv6 address of the interface (virtual IPv6 address of the VRRP group) to establish an OSPFv3 neighbor relationship with the adjacent router, that is, not using the ospfv3 area command to enable OSPFv3 on the interface. For more information about ospfv3 area command, see Network Management Command Reference. The maximum number of VRRP groups on an interface and the maximum number of virtual IPv6 addresses in a VRRP group are both 16. A VRRP group is removed after you remove all the virtual IPv6 addresses in it. In addition, configurations on that VRRP group do not take effect any longer. Removal of the VRRP group on the IP address owner causes IP address collision. To resolve the collision, change the IPv6 address of the interface on the IP address owner first and then remove the VRRP group from the interface. Configuration procedure To create a VRRP group and configure its virtual IPv6 address: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter the specified interface view. 3. Create a VRRP group and configure its virtual IPv6 address, which is a link local address. 4. Configure the VRRP group with a virtual IPv6 address, which is a global unicast address. interface interface-type interface-number vrrp ipv6 vrid virtual-router-id virtual-ip virtual-address link-local vrrp ipv6 vrid virtual-router-id virtual-ip virtual-address N/A No VRRP group is created by default. The first virtual IPv6 address of the VRRP group must be a link local address. Only one link local address is allowed in a VRRP group, and must be removed the last. Optional. By default, no global unicast address is configured as the virtual IPv6 address of a VRRP group. 22

30 Configuring router priority, preemptive mode and tracking function Configuration prerequisites Before you configure router priority, preemptive mode and tracking function, create a VRRP group and configure its virtual IPv6 address. Configuration guidelines The running priority of an IP address owner is always 255 and you do not need to configure it. An IP address owner always operates in preemptive mode. Interface tracking is not configurable on an IP address owner. If you configure an interface to be tracked or a track entry to be monitored on a firewall that is the IP address owner in a VRRP group, the configuration does not take effect. If the router is not the IP address owner in the VRRP group later, the configuration takes effect. The tracked interface can be a Layer 3 Ethernet interface, a VLAN interfaces or a Layer 3 aggregate interface. If the state of a tracked interface changes from down or removed to up, the priority of the firewall that owns the interface is automatically restored. If the state of a track entry changes from negative or invalid to positive, the priority of the firewall where the track entry is configured is automatically restored. Configuration procedure By configuring router priority, preemptive mode, interface tracking, or a track entry, determine which router in the VRRP group serves as the master. To configure router priority, preemptive mode and interface tracking: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter the specified interface view. 3. Configure the priority of the firewall in the VRRP group. 4. Configure the firewall in the VRRP group to operate in preemptive mode and configure preemption delay of the VRRP group. 5. Configure the interface to be tracked. 6. Configure VRRP to track a specified track entry. interface interface-type interface-number vrrp ipv6 vrid virtual-router-id priority priority-value vrrp ipv6 vrid virtual-router-id preempt-mode [ timer delay delay-value ] vrrp ipv6 vrid virtual-router-id track interface interface-type interface-number [ reduced priority-reduced ] vrrp ipv6 vrid virtual-router-id track track-entry-number [ reduced priority-reduced switchover ] N/A Optional. 100 by default. Optional. The firewall in the VRRP group operates in preemptive mode and the preemption delay is zero seconds by default. Optional. No interface is being tracked by default. Optional. Not configured by default. 23

31 Configuring VRRP packet attributes Configuration prerequisites Before you configure the relevant attributes of VRRP packets, create a VRRP group and configure a virtual IPv6 address. Configuration guidelines You might configure different authentication modes and authentication keys for the VRRP groups on an interface. However, the members of the same VRRP group must use the same authentication mode and authentication key. Excessive traffic might cause a backup to trigger a change of its status because the backup does not receive any VRRP advertisements for a specified period of time. To solve this problem, prolong the time interval to send VRRP advertisements. Configuring different intervals for sending VRRP advertisements on the firewalls in a VRRP group might cause a backup to trigger a change of its status because the backup does not receive any VRRP advertisements for a specified period of time. To solve this problem, configure the same interval for sending VRRP advertisements on each firewall in the VRRP group. Configuration procedure To configure VRRP packet attributes: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter the specified interface view. 3. Configure the authentication mode and authentication key when the VRRP groups send or receive VRRP packets. 4. Configure the time interval for the master in the VRRP group to send VRRP advertisement. interface interface-type interface-number vrrp ipv6 vrid virtual-router-id authentication-mode simple [ cipher ] key vrrp ipv6 vrid virtual-router-id timer advertise adver-interval N/A Optional. Authentication is not performed by default. Optional. 100 centiseconds by default. Displaying and maintaining VRRP for IPv6 Task Command Remarks Display VRRP group status. Display VRRP group statistics. Clear VRRP group statistics. display vrrp ipv6 [ verbose ] [ interface interface-type interface-number [ vrid virtual-router-id ] ] [ { begin exclude include } regular-expression ] display vrrp ipv6 statistics [ interface interface-type interface-number [ vrid virtual-router-id ] ] [ { begin exclude include } regular-expression ] reset vrrp ipv6 statistics [ interface interface-type interface-number [ vrid virtual-router-id ] ] Available in any view. Available in any view. Available in user view. 24

32 IPv4 VRRP configuration examples Single VRRP group configuration example (in the Web interface) Network requirements As shown in Figure 12, Host A wants to access Host B on the Internet, using /24 as its default gateway. Firewall A and Firewall B belong to VRRP group 1 with the virtual IP address /24. If Firewall A operates correctly, the packets that Host A sends to Host B are forwarded by Firewall A. If GigabitEthernet 0/2 connecting Firewall A to the Internet becomes unavailable, packets sent from Host A to Host B are forwarded by Firewall B. To prevent spoof attacks to the VRRP group from unauthorized users, configure the authentication mode as plain text to authenticate the VRRP packets in VRRP group 1. Specify the authentication key as hello. Figure 12 Network diagram Configuring Firewall A 1. Configure the IP address of each interface and the zones. (Details not shown.) 2. Create VRRP group 1 on GigabitEthernet 0/1 and configure the virtual IP address as : a. Select High Availability > VRRP from the navigation tree. b. Click the icon corresponding to GigabitEthernet 0/1. The VRRP group page appears. c. Click Add. The page for creating a VRRP group appears. d. Enter 1 in the VRID field and in the Virtual IP field, and then click Add to add the virtual IP address to the Virtual IP Members field. e. Click Apply. 25

33 Figure 13 Creating VRRP group 1 3. Configure VRRP group attributes: a. On the VRRP group page of GigabitEthernet 0/1, click the icon corresponding to VRRP group 1. b. Enter 110 in the Priority field. c. Select Preemptive from the Preempt Mode field. d. Enter 5 in the Delay field. e. Select Simple from the Authentication field. f. Enter hello in the Key field. g. Enter 5 in the Advertise Time field. h. Click Display Track Config. i. Select GigabitEthernet0/2 from the Interface field, enter 30 in the Reduced Priority field, and then click Add to add the interface to the list box of tracked interface. j. Click Apply. Figure 14 Configuring VRRP group attributes 26

34 Configuring Firewall B 1. Configure the IP address of each interface and the zones. (Details not shown) 2. Create VRRP group 1 on GigabitEthernet 0/1 and configure the virtual IP address as : a. Select High Availability > VRRP from the navigation tree. b. Click the icon corresponding to GigabitEthernet 0/1. The VRRP group page appears. c. Click Add. The page for creating a VRRP group appears. d. Enter 1 in the VRID field and in the Virtual IP field, and click Add to add the virtual IP address to the Virtual IP Members field. e. Click Apply. Figure 15 Creating VRRP group 1 3. Configure VRRP group attributes: a. On the VRRP group page of GigabitEthernet 0/1, click the icon corresponding to VRRP group 1. b. Select Preemptive from the Preempt Mode field. c. Enter 5 in the Delay field. d. Select Simple from the Authentication field. e. Enter hello in the Key field. f. Enter 5 in the Advertise Time field. g. Click Apply. 27

35 Figure 16 Configuring VRRP group attributes Verifying the configuration After the configuration, Host A can ping Host B. You can view the VRRP group information on GigabitEthernet 0/1 on Firewall A and Firewall B. In VRRP group 1, Firewall A is the master and Firewall B is the backup. Firewall A is responsible for forwarding packets sent from Host A to Host B. If the interface that connects Firewall A to the Internet fails, Host A can still ping Host B. In this case, the VRRP group information on the two firewalls shows that Firewall A becomes a backup with the priority 80 and Firewall B becomes the master. Firewall B forwards the packets from Host A to Host B. Single VRRP group configuration example (at the CLI) Network requirements Host A needs to access Host B on the Internet, using /24 as its default gateway. Firewall A and Firewall B belong to VRRP group 1 with the virtual IP address of /24. If Firewall A operates correctly, packets sent from Host A to Host B are forwarded by Firewall A. If Firewall A fails, packets sent from Host A to Host B are forwarded by Firewall B. 28

36 Figure 17 Network diagram Configuration procedure 1. Configure Firewall A: <FirewallA> system-view [FirewallA] interface gigabitethernet 0/1 [FirewallA-GigabitEthernet0/1] ip address # Create VRRP group 1 and configure its virtual IP address as [FirewallA-GigabitEthernet0/1] vrrp vrid 1 virtual-ip # Configure the priority of Firewall A in the VRRP group 1 as 110, which is higher than that of Firewall B (100), so that Firewall A can become the master. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 priority 110 # Configure Firewall A to operate in preemptive mode so that it can become the master whenever it works correctly. Configure the preemption delay as five seconds to avoid frequent status switchover. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 preempt-mode timer delay 5 2. Configure Firewall B: <FirewallB> system-view [FirewallB] interface gigabitethernet 0/1 [FirewallB-GigabitEthernet0/1] ip address # Create VRRP group 1 and configure its virtual IP address as [FirewallB-GigabitEthernet0/1] vrrp vrid 1 virtual-ip # Configure Firewall B to operate in preemptive mode, with the preemption delay set to five seconds. [FirewallB-GigabitEthernet0/1] vrrp vrid 1 preempt-mode timer delay 5 3. Verify the configuration: After the configuration, Host B can be pinged successfully on Host A. To verify your configuration, use the display vrrp verbose command. # Display the detailed information about VRRP group 1 on Firewall A. [FirewallA-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: Run Mode : Standard 29

37 Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 1 Admin Status : Up State : Master Config Pri : 110 Running Pri : 110 Preempt Mode : Yes Delay Time : 5 Auth Type : None Virtual IP : Virtual MAC : e Master IP : # Display the detailed information about VRRP group 1 on Firewall B. [FirewallB-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 1 Admin Status : Up State : Backup Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 5 Become Master : 4200ms left Auth Type : None Virtual IP : Master IP : The output shows that in VRRP group 1 Firewall A is the master, Firewall B is the backup and packets sent from Host A to Host B are forwarded by Firewall A. If Firewall A fails, you can still ping Host B successfully on Host A. To view the detailed information about the VRRP group on Firewall B, use the display vrrp verbose command. # If Firewall A fails, display the detailed information about VRRP group 1 on Firewall B. [FirewallB-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 1 Admin Status : Up State : Master Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 5 Auth Type : None Virtual IP : Virtual MAC : e Master IP : The output shows that if Firewall A fails, Firewall B becomes the master, and packets sent from host A to host B are forwarded by Firewall B. 30

38 # After Firewall A resumes normal operation, use the display vrrp verbose command to display the detailed information about VRRP group 1 on Firewall A. [FirewallA-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 1 Admin Status : Up State : Backup Config Pri : 110 Running Pri : 110 Preempt Mode : Yes Delay Time : 5 Auth Type : None Virtual IP : Virtual MAC : e Master IP : The output shows that after Firewall A resumes normal operation, it becomes the master, and packets sent from Host A to Host B are forwarded by Firewall A. VRRP interface tracking configuration example Network requirements Host A wants to access Host B on the Internet, using /24 as its default gateway. Firewall A and Firewall B belong to VRRP group 1 with the virtual IP address of /24. When Firewall A operates correctly, packets sent from Host A to Host B are forwarded by Firewall A. When interface GigabitEthernet 0/2 through which Firewall A connects to the Internet is not available, packets sent from Host A to Host B are forwarded by Firewall B. To prevent attacks to the VRRP group from illegal users by using spoofed packets, configure the authentication mode as plain text to authenticate the VRRP packets in VRRP group 1. Specify the authentication key as hello. Figure 18 Network diagram 31

39 Configuration procedure 1. Configure Firewall A: <FirewallA> system-view [FirewallA] interface gigabitethernet 0/1 [FirewallA-GigabitEthernet0/1] ip address # Create VRRP group 1 and configure its virtual IP address as [FirewallA-GigabitEthernet0/1] vrrp vrid 1 virtual-ip # Configure the priority of Firewall A in the VRRP group as 110, which is higher than that of Firewall B (100), so that Firewall A can become the master. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 priority 110 # Configure the authentication mode of the VRRP group as simple and authentication key as hello. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 authentication-mode simple hello # Configure the master to send VRRP packets every four seconds. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 timer advertise 4 # Configure Firewall A to operate in preemptive mode, so that it can become the master whenever it works correctly. Configure the preemption delay as five seconds to avoid frequent status switchover. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 preempt-mode timer delay 5 # Set interface GigabitEthernet 0/2 on Firewall A to be tracked. Configure the amount by which the priority value decreases to be more than 10 (30 in this example). Then when GigabitEthernet 0/2 fails, the priority of Firewall A in VRRP group 1 decreases to a value lower than 100 and Firewall B can become the master. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 track interface gigabitethernet 0/2 reduced Configure Firewall B: <FirewallB> system-view [FirewallB] interface gigabitethernet 0/1 [FirewallB-GigabitEthernet0/1] ip address # Create VRRP group 1 and configure its virtual IP address as [FirewallB-GigabitEthernet0/1] vrrp vrid 1 virtual-ip # Configure the authentication mode of the VRRP group as simple and authentication key as hello. [FirewallB-GigabitEthernet0/1] vrrp vrid 1 authentication-mode simple hello # Configure the master to send VRRP packets every four seconds. [FirewallB-GigabitEthernet0/1] vrrp vrid 1 timer advertise 4 # Configure Firewall B to operate in preemptive mode, so that Firewall B can become the master after the priority of Firewall A decreases to a value lower than 100. Configure the preemption delay as five seconds to avoid frequent status switchover. [FirewallB-GigabitEthernet0/1] vrrp vrid 1 preempt-mode timer delay 5 3. Verify the configuration: After the configuration, Host B can be pinged successfully on Host A. To verify your configuration, use the display vrrp verbose command. # Display the detailed information about VRRP group 1 on Firewall A. [FirewallA-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: Run Mode : Standard 32

40 Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 4 Admin Status : Up State : Master Config Pri : 110 Running Pri : 110 Preempt Mode : Yes Delay Time : 5 Auth Type : Simple Key : ****** Virtual IP : Virtual MAC : e Master IP : VRRP Track Information: Track Interface: GE0/2 State : Up Pri Reduced : 30 # Display the detailed information about VRRP group 1 on Firewall B. [FirewallB-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 4 Admin Status : Up State : Backup Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 5 Become Master : 4200ms left Auth Type : Simple Key : ****** Virtual IP : Master IP : The output shows that in VRRP group 1 Firewall A is the master, Firewall B is the backup and packets sent from Host A to host B are forwarded by Firewall A. If interface GigabitEthernet 0/2 through which Firewall A connects to the Internet is not available, you can still successfully ping Host B on Host A. To view the detailed information about the VRRP group, use the display vrrp verbose command. # If interface GigabitEthernet 0/2 on Firewall A is not available, the detailed information about VRRP group 1 on Firewall A is displayed. [FirewallA-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 4 Admin Status : Up State : Backup Config Pri : 110 Running Pri : 80 Preempt Mode : Yes Delay Time : 5 Become Master : 4200ms left Auth Type : Simple Key : ****** Virtual IP :

41 Master IP : VRRP Track Information: Track Interface: GE0/2 State : Down Pri Reduced : 30 # If interface GigabitEthernet 0/2 on Firewall A is not available, the detailed information about VRRP group 1 on Firewall B is displayed. [FirewallB-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 4 Admin Status : Up State : Master Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 5 Auth Type : Simple Key : ****** Virtual IP : Virtual MAC : e Master IP : The output shows that if interface GigabitEthernet 0/2 on Firewall A is not available, the priority of Firewall A is reduced to 80 and it becomes the backup. Firewall B becomes the master and packets sent from Host A to Host B are forwarded by Firewall B. Multiple VRRP groups configuration example (in the Web interface) Network requirements As shown in Figure 19, in the segment /24, some hosts use /24 as their default gateway and some hosts use /24 as their default gateway. Use VRRP groups to implement load balancing and mutual backup between default gateways. 34

42 Figure 19 Network diagram Configuring Firewall A 1. Configure the IP address of each interface and the zones. (Details not shown.) 2. Create VRRP group 1 on GigabitEthernet 0/1 and configure the virtual IP address as : a. Select High Availability > VRRP from the navigation tree. b. Click the icon corresponding to GigabitEthernet 0/1. The VRRP group page appears. c. Click Add. The page for creating a VRRP group appears. d. Enter 1 in the VRID field and in the Virtual IP field, and click Add to add the virtual IP address to the Virtual IP Members field. e. Click Apply. Figure 20 Creating VRRP group 1 3. Create VRRP group 2 on GigabitEthernet 0/1 and configure the virtual IP address as : a. On the VRRP group page of GigabitEthernet 0/1, click Add. b. Enter 2 in the VRID field and in the Virtual IP field, and click Add to add the virtual IP address to the Virtual IP Members field. 35

43 c. Click Apply. Figure 21 Creating VRRP group 2 4. Set the priority of Firewall A in VRRP group 1 to 110: a. On the VRRP group page of GigabitEthernet 0/1, click the icon corresponding to VRRP group 1. b. Enter 110 in the Priority field. c. Click Apply. Figure 22 Setting the priority of Firewall A in VRRP group 1 Configuring Firewall B Configure Firewall B in the same way Firewall A is configured. The figures are omitted. 1. Configure the IP address of each interface and the zones. (Details not shown.) 2. Create VRRP group 1 on GigabitEthernet 0/1 and configure the virtual IP address as : a. Select High Availability > VRRP from the navigation tree. b. Click the icon corresponding to GigabitEthernet 0/1. The VRRP group page appears. c. Click Add. The page for creating a VRRP group appears. 36

44 d. Enter 1 in the VRID field and in the Virtual IP field, and click Add to add the virtual IP address to the Virtual IP Members field. e. Click Apply. 3. Create VRRP group 2 on GigabitEthernet 0/1 and configure the virtual IP address as : a. On the VRRP group page of GigabitEthernet 0/1, click Add. b. Enter 2 in the VRID field and in the Virtual IP field, and click Add to add the virtual IP address to the Virtual IP Members field. c. Click Apply. 4. Set the priority of Firewall B in VRRP group 2 to 110: Verifying the configuration a. Click the icon corresponding to VRRP group 2 on the VRRP group page of GigabitEthernet 0/1. b. Enter 110 in the Priority field. c. Click Apply. After the configuration, the VRRP group information on GigabitEthernet 0/1 on Firewall A and Firewall B shows that: In VRRP group 1, Firewall A is the master and Firewall B is the backup. Hosts on /24 access the Internet through Firewall A. In VRRP group 2, Firewall A is the backup and Firewall B is the master. Hosts on /24 access the Internet through Firewall B Multiple VRRP groups configuration example (at the CLI) Network requirements In the segment /24, some hosts use /24 as their default gateway and some hosts use /24 as their default gateway. Load sharing and mutual backup between default gateways can be implemented by using VRRP groups. 37

45 Figure 23 Network diagram Configuration procedure 1. Configure Firewall A: <FirewallA> system-view [FirewallA] interface gigabitethernet0/1 [FirewallA-GigabitEthernet0/1] ip address # Create VRRP group 1 and configure its virtual IP address as [FirewallA-GigabitEthernet0/1] vrrp vrid 1 virtual-ip # Set the priority of Firewall A in VRRP group 1 to 110, which is higher than that of Firewall B (100), so that Firewall A can become the master in VRRP group 1. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 priority 110 # Create VRRP group 2 and configure its virtual IP address as [FirewallA-GigabitEthernet0/1] vrrp vrid 2 virtual-ip Configure Firewall B: <FirewallB> system-view [FirewallB] interface gigabitethernet0/1 [FirewallB-GigabitEthernet0/1] ip address # Create VRRP group 1 and configure its virtual IP address as [FirewallB-GigabitEthernet0/1] vrrp vrid 1 virtual-ip # Create VRRP group 2 and configure its virtual IP address as [FirewallB-GigabitEthernet0/1] vrrp vrid 2 virtual-ip # Set the priority of Firewall B in VRRP group 2 to 110, which is higher than that of Firewall A (100), so that Firewall B can become the master in VRRP group 2. [FirewallB-GigabitEthernet0/1] vrrp vrid 2 priority Verify the configuration: To verify your configuration, use the display vrrp verbose command. # Display the detailed information about the VRRP group on Firewall A. [FirewallA-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: 38

46 Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 2 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 1 Admin Status : Up State : Master Config Pri : 110 Running Pri : 110 Preempt Mode : Yes Delay Time : 0 Auth Type : None Virtual IP : Virtual MAC : e Master IP : Interface GigabitEthernet0/1 VRID : 2 Adver Timer : 1 Admin Status : Up State : Backup Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 0 Become Master : 2200ms left Auth Type : None Virtual IP : Master IP : # Display the detailed information about the VRRP group on Firewall B. [FirewallB-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 2 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 1 Admin Status : Up State : Backup Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 0 Become Master : 2200ms left Auth Type : None Virtual IP : Master IP : Interface GigabitEthernet0/1 VRID : 2 Adver Timer : 1 Admin Status : Up State : Master Config Pri : 110 Running Pri : 110 Preempt Mode : Yes Delay Time : 0 Auth Type : None Virtual IP : Virtual MAC : e Master IP :

47 The output shows that in VRRP group 1 Firewall A is the master, Firewall B is the backup and the host with the default gateway of /24 accesses the Internet through Firewall A. In VRRP group 2 Firewall A is the backup, Firewall B is the master and the host with the default gateway of /24 accesses the Internet through Firewall B. NOTE: To implement load balancing between the VRRP groups, be sure to configure the default gateway as or on the hosts on network segment /24. IPv6 VRRP configuration examples Single VRRP group configuration example Network requirements Firewall A and Firewall B belong to VRRP group 1 with the virtual IPv6 addresses of 1::10/64 and FE80::10. Host A wants to access Host B on the Internet. Host A learns 1::10/64 as its default gateway through the RA messages sent by the routers. When Firewall A operates correctly, packets sent from Host A to Host B are forwarded by Firewall A. When Firewall A fails, packets sent from Host A to Host B are forwarded by Firewall B. Figure 24 Network diagram Configuration procedure 1. Configure Firewall A: <FirewallA> system-view [FirewallA] ipv6 [FirewallA] interface gigabitethernet0/1 [FirewallA-GigabitEthernet0/1] ipv6 address fe80::1 link-local [FirewallA-GigabitEthernet0/1] ipv6 address 1::1 64 # Create a VRRP group 1 and set its virtual IPv6 addresses to FE80::10 and 1::10. [FirewallA-GigabitEthernet0/1] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local 40

48 [FirewallA-GigabitEthernet0/1] vrrp ipv6 vrid 1 virtual-ip 1::10 # Configure the priority of Firewall A in VRRP group 1 as 110, which is higher than that of Firewall B (100), so that Firewall A can become the master. [FirewallA-GigabitEthernet0/1] vrrp ipv6 vrid 1 priority 110 # Configure Firewall A to operate in preemptive mode so that it can become the master whenever it works correctly; configure the preemption delay as five seconds to avoid frequent status switchover. [FirewallA-GigabitEthernet0/1] vrrp ipv6 vrid 1 preempt-mode timer delay 5 # Enable Firewall A to send RA messages, so that Host A can learn the default gateway address. [FirewallA-GigabitEthernet0/1] undo ipv6 nd ra halt 2. Configure Firewall B: <FirewallB> system-view [FirewallB] ipv6 [FirewallB] interface gigabitethernet0/1 [FirewallB-GigabitEthernet0/1] ipv6 address fe80::2 link-local [FirewallB-GigabitEthernet0/1] ipv6 address 1::2 64 # Create a VRRP group 1 and set its virtual IPv6 addresses to FE80::10 and 1::10. [FirewallB-GigabitEthernet0/1] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local [FirewallB-GigabitEthernet0/1] vrrp ipv6 vrid 1 virtual-ip 1::10 # Configure Firewall B to operate in preemptive mode, with the preemption delay set to five seconds. [FirewallB-GigabitEthernet0/1] vrrp ipv6 vrid 1 preempt-mode timer delay 5 # Enable Firewall B to send RA messages, so that Host A can learns the default gateway address. [FirewallB-GigabitEthernet0/1] undo ipv6 nd ra halt 3. Verify the configuration: After the configuration, Host B can be pinged successfully on Host A. To verify your configuration, use the display vrrp ipv6 verbose command. # Display the detailed information about VRRP group 1 on Firewall A. [FirewallA-GigabitEthernet0/1] display vrrp ipv6 verbose IPv6 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface Ethernet1/1 VRID : 1 Adver Timer : 100 Admin Status : Up State : Master Config Pri : 110 Running Pri : 110 Preempt Mode : Yes Delay Time : 5 Auth Type : None Virtual IP : FE80::10 1::10 Virtual MAC : e Master IP : FE80::1 # Display the detailed information about VRRP group 1 on Firewall B. [FirewallB-GigabitEthernet0/1] display vrrp ipv6 verbose IPv6 Standby Information: 41

49 Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 100 Admin Status : Up State : Backup Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 5 Become Master : 4200ms left Auth Type : None Virtual IP : FE80::10 1::10 Master IP : FE80::1 The output shows that in VRRP group 1 Firewall A is the master, Firewall B is the backup and packets sent from Host A to Host B are forwarded by Firewall A. When Firewall A fails, you can still ping Firewall B successfully on Host A. To view the detailed information about the VRRP group on Firewall B, use the display vrrp ipv6 verbose command. # When Firewall A fails, display the detailed information about VRRP group 1 on Firewall B. [FirewallB-GigabitEthernet0/1] display vrrp ipv6 verbose IPv6 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 100 Admin Status : Up State : Master Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 5 Auth Type : None Virtual IP : FE80::10 1::10 Virtual MAC : e Master IP : FE80::2 The output shows that when Firewall A fails, Firewall B becomes the master, and packets sent from Host A to Host B are forwarded by Firewall B. # After Firewall A resumes normal operation, use the display vrrp ipv6 verbose command to display the detailed information about VRRP group 1 on Firewall A. [RouterA-GigabitEthernet0/1] display vrrp ipv6 verbose IPv6 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 100 Admin Status : Up State : Master Config Pri : 110 Running Pri : 110 Preempt Mode : Yes Delay Time : 5 Auth Type : None 42

50 Virtual IP : FE80::10 1::10 Virtual MAC : e Master IP : FE80::1 The output shows that after Firewall A resumes normal operation, it becomes the master, and packets sent from Host A to Host B are forwarded by Firewall A. VRRP interface tracking configuration example Network requirements Firewall A and Firewall B belong to VRRP group 1 with the virtual IPv6 addresses of 1::10/64 and FE80::10. Host A wants to access Host B on the Internet, and learns 1::10/64 as its default gateway through RA messages sent by the routers. When Firewall A operates correctly, Firewall A forwards the packets that Host A sends to Host B. If interface GigabitEthernet 0/2 through which Firewall A connects to the Internet is not available, Firewall B forwards the packets that Host A sends to Host B. To prevent attacks to the VRRP group from illegal users by using spoofed packets, configure the authentication mode as plain text to authenticate the VRRP packets in VRRP group 1. Specify the authentication key as hello. Figure 25 Network diagram Configuration procedure 1. Configure Firewall A: <FirewallA> system-view [FirewallA] ipv6 [FirewallA] interface gigabitethernet0/1 [FirewallA-GigabitEthernet0/1] ipv6 address fe80::1 link-local [FirewallA-GigabitEthernet0/1] ipv6 address 1::1 64 # Create a VRRP group 1 and set its virtual IPv6 addresses to FE80::10 and 1::10. [FirewallA-GigabitEthernet0/1] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local [FirewallA-GigabitEthernet0/1] vrrp ipv6 vrid 1 virtual-ip 1::10 43

51 # Configure the priority of Firewall A in VRRP group 1 as 110, which is higher than that of Firewall B (100), so that Firewall A can become the master. [FirewallA-GigabitEthernet0/1] vrrp ipv6 vrid 1 priority 110 # Set the authentication mode of VRRP group 1 as simple and authentication key to hello. [FirewallA-GigabitEthernet0/1] vrrp ipv6 vrid 1 authentication-mode simple hello # Set the interval on Firewall A for sending VRRP advertisements to 400 centiseconds. [FirewallA-GigabitEthernet0/1] vrrp ipv6 vrid 1 timer advertise 400 # Configure Firewall A to operate in preemptive mode, so that it can become the master whenever it works correctly. Set the preemption delay to five seconds to avoid frequent status switchover. [FirewallA-GigabitEthernet0/1] vrrp ipv6 vrid 1 preempt-mode timer delay 5 # Set GigabitEthernet 0/2 on Firewall A to be tracked, and configure the amount by which the priority value decreases to be more than 10 (30 in this example), so that when GigabitEthernet 0/2 fails, the priority of Firewall A in VRRP group 1 decreases to a value lower than 100 and thus Firewall B can become the master. [FirewallA-GigabitEthernet0/1] vrrp ipv6 vrid 1 track interface gigabitethernet0/2 reduced 30 # Enable Firewall A to send RA messages, so that Host A can learn the default gateway address. [FirewallA-GigabitEthernet0/1] undo ipv6 nd ra halt 2. Configure Firewall B: <FirewallB> system-view [FirewallB] ipv6 [FirewallB] interface gigabitethernet0/1 [FirewallB-GigabitEthernet0/1] ipv6 address fe80::2 link-local [FirewallB-GigabitEthernet0/1] ipv6 address 1::2 64 # Create a VRRP group 1 and set its virtual IPv6 addresses to FE80::10 and 1::10. [FirewallB-GigabitEthernet0/1] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local [FirewallB-GigabitEthernet0/1] vrrp ipv6 vrid 1 virtual-ip 1::10 # Set the authentication mode of VRRP group 1 as simple and authentication key as hello. [FirewallB-GigabitEthernet0/1] vrrp ipv6 vrid 1 authentication-mode simple hello # Set the interval between sending VRRP advertisements to 400 centiseconds. [FirewallB-GigabitEthernet0/1] vrrp ipv6 vrid 1 timer advertise 400 # Configure Firewall B to operate in preemptive mode, so that Firewall B can become the master after the priority of Firewall A decreases to a value lower than 100. Configure the preemption delay as five seconds to avoid frequent status switchover. [FirewallB-GigabitEthernet0/1] vrrp ipv6 vrid 1 preempt-mode timer delay 5 # Enable Firewall B to send RA messages, so that Host A can learn the default gateway address. [FirewallB-GigabitEthernet0/1] undo ipv6 nd ra halt 3. Verify the configuration: After the configuration, Host B can be pinged successfully on Host A. To verify your configuration, use the display vrrp ipv6 verbose command. # Display the detailed information about VRRP group 1 on Firewall A. [FirewallA-GigabitEthernet0/1] display vrrp ipv6 verbose IPv6 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 44

52 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 400 Admin Status : Up State : Master Config Pri : 110 Running Pri : 110 Preempt Mode : Yes Delay Time : 5 Auth Type : Simple Key : ****** Virtual IP : FE80::10 1::10 Virtual MAC : e Master IP : FE80::1 VRRP Track Information: Track Interface: GE0/2 State : Up Pri Reduced : 30 # Display the detailed information about VRRP group 1 on Firewall B. [FirewallB-GigabitEthernet0/1] display vrrp ipv6 verbose IPv6 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 400 Admin Status : Up State : Backup Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 5 Become Master : 2200ms left Auth Type : Simple Key : ****** Virtual IP : FE80::10 1::10 Master IP : FE80::1 The output shows that in VRRP group 1 Firewall A is the master, Firewall B is the backup and packets sent from Host A to Host B are forwarded by Firewall A. When interface GigabitEthernet 0/2 on Firewall A is not available, you can still ping Host B on Host A. To view the detailed information about the VRRP group, use the display vrrp ipv6 verbose command. # When interface GigabitEthernet 0/2 on Firewall A fails, display the detailed information about VRRP group 1 on Firewall A. [FirewallA-GigabitEthernet0/1] display vrrp ipv6 verbose IPv6 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 400 Admin Status : Up State : Backup Config Pri : 110 Running Pri : 80 Preempt Mode : Yes Delay Time : 5 Become Master : 2200ms left Auth Type : Simple Key : ****** Virtual IP : FE80::10 45

53 1::10 Master IP : FE80::2 VRRP Track Information: Track Interface: GE0/2 State : Down Pri Reduced : 30 # When interface GigabitEthernet 0/2 on Firewall A fails, display the detailed information about VRRP group 1 on Firewall B. [FirewallB-GigabitEthernet0/1] display vrrp ipv6 verbose IPv6 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 400 Admin Status : Up State : Master Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 5 Auth Type : Simple Key : ****** Virtual IP : FE80::10 1::10 Virtual MAC : e Master IP : FE80::2 The output shows that when interface GigabitEthernet 0/2 on Firewall A is not available, the priority of Firewall A reduces to 80 and it becomes the backup. Firewall B becomes the master and packets sent from Host A to Host B are forwarded by Firewall B. Multiple VRRP groups configuration example Network requirements In the network, some hosts use 1::10/64 as their default gateway and some hosts use 1::20/64 as their default gateway. Load sharing and mutual backup between default gateways can be implemented by using VRRP groups. 46

54 Figure 26 Network diagram Virtual IPv6 address 2: FE80::20 1::20/64 Virtual IP address 1: FE80::10 1::10/64 Host A Gateway: 1::10/64 GE0/1 FE80::1 1::1/64 Gateway: 1::20/64 Firewall A Internet Host B GE0/1 FE80::2 1::2/64 Gateway: 1::20/64 Firewall B Host C Configuration procedure 1. Configure Firewall A: <FirewallA> system-view [FirewallA] ipv6 [FirewallA] interface gigabitethernet0/1 [FirewallA-GigabitEthernet0/1] ipv6 address fe80::1 link-local [FirewallA-GigabitEthernet0/1] ipv6 address 1::1 64 # Create VRRP group 1 and set its virtual IPv6 addresses to FE80::10 and 1::10. [FirewallA-GigabitEthernet0/1] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local [FirewallA-GigabitEthernet0/1] vrrp ipv6 vrid 1 virtual-ip 1::10 # Set the priority of Firewall A in VRRP group 1 to 110, which is higher than that of Firewall B (100), so that Firewall A can become the master in VRRP group 1. [FirewallA-GigabitEthernet0/1] vrrp ipv6 vrid 1 priority 110 # Create VRRP group 2 set its virtual IPv6 addresses to FE80::20 and 1::20. [FirewallA-GigabitEthernet0/1] vrrp ipv6 vrid 2 virtual-ip fe80::20 link-local [FirewallA-GigabitEthernet0/1] vrrp ipv6 vrid 2 virtual-ip 1::20 2. Configure Firewall B: <FirewallB> system-view [FirewallB] ipv6 [FirewallB] interface gigabitethernet0/1 [FirewallB-GigabitEthernet0/1] ipv6 address fe80::2 link-local [FirewallB-GigabitEthernet0/1] ipv6 address 1::2 64 # Create VRRP group 1 and set its virtual IPv6 addresses to FE80::10 and 1::10. [FirewallB-GigabitEthernet0/1] vrrp ipv6 vrid 1 virtual-ip fe80::10 link-local [FirewallB-GigabitEthernet0/1] vrrp ipv6 vrid 1 virtual-ip 1::10 # Create VRRP group 2 set its virtual IPv6 addresses to FE80::20 and 1::20. [FirewallB-GigabitEthernet0/1] vrrp ipv6 vrid 2 virtual-ip fe80::20 link-local [FirewallB-GigabitEthernet0/1] vrrp ipv6 vrid 2 virtual-ip 1::20 47

55 # Set the priority of Firewall B in VRRP group 2 to 110, which is higher than that of Firewall A (100), so that Firewall B can become the master in VRRP group 2. [FirewallB-GigabitEthernet0/1] vrrp ipv6 vrid 2 priority Verify the configuration: To verify your configuration, use the display vrrp ipv6 verbose command. # Display the detailed information about the VRRP group on Firewall A. [FirewallA-GigabitEthernet0/1] display vrrp ipv6 verbose IPv6 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 2 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 100 Admin Status : Up State : Master Config Pri : 110 Running Pri : 110 Preempt Mode : Yes Delay Time : 0 Auth Type : None Virtual IP : FE80::10 1::10 Virtual MAC : e Master IP : FE80::1 Interface GigabitEthernet0/1 VRID : 2 Adver Timer : 100 Admin Status : Up State : Backup Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 0 Become Master : 2200ms left Auth Type : None Virtual IP : FE80::20 1::20 Master IP : FE80::2 # Display the detailed information about the VRRP group on Firewall B. [RouterB-GigabitEthernet0/1] display vrrp ipv6 verbose IPv6 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 2 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 100 Admin Status : Up State : Backup Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 0 Become Master : 2200ms left Auth Type : None Virtual IP : FE80::10 1::10 48

56 Master IP : FE80::1 Interface GigabitEthernet0/1 VRID : 2 Adver Timer : 100 Admin Status : Up State : Master Config Pri : 110 Running Pri : 110 Preempt Mode : Yes Delay Time : 0 Auth Type : None Virtual IP : FE80::20 1::20 Virtual MAC : e Master IP : FE80::2 The output shows that in VRRP group 1, Firewall A is the master, Firewall B is the backup, and the host with the default gateway of 1::10/64 access the Internet through Firewall A. In VRRP group 2, Firewall A is the backup, Firewall B is the master, and the host with the default gateway of 1::20/64 access the Internet through Firewall B. NOTE: To implement load balancing between the VRRP groups, be sure to configure the default gateway as 1::10 or 1::20 on the hosts on network segment 1::/64. Troubleshooting VRRP The screen frequently displays error prompts Symptom The screen frequently displays error prompts. Analysis Solution This error is probably caused by: Inconsistent configuration of the firewalls in the VRRP group. A device is attempting to send illegitimate VRRP packets. In the first case, modify the configuration. In the latter case, resort to non-technical measures. Multiple masters appear in a VRRP group Symptom Multiple masters are present in the same VRRP group. Analysis Multiple masters coexist for a short period. This is normal and requires no manual intervention. 49

57 Multiple masters coexist for a long period. This is because firewalls in the VRRP group cannot receive VRRP packets, or the received VRRP packets are illegal. Solution Ping between these masters, and do the following: If the ping fails, check network connectivity. If the ping succeeds, check that their configurations are consistent in terms of number of virtual IP addresses, virtual IP addresses, advertisement interval, and authentication. Frequent VRRP state transition Symptom Analysis Solution Frequent VRRP state transition. The VRRP advertisement interval is set too short. Increase the interval for sending VRRP advertisements or configure a preemption delay. 50

58 Configuring stateful failover Stateful failover overview Some customers require the key entries or access points of their networks, such as the Internet access point of an enterprise or a database server of a bank, to be highly reliable to ensure continuous data transmission. Deploying only one device (even with high reliability) in such a network risks a single point of failure, as shown in Figure 27. Stateful failover can solve this problem. Figure 27 Network with one device deployed Operating procedure Stateful failover involves service backup and traffic switchover. Stateful failover works as follows: 1. As shown in Figure 28, Device A and Device B connect to each other over a failover link. 2. The two devices exchange state negotiation messages periodically through the failover link. After the two devices enter the synchronized state, they back up the sessions of each other to make sure that the sessions on them are consistent. 3. If one device fails, the other device can take over the services by using VRRP or a dynamic routing protocol (such as OSPF) to avoid service interruption. The stateful failover feature supports backing up NAT, ALG, blacklist, ASPF, and IPsec services. 51

59 Figure 28 Network diagram for stateful failover Internet GE1/1 GE1/1 Device A GE1/2 GE1/2 Failover link Device B GE1/3 GE1/3 Internal network Host A Host B Service backup The two devices exchange state negotiation messages through the failover link periodically. After the two devices enter the synchronization state, they back up the services of each other to make sure that the services on them are consistent. If one device fails, the other device can take over the services by using VRRP or a dynamic routing protocol (such as OSPF). Configuration synchronization To implement service backup, the key service configurations on the two devices must be consistent. With the configuration synchronization function, you can synchronize such configurations from the active device to the standby device through the failover link, instead of making repeated configurations on both devices. With auto synchronization, the active device synchronizes all its configurations to the standby device at a time. After that, when its configuration is changed, the active device automatically synchronizes the new configuration to the standby device. NOTE: The device does not support synchronization of IPv6 ACL. Stateful failover states Stateful failover includes the following states: Silence The device has just started, or is transiting from synchronization state to independence state. Independence The silence timer has expired, but no failover link is established. Synchronization The device has completed state negotiation with the other device and is ready for service backup. 52

60 Figure 29 Stateful failover state relations Configuration guidelines When you configure stateful failover, follow these guidelines: Stateful failover can be implemented only between two devices. The failover interfaces on the two devices must have consistent configurations, including interface name, number of interfaces, backup VLAN, and configuration order. If NAT is enabled on the stateful failover devices, the order to create subinterfaces must be consistent. On the standby device, do not perform configurations that can be synchronized from the active device. For interface or security zone configurations, make sure the configuration order, name, and index of the interfaces or security zones on the standby device are consistent with those on the active device. The same numbered interfaces must exist on the two devices. Otherwise, session backup fails. For example, if Device A uses GigabitEthernet 0/1 and GigabitEthernet 0/3 to forward backup data, Device B must also use GigabitEthernet 0/1 and GigabitEthernet 0/3. To run NAT on two failover devices, you must configure two identical NAT address pools for each device. The higher-priority address pool on a device must be different from that on the other. Otherwise, a conflict might occur during backup. For example, you can configure two NAT address pools, through (Pool 1) and through (Pool 2), on devices A and B. Pool 1 has a lower priority on Device A, and Pool 2 has a lower priority on Device B. For more information, see Access Control Configuration Guide. Configure VRRP or a dynamic routing protocol on the failover devices and the uplink/downlink devices to make sure that the traffic can automatically switch to the other device if one device fails. While the active device synchronizes all configurations to the standby device, the redundant configurations, if any, on the standby device are not removed. This might result in a synchronization failure. To avoid this problem, HP recommends that you check the configurations on the active and standby devices to make sure they are consistent before configuration synchronization. An intermediary device (such as a router, a switch, or a hub) is allowed between the failover interfaces. Make sure the packets forwarded by the intermediary device carry the backup VLAN tag. Do not directly connect two failover interfaces on the same stateful failover device. 53

61 Configuring stateful failover in the Web interface Configuring stateful failover 1. Select High Reliability > Stateful Failover from the navigation tree. The stateful failover configuration page appears. The upper part of the page allows you to configure stateful failover parameters, and the lower part of the page displays the current stateful failover state and the configuration synchronization state. Figure 30 Stateful failover configuration page 2. Configure the parameters as described in Table Click Apply. Table 6 Configuration items Item Enable Stateful Failover Session Failover Description Enable/disable the stateful failover feature. IMPORTANT: The configuration items are available only after you select the Enable Stateful Failover box. Enable/disable the session failover function. IMPORTANT: To enable stateful failover for NAT, ALG, and ASPF services, you must enable session failover. Enable/disable the IPsec failover function. IPSec Failover IMPORTANT: To enable stateful failover for IPsec services, you must enable IPsec failover. 54

62 Item Asymmetric Path Description Select whether to support asymmetric path. Select the Asymmetric Path box if sessions enter and leave the internal network through one device. Do not select the Asymmetric Path box if sessions might enter and leave the internal network through different devices. IMPORTANT: This setting must be consistent on both devices. The configuration synchronization function supports synchronization of this setting. Main Device for Configuration Synchronization Specify the local device as the active device during configuration synchronization. If the box is not selected, the local device serves as the standby device during configuration synchronization. Select this box to enable auto synchronization when the local device serves as the active device in configuration synchronization. Auto Synchronization Backup Interface Modify Backup Interface IMPORTANT: You must enable auto synchronization for the active device; otherwise, the device cannot perform configuration synchronization. Displays the failover interface. Click Modify Backup Interface to enter the Backup Interface Configuration page, and then you can do the following: Select one or more interfaces from the Optional Backup Interface(s) list, and then click the << button to add the selected interfaces to the Backup Interface(s) list. Select one or more interfaces from the Backup Interface(s) list, and then click the >> button to remove the selected interfaces from the list. After completing the settings, click Apply to return to the stateful failover configuration page. IMPORTANT: The device supports up to two failover interfaces. If you click Modify Backup Interface before clicking Apply, the configurations you have made on the stateful failover configuration page will be lost. Specify the backup VLAN. Backup VLAN Manual Synchronization Backup VLAN is specific to stateful failover. After you specify a backup VLAN, each device sends stateful failover packets carrying the backup VLAN tag and judges whether a packet is a stateful over packet based on the backup VLAN tag. IMPORTANT: HP recommends not configuring other services for the backup VLAN; otherwise, the operation of stateful failover might be affected. Click the Manual Synchronization button to synchronize all configurations from the active device to the standby device. If the current stateful failover state is synchronization, you can select the manual synchronization method. 55

63 Item Current Status Current Configuration Synchronization Status Description Current stateful failover state of the device: Silence The device has just started, or is transiting from synchronization state to independence state. Independence The silence timer has expired, but no failover link is established. Synchronization The device has completed state negotiation with the other device and is ready for data backup. Displays the current configuration synchronization state, including: A configuration conflict occurs Both devices are active or standby devices. Waiting for the synchronization status. Preparing for synchronization. Synchronizing all configurations. Synchronizes configurations automatically The synchronization of all configurations has completed. Configuration updates on the active device will be automatically synchronized to the standby device. Auto synchronization is not performed Because auto synchronization is not specified, configuration updates on the active device will not be automatically synchronized to the standby device. Stateful failover configuration example Network requirements Firewall A and Firewall B are deployed for stateful failover in an enterprise network to provide Internet access. They both run NAT to provide IP address translation. Configure the firewalls to back up each other, so that when one firewall fails, the other firewall takes over the services to ensure service continuity. Enable automatic configuration synchronization from Firewall A (active firewall) to Firewall B (standby firewall). Figure 31 Network diagram Internet Firewall A GE0/3 GE0/3 VLAN 4001 GE0/1 GE0/1 Failover link Firewall B GE0/2 GE0/2 Internal network Host A Host B 56

64 Configuring Firewall A 1. Configure failover interfaces: a. Select High Reliability > Stateful Failover from the navigation tree. b. Click Modify Backup Interface. The Backup Interface Configuration page appears. c. Select GigabitEthernet0/1 from the Optional Backup Interface(s) list, and click the << button. d. Click Apply. Figure 32 Configuring failover interfaces 2. Configure stateful failover: a. On the Stateful Failover Configuration page, select the Enable Stateful Failover box. b. Select the Session Failover, Main Device for Configuration Synchronization, and Auto Synchronization boxes, and clear the IPSec Failover box. c. Enter 4001 for Backup VLAN. d. Click Apply. Figure 33 Configuring stateful failover 57

65 Configuring Firewall B Except the Main Device for Configuration Synchronization and Auto Synchronization settings that are not needed for Firewall B, other settings on Firewall B are consistent with those on Firewall A and are not shown. Configuring stateful failover at the CLI Stateful failover configuration task list To implement stateful failover on two devices, you need to perform the following configurations: Routing configuration. Configure VRRP or a dynamic routing protocol on the devices and the uplink/downlink devices to make sure that the traffic can automatically switch to the other device when a device fails. Service backup configuration, which can implement real-time service backup between the two devices. The real-time service backup is triggered by adding, modifying, or deleting service features. This configuration guide only introduces the service backup configuration. Complete the following tasks to configure stateful failover: Task Enabling stateful failover Enabling automatic configuration synchronization Configuring a failover interface and a backup VLAN Service module related configurations Remarks Required. Required. Required. Optional. A device providing NAT, ALG, or blacklist services automatically backs up related information to the backup device after the configurations take effect. Enabling stateful failover When you enable stateful failover with the dhbk enable backup-type { dissymmetric-path symmetric-path } command, one of the following happens: If you specify the dissymmetric-path keyword, the two devices operate in active/active mode. Sessions enter and leave the internal network through different devices to achieve load sharing. If you specify the symmetric-path keyword, the two devices operate in active/standby mode. Sessions enter and leave the internal network through one device. Select a keyword based on the network environment and resources, and specify the same keyword for both devices. To enable stateful failover: 58

66 Step Command Remarks 1. Enter system view. system-view N/A 2. Enable stateful failover in a specified mode. dhbk enable backup-type { dissymmetric-path symmetric-path } Disabled by default. Enabling automatic configuration synchronization To implement service backup between two devices (A and B, for example), make sure the service status, service data, and service configurations on the two devices are consistent. You can enable automatic configuration synchronization on A and use the default configuration on B. After that, A automatically synchronizes configurations of the service modules that support stateful failover to B in real time. To enable automatic configuration synchronization: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable the local device to perform automatic configuration synchronization to the peer. dhbk configuration-backup master [ synchronization ] By default, a device only receives backup configuration from the peer. If the synchronization keyword is specified, the local device automatically synchronizes configurations of the service modules that support stateful failover to the peer. If the synchronization keyword is not specified, automatic synchronization is not performed. Configuring a failover interface and a backup VLAN Failover interfaces send and receive stateful failover packets for data backup. Stateful failover packets are identified by the backup VLAN. Each stateful failover device adds the backup VLAN tag to the stateful failover packets, and sends the packets through the failover interface. Only the packets that are received from failover interfaces and carry the backup VLAN tag are treated as stateful failover packets. Do not configure other services for the backup VLAN. Otherwise, the operation of stateful failover might be affected. To configure a failover interface and a backup VLAN: Step Command Remarks 1. Enter system view. system-view N/A 2. Configure a failover interface and a backup VLAN. dhbk interface interface-list vlan vlan-id By default, no failover interface or backup VLAN is specified. 59

67 Displaying and maintaining stateful failover Task Command Remarks Display the running status and related information of stateful failover. display dhbk status [ { begin exclude include } regular-expression ] Available in any view. Stateful failover configuration example Network requirements In Figure 34, Device A and Device B serve as the internal gateways of an enterprise network. Firewall A and Firewall B, respectively attached to Device A and Device B, provide portal access authentication for internal users. Configure stateful failover between Firewall A and Firewall B. When one device fails, the other device takes over the services to ensure service continuity. Figure 34 Network diagram Configuration procedure 1. Configure Firewall A: # Create VLAN 100. <FirewallA> system-view [FirewallA] vlan 100 # Assign GigabitEthernet 1/1 to VLAN 100. [FirewallA -vlan100] port gigabitethernet 1/1 [FirewallA -vlan100] quit # Specify VLAN 100 as a backup VLAN. [FirewallA] dhbk interface gigabitethernet 1/1 vlan 100 # Enable symmetric-path mode stateful failover. [FirewallA] dhbk enable backup-type symmetric-path 2. Configure Device A: 60

68 # Create VLAN 100. <DeviceA> system-view [DeviceA] vlan 100 # Assign GigabitEthernet 1/1 to VLAN 100. [DeviceA-vlan100] port gigabitethernet 1/1 [DeviceA-vlan100] quit # Assign GigabitEthernet 1/2 to VLAN 100. Because Device A and Device B might exchange packets of multiple VLANs, configure GigabitEthernet 1/2 as a trunk port and permit packets of VLAN 100 to pass. [DeviceA] interface gigabitethernet 1/2 [DeviceA-GigabitEthernet1/2] port link-type trunk [DeviceA-GigabitEthernet1/2] port trunk permit vlan 100 Please wait... Done. 3. Configure Device B in the same way Device A is configured. (Details not shown.) 4. Configure Firewall B in the same way Firewall A is configured. (Details not shown.) 61

69 Configuring IPC IPC can be configured only at the CLI. This chapter provides an overview of IPC and describes the IPC monitoring commands. Overview Node Link Channel Inter-Process Communication (IPC) provides a reliable communication mechanism among processing units, typically CPUs. This section describes the basic IPC concepts. An IPC node is an independent IPC-capable processing unit, typically, a CPU. The device is a centralized device that has only one CPU. An IPC link is a connection between any two IPC nodes. Any two IPC nodes have one and only one IPC link for sending and receiving packets. All IPC nodes are fully meshed. IPC links are created when the system is initialized. An IPC node, upon startup, sends handshake packets to other nodes. If the handshake succeeds, a connection is established. The system uses link status to identify the link connectivity between two nodes. An IPC node can have multiple links, and each link has its own status. A channel is the communication interface between peer upper layer application modules that use different IPC nodes. Each node assigns a locally unique channel number to each upper layer application module for identification. An upper layer application module sends data to an IPC module across a channel, and the IPC module sends the data to a peer node across a link, as shown in Figure

70 Figure 35 Relationship between a node, link and channel Channel 2 Link Packet sending modes IPC uses one of the following modes to send packets for upper layer application modules: Unicast One node sends packets to another node. Multicast One node sends packets to several other nodes. This mode includes broadcast, a special multicast. To use multicast mode, an application module must create a multicast group that includes a set of nodes. Multicasts destined for this group are sent to all the nodes in the group. An application module can create multiple multicast groups. Creation and deletion of a multicast group or group member depend on the application module. Mixcast Supports both unicast and multicast. IPC assigns one queue for each mode. An upper layer application module automatically selects one mode as needed. Enabling IPC performance statistics The IPC performance statistics function provides the most recent 10-second, 1-minute, and 5-minute traffic input and output statistics for IPC nodes. If this function is disabled, the display ipc performance command displays the statistics collected before IPC performance statistics was disabled. Perform the following task in user view: Task Command Remarks Enable IPC performance statistics. ipc performance enable { node node-id self-node } [ channel channel-id ] By default, the function is disabled. 63

71 Displaying and maintaining IPC Task Command Remarks Display IPC node information. Display channel information for a node. Display queue information for a node. Display multicast group information for a node. Display packet information for a node. Display link status information for a node. Display IPC performance statistics for a node. Clear IPC performance statistics for a node. display ipc node [ { begin exclude include } regular-expression ] display ipc channel { node node-id self-node } [ { begin exclude include } regular-expression ] display ipc queue { node node-id self-node } [ { begin exclude include } regular-expression ] display ipc multicast-group { node node-id self-node } [ { begin exclude include } regular-expression ] display ipc packet { node node-id self-node } [ { begin exclude include } regular-expression ] display ipc link { node node-id self-node } [ { begin exclude include } regular-expression ] display ipc performance { node node-id self-node } [ channel channel-id ] [ { begin exclude include } regular-expression ] reset ipc performance [ node node-id self-node ] [ channel channel-id ] Available in any view. Available in any view. Available in any view. Available in any view. Available in any view. Available in any view. Available in any view. Available in user view. 64

72 Configuring Track Track can be configured only at the CLI. Overview The Track module works between application and detection modules, as shown in Figure 36. It shields the differences between various detection modules from application modules. Collaboration is enabled after you associate the Track module with a detection module and an application module. The detection module probes specific objects such as interface status, link status, network reachability, and network performance, and informs the Track module of detection results. The Track module sends the detection results to the associated application module. When notified of changes for the tracked object, the application modules can react to avoid communication interruption and network performance degradation. Figure 36 Collaboration through the Track module Collaboration fundamentals The Track module collaborates with detection modules and application modules: Collaboration between the Track module and a detection module Collaboration between the Track module and an application module Collaboration between the Track module and a detection module The detection module sends the detection result of the associated tracked object to the Track module. Depending on the result, the Track module changes the status of the track entry: If the tracked object functions correctly, for example, the target interface is up or the target network is reachable, the state of the track entry is Positive. If the tracked object does not function correctly, for example, the target interface is down or the target network is unreachable, the state of the track entry is Negative. If the detection result is not valid, for example, the network quality analyzer (NQA) test group that is associated with the track entry does not exist, the state of the track entry is Invalid. The following detection modules can be associated with the Track module: 65

73 NQA. BFD. Interface management module. Collaboration between the Track module and an application module After being associated with an application module, when the status of the track entry changes, the Track module notifies the application module, which then takes proper actions. The following application modules can be associated with the Track module: VRRP. Static routing. Policy-based routing. Interface backup. In some cases, the status of a track entry changes while a route is still recovering. This leads to problems if the Track module immediately notifies the application modules of the status change and the application modules begin using the route before it is ready. For example, the master in a VRRP group monitors the uplink interface through the Track module. When the uplink interface fails, the Track module notifies the master to reduce its priority so that a backup with a higher priority can preempt as the master to forward packets. When failed uplink interface recovers, if the Track module immediately notifies the original master to restore its priority, the master immediately will forward packets to that interface. However, this result in packet forwarding failure because the uplink route has not yet been recovered. To solve this problem, configure a delay before the Track module notifies the application modules of the track entry status changes. Collaboration application example The following is an example of collaboration between NQA, Track, and static routing. Configure a static route with next hop on the device. If the next hop is reachable, the static route is valid. If the next hop becomes unreachable, the static route should become invalid. For this purpose, configure collaboration between the NQA, Track, and static routing modules: 1. Create an NQA test group to monitor the accessibility of IP address Create a track entry and associate it with the NQA test group. When the next hop is reachable, the track entry is in Positive state. When the next hop becomes unreachable, the track entry is in Negative state. 3. Associate the track entry with the static route. When the track entry turns to the Positive state, the static route is valid. When the associated track entry turns to the Negative state, the static route is invalid. Collaboration application example on an AC This example shows how to implement collaboration between NQA, Track, and uplink detection. 66

74 Figure 37 Network diagram If the uplink fails, the AC disables the radio on the AP that associates with the AC. If the uplink recovers, the AC enables the radio on the AP. For this purpose, configure collaboration between the NQA, Track, and uplink detection: 1. Configure an NQA test group to check the accessibility of the Device. 2. Create a track entry and associate it with the NQA test group. When the Device is reachable, the track entry is in Positive state. When the Device becomes unreachable, the track entry is in Negative state. 3. Associate the track entry with the WLAN uplink detection feature. When the associated track entry turns to the Negative state, the uplink detection feature disables the radio on the AP so that wireless clients will not associate with the AP. When the track entry changes to the Positive state, the uplink detection feature enables the radio on the AP so that wireless clients can associate with the AP. Track configuration task list To implement the collaboration function, establish associations between the Track module and the detection modules, and between the Track module and the application modules. Complete these tasks to configure the Track module: Task Associating the Track module with a detection module Associating the Track module with an application module Associating Track with NQA Associating Track with BFD Associating Track with interface management Associating Track with VRRP Associating Track with static routing Associating Track with PBR Associating Track with interface backup Remarks Required. Use one of the methods. Required. Use one of the methods. Associating the Track module with a detection module Associating Track with NQA NQA supports multiple test types to analyze network performance, services, service quality. For example, an NQA test group can periodically detect whether a destination is reachable, or whether the TCP connection to a TCP server can be set up. 67

75 An NQA test group functions as follows when it is associated with a track entry: If the consecutive failures reach the specified threshold, the NQA module tells the Track module that the tracked object malfunctions. Then the Track module sets the track entry to Negative state. If the specified threshold is not reached, the NQA module tells the Track module that the tracked object functions correctly. The Track module then sets the track entry to Positive state. For more information about NQA, see "Configuring NQA." To associate Track with NQA: Step Command Remarks 1. Enter system view. system-view N/A 2. Create a track entry, associate it with an NQA reaction entry, and specify the delay time for the Track module to notify the associated application module when the track entry status changes. track track-entry-number nqa entry admin-name operation-tag reaction item-number [ delay { negative negative-time positive positive-time } * ] No track entry is created by default. NOTE: If the specified NQA test group or the reaction entry in the track entry does not exist, the status of the track entry is Invalid. Associating Track with BFD The following matrix shows the feature and hardware compatibility: Hardware F1000-A-EI/F1000-S-EI F1000-E F5000 F5000-S/F5000-C VPN firewall modules 20-Gbps VPN firewall modules Compatibility No No Yes No No No BFD supports the control packet mode and echo packet mode: Associating a track entry with the echo-mode BFD session detects a directly connected link. Before that, you must configure the source IP address of BFD echo packets. Associating a track entry with the control-mode BFD session detects an indirectly connected link. You must make this configuration for both the local and remote ends. Otherwise, BFD does not take effect. The BFD functions as follows when it is associated with a track entry: If the BFD detects that the link fails, it informs the track entry of the link failure. The Track module then sets the track entry to the Negative state. If the BFD detects that the link is normal, the Track module sets the track entry to the Positive state. For more information about BFD, see "Configuring BFD." 68

76 Configuration procedure To associate Track with BFD: Step Command Remarks 1. Enter system view. system-view N/A 2. Create a track entry, associate it with the BFD session, and specify the delay time for the Track module to notify the associated application module when the track entry status changes. track track-entry-number bfd { control echo } interface interface-type interface-number remote ip remote-ip local ip local-ip [ delay { negative negative-time positive positive-time } * ] No track entry is created by default. NOTE: When associating Track with BFD, do not configure the virtual IP address of a VRRP group as the local or remote address of a BFD session. Associating Track with interface management The interface management module monitors the physical status or network-layer protocol status of the interface. The interface management module functions as follows when it is associated with a track entry: When the physical or network-layer protocol status of the interface changes to up, the interface management module informs the Track module of the change and the Track module sets the track entry to Positive. When the physical or network-layer protocol status of the interface changes to down, the interface management module informs the Track module of the change and the Track module sets the track entry to Negative. To associate Track with interface management: Step Command Remarks 1. Enter system view. system-view N/A 2. Associating Track with interface management. Create a track entry, associate it with the interface management module to monitor the physical status of an interface, and specify the delay time for the Track module to notify the associated application module when the track entry status changes: track track-entry-number interface interface-type interface-number [ delay { negative negative-time positive positive-time } * ] Create a track entry, associate it with the interface management module to monitor the Layer 3 protocol status of an interface, and specify the delay time for the Track module to notify the associated application module when the track entry status changes: track track-entry-number interface interface-type interface-number protocol { ipv4 ipv6 } [ delay { negative negative-time positive positive-time } * ] Use either method. No track entry is created by default. 69

77 Associating the Track module with an application module Associating Track with VRRP VRRP is an error-tolerant protocol. It adds a group of routers that can act as network gateways to a VRRP group, which forms a virtual router. Routers in the VRRP group elect the master acting as the gateway according to their priorities. A router with a higher priority is more likely to become the master. The other routers function as the backups. When the master fails, the backups in the VRRP group elect a new gateway to undertake the responsibility of the failed master. This ensures that the hosts in the network segment can uninterruptedly communicate with external networks. When VRRP is operating in standard protocol mode, associate the Track module with the VRRP group to implement the following actions: Change the priority of a router according to the status of the uplink. If a fault occurs on the uplink of the router, the VRRP group cannot be aware of the uplink failure. If the router is the master, hosts in the LAN cannot access the external network. This problem can be solved by establishing a Track-VRRP group association. Use the detection modules to monitor the status of the uplink of the router and establish collaborations between the detection modules, Track module, and VRRP. When the uplink fails, the detection modules notify the Track module to change the status of the monitored track entry to Negative, and the priority of the master decreases by a specific value. This allows a higher priority router in the VRRP group to become the master, and maintains proper communication between the hosts in the LAN and the external network. Monitor the master on a backup. If a fault occurs on the master, the backup working in switchover mode will switch to the master immediately to maintain normal communication. Follow these guidelines when you associate Track with VRRP: VRRP tracking is not valid on an IP address owner. An IP address owner refers to a router when the IP address of the virtual router is the IP address of an interface on the router in the VRRP group. You can associate a nonexistent track entry with a VRRP group or VF. The association takes effect only after you use the track command to create the track entry. For more information about VRRP, see "Configuring VRRP." To associate Track with VRRP group: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Create a VRRP group and configure its virtual IP address. 4. Associate a track entry with a VRRP group. interface interface-type interface-number vrrp vrid virtual-router-id virtual-ip virtual-address vrrp [ ipv6 ] vrid virtual-router-id track track-entry-number [ reduced priority-reduced switchover ] N/A No VRRP group is created by default. No track entry is specified for a VRRP group by default. 70

78 Associating Track with static routing A static route is a manually configured route. With a static route configured, packets to the specified destination are forwarded through the path specified by the administrator. The disadvantage of using static routes is that they cannot adapt to network topology changes. Faults or topological changes in the network can make the routes unreachable, causing network breaks. To prevent this problem, configure another route to back up the static route. When the static route is reachable, packets are forwarded through the static route. When the static route is unreachable, packets are forwarded through the backup route, avoiding network breaks and enhancing network reliability. To check the accessibility of a static route in real time, establish association between Track and the static route. If you specify the next hop but not the egress interface when configuring a static route, you can establish collaborations among the static route, the Track module, and detection modules. This enables you to check the accessibility of the static route by the status of the track entry. The Positive state of the track entry shows that the next hop of the static route is reachable, and that the configured static route is valid. The Negative state of the track entry shows that the next hop of the static route is not reachable, and that the configured static route is invalid. The Invalid state of the track entry shows that the accessibility of the next hop of the static route is unknown, and that the static route is valid. Follow these guidelines when you associate Track with static routing: You can associate a nonexistent track entry with a static route. The association takes effect only after you use the track command to create the track entry. If the Track module detects the next hop accessibility of the static route in a private network through NQA, the VPN instance name of the next hop of the static route must be consistent with that configured for the NQA test group. Otherwise, accessibility detection cannot function correctly. If a static route needs route recursion, the associated track entry must monitor the next hop of the recursive route instead of that of the static route. Otherwise, a valid route might be considered invalid. For more information about static route configuration, see Network Management Configuration Guide. To associate Track with static routing: Step Command Remarks 1. Enter system view. system-view N/A 71

79 Step Command Remarks 2. Associate the static route with a track entry to check the accessibility of the next hop. Method 1: ip route-static dest-address { mask mask-length } { next-hop-address vpn-instance d-vpn-instance-name next-hop-address } track track-entry-number [ preference preference-value ] [ tag tag-value ] [ description description-text ] Method 2: ip route-static vpn-instance s-vpn-instance-name&<1-6> dest-address { mask mask-length } { next-hop-address track track-entry-number [ public ] vpn-instance d-vpn-instance-name next-hop-address track track-entry-number } [ preference preference-value ] [ tag tag-value ] [ description description-text ] Use either method. Not configured by default. Associating Track with PBR Policy-based routing (PBR) is a routing mechanism based on user-defined policies. Different from the traditional destination-based routing mechanism, PBR allows you to use a policy (based on the source address, packet length, and other criteria) to route packets. You can specify the VPN instance, packet priority, outgoing interface, next hop, default outgoing interface, default next hop, and other parameters to guide the forwarding of packets that match specific ACLs or have specific lengths. PBR cannot detect the availability of any action taken on packets. When an action is not available, packets processed by the action might be discarded. For example, configure PBR to forward packets that match certain criteria through a specific interface. When the specified interface fails, PBR cannot sense the failure, and continues to forward matching packets out of the interface. This problem can be solved by associating Track with PBR, which improves the flexibility of the PBR application and enables PBR to sense topology changes. After you associate a track entry with an apply clause, the detection module associated with the track entry sends the detection result of the availability of the object (an interface or an IP address) specified in the apply clause. The Positive state of the track entry shows that the object is available, and the apply clause is valid. The Negative state of the track entry shows that the object is not available, and the apply clause is invalid. The Invalid state of the track entry shows that the apply clause is valid. The following objects can be associated with a track entry: Outgoing interface. Next hop. Default outgoing interface. Default next hop. Configuration prerequisites Before you associate Track with PBR, create a policy or a policy node and configure the match criteria as well. 72

80 Configuration procedure You can associate a nonexistent track entry with PBR. The association takes effect only after you use the track command to create the track entry. For more information about PBR, see Network Management Configuration Guide. To associate Track with PBR: Step Command Remarks 1. Enter system view. system-view N/A 2. Create a policy or policy node and enter PBR policy node view. 3. Define a match criterion. 4. Associate Track with PBR. policy-based-route policy-name [ deny permit ] node node-number Define a packet length match criterion: if-match packet-length min-len max-len Define an ACL match criterion: if-match acl acl-number Set the outgoing interface, and associate it with a track entry: apply output-interface interface-type interface-number [ track track-entry-number ] [ interface-type interface-number [ track track-entry-number ] ] Set the next hop, and associate it with a track entry: apply ip-address next-hop ip-address [ track track-entry-number ] [ ip-address [ track track-entry-number ] ] Set the default outgoing interface, and associate it with a track entry: apply default output-interface interface-type interface-number [ track track-entry-number ] [ interface-type interface-number [ track track-entry-number ] ] Set the default next hop, and associate it with a track entry: apply ip-address default next-hop ip-address [ track track-entry-number] [ ip-address [ track track-entry-number] ] N/A Optional. By default, no packets are filtered. Use at least one of the commands. Associating Track with interface backup Interface backup allows interfaces on a device to back up each other, with the active interface transmitting data and the standby interfaces staying in backup state. When the active interface or the link where the active interface resides fails, and data cannot be transmitted, a standby interface is brought up to transmit data, enhancing the reliability of the network. Associate a standby interface with a track entry so that the standby interface can detect the status of the active interface by checking the status of the track entry, and change its status. 73

81 The Positive state of the track entry shows that the link where the active interface resides operates correctly, and the standby interfaces stay in backup state. The Negative state of the track entry shows that the link where the active interface resides has failed, and a standby interface changes to the active interface for data transmission. The always Invalid state of the track entry shows that the association does not take effect and each interface keeps its original forwarding state. When the track entry turns to Invalid from other state, a standby interface becomes the active interface. You can associate a nonexistent track entry with an interface. The association takes effect only after you use the track command to create the track entry. For more information, see "Configuring interface backup." To associate Track with interface backup: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Associate the interface with a track entry. interface interface-type interface-number standby track track-entry-number N/A Not configured by default. NOTE: You can associate an interface with only one track entry. If you execute the standby track command multiple times, the last configuration takes effect. Displaying and maintaining track entries Task Command Remarks Display information about the specified or all track entries. display track { track-entry-number all } [ { begin exclude include } regular-expression ] Available in any view. Track configuration examples VRRP-Track-NQA collaboration configuration example In this example, the master monitors the uplink. Network requirements As shown in Figure 38, configure Host A to access Host B on the Internet. The default gateway of Host A is /24. Firewall A and Firewall B belong to VRRP group 1, which has the virtual IP address When Firewall A works correctly, packets from Host A to Host B are forwarded through Firewall A. When NQA detects that a fault is on the uplink of Firewall A, packets from Host A to Host B are forwarded through Firewall B. 74

82 Figure 38 Network diagram Configuration procedure 1. Configure the IP address of each interface as shown in Figure 38. (Details not shown.) 2. Configure an NQA test group on Firewall A: # Create an NQA test group with the administrator name admin and the operation tag test. <FirewallA> system-view [FirewallA] nqa entry admin test # Configure the test type as ICMP echo test. [FirewallA-nqa-admin-test] type icmp-echo # Configure the destination address as [FirewallA-nqa-admin-test-icmp-echo] destination ip # Configure the interval between two consecutive tests as 100 milliseconds. [FirewallA-nqa-admin-test-icmp-echo] frequency 100 # Create reaction entry 1, specifying that five consecutive probe failures trigger the Track module. [FirewallA-nqa-admin-test-icmp-echo] reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only [FirewallA-nqa-admin-test-icmp-echo] quit # Start the NQA test. [FirewallA] nqa schedule admin test start-time now lifetime forever 3. Configure a track entry on Firewall A: # Configure track entry 1, and associate it with reaction entry 1 of the NQA test group (with the administrator admin, and the operation tag test). [FirewallA] track 1 nqa entry admin test reaction 1 4. Configure VRRP on Firewall A: # Create VRRP group 1, and configure the virtual IP address for the group. [FirewallA] interface gigabitethernet0/1 [FirewallA-GigabitEthernet0/1] vrrp vrid 1 virtual-ip # Set the priority of Firewall A in VRRP group 1 to 110. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 priority 110 # Set the authentication mode of VRRP group 1 to simple, and the authentication key to hello. 75

83 [FirewallA-GigabitEthernet0/1] vrrp vrid 1 authentication-mode simple hello # Configure the master to send VRRP packets at an interval of five seconds. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 timer advertise 5 # Configure Router A to operate in preemptive mode, and set the preemption delay to five seconds. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 preempt-mode timer delay 5 # Configure to monitor track entry 1 and specify the priority decrement to 30. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 track 1 reduced Configure VRRP on Firewall B: <FirewallB> system-view [FirewallB] interface gigabitethernet0/1 # Create VRRP group 1, and configure the virtual IP address for the group. [FirewallB-GigabitEthernet0/1] vrrp vrid 1 virtual-ip # Set the authentication mode of VRRP group 1 to simple, and the authentication key to hello. [FirewallB-GigabitEthernet0/1] vrrp vrid 1 authentication-mode simple hello # Configure the master to send VRRP packets at an interval of five seconds. [FirewallB-GigabitEthernet0/1] vrrp vrid 1 timer advertise 5 # Configure Firewall B to operate in preemptive mode, and set the preemption delay to five seconds. [FirewallB- GigabitEthernet0/1] vrrp vrid 1 preempt-mode timer delay 5 Verifying the configuration After configuration, ping Host B on Host A, and you can see that Host B is reachable. To view the configuration result, use the display vrrp command. # Display detailed information about VRRP group 1 on Firewall A. [FirewallA-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 5 Admin Status : Up State : Master Config Pri : 110 Running Pri : 110 Preempt Mode : Yes Delay Time : 5 Auth Type : Simple Key : hello Virtual IP : Virtual MAC : e Master IP : VRRP Track Information: Track Object : 1 State : Positive Pri Reduced : 30 # Display detailed information about VRRP group 1 on Firewall B. [FirewallB-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC 76

84 Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 5 Admin Status : Up State : Backup Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 5 Become Master : 2200ms left Auth Type : Simple Key : hello Virtual IP : Master IP : The output shows that in VRRP group 1, Firewall A is the master and Firewall B is a backup. Packets from Host A to Host B are forwarded through Firewall A. When a fault is on the link between Firewall A and Router A, you can still successfully ping Host B on Host A. To view information about VRRP group 1, use the display vrrp command. # Display detailed information about VRRP group 1 on Firewall A when a fault is on the link between Firewall A and Router A. [FirewallA-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 5 Admin Status : Up State : Backup Config Pri : 110 Running Pri : 80 Preempt Mode : Yes Delay Time : 5 Become Master : 2200ms left Auth Type : Simple Key : hello Virtual IP : Master IP : VRRP Track Information: Track Object : 1 State : Negative Pri Reduced : 30 # Display detailed information about VRRP group 1 on Firewall B when a fault is on the link between Firewall A and Router A. [FirewallB-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 5 Admin Status : Up State : Master Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 5 Auth Type : Simple Key : hello Virtual IP : Virtual MAC : e

85 Master IP : The output shows that when a fault is on the link between Firewall A and Router A, the priority of Firewall A decreases to 80. Firewall A becomes the backup, and Firewall B becomes the master. Packets from Host A to Host B are forwarded through Firewall B. Configuring BFD for a VRRP backup to monitor the master The following matrix shows the configuration example and hardware compatibility: Hardware F1000-A-EI/F1000-S-EI F1000-E F5000 F5000-S/F5000-C VPN firewall modules 20-Gbps VPN firewall modules Compatibility No No Yes No No No Network requirements As shown in Figure 39, Firewall A and Firewall B belong to VRRP group 1, whose virtual IP address is The default gateway of the hosts in the LAN is When Firewall A operates correctly, the hosts in the LAN access the external network through Firewall A. When Firewall A fails, the hosts in the LAN access the external network through Firewall B. If BFD is not configured, when the master in a VRRP group fails, the backup cannot become the master until the configured timeout timer expires. The timeout is generally three to four seconds, which makes the switchover slow. To solve this problem, VRRP uses BFD to probe the state of the master. Once the master fails, the backup can become the new master in milliseconds. 78

86 Figure 39 Network diagram Configuration procedure 1. Configure VRRP on Firewall A: <FirewallA> system-view [FirewallA] interface gigabitethernet 1/1 # Create VRRP group 1, and configure the virtual IP address for the group. Set the priority of Firewall A in VRRP group 1 to 110. [FirewallA-gigabitethernet1/1] vrrp vrid 1 virtual-ip [FirewallA-gigabitethernet1/1] vrrp vrid 1 priority 110 [FirewallA-gigabitethernet1/1] return 2. Configure BFD on Firewall B: # Configure the source address of BFD echo packets as <FirewallB> system-view [FirewallB] bfd echo-source-ip Create a track entry to be associated with the BFD session on Firewall B: # Create track entry 1 to be associated with the BFD session to check whether Firewall A is reachable. [FirewallB] track 1 bfd echo interface gigabitethernet 1/1 remote ip local ip Configure VRRP on Firewall B: # Create VRRP group 1, and configure the virtual IP address for the group. VRRP group 1 monitors the status of track entry 1. When the status of the track entry becomes Negative, Firewall B becomes the master quickly. [FirewallB] interface gigabitethernet 1/1 79

87 [FirewallB-gigabitethernet1/1] vrrp vrid 1 virtual-ip [FirewallB-gigabitethernet1/1] vrrp vrid 1 track 1 switchover [FirewallB-gigabitethernet1/1] return Verifying the configuration # Display detailed information about VRRP group 1 on Firewall A. <FirewallA> display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface gigabitethernet1/1 VRID : 1 Adver Timer : 1 Admin Status : Up State : Master Config Pri : 110 Running Pri : 110 Preempt Mode : Yes Delay Time : 0 Auth Type : None Virtual IP : Virtual MAC : e Master IP : # Display detailed information about VRRP group 1 on Firewall B. <FirewallB> display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface gigabitethernet1/1 VRID : 1 Adver Timer : 1 Admin Status : Up State : Backup Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 0 Become Master : 2200ms left Auth Type : None Virtual IP : Master IP : VRRP Track Information: Track Object : 1 State : Positive Switchover # Display information about track entry 1 on Firewall B. <FirewallB> display track 1 Track ID: 1 Status: Positive Duration: 0 days 0 hours 0 minutes 32 seconds Notification delay: Positive 0, Negative 0 (in seconds) Reference object: BFD session: Packet type: Echo Interface : gigabitethernet1/1 Remote IP :

88 Local IP : The output shows that when the status of the track entry becomes Positive, Firewall A is the master, and Firewall B the backup. # Enable VRRP state debugging and BFD event debugging on Firewall B. <FirewallB> terminal debugging <FirewallB> terminal monitor <FirewallB> debugging vrrp state <FirewallB> debugging bfd event # When Firewall A fails, the following output is displayed on Firewall B. *Dec 17 14:44:34: FirewallB BFD/7/EVENT:Send sess-down Msg, [Src: ,Dst: ,Ethernet1/1,Echo], instance:0, protocol:track *Dec 17 14:44:34: FirewallB VRRP/7/DebugState: IPv4 gigabitethernet1/1 Virtual Router 1 : Backup --> Master reason: The status of the tracked object changed # Display detailed information about the VRRP group on Firewall B. <FirewallB> display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface gigabitethernet1/1 VRID : 1 Adver Timer : 1 Admin Status : Up State : Master Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 0 Auth Type : None Virtual IP : Virtual MAC : e Master IP : VRRP Track Information: Track Object : 1 State : Negative Switchover The output shows that when BFD detects that Firewall A fails, it notifies VRRP through the Track module to change the status of Firewall B to master without waiting for a period three times the advertisement interval. This ensures that a backup can quickly preempt as the master. Configuring BFD for the VRRP master to monitor the uplink The following matrix shows the configuration example and hardware compatibility: Hardware F1000-A-EI/F1000-S-EI F1000-E F5000 F5000-S/F5000-C VPN firewall modules Compatibility No No Yes No No 81

89 Hardware 20-Gbps VPN firewall modules Compatibility No Network requirements As shown in Figure 40, Firewall A and Firewall B belong to VRRP group 1, whose virtual IP address is The default gateway of the hosts in the LAN is When Firewall A works correctly, hosts in the LAN access the external network through Firewall A. When Firewall A detects that the uplink is down through BFD, it decreases its priority so that Firewall B can preempt as the master, ensuring that the hosts in the LAN can access the external network through Firewall B. Figure 40 Network diagram Configuration procedure 1. Configure BFD on Firewall A: # Configure the source address of BFD echo packets as <FirewallA> system-view [FirewallA] bfd echo-source-ip Create the track entry to associate with the BFD session on Firewall A: # Create track entry 1 for the BFD session on Firewall A to check whether the uplink device with the IP address is reachable. [FirewallA] track 1 bfd echo interface gigabitethernet1/1 remote ip local ip Configure VRRP on Firewall A: 82

90 # Create VRRP group 1, and configure the virtual IP address of the group as Configure the priority of Firewall A in VRRP group 1 as 110, and configure VRRP group 1 to monitor the status of track entry 1. When the status of the track entry becomes Negative, the priority of Firewall A decreases by 20. [FirewallA] interface gigabitethernet 1/2 [FirewallA-gigabitethernet 1/2] vrrp vrid 1 virtual-ip [FirewallA-gigabitethernet 1/2] vrrp vrid 1 priority 110 [FirewallA-gigabitethernet 1/2] vrrp vrid 1 track 1 reduced 20 [FirewallA-gigabitethernet 1/2] return 4. Configure VRRP on Firewall B: # Create VRRP group 1, and configure the virtual IP address of the group as <FirewallB> system-view [FirewallB] interface gigabitethernet 1/2 [FirewallB-gigabitethernet 1/2] vrrp vrid 1 virtual-ip [FirewallB-gigabitethernet 1/2] return Verifying the configuration # Display detailed information about the VRRP group on Firewall A. <FirewallA> display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface gigabitethernet 1/2 VRID : 1 Adver Timer : 1 Admin Status : Up State : Master Config Pri : 110 Running Pri : 110 Preempt Mode : Yes Delay Time : 0 Auth Type : None Virtual IP : Virtual MAC : e Master IP : VRRP Track Information: Track Object : 1 State : Positive Pri Reduced : 20 # Display information about track entry 1 on Firewall A. <FirewallA> display track 1 Track ID: 1 Status: Positive Duration: 0 days 0 hours 0 minutes 32 seconds Notification delay: Positive 0, Negative 0 (in seconds) Reference object: BFD session: Packet type: Echo Interface : gigabitethernet 1/1 Remote IP : Local IP : # Display detailed information about the VRRP group on Firewall B. <FirewallB> display vrrp verbose 83

91 IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface gigabitethernet 1/2 VRID : 1 Adver Timer : 1 Admin Status : Up State : Backup Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 0 Become Master : 2200ms left Auth Type : None Virtual IP : Master IP : The output shows that when the status of track entry 1 becomes Positive, Firewall A is the master and Firewall B the backup. # When the uplink of Firewall A goes down, the status of track entry 1 becomes Negative. <FirewallA> display track 1 Track ID: 1 Status: Negative Duration: 0 days 0 hours 0 minutes 32 seconds Notification delay: Positive 0, Negative 0 (in seconds) Reference object: BFD session: Packet type: Echo Interface : gigabitethernet 1/1 Remote IP : Local IP : # Display detailed information about the VRRP group on Firewall A. <FirewallA> display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface gigabitethernet 1/2 VRID : 1 Adver Timer : 1 Admin Status : Up State : Backup Config Pri : 110 Running Pri : 90 Preempt Mode : Yes Delay Time : 0 Become Master : 2200ms left Auth Type : None Virtual IP : Master IP : VRRP Track Information: Track Object : 1 State : Negative Pri Reduced : 20 # Display detailed information about VRRP group 1 on Firewall B. <FirewallB> display vrrp verbose IPv4 Standby Information: 84

92 Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface gigabitethernet 1/2 VRID : 1 Adver Timer : 1 Admin Status : Up State : Master Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 0 Auth Type : None Virtual IP : Virtual MAC : e Master IP : The output shows that when Firewall A detects that the uplink fails through BFD, it decreases its priority by 20 to make sure that Firewall B can preempt as the master. Static routing-track-nqa collaboration configuration example Network requirements As shown in Figure 41, Firewall A, Firewall B, Router A, and Router B are connected to two segments /24 and /24. Configure static routes on these routers so that the two segments can communicate with each other. Configure route backup to improve network reliability. Firewall A is the default gateway of the hosts in segment /24. Two static routes to /24 exist on Firewall A, with the next hop being Router A and Router B, respectively. These two static routes back up each other, where: The static route with Router A as the next hop has a higher priority, and is the master route. If this route is available, Firewall A forwards packets to /24 through Router A. The static route with Router B as the next hop acts as the backup route. Configure static routing-track-nqa collaboration to determine whether the master route is available in real time. If the master route is unavailable, the backup route takes effect, and Firewall A forwards packets to /24 through Router B. Similarly, Firewall B is the default gateway of the hosts in segment /24. Two static routes to /24 exist on Firewall B, with the next hop being Router A and Router B, respectively. These two static routes back up each other, where: The static route with Router A as the next hop has a higher priority, and is the master route. If this route is available, Firewall B forwards packets to /24 through Router A. The static route with Router B as the next hop acts as the backup route. Configure static routing-track-nqa collaboration to determine whether the master route is available in real time. If the master route is unavailable, the backup route takes effect, and Firewall B forwards packets to /24 through Router B. 85

93 Figure 41 Network diagram Configuration procedure 1. Configure the IP address of each interface as shown in Figure 41. (Details not shown.) 2. Configure Firewall A: # Configure a static route to /24, with the address of the next hop as and the default priority 60. This static route is associated with track entry 1. <FirewallA> system-view [FirewallA] ip route-static track 1 # Configure a static route to /24, with the address of the next hop as and the priority 80. [FirewallA] ip route-static preference 80 # Configure a static route to , with the address of the next hop as [FirewallA] ip route-static # Create an NQA test group with the administrator admin and the operation tag test. [FirewallA] nqa entry admin test # Configure the test type as ICMP-echo. [FirewallA-nqa-admin-test] type icmp-echo # Configure the destination address of the test as and the next hop address as to check the connectivity of the path from Firewall A to Router A, and then to Firewall B through NQA. [FirewallA-nqa-admin-test-icmp-echo] destination ip [FirewallA-nqa-admin-test-icmp-echo] next-hop # Configure the test frequency as 100 ms. [FirewallA-nqa-admin-test-icmp-echo] frequency 100 # Configure reaction entry 1, specifying that five consecutive probe failures trigger the Track module. [FirewallA-nqa-admin-test-icmp-echo] reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only [FirewallA-nqa-admin-test-icmp-echo] quit # Start the NQA test. 86

94 [FirewallA] nqa schedule admin test start-time now lifetime forever # Configure track entry 1, and associate it with reaction entry 1 of the NQA test group (with the administrator admin, and the operation tag test). [FirewallA] track 1 nqa entry admin test reaction 1 3. Configure Router A: # Configure a static route to /24, with the address of the next hop as <RouterA> system-view [RouterA] ip route-static # Configure a static route to /24, with the address of the next hop as [RouterA] ip route-static Configure Router B: # Configure a static route to /24, with the address of the next hop as <RouterB> system-view [RouterB] ip route-static # Configure a static route to /24, with the address of the next hop as [RouterB] ip route-static Configure Firewall B: # Configure a static route to /24, with the address of the next hop as and the default priority 60. This static route is associated with track entry 1. <FirewallB> system-view [FirewallB] ip route-static track 1 # Configure a static route to /24, with the address of the next hop as and the default priority 80. [FirewallB] ip route-static preference 80 # Configure a static route to , with the address of the next hop as [FirewallB] ip route-static # Create an NQA test group with the administrator admin and the operation tag test. [FirewallB] nqa entry admin test # Configure the test type as ICMP-echo. [FirewallB-nqa-admin-test] type icmp-echo # Configure the destination address of the test as and the next hop address as to check the connectivity of the path from Firewall B to Router A, and then to Firewall A through NQA. [FirewallB-nqa-admin-test-icmp-echo] destination ip [FirewallB-nqa-admin-test-icmp-echo] next-hop # Configure the test frequency as 100 ms. [FirewallB-nqa-admin-test-icmp-echo] frequency 100 # Configure reaction entry 1, specifying that five consecutive probe failures trigger the Track module. [FirewallB-nqa-admin-test-icmp-echo] reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only [FirewallB-nqa-admin-test-icmp-echo] quit # Start the NQA test. [FirewallB] nqa schedule admin test start-time now lifetime forever 87

95 # Configure track entry 1, and associate it with reaction entry 1 of the NQA test group (with the administrator admin, and the operation tag test). [FirewallB] track 1 nqa entry admin test reaction 1 Verifying the configuration # Display information about the track entry on Firewall A. [FirewallA] display track all Track ID: 1 Status: Positive Duration: 0 days 0 hours 0 minutes 32 seconds Notification delay: Positive 0, Negative 0 (in seconds) Reference object: NQA entry: admin test Reaction: 1 # Display the routing table of Firewall A. [FirewallA] display ip routing-table Routing Tables: Public Destinations : 10 Routes : 10 Destination/Mask Proto Pre Cost NextHop Interface /24 Direct GE0/ /32 Direct InLoop /24 Static GE0/ /24 Direct GE0/ /32 Direct InLoop /24 Direct GE0/ /32 Direct InLoop /24 Static GE0/ /8 Direct InLoop /32 Direct InLoop0 The output shows the NQA test result: the master route is available (the status of the track entry is Positive), and Firewall A forwards packets to /24 through Router A. # Remove the IP address of interface Ethernet 1/1 on Router A. <RouterA> system-view [RouterA] interface ethernet 1/1 [RouterA-Ethernet1/1] undo ip address # Display information about the track entry on Firewall A. [FirewallA] display track all Track ID: 1 Status: Negative Duration: 0 days 0 hours 0 minutes 32 seconds Notification delay: Positive 0, Negative 0 (in seconds) Reference object: NQA entry: admin test Reaction: 1 # Display the routing table of Firewall A. 88

96 [FirewallA] display ip routing-table Routing Tables: Public Destinations : 10 Routes : 10 Destination/Mask Proto Pre Cost NextHop Interface /24 Direct GE0/ /32 Direct InLoop /24 Static GE0/ /24 Direct GE0/ /32 Direct InLoop /24 Direct GE0/ /32 Direct InLoop /24 Static GE0/ /8 Direct InLoop /32 Direct InLoop0 The output shows the NQA test result: if the master route is unavailable (the status of the track entry is Negative), the backup static route takes effect and Firewall A forwards packets to /24 through Router B. # When the master route fails, the hosts in /24 can still communicate with the hosts in /24. [FirewallA] ping -a PING : 56 data bytes, press CTRL_C to break Reply from : bytes=56 Sequence=1 ttl=254 time=2 ms Reply from : bytes=56 Sequence=2 ttl=254 time=1 ms Reply from : bytes=56 Sequence=3 ttl=254 time=1 ms Reply from : bytes=56 Sequence=4 ttl=254 time=2 ms Reply from : bytes=56 Sequence=5 ttl=254 time=1 ms ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/2 ms # The output on Firewall B is similar to that on Firewall A. When the master route fails, the hosts in /24 can still communicate with the hosts in /24. [FirewallB] ping -a PING : 56 data bytes, press CTRL_C to break Reply from : bytes=56 Sequence=1 ttl=254 time=2 ms Reply from : bytes=56 Sequence=2 ttl=254 time=1 ms Reply from : bytes=56 Sequence=3 ttl=254 time=1 ms Reply from : bytes=56 Sequence=4 ttl=254 time=1 ms Reply from : bytes=56 Sequence=5 ttl=254 time=1 ms ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/2 ms 89

97 VRRP-Track-interface management collaboration configuration example In this example, the master monitors the uplink interface. Network requirements As shown in Figure 42, Host A needs to access Host B on the Internet. The default gateway of Host A is /24. Firewall A and Firewall B belong to VRRP group 1, whose virtual IP address is When Firewall A operates correctly, packets from Host A to Host B are forwarded through Firewall A. When VRRP detects that a fault is on the uplink interface of Firewall A through the interface management module, packets from Host A to Host B are forwarded through Firewall B. Figure 42 Network diagram Configuration procedure 1. Configure the IP address of each interface as shown in Figure 42. (Details not shown.) 2. Configure a track entry on Firewall A: # Configure track entry 1, and associate it with the physical status of the uplink interface GigabitEthernet 0/2. [FirewallA] track 1 interface gigabitethernet0/2 3. Configure VRRP on Firewall A: # Create VRRP group 1, and configure the virtual IP address for the group. [FirewallA] interface gigabitethernet0/1 [FirewallA-GigabitEthernet0/1] vrrp vrid 1 virtual-ip # Set the priority of Firewall A in VRRP group 1 to 110. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 priority 110 # Configure to monitor track entry 1 and specify the priority decrement as 30. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 track 1 reduced Configure VRRP on Firewall B: <FirewallB> system-view [FirewallB] interface gigabitethernet0/1 90

98 Verifying the configuration # Create VRRP group 1 and configure the virtual IP address for the group. [FirewallB-GigabitEthernet0/1] vrrp vrid 1 virtual-ip After configuration, ping Host B on Host A, and you can see that Host B is reachable. Use the display vrrp command to view the configuration result. # Display detailed information about VRRP group 1 on Firewall A. [FirewallA-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 1 Admin Status : Up State : Master Config Pri : 110 Running Pri : 110 Preempt Mode : Yes Delay Time : 0 Auth Type : None Virtual IP : Virtual MAC : e Master IP : VRRP Track Information: Track Object : 1 State : Positive Pri Reduced : 30 # Display detailed information about VRRP group 1 on Firewall B. [FirewallB-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 1 Admin Status : Up State : Backup Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 0 Become Master : 2200ms left Auth Type : None Virtual IP : Master IP : The output shows that in VRRP group 1, Firewall A is the master and Firewall B is a backup. Packets from Host A to Host B are forwarded through Firewall A. # Shut down the uplink interface GigabitEthernet 0/2 on Firewall A. [FirewallA-GigabitEthernet0/1] interface gigabitethernet0/2 [FirewallA-GigabitEthernet0/2] shutdown After shutting down the uplink interface on Firewall A, you can still successfully ping Host B on Host A. Use the display vrrp command to view information about VRRP group 1. # After shutting down the uplink interface on Firewall A, display detailed information about VRRP group 1 on Firewall A. 91

99 [FirewallA-GigabitEthernet0/2] display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 1 Admin Status : Up State : Backup Config Pri : 110 Running Pri : 80 Preempt Mode : Yes Delay Time : 0 Become Master : 2200ms left Auth Type : None Virtual IP : Master IP : VRRP Track Information: Track Object : 1 State : Negative Pri Reduced : 30 # After shutting down the uplink interface on Firewall A, display detailed information about VRRP group 1 on Firewall B. [FirewallB-GigabitEthernet0/1] display vrrp verbose IPv4 Standby Information: Run Mode : Standard Run Method : Virtual MAC Total number of virtual routers : 1 Interface GigabitEthernet0/1 VRID : 1 Adver Timer : 1 Admin Status : Up State : Master Config Pri : 100 Running Pri : 100 Preempt Mode : Yes Delay Time : 0 Auth Type : None Virtual IP : Virtual MAC : e Master IP : The output shows that when the uplink interface on Firewall A is shut down, the priority of Firewall A decreases to 80. Firewall A becomes the backup, and Firewall B becomes the master. Packets from Host A to Host B are forwarded through Firewall B. 92

100 Configuring a collaboration group Overview You can add ports on a device to one group called "collaboration group." All ports in the group have consistent state. They are either able or unable to forward packets at the same time. Collaboration group is mainly used to trigger the downlink port state based on the uplink port state, and implement fast link switchover. As shown in Figure 43, LAN users Host A, Host B and Host C access the Internet through Device B. When the interface on Device B connecting Device A goes down, the traffic switches from Device B to the standby device Device C because dynamic routing is enabled in the network. However, because the link connecting Device B and the LAN is still up, the time required for dynamic route update is long and the traffic switchover is slow, which greatly affect the LAN users' access to the Internet. Figure 43 Network diagram After you assign Device B's ports connecting Device A and the LAN to a collaboration group, the following happens: When the physical state of any port in the collaboration group is down, the other ports in the collaboration group are set to the linkgroup-down state, and cannot exchange traffic with the peers. The collaboration group is in down state. When the port that was physically down goes up, the system tries to bring up the other ports in the collaboration group. If they go up in ten seconds, the collaboration group goes up; if any port fails to go up, all the other ports are set to the linkgroup-down state. The collaboration group is in down state. 93

101 Configuring a collaboration group in the web interface Assigning interfaces to a collaboration group By default, 24 collaboration groups numbered from 1 to 24 exist in the system, and the groups do not contain any interface. To assign interfaces to a collaboration group: 1. Select High Reliability > Collaboration Group from the navigation tree. The page for displaying collaboration groups appears. Figure 44 Managing collaboration groups 2. Click the icon for a collaboration group. As shown in Figure 45, the page displays the member interfaces of the collaboration group (the boxes selected) and interfaces that are not assigned to any collaboration group (the boxes are not selected). 94

102 Figure 45 Configuring a collaboration group 3. Select the boxes of interfaces to be assigned to the collaboration group. The number of interfaces assigned to the collaboration group must be no more than the maximum supported interface number displayed on the page. 4. Click Apply. When you assign interfaces to a collaboration group, follow these guidelines: A port can belong to only one collaboration group. Do not assign the port that is used to log in to the Web interface and ports that are down to the same collaboration group. Otherwise, the device will be disconnected. When a device is connected to another device through multiple interface, do not assign these interfaces to the same collaboration group. Otherwise, when one interface goes down, its peer interface on the remote device might be set to the Linkgroup-down state. In that case, all the interfaces might fail to be brought up. Viewing the status of a collaboration group and its member ports 1. Select High Reliability > Collaboration Group from the navigation tree. The page for displaying collaboration groups appears, as shown in Figure 44. A collaboration group can be in one of the following states: Initial The collaboration group has no member interface. Up All the member interfaces in the collaboration group are up. Down At least one interface in the collaboration group is down, and other interfaces are Linkgroup-down. Ambiguous The collaboration group state is uncertain and will be stable in ten seconds. 2. Click the icon for a collaboration group to enter the page for configuring the collaboration group, as shown in Figure 45. The selected interfaces are the member interfaces of the collaboration group. The interfaces can be in one of the following states: 95

103 Up The interface is physically up. Down The interface is physically down. Linkgroup-down The interface is forcibly shut down by the collaboration group and cannot transmit packets. Collaboration group configuration example Network requirements As shown in Figure 46, LAN users Host A, Host B, and Host C access the Internet through Firewall A. Firewall B serves as a backup for Firewall A. Configure on Firewall A so that when the link connecting Device and Firewall A goes down, the traffic rapidly switches from Firewall A to Firewall B. Figure 46 Network diagram Configuring Firewall A To assign GigabitEthernet 0/1 and GigabitEthernet 0/2 to Collaboration Group 1: 1. Select High Reliability > Collaboration Group from the navigation tree of Firewall A. 2. Click the icon for Collaboration Group Select GigabitEthernet 0/1 and GigabitEthernet 0/2. 4. Click Apply. 96

104 Figure 47 Assigning GigabitEthernet 0/1 and GigabitEthernet 0/2 to Collaboration Group 1 Verifying the configuration 1. Remove the cable connecting Device to GigabitEthernet 0/2 on Firewall A. 2. Select High Reliability > Collaboration Group from the navigation tree of Firewall A, and check the status of Collaboration Group 1. The page that appears shows that the status of Collaboration Group 1 is down. Figure 48 Checking the status of Collaboration Group 1 3. Click the icon for Collaboration Group 1 and check the status of its member ports. The page that appear shows that the status of GigabitEthernet 0/1 is down and that of GigabitEthernet 0/2 is Linkgroup-down. 97

105 Figure 49 Checking the status of Collaboration Group 1's member ports Configuring a collaboration group at the CLI Configuring a collaboration group Perform the following operation on multiple interfaces to add them to a collaboration group. An interface can belong to only one collaboration group. A collaboration group can have at most eight interfaces. When a device is connected to another device through multiple ports, do not assign these ports to the same collaboration group. Otherwise, when one port goes down, its peer port on the remote device might be set to the linkgroup-down state. In that case, all the ports might fail to be brought up. To configure a collaboration group: Step Command Remarks Enter system view. system-view N/A Enter interface view. interface interface-type interface-number N/A Add the interface to the specified collaboration group. link-group link-group-number By default, an interface does not belong to any collaboration group. Displaying and maintaining collaboration group Task Command Remarks Display the collaboration group information display link-group [ number link-group-number brief ] [ { begin exclude include } regular-expression ] Available in any view. 98

106 Collaboration group configuration example Network requirements As shown in Figure 50, LAN users Host A, Host B, and Host C access the Internet through Firewall A. Firewall B serves as a backup for Firewall A. Configure Firewall A so that when the link connecting Device and Firewall A goes down, the traffic rapidly switches from Firewall A to Firewall B. Figure 50 Network diagram Configuration procedure # Assign GigabitEthernet 0/1 and GigabitEthernet 0/2 on Firewall A to collaboration group 1. <FirewallA> system-view [FirewallA] interface gigabitethernet 0/1 [FirewallA-GigabitEthernet0/1] link-group 1 [FirewallA-GigabitEthernet0/1] quit [FirewallA] interface gigabitethernet 0/2 [FirewallA-GigabitEtherne0/2] link-group 1 [FirewallA-GigabitEtherne0/2] quit Verifying the configuration # Remove the cable connecting Device to GigabitEthernet 0/1 on Firewall A, and check the status of collaboration group 1 and its member ports. The status of GigabitEthernet 0/1 is down, and that of GigabitEthernet 0/2 is linkgroup-down. [FirewallA] display link-group Group Number: 1 Group Status: Down Interface Information: Interface Name Interface Status GigabitEthernet0/1 Down GigabitEthernet0/2 Linkgroup-down 99

107 Configuring NQA NQA can be configured only at the CLI. Overview Network quality analyzer (NQA) allows you to monitor link status, measure network performance, verify the service levels for IP services and applications, and troubleshoot network problems. It provides the following types of operations: ICMP echo DHCP DNS FTP HTTP UDP jitter SNMP TCP UDP echo Voice Data Link Switching (DLSw) As shown in Figure 51, the NQA source device (NQA client) sends data to the NQA destination device by simulating IP services and applications to measure network performance. The obtained performance metrics include the one-way latency, jitter, packet loss, voice quality, application performance, and server response time. All types of NQA operations require the NQA client, but only the TCP, UDP echo, UDP jitter, and voice operations require the NQA server. The NQA operations for services that are already provided by the destination device such as FTP do not need the NQA server. You can configure the NQA server to listen and respond on specific ports to meet various test needs. Figure 51 Network diagram Collaboration NQA can collaborate with the Track module to notify application modules of state or performance changes so that the application modules can take predefined actions. 100

108 Figure 52 Collaboration The following describes how a static route destined for is monitored through collaboration: 1. NQA monitors the reachability to When becomes unreachable, NQA notifies the Track module of the change. 3. The Track module notifies the static routing module of the state change. 4. The static routing module sets the static route as invalid according to a predefined action. For more information about collaboration, see High Availability Configuration Guide. Threshold monitoring Threshold monitoring enables the NQA client to display results or send trap messages to the network management station (NMS) when the performance metrics that an NQA operation gathers violate the specified thresholds. Table 7 describes the relationships between performance metrics and NQA operation types. Table 7 Performance metrics and NQA operation types Performance metric Probe duration Number of probe failures Round-trip time Number of discarded packets One-way jitter (source-to-destination and destination-to-source) One-way latency (source-to-destination and destination-to-source) Calculated Planning Impairment Factor (ICPIF) (see "Configuring a voice operation") Mean Opinion Scores (MOS) (see "Configuring a voice operation") NQA operation types that can gather the metric All NQA operation types excluding UDP jitter and voice All NQA operation types excluding UDP jitter and voice UDP jitter and voice UDP jitter and voice UDP jitter and voice UDP jitter and voice Voice Voice 101

109 NQA configuration task list Complete the following task to configure the NQA server: Task Configuring the NQA server Remarks Required for NQA operations types of TCP, UDP echo, UDP jitter, and voice. Complete these tasks to configure the NQA client: Task Enabling the NQA client Remarks Required. Configuring an ICMP echo operation Configuring a DHCP operation Configuring a DNS operation Configuring an FTP operation Configuring an HTTP operation Configuring a UDP jitter operation Configuring an SNMP operation Required. Use at least one method. Configuring a TCP operation Configuring a UDP echo operation Configuring a voice operation Configuring a DLSw operation Configuring optional parameters for an NQA operation Configuring the collaboration function Configuring threshold monitoring Configuring the NQA statistics function Configuring NQA history records saving function Scheduling an NQA operation Optional. Optional. Optional. Optional. Optional. Required. Configuring the NQA server To perform TCP, UDP echo, UDP jitter, and voice operations, you must enable the NQA server on the destination device. The NQA server listens and responds to requests on the specified IP addresses and ports. You can configure multiple TCP (or UDP) listening services on an NQA server, each of which corresponds to a specific destination IP address and port number. The destination IP address and port number must be the same as those configured on the NQA client and must be different from those of an existing listening service. 102

110 To configure the NQA server: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable the NQA server. nqa server enable Disabled by default. 3. Configure a listening service. Method 1: nqa server tcp-connect ip-address port-number Method 2: nqa server udp-echo ip-address port-number Use at least one method. Configuring the NQA client Enabling the NQA client Step Command Remarks 1. Enter system view. system-view N/A 2. Enable the NQA client. nqa agent enable Optional. Enabled by default. Configuring an ICMP echo operation An ICMP echo operation measures the reachability of a destination device. It has the same function as the ping command, but provides more output information. In addition, if multiple paths exist between the source and destination devices, you can specify the next hop for the ICMP echo operation. The ICMP echo operation is not supported in IPv6 networks. To test the reachability of an IPv6 address, use the ping ipv6 command. For more information about the command, see System Management and Maintenance Command Reference. To configure an ICMP echo operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify the ICMP echo type and enter its view. 4. Specify the destination address of ICMP echo requests. 5. Specify the payload size in each ICMP echo request. nqa entry admin-name operation-tag type icmp-echo destination ip ip-address data-size size By default, no NQA operation is created. N/A By default, no destination IP address is configured. Optional. 100 bytes by default. 103

111 Step Command Remarks 6. Configure the string to be filled in the payload of each ICMP echo request. 7. Specify the VPN where the operation is performed. 8. Specify the source interface and the source IP address of ICMP echo requests. 9. Configure the next hop IP address for ICMP echo requests. data-fill string vpn-instance vpn-instance-name Method 1: source interface interface-type interface-number Method 2: source ip ip-address next-hop ip-address Optional. By default, the string is the hexadecimal number Optional. By default, the operation is performed on the public network. This command is available only for the ICMP echo operation. Optional. By default, no source interface or source IP address is configured. The requests take the primary IP address of the outgoing interface as their source IP address. If you configure both the source ip command and the source interface command, the source ip command takes effect. The specified source interface must be up. The source IP address must be the IP address of a local interface and the interface must be up. Optional. By default, no next hop IP address is configured. Configuring a DHCP operation A DHCP operation measures the time the NQA client uses to get an IP address from a DHCP server. The specified interface simulates the DHCP client to acquire an IP address and it does not change its IP address. When the DHCP operation completes, the NQA client sends a packet to release the obtained IP address. To configure a DHCP operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify the DHCP type and enter its view. nqa entry admin-name operation-tag type dhcp By default, no NQA operation is created. N/A 104

112 Step Command Remarks 4. Specify an interface to perform the DHCP operation. operation interface interface-type interface-number By default, no interface is specified to perform a DHCP operation. The specified interface must be up. Otherwise, no probe packets can be sent out. Configuring a DNS operation A DNS operation measures the time the NQA client uses to translate a domain name into an IP address through a DNS server. A DNS operation simulates domain name resolution and does not save the obtained DNS entry. To configure a DNS operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify the DNS type and enter its view. 4. Specify the IP address of the DNS server as the destination address of DNS packets. 5. Configure the domain name that needs to be translated. nqa entry admin-name operation-tag type dns destination ip ip-address resolve-target domain-name By default, no NQA operation is created. N/A By default, no destination IP address is configured. By default, no domain name is configured. Configuring an FTP operation An FTP operation measures the time the NQA client uses to transfer a file to or download a file from an FTP server. Follow these guidelines when you configure an FTP operation: Before you perform an FTP operation, obtain the username and password for logging in to the FTP server. When you execute the put command, the NQA client creates a file named file-name of fixed size on the FTP server. When you execute the get command, the client does not save the file obtained from the FTP server. If you get a file that does not exist on the FTP server, the FTP operation fails. Only use the get command to download a small file. A big file might result in transfer failure because of timeout, or might affect other services for occupying much network bandwidth. To configure an FTP operation: 105

113 Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify the FTP type and enter its view. 4. Specify the IP address of the FTP server as the destination address of FTP request packets. 5. Configure the source IP address of FTP request packets. nqa entry admin-name operation-tag type ftp destination ip ip-address source ip ip-address By default, no NQA operation is created. N/A By default, no destination IP address is configured. By default, no source IP address is specified. The source IP address must be the IP address of a local interface. The local interface must be up. Otherwise, no FTP requests can be sent out. 6. Specify the operation type. operation { get put } 7. Configure a login username. username name Optional. By default, the operation type for the FTP operation is get, which means obtaining files from the FTP server. Optional. By default, no login username is configured. 8. Configure a login password. 9. Specify the name of a file to be transferred. 10. Set the data transmission mode. password [ cipher simple ] password filename file-name mode { active passive } Optional. By default, no login password is configured. By default, no file is specified. Optional. active by default. Configuring an HTTP operation An HTTP operation measures the time the NQA client uses to obtain data from an HTTP server. The TCP port number of the HTTP server must be 80. Otherwise, the HTTP operation fails. To configure an HTTP operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. nqa entry admin-name operation-tag By default, no NQA operation is created. 106

114 Step Command Remarks 3. Specify the HTTP type and enter its view. 4. Configure the IP address of the HTTP server as the destination address of HTTP request packets. type http destination ip ip-address N/A By default, no destination IP address is configured. 5. Configure the source IP address of request packets. source ip ip-address Optional. By default, no source IP address is specified. The source IP address must be the IP address of a local interface. The local interface must be up. Otherwise, no request packets can be sent out. 6. Configure the operation type. operation { get post } 7. Specify the destination website URL. url url 8. Specify the HTTP version. http-version v1.0 Optional. By default, the operation type for the HTTP is get, which means obtaining data from the HTTP server. N/A Optional. By default, HTTP 1.0 is used. Configuring a UDP jitter operation CAUTION: Do not perform the UDP jitter operation to well-known ports from 1 to Otherwise, the UDP jitter operation might fail or the service on the well-known port becomes unavailable. Jitter means inter-packet delay variance. A UDP jitter operation measures unidirectional and bidirectional jitters so that you can verify whether the network can carry jitter-sensitive services such as real-time voice and video services. The UDP jitter operation works as follows: 1. The NQA client sends UDP packets to the destination port at a regular interval. 2. The destination device takes a time stamp to each packet that it receives, and then sends the packet back to the NQA client. 3. Upon receiving the responses, the NQA client calculates the jitter according to the time stamps. The UDP jitter operation requires both the NQA server and the NQA client. Before you perform the UDP jitter operation, configure the UDP listening service on the NQA server. For more information about UDP listening service configuration, see "Configuring the NQA server." To configure a UDP jitter operation: 107

115 Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify the UDP jitter type and enter its view. 4. Configure the destination address of UDP packets. 5. Configure the destination port of UDP packets. 6. Specify the source port number of UDP packets. 7. Configure the payload size in each UDP packet. 8. Configure the string to be filled in the payload of each UDP packet. 9. Configure the number of UDP packets sent in one UDP jitter probe. 10. Configure the interval for sending UDP packets. 11. Configure how long the NQA client waits for a response from the server before it regards the response times out. 12. Configure the source IP address for UDP packets. nqa entry admin-name operation-tag type udp-jitter destination ip ip-address destination port port-number source port port-number data-size size data-fill string probe packet-number packet-number probe packet-interval packet-interval probe packet-timeout packet-timeout source ip ip-address By default, no NQA operation is created. N/A By default, no destination IP address is configured. The destination IP address must be the same as that of the listening service on the NQA server. By default, no destination port number is configured. The destination port must be the same as that of the listening service on the NQA server. Optional. By default, no source port number is specified. Optional. 100 bytes by default. Optional. By default, the string is the hexadecimal number Optional. 10 by default. Optional. 20 milliseconds by default. Optional milliseconds by default. Optional. By default, no source IP address is specified. The source IP address must be the IP address of a local interface. The local interface must be up. Otherwise, no UDP packets can be sent out. 108

116 NOTE: The display nqa history command does not show the results of the UDP jitter operation. Use the display nqa result command to display the results, or use the display nqa statistics command to display the statistics of the operation. Configuring an SNMP operation An SNMP operation measures the time the NQA client uses to get a value from an SNMP agent. To configure an SNMP operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify the SNMP type and enter its view. 4. Configure the destination address of SNMP packets. 5. Specify the source port of SNMP packets. 6. Configure the source IP address of SNMP packets. nqa entry admin-name operation-tag type snmp destination ip ip-address source port port-number source ip ip-address By default, no NQA operation is created. N/A By default, no destination IP address is configured. Optional. By default, no source port number is specified. Optional. By default, no source IP address is specified. The source IP address must be the IP address of a local interface. The local interface must be up. Otherwise, no SNMP packets can be sent out. Configuring a TCP operation A TCP operation measures the time the NQA client uses to establish a TCP connection to a specific port on the NQA server. The TCP operation requires both the NQA server and the NQA client. Before you perform a TCP operation, configure a TCP listening service on the NQA server. For more information about the TCP listening service configuration, see "Configuring the NQA server." To configure a TCP operation: Step Command Remarks 1. Enter system view. system-view N/A 109

117 Step Command Remarks 2. Create an NQA operation and enter NQA operation view. 3. Specify the TCP type and enter its view. nqa entry admin-name operation-tag type tcp By default, no NQA operation is created. N/A 4. Configure the destination address of TCP packets. 5. Configure the destination port of TCP packets. 6. Configure the source IP address of TCP packets. destination ip ip-address destination port port-number source ip ip-address By default, no destination IP address is configured. The destination address must be the same as the IP address of the listening service configured on the NQA server. By default, no destination port number is configured. The destination port number must be the same as that of the listening service on the NQA server. Optional. By default, no source IP address is specified. The source IP address must be the IP address of a local interface. The local interface must be up. Otherwise, no TCP packets can be sent out. Configuring a UDP echo operation A UDP echo operation measures the round-trip time between the client and a specific UDP port on the NQA server. The UDP echo operation requires both the NQA server and the NQA client. Before you perform a UDP echo operation, configure a UDP listening service on the NQA server. For more information about the UDP listening service configuration, see "Configuring the NQA server." To configure a UDP echo operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify the UDP echo type and enter its view. nqa entry admin-name operation-tag type udp-echo By default, no NQA operation is created. N/A 110

118 Step Command Remarks 4. Configure the destination address of UDP packets. 5. Configure the destination port of UDP packets. 6. Configure the payload size in each UDP packet. 7. Configure the string to be filled in the payload of each UDP packet. 8. Specify the source port of UDP packets. 9. Configure the source IP address of UDP packets. destination ip ip-address destination port port-number data-size size data-fill string source port port-number source ip ip-address By default, no destination IP address is configured. The destination address must be the same as the IP address of the listening service configured on the NQA server. By default, no destination port number is configured. The destination port number must be the same as that of the listening service on the NQA server. Optional. 100 bytes by default. Optional. By default, the string is the hexadecimal number Optional. By default, no source port number is specified. Optional. By default, no source IP address is specified. The source IP address must be that of an interface on the device and the interface must be up. Otherwise, no UDP packets can be sent out. Configuring a voice operation CAUTION: Do not perform a voice operation to a well-known port from 1 to Otherwise, the NQA operation might fail or the service on that port becomes unavailable. A voice operation measures voice over IP (VoIP) network performance. A voice operation works as follows: 1. The NQA client sends voice packets of G.711 A-law, G.711 μ-law or G.729 A-law codec type at a specific interval to the destination device (NQA server). 2. The destination device takes a time stamp to each voice packet it receives and sends it back to the source. 3. Upon receiving the packet, the source device calculates the jitter and one-way delay based on the time stamp. 111

119 The following parameters that reflect VoIP network performance can be calculated by using the metrics gathered by the voice operation: Calculated Planning Impairment Factor (ICPIF) Measures impairment to voice quality in a VoIP network. It is decided by packet loss and delay. A higher value represents a lower service quality. Mean Opinion Scores (MOS) A MOS value can be evaluated by using the ICPIF value, in the range of 1 to 5. A higher value represents a higher service quality. The evaluation of voice quality depends on users' tolerance for voice quality, which you should consider. For users with higher tolerance for voice quality, use the advantage-factor command to configure the advantage factor. When the system calculates the ICPIF value, it subtracts the advantage factor to modify ICPIF and MOS values, so both objective and subjective factors are considered. The voice operation requires both the NQA server and the NQA client. Before you perform a voice operation, configure a UDP listening service on the NQA server. For more information about UDP listening service configuration, see "Configuring the NQA server." A voice operation cannot repeat. To configure a voice operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify the voice type and enter its view. 4. Configure the destination address of voice packets. 5. Configure the destination port of voice packets. 6. Specify the codec type. 7. Configure the advantage factor for calculating MOS and ICPIF values. nqa entry admin-name operation-tag type voice destination ip ip-address destination port port-number codec-type { g711a g711u g729a } advantage-factor factor By default, no NQA operation is created. N/A By default, no destination IP address is configured. The destination IP address must be the same as that of the listening service on the NQA server. By default, no destination port number is configured. The destination port must be the same as that of the listening service on the NQA server. Optional. By default, the codec type is G.711 A-law. Optional. By default, the advantage factor is

120 Step Command Remarks 8. Specify the source IP address of voice packets. 9. Specify the source port number of voice packets. 10. Configure the payload size in each voice packet. 11. Configure the string to be filled in the payload of each voice packet. 12. Configure the number of voice packets to be sent in a voice probe. 13. Configure the interval for sending voice packets. 14. Configure how long the NQA client waits for a response from the server before it regards the response times out. source ip ip-address source port port-number data-size size data-fill string probe packet-number packet-number probe packet-interval packet-interval probe packet-timeout packet-timeout Optional. By default, no source IP address is specified. The source IP address must be the IP address of a local interface. The local interface must be up. Otherwise, no voice packets can be sent out. Optional. By default, no source port number is specified. Optional. By default, the voice packet size depends on the codec type. The default packet size is 172 bytes for G.711A-law and G.711 μ-law codec type, and 32 bytes for G.729 A-law codec type. Optional. By default, the string is the hexadecimal number Optional by default. Optional. 20 milliseconds by default. Optional milliseconds by default. NOTE: The display nqa history command cannot show the results of the voice operation. Use the display nqa result command to display the results, or use the display nqa statistics command to display the statistics of the operation. Configuring a DLSw operation A DLSw operation measures the response time of a DLSw device. To configure a DLSw operation: Step Command Remarks 1. Enter system view. system-view N/A 113

121 Step Command Remarks 2. Create an NQA operation and enter NQA operation view. 3. Specify the DLSw type and enter its view. 4. Configure the destination address of probe packets. nqa entry admin-name operation-tag type dlsw destination ip ip-address By default, no NQA operation is created. N/A By default, no destination IP address is configured. 5. Configure the source IP address of probe packets. source ip ip-address Optional. By default, no source IP address is specified. The source IP address must be the IP address of a local interface. The local interface must be up. Otherwise, no probe packets can be sent out. Configuring optional parameters for an NQA operation Unless otherwise specified, the following optional parameters apply to all NQA operation types. The following describes how different NQA operation types operate: A TCP or DLSw operation sets up a connection. A UDP jitter or a voice operation sends a specific number of probe packets. The number of probe packets is configurable with the probe packet-number command. An FTP, HTTP, DHCP, or DNS operation uploads or downloads a file, gets a web page, gets an IP address through DHCP, or translates a domain name to an IP address. An ICMP echo or UDP echo operation sends an ICMP echo request or a UDP packet. An SNMP operation sends one SNMPv1 packet, one SNMPv2c packet, and one SNMPv3 packet. To configure optional parameters for an NQA operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify an NQA operation type and enter its view. nqa entry admin-name operation-tag type { dhcp dlsw dns ftp http icmp-echo snmp tcp udp-echo udp-jitter voice } By default, no NQA operation is created. N/A 4. Configure a description. description text Optional. By default, no description is configured. 114

122 Step Command Remarks 5. Specify the interval at which the NQA operation repeats. frequency interval Optional. By default, the interval is 0 milliseconds. Only one operation is performed. If the operation is not completed when the interval expires, the next operation does not start. 6. Specify the probe times. probe count times Optional. By default, an NQA operation performs one probe. The voice operation can perform only one probe, and does not support this command. 7. Specify the probe timeout time. 8. Specify the TTL for probe packets. 9. Specify the ToS value in the IP packet header of probe packets. 10. Enable the routing table bypass function. probe timeout timeout ttl value tos value route-option bypass-route Optional. By default, the timeout time is 3000 milliseconds. This setting is not available for the UDP jitter or voice operation. Optional. 20 by default. This setting is not available for the DHCP operation. Optional. 0 by default. This setting is not available for the DHCP operation. Optional. Disabled by default. This setting is not available for the DHCP operation. Configuring the collaboration function Collaboration is implemented by associating a reaction entry of an NQA operation a track entry. The reaction entry monitors the NQA operation. If the number of operation failures reaches the specified threshold, the configured action is triggered. To configure the collaboration function: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. nqa entry admin-name operation-tag By default, no NQA operation is created. 115

123 Step Command Remarks 3. Specify an NQA operation type and enter its view. 4. Configure a reaction entry. type { dhcp dlsw dns ftp http icmp-echo snmp tcp udp-echo } reaction item-number checked-element probe-fail threshold-type consecutive consecutive-occurrences action-type trigger-only The collaboration function is not available for the UDP jitter and voice operations. Not configured by default. You cannot modify the content of an existing reaction entry. 5. Exit to system view. quit N/A 6. Associate Track with NQA. See "Configuring Track." N/A 7. Associate Track with an application module. See "Configuring Track." N/A Configuring threshold monitoring Introduction 1. Threshold types An NQA operation supports the following threshold types: average If the average value for the monitored performance metric either exceeds the upper threshold or goes below the lower threshold, a threshold violation occurs. accumulate If the total number of times that the monitored performance metric is out of the specified value range reaches or exceeds the specified threshold, a threshold violation occurs. consecutive If the number of consecutive times that the monitored performance metric is out of the specified value range reaches or exceeds the specified threshold, a threshold violation occurs. Threshold violations for the average or accumulate threshold type are determined on a per NQA operation basis, and threshold violations for the consecutive type are determined from the time the NQA operation starts. 2. Triggered actions The following actions might be triggered: none NQA displays results only on the terminal screen. It does not send traps to the NMS. trap-only NQA displays results on the terminal screen, and meanwhile it sends traps to the NMS. The DNS operation does not support the action of sending trap messages. 3. Reaction entry In a reaction entry, a monitored element, a threshold type, and an action to be triggered are configured to implement threshold monitoring. The state of a reaction entry can be invalid, over-threshold, or below-threshold. Before an NQA operation starts, the reaction entry is in invalid state. 116

124 Configuration prerequisites If the threshold is violated, the state of the entry is set to over-threshold. Otherwise, the state of the entry is set to below-threshold. If the action to be triggered is configured as trap-only for a reaction entry, when the state of the entry changes, a trap message is generated and sent to the NMS. Before you configure threshold monitoring, configure the destination address of the trap messages by using the snmp-agent target-host command. For more information about the command, see System Management and Maintenance Command Reference. Configuration procedure To configure threshold monitoring: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify an NQA operation type and enter its view. nqa entry admin-name operation-tag type { dhcp dlsw dns ftp http icmp-echo snmp tcp udp-echo udp-jitter voice } By default, no NQA operation is created. N/A 117

125 Step Command Remarks 4. Configure threshold monitoring. Enable sending traps to the NMS when specified conditions are met: reaction trap { probe-failure consecutive-probe-failures test-complete test-failure cumulate-probe-failures } Configure a reaction entry for monitoring the duration of an NQA operation (not supported in UDP jitter and voice operations): reaction item-number checked-element probe-duration threshold-type { accumulate accumulate-occurrences average consecutive consecutive-occurrences } threshold-value upper-threshold lower-threshold [ action-type { none trap-only } ] Configure a reaction entry for monitoring failure times (not supported in UDP jitter and voice operations): reaction item-number checked-element probe-fail threshold-type { accumulate accumulate-occurrences consecutive consecutive-occurrences } [ action-type { none trap-only } ] Configure a reaction entry for monitoring the round-trip time (only supported in UDP jitter and voice operations): reaction item-number checked-element rtt threshold-type { accumulate accumulate-occurrences average } threshold-value upper-threshold lower-threshold [ action-type { none trap-only } ] Configure a reaction entry for monitoring packet loss (only supported in UDP jitter and voice operations): reaction item-number checked-element packet-loss threshold-type accumulate accumulate-occurrences [ action-type { none trap-only } ] Configure a reaction entry for monitoring one-way jitter (only supported in UDP jitter and voice operations): reaction item-number checked-element { jitter-ds jitter-sd } threshold-type { accumulate accumulate-occurrences average } threshold-value upper-threshold lower-threshold [ action-type { none trap-only } ] Configure a reaction entry for monitoring the one-way delay (only supported in UDP jitter and voice operations): reaction item-number checked-element { owd-ds owd-sd } threshold-value upper-threshold lower-threshold Configure a reaction entry for monitoring the ICPIF value (only supported in the voice operation): reaction item-number checked-element icpif threshold-value upper-threshold lower-threshold [ action-type { none trap-only } ] Configure a reaction entry for monitoring the MOS value (only supported in the voice operation): reaction item-number checked-element mos threshold-value upper-threshold lower-threshold [ action-type { none trap-only } ] Configure the trap sending method as needed. No traps are sent to the NMS by default. The reaction trap command in voice operation view only supports the test-complete keyword. 118

126 Configuring the NQA statistics function NQA collects statistics for an operation in a statistics group. To view information about the statistics groups, use the display nqa statistics command. To set the interval for collecting statistics, use the statistics interval command. If a new statistics group is to be saved when the number of statistics groups reaches the upper limit, the oldest statistics group is deleted. To set the maximum number of statistics groups that can be saved, use the statistics max-group command. A statistics group is formed after an operation is completed. Statistics groups have an aging mechanism. A statistics group is deleted when its hold time expires. To set the hold time, use the statistics hold-time command. The DHCP operation does not support the NQA statistics function. If you use the frequency command to set the interval between two consecutive operations to 0, only one operation is performed, and no statistics group information is generated. To configure the NQA statistics collection function: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify an NQA operation type and enter its view. 4. Configure the interval for collecting the statistics. 5. Configure the maximum number of statistics groups that can be saved. 6. Configure the hold time of statistics groups. nqa entry admin-name operation-tag type { dlsw dns ftp http icmp-echo snmp tcp udp-echo udp-jitter voice } statistics interval interval statistics max-group number statistics hold-time hold-time By default, no NQA operation is created. N/A Optional. 60 minutes by default. Optional. 2 by default. To disable collecting NQA statistics, set the maximum number to 0. Optional. 120 minutes by default. Configuring NQA history records saving function Perform this task to enable the system to save the history records of NQA operations. To display NQA history records, use the display nqa history command. This task also configures the following parameters: Lifetime of the history records. The records are removed when the lifetime is reached. Maximum number of history records that can be saved for an NQA operation. If the maxim number is reached, the earliest history records are removed. 119

127 To configure the history records saving function: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Enter NQA operation type view. 4. Enable saving history records for the NQA operation. 5. Set the lifetime of history records. 6. Configure the maximum number of history records that can be saved. nqa entry admin-name operation-tag type { dhcp dlsw dns ftp http icmp-echo snmp tcp udp-echo udp-jitter voice } history-record enable history-record keep-time keep-time history-record number number By default, no NQA operation is created. N/A By default, this feature is not enabled. Optional. By default, the history records in the NQA operation are kept for 120 minutes. Optional. By default, the maximum number of records that can be saved for the NQA operation is 50. Scheduling an NQA operation The NQA operation works between the specified start time and the end time (the start time plus operation duration). If the specified start time is ahead of the system time, the operation starts immediately. If both the specified start and end time are ahead of the system time, the operation does not start. To view the current system time, use the display clock command. You can configure the maximum number of NQA operations that can work simultaneously as needed to avoid excessive system resource consumption. You cannot enter the operation type view or the operation view of a scheduled NQA operation. A system time adjustment does not affect started or completed NQA operations. It only affects the NQA operations that have not started. To schedule an NQA operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Configure the scheduling parameters for an NQA operation. 3. Configure the maximum number of NQA operations that can work simultaneously. nqa schedule admin-name operation-tag start-time { hh:mm:ss [ yyyy/mm/dd ] now } lifetime { lifetime forever } nqa agent max-concurrent number N/A Optional. The default setting is two. 120

128 Displaying and maintaining NQA Task Command Remarks Display history records of NQA operations. Display the current monitoring results of reaction entries. Display the result of the specified NQA operation. Display NQA statistics. Display NQA server status. display nqa history [ admin-name operation-tag ] [ { begin exclude include } regular-expression ] display nqa reaction counters [ admin-name operation-tag [ item-number ] ] [ { begin exclude include } regular-expression ] display nqa result [ admin-name operation-tag ] [ { begin exclude include } regular-expression ] display nqa statistics [ admin-name operation-tag ] [ { begin exclude include } regular-expression ] display nqa server status [ { begin exclude include } regular-expression ] Available in any view. Available in any view. Available in any view. Available in any view. Available in any view. NQA configuration examples ICMP echo operation configuration example Network requirements As shown in Figure 53, configure and schedule an ICMP echo operation from the NQA client Firewall to Device A through Device B to test the round-trip time. Figure 53 Network diagram 121

129 Configuration procedure # Assign each interface an IP address. (Details not shown.) # Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) # Create an ICMP echo operation, and specify as the destination IP address. <Firewall> system-view [Firewall] nqa entry admin test1 [Firewall-nqa-admin-test1] type icmp-echo [Firewall-nqa-admin-test1-icmp-echo] destination ip # Configure as the next hop. The ICMP echo requests are sent through Device B to Device A. [Firewall-nqa-admin-test1-icmp-echo] next-hop # Configure the ICMP echo operation to perform 10 probes, specify the probe timeout time as 500 milliseconds, and configure the operation to repeat at an interval of 5000 milliseconds. [Firewall-nqa-admin-test1-icmp-echo] probe count 10 [Firewall-nqa-admin-test1-icmp-echo] probe timeout 500 [Firewall-nqa-admin-test1-icmp-echo] frequency 5000 # Enable saving history records and configure the maximum number of history records that can be saved as 10. [Firewall-nqa-admin-test1-icmp-echo] history-record enable [Firewall-nqa-admin-test1-icmp-echo] history-record number 10 [Firewall-nqa-admin-test1-icmp-echo] quit # Start the ICMP echo operation. [Firewall] nqa schedule admin test1 start-time now lifetime forever # Stop the ICMP echo operation after a period of time. [Firewall] undo nqa schedule admin test1 # Display the results of the ICMP echo operation. [Firewall] display nqa result admin test1 NQA entry (admin admin, tag test) test1 results: Destination IP address: Send operation times: 10 Receive response times: 10 Min/Max/Average round trip time: 2/5/3 Square-Sum of round trip time: 96 Last succeeded probe time: :00:01.2 Extended results: Packet loss in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0 # Display the history records of the ICMP echo operation. [Firewall] display nqa history admin test1 NQA entry (admin admin, tag test1) history record(s): 122

130 Index Response Status Time Succeeded :00: Succeeded :00: Succeeded :00: Succeeded :00: Succeeded :00: Succeeded :00: Succeeded :00: Succeeded :00: Succeeded :00: Succeeded :00:01.1 The output shows that the packets sent by Firewall can reach Device A through Device B. No packet loss occurs during the operation. The minimum, maximum, and average round-trip times are 2, 5, and 3 milliseconds, respectively. DHCP operation configuration example Network requirements As shown in Figure 54, configure and schedule a DHCP operation to test the time required for Firewall to obtain an IP address from the DHCP server (Device). Figure 54 Network diagram Configuration procedure # Create a DHCP operation to be performed on interface GigabitEthernet 0/1. <Firewall> system-view [Firewall] nqa entry admin test1 [Firewall-nqa-admin-test1] type dhcp [Firewall-nqa-admin-test1-dhcp] operation interface gigabitethernet 0/1 # Enable the saving of history records. [Firewall-nqa-admin-test1-dhcp] history-record enable [Firewall-nqa-admin-test1-dhcp] quit # Start the DHCP operation. [Firewall] nqa schedule admin test1 start-time now lifetime forever # Stop the DHCP operation after a period of time. [Firewall] undo nqa schedule admin test1 # Display the results of the DHCP operation. [Firewall] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 512/512/

131 Square-Sum of round trip time: Last succeeded probe time: :54:03.8 Extended results: Packet loss in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0 # Display the history records of the DHCP operation. [Firewall] display nqa history admin test1 NQA entry (admin admin, tag test1) history record(s): Index Response Status Time Succeeded :54:03.8 The output shows that Firewall uses 512 milliseconds to obtain an IP address from the DHCP server. DNS operation configuration example Network requirements As shown in Figure 55, configure a DNS operation to test whether Firewall can translate the domain name host.com into an IP address through the DNS server, and test the time required for resolution. Figure 55 Network diagram Configuration procedure # Assign each interface an IP address. (Details not shown.) # Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) # Create a DNS operation. <Firewall> system-view [Firewall] nqa entry admin test1 [Firewall-nqa-admin-test1] type dns # Specify the IP address of the DNS server as the destination address, and specify the domain name to be translated as host.com. [Firewall-nqa-admin-test1-dns] destination ip [Firewall-nqa-admin-test1-dns] resolve-target host.com # Enable the saving of history records. [Firewall-nqa-admin-test1-dns] history-record enable [Firewall-nqa-admin-test1-dns] quit 124

132 # Start the DNS operation. [Firewall] nqa schedule admin test1 start-time now lifetime forever # Stop the DNS operation after a period of time. [Firewall] undo nqa schedule admin test1 # Display the results of the DNS operation. [Firewall] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Destination IP address: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 62/62/62 Square-Sum of round trip time: 3844 Last succeeded probe time: :49:37.3 Extended results: Packet loss in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0 # Display the history records of the DNS operation. [Firewall] display nqa history admin test1 NQA entry (admin admin, tag test1) history record(s): Index Response Status Time 1 62 Succeeded :49:37.3 The output shows that Firewall uses 62 milliseconds to translate domain name host.com into an IP address. FTP operation configuration example Network requirements As shown in Figure 56, configure an FTP operation to test the time required for Firewall to upload a file to the FTP server. The login username is admin, the login password is systemtest, and the file to be transferred to the FTP server is config.txt. Figure 56 Network diagram Configuration procedure # Assign each interface an IP address. (Details not shown.) # Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) 125

133 # Create an FTP operation. <Firewall> system-view [Firewall] nqa entry admin test1 [Firewall-nqa-admin-test1] type ftp # Specify the IP address of the FTP server as the destination IP address. [Firewall-nqa-admin-test1-ftp] destination ip # Specify as the source IP address. [Firewall-nqa-admin-test1-ftp] source ip # Set the FTP username to admin, and password to systemtest. [Firewall-nqa-admin-test1-ftp] username admin [Firewall-nqa-admin-test1-ftp] password simple systemtest # Configure the device to upload file config.txt to the FTP server. [Firewall-nqa-admin-test1-ftp] operation put [Firewall-nqa-admin-test1-ftp] filename config.txt # Enable the saving of history records. [Firewall-nqa-admin-test1-ftp] history-record enable [Firewall-nqa-admin-test1-ftp] quit # Start the FTP operation. [Firewall] nqa schedule admin test1 start-time now lifetime forever # Stop the FTP operation after a period of time. [Firewall] undo nqa schedule admin test1 # Display the results of the FTP operation. [Firewall] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Destination IP address: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 173/173/173 Square-Sum of round trip time: Last succeeded probe time: :07:28.6 Extended results: Packet loss in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0 # Display the history records of the FTP operation. [Firewall] display nqa history admin test1 NQA entry (admin admin, tag test1) history record(s): Index Response Status Time Succeeded :07:28.6 The output shows that Firewall uses 173 milliseconds to upload a file to the FTP server. 126

134 HTTP operation configuration example Network requirements As shown in Figure 57, configure an HTTP operation on the NQA client to test the time required to obtain data from the HTTP server. Figure 57 Network diagram Configuration procedure # Assign each interface an IP address. (Details not shown.) # Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) # Create an HTTP operation. <Firewall> system-view [Firewall] nqa entry admin test1 [Firewall-nqa-admin-test1] type http # Specify the IP address of the HTTP server as the destination IP address. [Firewall-nqa-admin-test1-http] destination ip # Configure the HTTP operation to get data from the HTTP server. (The default HTTP operation type is get, and this step can be omitted.) [Firewall-nqa-admin-test1-http] operation get # Configure the HTTP operation to visit the website /index.htm. [Firewall-nqa-admin-test1-http] url /index.htm # Configure the operation to use HTTP version 1.0. (Version 1.0 is the default version, and this step can be omitted.) [Firewall-nqa-admin-test1-http] http-version v1.0 # Enable the saving of history records. [Firewall-nqa-admin-test1-http] history-record enable [Firewall-nqa-admin-test1-http] quit # Start the HTTP operation. [Firewall] nqa schedule admin test1 start-time now lifetime forever # Stop the HTTP operation after a period of time. [Firewall] undo nqa schedule admin test1 # Display the results of the HTTP operation. [Firewall] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Destination IP address: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 64/64/64 Square-Sum of round trip time:

135 Last succeeded probe time: :12:47.9 Extended results: Packet loss in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: Packet(s) arrived late: 0 # Display the history records of the HTTP operation. [Firewall] display nqa history admin test1 NQA entry (admin admin, tag test1) history record(s): Index Response Status Time 1 64 Succeeded :12:47.9 The output shows that Firewall uses 64 milliseconds to obtain data from the HTTP server. UDP jitter operation configuration example Network requirements As shown in Figure 58, configure a UDP jitter operation to test the jitter, delay, and round-trip time between Firewall A and Firewall B. Figure 58 Network diagram Configuration procedure 1. Assign each interface an IP address. (Details not shown.) 2. Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) 3. Configure Firewall B: # Enable the NQA server and configure a listening service to listen on the IP address and UDP port <FirewallB> system-view [FirewallB] nqa server enable [FirewallB] nqa server udp-echo Configure Firewall A: # Create a UDP jitter operation. <FirewallA> system-view [FirewallA] nqa entry admin test1 [FirewallA-nqa-admin-test1] type udp-jitter # Configure as the destination IP address and port 9000 as the destination port. 128

136 [FirewallA-nqa-admin-test1-udp-jitter] destination ip [FirewallA-nqa-admin-test1-udp-jitter] destination port 9000 # Configure the operation to repeat at an interval of 1000 milliseconds. [FirewallA-nqa-admin-test1-udp-jitter] frequency 1000 [FirewallA-nqa-admin-test1-udp-jitter] quit # Start the UDP jitter operation. [FirewallA] nqa schedule admin test1 start-time now lifetime forever # Stop the UDP jitter operation after a period of time. [FirewallA] undo nqa schedule admin test1 # Display the results of the UDP jitter operation. [FirewallA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Destination IP address: Send operation times: 10 Receive response times: 10 Min/Max/Average round trip time: 15/32/17 Square-Sum of round trip time: 3235 Last succeeded probe time: :56:17.6 Extended results: Packet loss in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0 UDP-jitter results: RTT number: 10 Min positive SD: 4 Min positive DS: 1 Max positive SD: 21 Max positive DS: 28 Positive SD number: 5 Positive DS number: 4 Positive SD sum: 52 Positive DS sum: 38 Positive SD average: 10 Positive DS average: 10 Positive SD square sum: 754 Positive DS square sum: 460 Min negative SD: 1 Min negative DS: 6 Max negative SD: 13 Max negative DS: 22 Negative SD number: 4 Negative DS number: 5 Negative SD sum: 38 Negative DS sum: 52 Negative SD average: 10 Negative DS average: 10 Negative SD square sum: 460 Negative DS square sum: 754 One way results: Max SD delay: 15 Max DS delay: 16 Min SD delay: 7 Min DS delay: 7 Number of SD delay: 10 Number of DS delay: 10 Sum of SD delay: 78 Sum of DS delay: 85 Square sum of SD delay: 666 Square sum of DS delay: 787 SD lost packet(s): 0 DS lost packet(s): 0 Lost packet(s) for unknown reason: 0 129

137 # Display the statistics of the UDP jitter operation. [FirewallA] display nqa statistics admin test1 NQA entry (admin admin, tag test1) test statistics: NO. : 1 Destination IP address: Start time: :56:14.0 Life time: 47 seconds Send operation times: 410 Receive response times: 410 Min/Max/Average round trip time: 1/93/19 Square-Sum of round trip time: Extended results: Packet loss in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0 UDP-jitter results: RTT number: 410 Min positive SD: 3 Min positive DS: 1 Max positive SD: 30 Max positive DS: 79 Positive SD number: 186 Positive DS number: 158 Positive SD sum: 2602 Positive DS sum: 1928 Positive SD average: 13 Positive DS average: 12 Positive SD square sum: Positive DS square sum: Min negative SD: 1 Min negative DS: 1 Max negative SD: 30 Max negative DS: 78 Negative SD number: 181 Negative DS number: 209 Negative SD sum: 181 Negative DS sum: 209 Negative SD average: 13 Negative DS average: 14 Negative SD square sum: Negative DS square sum: 3030 One way results: Max SD delay: 46 Max DS delay: 46 Min SD delay: 7 Min DS delay: 7 Number of SD delay: 410 Number of DS delay: 410 Sum of SD delay: 3705 Sum of DS delay: 3891 Square sum of SD delay: Square sum of DS delay: SD lost packet(s): 0 DS lost packet(s): 0 Lost packet(s) for unknown reason: 0 SNMP operation configuration example Network requirements As shown in Figure 59, configure an SNMP operation to test the time the NQA client uses to get a value from the SNMP agent. 130

138 Figure 59 Network diagram Configuration procedure 1. Assign each interface an IP address. (Details not shown.) 2. Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) 3. Configure the SNMP agent (Device): # Enable the SNMP agent, and set the SNMP version to all, the read community to public, and the write community to private. <Device> system-view [Device] snmp-agent [Device] snmp-agent sys-info version all [Device] snmp-agent community read public [Device] snmp-agent community write private 4. Configure Firewall: # Create an SNMP operation, and configure as the destination IP address. <Firewall> system-view [Firewall] nqa entry admin test1 [Firewall-nqa-admin-test1] type snmp [Firewall-nqa-admin-test1-snmp] destination ip # Enable the saving of history records. [Firewall-nqa-admin-test1-snmp] history-record enable [Firewall-nqa-admin-test1-snmp] quit # Start the SNMP operation. [Firewall] nqa schedule admin test1 start-time now lifetime forever # Stop the SNMP operation after a period of time. [Firewall] undo nqa schedule admin test1 # Display the results of the SNMP operation. [Firewall] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Destination IP address: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 50/50/50 Square-Sum of round trip time: 2500 Last succeeded probe time: :24:41.1 Extended results: Packet loss in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 131

139 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0 # Display the history records of the SNMP operation. [Firewall] display nqa history admin test1 NQA entry (admin admin, tag test1) history record(s): Index Response Status Time 1 50 Timeout :24:41.1 The output shows that Firewall uses 50 milliseconds to receive a response from the SNMP agent. TCP operation configuration example Network requirements As shown in Figure 60, configure a TCP operation to test the time the NQA client uses to establish a TCP connection to the NQA server on Firewall B. Figure 60 Network diagram Configuration procedure 1. Assign each interface an IP address. (Details not shown.) 2. Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) 3. Configure Firewall B: # Enable the NQA server, and configure a listening service to listen on the IP address and TCP port <FirewallB> system-view [FirewallB] nqa server enable [FirewallB] nqa server tcp-connect Configure Firewall A: # Create a TCP operation. <FirewallA> system-view [FirewallA] nqa entry admin test1 [FirewallA-nqa-admin-test1] type tcp # Configure as the destination IP address and port 9000 as the destination port. [FirewallA-nqa-admin-test1-tcp] destination ip [FirewallA-nqa-admin-test1-tcp] destination port 9000 # Enable the saving of history records. [FirewallA-nqa-admin-test1-tcp] history-record enable [FirewallA-nqa-admin-test1-tcp] quit # Start the TCP operation. [FirewallA] nqa schedule admin test1 start-time now lifetime forever 132

140 # Stop the TCP operation after a period of time. [FirewallA] undo nqa schedule admin test1 # Display the results of the TCP operation. [FirewallA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Destination IP address: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 13/13/13 Square-Sum of round trip time: 169 Last succeeded probe time: :27:25.1 Extended results: Packet loss in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0 # Display the history records of the TCP operation. [FirewallA] display nqa history admin test1 NQA entry (admin admin, tag test1) history record(s): Index Response Status Time 1 13 Succeeded :27:25.1 The output shows that Firewall A uses 13 milliseconds to establish a TCP connection to port 9000 on the NQA server. UDP echo operation configuration example Network requirements As shown in Figure 61, configure a UDP echo operation to test the round-trip time between Firewall A and Firewall B. The destination port number is Figure 61 Network diagram Configuration procedure 1. Assign each interface an IP address. (Details not shown.) 2. Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) 3. Configure Firewall B: # Enable the NQA server, and configure a listening service to listen on the IP address and UDP port

141 <FirewallB> system-view [FirewallB] nqa server enable [FirewallB] nqa server udp-echo Configure Firewall A: # Create a UDP echo operation. <FirewallA> system-view [FirewallA] nqa entry admin test1 [FirewallA-nqa-admin-test1] type udp-echo # Configure as the destination IP address and port 8000 as the destination port. [FirewallA-nqa-admin-test1-udp-echo] destination ip [FirewallA-nqa-admin-test1-udp-echo] destination port 8000 # Enable the saving of history records. [FirewallA-nqa-admin-test1-udp-echo] history-record enable [FirewallA-nqa-admin-test1-udp-echo] quit # Start the UDP echo operation. [FirewallA] nqa schedule admin test1 start-time now lifetime forever # Stop the UDP echo operation after a period of time. [FirewallA] undo nqa schedule admin test1 # Display the results of the UDP echo operation. [FirewallA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Destination IP address: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 25/25/25 Square-Sum of round trip time: 625 Last succeeded probe time: :36:17.9 Extended results: Packet loss in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0 # Display the history records of the UDP echo operation. [FirewallA] display nqa history admin test1 NQA entry (admin admin, tag test1) history record(s): Index Response Status Time 1 25 Succeeded :36:17.9 The output shows that the round-trip time between Firewall A and port 8000 on Firewall B is 25 milliseconds. 134

142 Voice operation configuration example Network requirements As shown in Figure 62, configure a voice operation to test the jitters between Firewall A and Firewall B. Figure 62 Network diagram Configuration procedure 1. Assign each interface an IP address. (Details not shown.) 2. Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) 3. Configure Firewall B: # Enable the NQA server, and configure a listening service to listen on IP address and UDP port <FirewallB> system-view [FirewallB] nqa server enable [FirewallB] nqa server udp-echo Configure Firewall A: # Create a voice operation. <FirewallA> system-view [FirewallA] nqa entry admin test1 [FirewallA-nqa-admin-test1] type voice # Configure as the destination IP address and port 9000 as the destination port. [FirewallA-nqa-admin-test1-voice] destination ip [FirewallA-nqa-admin-test1-voice] destination port 9000 [FirewallA-nqa-admin-test1-voice] quit # Start the voice operation. [FirewallA] nqa schedule admin test1 start-time now lifetime forever # Stop the voice operation after a period of time. [FirewallA] undo nqa schedule admin test1 # Display the results of the voice operation. [FirewallA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Destination IP address: Send operation times: 1000 Receive response times: 1000 Min/Max/Average round trip time: 31/1328/33 Square-Sum of round trip time: Last succeeded probe time: :49:31.1 Extended results: Packet loss in test: 0% Failures due to timeout: 0 135

143 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0 Voice results: RTT number: 1000 Min positive SD: 1 Min positive DS: 1 Max positive SD: 204 Max positive DS: 1297 Positive SD number: 257 Positive DS number: 259 Positive SD sum: 759 Positive DS sum: 1797 Positive SD average: 2 Positive DS average: 6 Positive SD square sum: Positive DS square sum: Min negative SD: 1 Min negative DS: 1 Max negative SD: 203 Max negative DS: 1297 Negative SD number: 255 Negative DS number: 259 Negative SD sum: 759 Negative DS sum: 1796 Negative SD average: 2 Negative DS average: 6 Negative SD square sum: Negative DS square sum: One way results: Max SD delay: 343 Max DS delay: 985 Min SD delay: 343 Min DS delay: 985 Number of SD delay: 1 Number of DS delay: 1 Sum of SD delay: 343 Sum of DS delay: 985 Square sum of SD delay: Square sum of DS delay: SD lost packet(s): 0 DS lost packet(s): 0 Lost packet(s) for unknown reason: 0 Voice scores: MOS value: 4.38 ICPIF value: 0 # Display the statistics of the voice operation. [FirewallA] display nqa statistics admin test1 NQA entry (admin admin, tag test1) test statistics: NO. : 1 Destination IP address: Start time: :45:37.8 Life time: 331 seconds Send operation times: 4000 Receive response times: 4000 Min/Max/Average round trip time: 15/1328/32 Square-Sum of round trip time: Extended results: Packet loss in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 136

144 Packet(s) arrived late: 0 Voice results: RTT number: 4000 Min positive SD: 1 Min positive DS: 1 Max positive SD: 360 Max positive DS: 1297 Positive SD number: 1030 Positive DS number: 1024 Positive SD sum: 4363 Positive DS sum: 5423 Positive SD average: 4 Positive DS average: 5 Positive SD square sum: Positive DS square sum: Min negative SD: 1 Min negative DS: 1 Max negative SD: 360 Max negative DS: 1297 Negative SD number: 1028 Negative DS number: 1022 Negative SD sum: 1028 Negative DS sum: 1022 Negative SD average: 4 Negative DS average: 5 Negative SD square sum: Negative DS square sum: 5419 One way results: Max SD delay: 359 Max DS delay: 985 Min SD delay: 0 Min DS delay: 0 Number of SD delay: 4 Number of DS delay: 4 Sum of SD delay: 1390 Sum of DS delay: 1079 Square sum of SD delay: Square sum of DS delay: SD lost packet(s): 0 DS lost packet(s): 0 Lost packet(s) for unknown reason: 0 Voice scores: Max MOS value: 4.38 Min MOS value: 4.38 Max ICPIF value: 0 Min ICPIF value: 0 DLSw operation configuration example Network requirements As shown in Figure 63, configure a DLSw operation to test the response time of the DLSw device. Figure 63 Network diagram Configuration procedure # Assign each interface an IP address. (Details not shown.) # Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) # Create a DLSw operation, and configure as the destination IP address. <Firewall> system-view [Firewall] nqa entry admin test1 [Firewall-nqa-admin-test1] type dlsw [Firewall-nqa-admin-test1-dlsw] destination ip

145 # Enable the saving of history records. [Firewall-nqa-admin-test1-dlsw] history-record enable [Firewall-nqa-admin-test1-dlsw] quit # Start the DLSw operation. [Firewall] nqa schedule admin test1 start-time now lifetime forever # Stop the DLSw operation after a period of time. [Firewall] undo nqa schedule admin test1 # Display the results of the DLSw operation. [Firewall] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Destination IP address: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 19/19/19 Square-Sum of round trip time: 361 Last succeeded probe time: :40:27.7 Extended results: Packet loss in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0 # Display the history records of the DLSw operation. [Firewall] display nqa history admin test1 NQA entry (admin admin, tag test1) history record(s): Index Response Status Time 1 19 Succeeded :40:27.7 The output shows that the response time of the DLSw device is 19 milliseconds. NQA collaboration configuration example Network requirements As shown in Figure 64, configure a static route to Device B with Device A as the next hop on Firewall. Associate the static route, a track entry, and an NQA operation to monitor the state of the static route. 138

146 Figure 64 Network diagram Configuration procedure 1. Assign each interface an IP address. (Details not shown.) 2. On Firewall, configure a unicast static route, and associate the static route with a track entry: # Configure a static route, and associate the static route with track entry 1. <Firewall> system-view [Firewall] ip route-static track 1 3. On Firewall, configure an ICMP echo operation: # Create an NQA operation with the administrator name being admin and operation tag being test1. [Firewall] nqa entry admin test1 # Configure the NQA operation type as ICMP echo. [Firewall-nqa-admin-test1] type icmp-echo # Configure as the destination IP address. [Firewall-nqa-admin-test1-icmp-echo] destination ip # Configure the operation to repeat at an interval of 100 milliseconds. [Firewall-nqa-admin-test1-icmp-echo] frequency 100 # Create reaction entry 1. If the number of consecutive probe failures reaches 5, collaboration is triggered. [Firewall-nqa-admin-test1-icmp-echo] reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only [Firewall-nqa-admin-test1-icmp-echo] quit # Start the ICMP echo operation. [Firewall] nqa schedule admin test1 start-time now lifetime forever 4. On Firewall, create the track entry: # Create track entry 1, and associate it with reaction entry 1 of ICMP echo operation admin-test1. [Firewall] track 1 nqa entry admin test1 reaction 1 Verifying the configuration # On Firewall, display information about all track entries. [Firewall] display track all Track ID: 1 Status: Positive Notification delay: Positive 0, Negative 0 (in seconds) Reference object: 139

147 NQA entry: admin test1 Reaction: 1 # Display brief information about active routes in the routing table on Firewall. [Firewall] display ip routing-table Routing Tables: Public Destinations : 5 Routes : 5 Destination/Mask Proto Pre Cost NextHop Interface /24 Static GE0/ /24 Direct GE0/ /32 Direct InLoop /8 Direct InLoop /32 Direct InLoop0 The output shows that the static route with the next hop is active, and the status of the track entry is positive. # Remove the IP address of GigabitEthernet 0/1 on Device A. <DeviceA> system-view [DeviceA] interface gigabitethernet 0/1 [DeviceA-GigabitEthernet0/1] undo ip address # On Firewall, display information about all track entries. [Firewall] display track all Track ID: 1 Status: Negative Notification delay: Positive 0, Negative 0 (in seconds) Reference object: NQA entry: admin test1 Reaction: 1 # Display brief information about active routes in the routing table on Firewall. [Firewall] display ip routing-table Routing Tables: Public Destinations : 4 Routes : 4 Destination/Mask Proto Pre Cost NextHop Interface /24 Direct GE0/ /32 Direct InLoop /8 Direct InLoop /32 Direct InLoop0 The output shows that the static route does not exist, and the status of the track entry is negative. 140

148 Configuring Ethernet link aggregation The device does not support the dynamic aggregation mode. Overview Ethernet link aggregation, or simply link aggregation, combines multiple physical Ethernet ports into one logical link called an "aggregate link." Link aggregation delivers the following benefits: Increases bandwidth beyond the limits of any single link. In an aggregate link, traffic is distributed across the member ports. Improves link reliability. The member ports dynamically back up one another. When a member port fails, its traffic is automatically switched to other member ports. As shown in Figure 65, Device A and Device B are connected by three physical Ethernet links. These physical Ethernet links are combined into an aggregate link, Link Aggregation 1. The bandwidth of this aggregate link is as high as the total bandwidth of the three physical Ethernet links. At the same time, the three Ethernet links back up one another. Figure 65 Ethernet link aggregation Basic concepts This section describes some basic link aggregation concepts. Aggregation group, member port, and aggregate interface Link aggregation is implemented by combining Ethernet interfaces into a link aggregation group. Each link aggregation group has one logical aggregate interface. To an upper layer entity, a link aggregation group appears to be a single logical link and data traffic is transmitted through the aggregate interface. The rate of an aggregate interface equals the total rate of its member ports in Selected state, and its duplex mode is the same as the selected member ports. For more information about the states of member ports in an aggregation group, see "Aggregation states of member ports in an aggregation group." Aggregate interfaces include the following types: Layer 2 aggregate interfaces On a Layer 2 aggregate interface, you can create subinterfaces, which are called Layer 2 aggregate subinterfaces. Layer 2 aggregate subinterfaces are logical interfaces that operate at the data link layer and forward Ethernet frames across VLANs on a firewall module (a subinterface of a VLAN forwards Ethernet frames to a subinterface of another VLAN). Layer 3 aggregate interfaces On a Layer 3 aggregate interface, you can create subinterfaces. The Layer 3 aggregate subinterfaces are logical interfaces operating at the network layer. They can receive VLAN tagged packets for their Layer 3 aggregate interface. 141

149 When you create an aggregate interface, the firewall automatically creates an aggregation group of the same type and number as the aggregate interface. For example, when you create interface Bridge-Aggregation 1, Layer 2 aggregation group 1 is automatically created. You can assign Layer 2 Ethernet interfaces only to a Layer 2 aggregation group, and Layer 3 Ethernet interfaces only to a Layer 3 aggregation group. Removing an aggregate interface also removes the corresponding aggregation group. At the same time, all member ports leave the aggregation group. When a Selected port fails, an Unselected port might become a Selected port and forward user traffic. Aggregation states of member ports in an aggregation group Operational key A member port in an aggregation group can be in either of the following aggregation states: Selected A Selected port can forward user traffic. Unselected An Unselected port cannot forward user traffic. When a Selected port fails, an Unselected port might become a Selected port and forward user traffic. When aggregating ports, the system automatically assigns each port an operational key based on port information such as port rate and duplex mode. Any change to this information triggers a recalculation of the operational key. In an aggregation group, all selected member ports are assigned the same operational key. Configuration classes Every configuration setting on a port might affect its aggregation state. Port configurations include the following classes: Port attribute configurations Include port rate, duplex mode, and link status (up or down). These are the most basic port configurations. Class-two configurations A member port can be placed in Selected state only if it has the same class-two configurations as the aggregate interface. Class-two configurations made on an aggregate interface are automatically synchronized to all its member ports. These configurations are retained on the member ports even after the aggregate interface is removed. Table 8 Class-two configurations Feature VLAN MAC address learning Considerations Permitted VLANs, PVID, link type (trunk, hybrid, or access), and VLAN tagging mode. MAC address learning capability, MAC address learning limit, forwarding of frames with unknown destination MAC addresses after the MAC address learning limit is reached. NOTE: Any class-two configuration change might affect the aggregation state of link aggregation member ports and ongoing traffic. To be sure that you are aware of the risk, the system displays a warning message every time you attempt to change a class-two configuration setting on a member port. 142

150 Reference port Class-one configurations Include settings that do not affect the aggregation state of the member port even if they are different from those on the aggregate interface. Spanning tree settings are examples of class-one configurations. The class-one configuration of a member port is effective only when the member port leaves the aggregation group. When setting the aggregation state of the ports in an aggregation group, the system automatically picks a member port as the reference port. A Selected port must have the same port attributes and class-two configurations as the reference port. For information about how a reference port is chosen in a static link aggregation group, see "Choosing a reference port" in the section "Aggregating links in static mode." For information about how a reference port is chosen in a dynamic link aggregation group, see "Choosing a reference port" in the section "Aggregating links in dynamic mode." Link aggregation modes Link aggregation can be done in dynamic mode or static mode. Dynamic link aggregation uses the IEEE 802.3ad LACP, but static link aggregation does not. Table 9 compares the two aggregation modes. Table 9 A comparison between static and dynamic aggregation modes Aggregation mode LACP status on member ports Pros Cons Static Disabled Aggregation is stable. Peers do not affect the aggregation state of member ports. Member ports do not automatically align their aggregation state with their peer ports. The administrator must manually maintain link aggregations. Dynamic Enabled The peer systems maintain the aggregation state of member ports automatically. Aggregation is unstable. The aggregation state of member ports is susceptible to network changes. In a dynamic link aggregation group, a Selected port can receive and send LACPDUs. An Unselected port can receive and send LACPDUs only if it is up and has the same class-two configurations as the aggregate interface. NOTE: Only static aggregation groups can be configured in the Web interface. LACP IEEE 802.3ad LACP enables dynamic aggregation of physical links. It uses LACPDUs for exchanging aggregation information between LACP-enabled devices. 1. Basic LACP functions: Basic LACP functions are implemented through the basic LACPDU fields. These fields include the system LACP priority, system MAC address, port aggregation priority, port number, and operational key. Each member port in a LACP-enabled aggregation group exchanges the preceding information with its peer. When a member port receives an LACPDU, it compares the received information with the information received on other member ports. In this way, the two systems reach an agreement on which ports should be placed in Selected state. 143

151 2. LACP priorities: LACP priorities have the following types: system LACP priority and port aggregation priority. The smaller the priority value, the higher the priority. Table 10 LACP priorities Type System LACP priority Port aggregation priority Description Used by two peer devices (or systems) to determine which one is superior in link aggregation. In dynamic link aggregation, the system with higher system LACP priority sets the Selected state of member ports on its side first, and then the system with lower priority sets the port state accordingly. Determines the likelihood of a member port to be selected on a system. The higher the port aggregation priority, the higher the likelihood. 3. LACP timeout interval: LACP timeout interval specifies how long a member port waits to receive LACPDUs from the peer port. If a local member port fails to receive LACPDUs from the peer within three times the LACP timeout interval, the member port assumes that the peer port has failed. You can configure the LACP timeout interval as either the short timeout interval (1 second) or the long timeout interval (30 seconds). Aggregating links in static mode LACP is disabled on the member ports in a static aggregation group. You must manually maintain their aggregation state. Choosing a reference port The system chooses a reference port from the UP member ports that have the same class-two configurations as the aggregate interface. The candidate ports are sorted by aggregation priority, duplex, and speed in the following order: Lowest aggregation priority value Full duplex/high speed Full duplex/low speed Half duplex/high speed Half duplex/low speed The one at the top is chosen as the reference port. If two ports have the same aggregation priority, duplex mode, and speed, the one with the lower port number is chosen. Setting the aggregation state of each member port After choosing the reference port, the static aggregation group sets the aggregation state of each member port, as shown in Figure 66. After the static aggregation group has reached the limit on Selected ports, any port assigned to the group is placed in Unselected state to avoid traffic interruption on the current Selected ports. 144

152 Figure 66 Setting the aggregation state of a member port in a static aggregation group Set the aggregation state of a member port Is there any hardware restriction? Yes No Is the port up? No Yes Port attribute/class 2 configurations same as the reference port? No Yes More candidate ports than max. number of Selected ports? Yes Port number as low as to set the port in the Selected state? No No Yes Set the port in the Selected state Set the port in the Unselected state Aggregating links in dynamic mode LACP is automatically enabled on all member ports in a dynamic aggregation group. The protocol automatically maintains the aggregation state of ports. Choosing a reference port The local system (the actor) and the remote system (the partner) negotiate a reference port by using the following workflow: 1. The systems compare their system IDs (each system ID comprises a system LACP priority and a system MAC address). The system with the lower LACP priority value is chosen. If they are the same, the systems compare the system MAC addresses. The system with the lower MAC address is chosen. 2. The system with the smaller system ID chooses the port with the smallest port ID as the reference port. A port ID comprises a port aggregation priority and a port number. The port with the lower aggregation priority value is chosen. If two ports have the same aggregation priority, the system compares their port numbers. The port with the smaller port number is chosen. Setting the aggregation state of each member port After the reference port is chosen, the system with the lower system ID sets the state of each member port in the dynamic aggregation group on its side. 145

153 Figure 67 Setting the state of a member port in a dynamic aggregation group Meanwhile, the system with the higher system ID, which has identified the aggregation state changes on the remote system, sets the aggregation state of local member ports as the same as their peer ports. A dynamic link aggregation group preferably sets full-duplex ports as the Selected ports, and will set one, and only one, half-duplex port as a Selected port when none of the full-duplex ports can be selected or only half-duplex ports exist in the group. When the aggregation state of a member port changes, the aggregation state of its peer port also changes. After the Selected port limit has been reached, a port assigned to the dynamic aggregation group is placed in Selected state if it is more eligible for being selected than a current member port. The port assigned to the dynamic aggregation group after the Selected port limit has been reached is placed in Selected state if it is more eligible for being selected than a current member port. 146

154 Load sharing criteria for link aggregation groups In a link aggregation group, traffic can be load-shared across the selected member ports based on a set of criteria, depending on your configuration. You can choose one or any combination of the following criteria for load sharing: Source/Destination service port numbers Source/Destination IP addresses Protocol numbers You can also load balance traffic on a per-packet basis. Configuration restrictions and guidelines When you configure a link aggregation group, follow these guidelines: To ensure stable aggregation state and service continuity, do not change port attributes or class-two configurations on any member port. If you must, make sure you understand its impact on the live network. Any port attribute or class-two configuration change might affect the aggregation state of link aggregation member ports and ongoing traffic. Avoid assigning ports to a static aggregation group that has reached the limit on Selected ports. These ports will be placed in Unselected state to avoid traffic interruption on the current Selected ports. However, a device reboot can cause the aggregation state of member ports to change. Configuring Ethernet link aggregation in the Web interface IMPORTANT: Only Layer 2 static aggregation groups can be configured in the Web interface. Configuring a Layer 2 static aggregation group 1. From the navigation tree, select Network > Link Aggregation. 2. Click Create. 147

155 Figure 68 Creating a static link aggregation group 3. Enter an ID for the Layer 2 link aggregation group to be created, which identifies both the Layer 2 aggregate interface and Layer 2 aggregation group. 4. Select one or multiple ports to be assigned to the link aggregation group from the chassis front panel. 5. Click Apply. Displaying information about a Layer 2 aggregate interface 1. From the navigation tree, select Network > Link Aggregation. The Summary tab is displayed by default. The list on the upper part of the page displays information about all the aggregate interfaces. 2. Select an aggregate interface from the list to display detailed information about its member ports on a list on the lower part. Table 11 describes each field of a Layer 2 aggregate interface. 148

156 Figure 69 Displaying information about an aggregate interface Table 11 Field description Field Aggregation interface Link Type Partner ID Selected Ports Standby Ports Member Port State Reason for being Unselected Description Type and ID of the aggregate interface. Bridge-Aggregation indicates a Layer 2 aggregate interface. Type of the aggregate interface. ID of the remote device, including its LACP priority and MAC address. Number of Selected ports in each link aggregation group. (Only Selected ports can transmit and receive user data.) Number of Unselected ports in each link aggregation group. (Unselected ports cannot transmit or receive user data.) A member port of the link aggregation group corresponding to the selected aggregate interface. Select state of a member port: Selected or Unselected. Reason why the state of a member port is Unselected. For a selected member port, this field is displayed as a hyphen (-). Layer 2 static link aggregation configuration example In this example, Device A is the firewall. 149

157 Network requirements As shown in Figure 70, aggregate the ports on Device A and Device B to form a static link aggregation group, enhancing link reliability. Figure 70 Network diagram Configuration procedure 1. Create static link aggregation group 1 on Device A: a. From the navigation tree, select Network > Link Aggregation. b. Click Create to enter the page as shown in Figure 71. c. Set the link aggregation interface ID to 1. Select GigabitEthernet 0/1, GigabitEthernet 0/2, and GigabitEthernet 0/3 on the chassis front panel. d. Click Apply. 150

158 Figure 71 Creating static link aggregation group 1 2. Configure Device B in the same way Device A is configured. (Details not shown.) Verifying the configuration To view information about Layer 2 static aggregate interface 1 on Device A: 1. From the navigation tree, select Network > Link Aggregation. The Summary tab appears. 2. Select aggregate interface Bridge-Aggregation1 from the list on the upper part, as shown in Figure 72. This aggregate interface comprises three Selected ports: GigabitEthernet 0/1, GigabitEthernet 0/2, and GigabitEthernet 0/3. 151

159 Figure 72 Configuration result Selected Selected Selected Configuring Ethernet link aggregation at the CLI Ethernet link aggregation configuration task list Task Configuring an aggregation group: Configuring a Layer 2 static aggregation group Configuring a Layer 3 static aggregation group Configuring a Layer 2 dynamic aggregation group Configuring a Layer 3 dynamic aggregation group Configuring an aggregate interface: Configuring the description of an aggregate interface or subinterface Configuring the MTU of a Layer 3 aggregate interface or subinterface Enabling link state traps for an aggregate interface Limiting the number of Selected ports for an aggregation group Shutting down an aggregate interface Restoring the default settings for an aggregate interface Configuring load sharing criteria for link aggregation groups: Configuring the global link-aggregation load sharing criteria Configuring group-specific load sharing criteria Remarks Perform one of the tasks. Optional. Optional. 152

160 Configuring an aggregation group You can choose to create a Layer 2 or Layer 3 link aggregation group depending on the ports to be aggregated: To aggregate Layer 2 Ethernet interfaces, create a Layer 2 link aggregation group. To aggregate Layer 3 Ethernet interfaces, create a Layer 3 link aggregation group. Configuration guidelines When you configure an aggregation group, follow these guidelines: You cannot assign a port to a Layer 2 aggregation group if any of the features listed in Table 12 is configured on the port. Table 12 Features incompatible with Layer 2 aggregation groups Feature Packet filtering Ports specified as source interfaces in portal-free rules Reference Firewall in Attack Prevention Configuration Guide. Portal in Access Control Configuration Guide. You cannot assign a port to a Layer 3 aggregation group if any of the features listed in Table 13 is configured on the port. Table 13 Interfaces that cannot be assigned to a Layer 3 aggregation group Interface type Interfaces configured with IP addresses Interfaces configured as DHCP/BOOTP clients VRRP Portal Reference IP addressing in Network Management Configuration Guide. DHCP in Network Management Configuration Guide. VRRP in High Availability Configuration Guide Portal in Access Control Configuration Guide. Interfaces configured with static MAC addresses can join a aggregation group. Removing an aggregate interface also removes its aggregation group. At the same time, all member ports leave the aggregation group. Configuring a Layer 2 static aggregation group To guarantee a successful static aggregation, make sure the ports at both ends of each link are in the same aggregation state. To configure a Layer 2 static aggregation group: Step Command Remarks 1. Enter system view. system-view N/A 2. Create a Layer 2 aggregate interface and enter Layer 2 aggregate interface view. interface bridge-aggregation interface-number When you create a Layer 2 aggregate interface, the system automatically creates a Layer 2 static aggregation group numbered the same. 153

161 Step Command Remarks 3. Exit to system view. quit N/A 4. Assign a Layer 2 Ethernet interface to the aggregation group. 5. Assign the port an aggregation priority. a. interface interface-type interface-number b. port link-aggregation group number link-aggregation port-priority port-priority Repeat these two sub-steps to assign more Layer 2 Ethernet interfaces to the aggregation group. Optional. By default, the aggregation priority of a port is When the number of ports eligible for Selected ports exceeds the maximum number of Selected ports allowed in a static aggregation group, changing the aggregation priority of a port might affect the aggregation state of the ports in the static aggregation group. Configuring a Layer 3 static aggregation group To guarantee a successful static aggregation, make sure the ports at both ends of each link are in the same aggregation state. To configure a Layer 3 static aggregation group: Step Command Remarks 1. Enter system view. system-view N/A 2. Create a Layer 3 aggregate interface and enter Layer 3 aggregate interface view. interface route-aggregation interface-number When you create a Layer 3 aggregate interface, the system automatically creates a Layer 3 static aggregation group with the same number. 3. Exit to system view. quit N/A 4. Assign a Layer 3 Ethernet interface to the aggregation group. 5. Assign the port an aggregation priority. a. interface interface-type interface-number b. port link-aggregation group number link-aggregation port-priority port-priority Repeat these two sub-steps to assign more Layer 3 Ethernet interfaces to the aggregation group. Optional. By default, the aggregation priority of a port is When the number of ports eligible for becoming Selected ports exceeds the maximum number of Selected ports allowed in a static aggregation group, changing the aggregation priority of a port might affect the aggregation state of the ports in the static aggregation group. 154

162 Configuring a Layer 2 dynamic aggregation group To guarantee a successful dynamic aggregation, make sure the peer ports of the ports aggregated at one end are also aggregated. The two ends can automatically negotiate the aggregation state of each member port. To configure a Layer 2 dynamic aggregation group: Step Command Remarks 1. Enter system view. system-view N/A 2. Set the system LACP priority. lacp system-priority system-priority Optional. By default, the system LACP priority is Changing the system LACP priority might affect the aggregation state of the ports in a dynamic aggregation group. 3. Create a Layer 2 aggregate interface and enter Layer 2 aggregate interface view. 4. Configure the aggregation group to operate in dynamic aggregation mode. interface bridge-aggregation interface-number link-aggregation mode dynamic When you create a Layer 2 aggregate interface, the system automatically creates a Layer 2 static aggregation group numbered the same. By default, an aggregation group operates in static aggregation mode. 5. Exit to system view. quit N/A 6. Assign a Layer 2 Ethernet interface to the aggregation group. 7. Assign the port an aggregation priority. 8. Set the LACP timeout interval on the port to the short timeout interval (1 second). a. interface interface-type interface-number b. port link-aggregation group number link-aggregation port-priority port-priority lacp period short Repeat these two sub-steps to assign more Layer 2 Ethernet interfaces to the aggregation group. Optional. By default, the aggregation priority of a port is When the number of ports eligible for Selected ports exceeds the maximum number of Selected ports allowed in a dynamic aggregation group, changing the aggregation priority of a port might affect the aggregation state of the ports in the dynamic aggregation group. Optional. By default, the LACP timeout interval on a port is the long timeout interval (30 seconds). Configuring a Layer 3 dynamic aggregation group To guarantee a successful dynamic aggregation, make sure the peer ports of the ports aggregated at one end are also aggregated. The two ends can automatically negotiate the aggregation state of each member port. 155

163 To configure a Layer 3 dynamic aggregation group: Step Command Remarks 1. Enter system view. system-view N/A 2. Set the system LACP priority. lacp system-priority system-priority Optional. By default, the system LACP priority is Changing the system LACP priority might affect the aggregation state of the ports in the dynamic aggregation group. 3. Create a Layer 3 aggregate interface and enter Layer 3 aggregate interface view. 4. Configure the aggregation group to operate in dynamic aggregation mode. interface route-aggregation interface-number link-aggregation mode dynamic When you create a Layer 3 aggregate interface, the system automatically creates a Layer 3 static aggregation group numbered the same. By default, an aggregation group operates in static aggregation mode. 5. Exit to system view. quit N/A 6. Assign a Layer 3 Ethernet interface to the aggregation group. 7. Assign the port an aggregation priority. 8. Set the LACP timeout interval on the port to the short timeout interval (1 second). a. interface interface-type interface-number b. port link-aggregation group number link-aggregation port-priority port-priority lacp period short Repeat these two sub-steps to assign more Layer 3 Ethernet interfaces to the aggregation group. Optional. By default, the aggregation priority of a port is When the number of ports eligible for becoming Selected ports exceeds the maximum number of Selected ports allowed in a dynamic aggregation group, changing the aggregation priority of a port might affect the aggregation state of ports in the dynamic aggregation group. Optional. By default, the LACP timeout interval on a port is the long timeout interval (30 seconds). Configuring an aggregate interface Most of the configurations that can be performed on Layer 2 or Layer 3 Ethernet interfaces can also be performed on Layer 2 or Layer 3 aggregate interfaces. 156

164 Configuring the description of an aggregate interface or subinterface You can configure the description of an aggregate interface for administration purposes such as describing the purpose of the interface. To configure the description of an aggregate interface or subinterface: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter aggregate interface view. 3. Configure the description of the aggregate interface or subinterface. Enter Layer 2 aggregate interface or subinterface view: interface bridge-aggregation { interface-number interface-number.subnumber } Enter Layer 3 aggregate interface or subinterface view: interface route-aggregation { interface-number interface-number.subnumber } description text Use either command. Optional. By default, the description of an interface is in the format of interface-name Interface, such as Bridge-Aggregation1 Interface. Configuring the MTU of a Layer 3 aggregate interface or subinterface The MTU of an interface affects IP packets fragmentation and reassembly on the interface. To change the MTU of a Layer 3 aggregate interface or subinterface: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter Layer 3 aggregate interface or subinterface view. 3. Configure the MTU of the Layer 3 aggregate interface or subinterface. interface route-aggregation { interface-number interface-number.subnumber } mtu size N/A. Optional. The default MTU is 1500 bytes. Enabling link state traps for an aggregate interface You can configure an aggregate interface to generate linkup trap messages when its link goes up and linkdown trap messages when its link goes down. For more information, see System Management and Maintenance Configuration Guide. To enable link state traps on an aggregate interface: Step Command Remarks 1. Enter system view. system-view N/A 157

165 Step Command Remarks 2. Enable the trap function globally. 3. Enter aggregate interface view. 4. Enable link state traps for the aggregate interface. snmp-agent trap enable [ standard [ linkdown linkup ] * ] Enter Layer 2 aggregate interface or subinterface view: interface bridge-aggregation { interface-number interface-number.subnumber } Enter Layer 3 aggregate interface view: interface route-aggregation interface-number enable snmp trap updown Optional. By default, link state trapping is enabled globally and on all interfaces. Use either command. Optional. Enabled by default. Limiting the number of Selected ports for an aggregation group The following matrix shows the feature and hardware compatibility: Hardware F1000-A-EI/F1000-S-EI F1000-E F5000 F5000-S/F5000-C VPN firewall modules 20-Gbps VPN firewall modules Compatibility Yes No Yes No No No The bandwidth of an aggregate link increases along with the number of selected member ports. To avoid congestion caused by an insufficient number of Selected ports on an aggregate link, set the minimum number of Selected ports required for bringing up the specific aggregate interface. This minimum threshold setting affects the aggregation state of both aggregation member ports and the aggregate interface, as follows: All member ports change to the Unselected state and the link of the aggregate interface goes down, when the number of member ports eligible for being selected is smaller than the minimum threshold. When the minimum threshold is reached, the eligible member ports change to the Selected state, and the aggregate interface link goes up. By default, the maximum number of Selected ports allowed in an aggregation group depends on the hardware capabilities of the member ports. After you manually configure the maximum number of Selected ports in an aggregation group, the maximum number of Selected ports allowed in the aggregation group is the lower value of the two upper limits. You can configure redundancy between two ports using the following guideline: Assign two ports to an aggregation group, and configure the maximum number of Selected ports allowed in the aggregation 158

166 group as 1. In this way, only one Selected port is allowed in the aggregation group at any point in time, while the Unselected port serves as a backup port. When you configure the port threshold settings, follow these guidelines: If you set a minimum threshold for a static aggregation group, also make the same setting for its peer aggregation group to guarantee correct aggregation. Make sure the two link aggregation ends have the same limit on the number of selected ports. Make sure you understand the following impacts of the port threshold settings: Configuring the minimum number of Selected ports required to bring up an aggregation group might cause all the member ports in the aggregation group to become unselected. Configuring the maximum number of Selected ports in an aggregation group might cause some of the selected member ports in the aggregation group to become unselected. To limit the number of Selected ports for an aggregation group: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter aggregate interface view. 3. Set the minimum number of Selected ports for the aggregation group. 4. Set the maximum number of Selected ports for the aggregation group. Enter Layer 2 aggregate interface view: interface bridge-aggregation interface-number Enter Layer 3 aggregate interface view: interface route-aggregation interface-number link-aggregation selected-port minimum number link-aggregation selected-port maximum number Use either command. Not specified by default. By default, the maximum number of Selected ports for an aggregation group depends on the hardware capabilities of the member ports. Shutting down an aggregate interface Shutting down or bringing up an aggregate interface affects the aggregation state and link state of aggregated member ports in the following ways: When an aggregate interface is shut down, all Selected member ports become unselected and their link state becomes down. Shutting down a Layer 3 aggregate subinterface does not affect any aggregation group, because Layer 3 aggregate subinterfaces are not associated with any aggregation groups. When an aggregate interface is brought up, the aggregation state of member ports is recalculated and their link state becomes up. To shut down an aggregate interface: Step Command Remarks 1. Enter system view. system-view N/A 159

167 Step Command Remarks 2. Enter aggregate interface view. 3. Shut down the aggregate interface or subinterface. Enter Layer 2 aggregate interface or subinterface view: interface bridge-aggregation { interface-number interface-number.subnumber } Enter Layer 3 aggregate interface view: interface route-aggregation interface-number shutdown Use either command. By default, aggregate interfaces or subinterfaces are up. Restoring the default settings for an aggregate interface Step Command Remarks 1. Enter system view. system-view N/A 2. Enter aggregate interface view. 3. Restore the default settings for the aggregate interface or subinterface. Enter Layer 2 aggregate interface or subinterface view: interface bridge-aggregation { interface-number interface-number.subnumber } Enter Layer 3 aggregate interface view: interface route-aggregation interface-number default Use either command. N/A Configuring load sharing criteria for link aggregation groups You can determine how traffic is load-shared in a link aggregation group by configuring load sharing criteria. The criteria can be source/destination service port numbers, source/destination IP addresses, or protocol numbers carried in packets, or any combination. You can also perform per-packet load sharing. You can configure global or group-specific load sharing criteria. A link aggregation group preferentially uses the group-specific load sharing criteria. If no group-specific load sharing criteria is available, the group uses the global load sharing criteria. Configuring the global link-aggregation load sharing criteria Step Command Remarks 1. Enter system view. system-view N/A 2. Configure the global link-aggregation load sharing criteria. link-aggregation load-sharing mode { { destination-ip destination-port ip-protocol source-ip source-port } * per-packet } By default, destination-ip, destination-port, ip-protocol, source-ip, and source-port are enabled. 160

168 Configuring group-specific load sharing criteria Step Command Remarks 1. Enter system view. system-view N/A 2. Enter aggregate interface view. 3. Configure the load sharing criteria for the aggregation group. Enter Layer 2 aggregate interface view: interface bridge-aggregation interface-number Enter Layer 3 aggregate interface view: interface route-aggregation interface-number link-aggregation load-sharing mode { { destination-ip destination-port ip-protocol source-ip source-port } * per-packet } Use either command. By default, the device performs load sharing based on the five-tuple (source IP address, destination IP address, source port, destination port, and protocol). Support for the per-packet keyword depends on the device model. For more information, see this command in High Availability Command Reference. Displaying and maintaining Ethernet link aggregation Task Command Remarks Display information about aggregate interfaces. Display the local system ID. Display the global or group-specific link-aggregation load sharing criteria. Display detailed link aggregation information for link aggregation member ports. Display summary information about all aggregation groups. Display detailed information about a specific or all aggregation groups. display interface [ bridge-aggregation route-aggregation ] [ brief [ down ] ] [ { begin exclude include } regular-expression ] display interface { bridge-aggregation route-aggregation } interface-number [ brief ] [ { begin exclude include } regular-expression ] display lacp system-id [ { begin exclude include } regular-expression ] display link-aggregation load-sharing mode [ interface [ { bridge-aggregation route-aggregation } interface-number ] ] [ { begin exclude include } regular-expression ] display link-aggregation member-port [ interface-list ] [ { begin exclude include } regular-expression ] display link-aggregation summary [ { begin exclude include } regular-expression ] display link-aggregation verbose [ { bridge-aggregation route-aggregation } [ interface-number ] ] [ { begin exclude include } regular-expression ] Available in any view. Available in any view. Available in any view. Available in any view. Available in any view. Available in any view. 161

169 Task Command Remarks Clear LACP statistics for a specific or all link aggregation member ports. Clear statistics for a specific or all aggregate interfaces. reset lacp statistics [ interface interface-list ] reset counters interface [ { bridge-aggregation route-aggregation } [ interface-number ] ] Available in user view. Available in user view. Ethernet link aggregation configuration examples In an aggregation group, only ports that have the same port attributes and class-two configurations (see "Configuration classes") as the reference port (see "Reference port") can operate as Selected ports. Make sure all member ports have the same port attributes and class-two configurations as the reference port. The other settings only need to be configured on the aggregate interface, not on the member ports. Layer 2 static aggregation configuration example 1. Network requirements As shown in Figure 73, configure a Layer 2 static aggregation group on Firewall A and Firewall B. Enable VLAN 10 at one end of the aggregate link to communicate with VLAN 10 at the other end, and enable VLAN 20 at one end to communicate with VLAN 20 at the other end. Enable traffic to be load-shared across aggregation group member ports based on the source and destination IP addresses. Figure 73 Network diagram VLAN 10 VLAN 10 Firewall A GE0/3 GE0/1 Link aggregation 1 GE0/1 GE0/3 Firewall B GE0/4 GE0/2 BAGG1 BAGG1 GE0/2 GE0/4 VLAN 20 VLAN Configuration procedure a. Configure Firewall A: # Create VLAN 10, and assign port GigabitEthernet 0/3 to VLAN 10. <FirewallA> system-view [FirewallA] vlan 10 [FirewallA-vlan10] port gigabitethernet 0/3 [FirewallA-vlan10] quit # Create VLAN 20, and assign port GigabitEthernet 0/4 to VLAN 20. [FirewallA] vlan 20 [FirewallA-vlan20] port gigabitethernet 0/4 [FirewallA-vlan20] quit 162

170 # Create Layer 2 aggregate interface Bridge-Aggregation 1. [FirewallA] interface bridge-aggregation 1 [FirewallA-Bridge-Aggregation1] quit # Assign ports GigabitEthernet 0/1 and GigabitEthernet 0/2 to link aggregation group 1. [FirewallA] interface gigabitethernet 0/1 [FirewallA-GigabitEthernet0/1] port link-aggregation group 1 [FirewallA-GigabitEthernet0/1] quit [FirewallA] interface gigabitethernet 0/2 [FirewallA-GigabitEthernet0/2] port link-aggregation group 1 [FirewallA-GigabitEthernet0/2] quit # Configure Layer 2 aggregate interface Bridge-Aggregation 1 as a trunk port and assign it to VLANs 10 and 20. [FirewallA] interface bridge-aggregation 1 [FirewallA-Bridge-Aggregation1] port link-type trunk [FirewallA-Bridge-Aggregation1] port trunk permit vlan Please wait... Done. Configuring GigabitEthernet0/1... Done. Configuring GigabitEthernet0/2... Done. [FirewallA-Bridge-Aggregation1] quit # Configure Device A to use the source and destination IP addresses of packets as the global link-aggregation load sharing criteria. [FirewallA] link-aggregation load-sharing mode source-ip destination-ip b. Configure Firewall B in the same way Firewall A is configured. (Details not shown.) 3. Verify the configuration # Display summary information about all aggregation groups on Firewall A. [FirewallA] display link-aggregation summary Aggregation Interface Type: BAGG -- Bridge-Aggregation, RAGG -- Route-Aggregation Aggregation Mode: S -- Static, D -- Dynamic Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing Actor System ID: 0x8000, 000f-e2ff-0001 AGG AGG Partner ID Select Unselect Share Interface Mode Ports Ports Type BAGG1 S none 2 0 Shar The output shows that link aggregation group 1 is a load-shared Layer 2 static aggregation group and it contains two Selected ports. # Display the global link-aggregation load sharing criteria on Firewall A. [FirewallA] display link-aggregation load-sharing mode Link-Aggregation Load-Sharing Mode: destination-ip address, source-ip address The output shows that all link aggregation groups created on the device perform load sharing based on source and destination IP addresses. Layer 2 dynamic aggregation configuration example 1. Network requirements 163

171 As shown in Figure 74, configure a Layer 2 dynamic aggregation group on Firewall A and Firewall B. Enable VLAN 10 at one end of the aggregate link to communicate with VLAN 10 at the other end, and enable VLAN 20 at one end to communicate with VLAN 20 at the other end. Enable traffic to be load-shared across aggregation group member ports based on source and destination IP addresses. Figure 74 Network diagram VLAN 10 VLAN 10 Firewall A GE0/3 GE0/1 Link aggregation 1 GE0/1 GE0/3 Firewall B GE0/4 GE0/2 BAGG1 BAGG1 GE0/2 GE0/4 VLAN 20 VLAN Configuration procedure a. Configure Firewall A: # Create VLAN 10, and assign the port GigabitEthernet 0/3 to VLAN 10. <FirewallA> system-view [FirewallA] vlan 10 [FirewallA-vlan10] port gigabitethernet 0/3 [FirewallA-vlan10] quit # Create VLAN 20, and assign port GigabitEthernet 0/4 to VLAN 20. [FirewallA] vlan 20 [FirewallA-vlan20] port gigabitethernet 0/4 [FirewallA-vlan20] quit # Create Layer 2 aggregate interface Bridge-Aggregation 1, and configure the link aggregation mode as dynamic. [FirewallA] interface bridge-aggregation 1 [FirewallA-Bridge-Aggregation1] link-aggregation mode dynamic # Assign ports GigabitEthernet 0/1 and GigabitEthernet 0/2 to link aggregation group 1. [FirewallA] interface gigabitethernet 0/1 [FirewallA-GigabitEthernet0/1] port link-aggregation group 1 [FirewallA-GigabitEthernet0/1] quit [FirewallA] interface gigabitethernet 0/2 [FirewallA-GigabitEthernet0/2] port link-aggregation group 1 [FirewallA-GigabitEthernet0/2] quit # Configure Layer 2 aggregate interface Bridge-Aggregation 1 as a trunk port and assign it to VLANs 10 and 20. [FirewallA] interface bridge-aggregation 1 [FirewallA-Bridge-Aggregation1] port link-type trunk [FirewallA-Bridge-Aggregation1] port trunk permit vlan

172 Please wait... Done. Configuring GigabitEthernet0/1... Done. Configuring GigabitEthernet0/2... Done. [FirewallA-Bridge-Aggregation1] quit # Configure the device to use the source and destination IP addresses of packets as the global link-aggregation load sharing criteria. [FirewallA] link-aggregation load-sharing mode source-ip destination-ip b. Configure Firewall B in the same way Firewall A is configured. (Details not shown.) 3. Verify the configuration # Display summary information about all aggregation groups on Firewall A. [FirewallA] display link-aggregation summary Aggregation Interface Type: BAGG -- Bridge-Aggregation, RAGG -- Route-Aggregation Aggregation Mode: S -- Static, D -- Dynamic Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing Actor System ID: 0x8000, 000f-e2ff-0001 AGG AGG Partner ID Select Unselect Share Interface Mode Ports Ports Type BAGG1 D 0x8000, 000f-e2ff Shar The output shows that link aggregation group 1 is a load-shared Layer 2 dynamic aggregation group, and it contains two Selected ports. # Display the global link-aggregation load sharing criteria on Firewall A. [FirewallA] display link-aggregation load-sharing mode Link-Aggregation Load-Sharing Mode: destination-ip address, source-ip address The output shows that all link aggregation groups created on the device perform load sharing based on source and destination IP addresses. Layer 2 aggregation load sharing configuration example 1. Network requirements As shown in Figure 75, configure two Layer 2 static aggregation groups (1 and 2) on Firewall A and Firewall B, and enable VLAN 10 at one end of the aggregate link to communicate with VLAN 10 at the other end, and enable VLAN 20 at one end to communicate with VLAN 20 at the other end. Configure the load sharing criterion for link aggregation group 1 as the source IP addresses of packets and the load sharing criterion for link aggregation group 2 as the destination IP addresses of packets to enable traffic to be load-shared across aggregation group member ports. 165

173 Figure 75 Network diagram 2. Configuration procedure a. Configure Firewall A: # Create VLAN 10, and assign port GigabitEthernet 0/5 to VLAN 10. <FirewallA> system-view [FirewallA] vlan 10 [FirewallA-vlan10] port gigabitethernet 0/5 [FirewallA-vlan10] quit # Create VLAN 20, and assign port GigabitEthernet 1/1 to VLAN 20. <FirewallA> system-view [FirewallA] vlan 20 [FirewallA-vlan20] port gigabitethernet 1/1 [FirewallA-vlan20] quit # Create Layer 2 aggregate interface Bridge-Aggregation 1, and configure the load sharing criterion for the link aggregation group as the source IP addresses of packets. [FirewallA] interface bridge-aggregation 1 [FirewallA-Bridge-Aggregation1] link-aggregation load-sharing mode source-ip [FirewallA-Bridge-Aggregation1] quit # Assign ports GigabitEthernet 0/1 and GigabitEthernet 0/2 to link aggregation group 1. [FirewallA] interface gigabitethernet 0/1 [FirewallA-GigabitEthernet0/1] port link-aggregation group 1 [FirewallA-GigabitEthernet0/1] quit [FirewallA] interface gigabitethernet 0/2 [FirewallA-GigabitEthernet0/2] port link-aggregation group 1 [FirewallA-GigabitEthernet0/2] quit # Configure Layer 2 aggregate interface Bridge-Aggregation 1 as a trunk port and assign it to VLAN 10. [FirewallA] interface bridge-aggregation 1 [FirewallA-Bridge-Aggregation1] port link-type trunk [FirewallA-Bridge-Aggregation1] port trunk permit vlan 10 Please wait... Done. Configuring GigabitEthernet0/1... Done. Configuring GigabitEthernet0/2... Done. [FirewallA-Bridge-Aggregation1] quit 166

174 # Create Layer 2 aggregate interface Bridge-Aggregation 2, and configure the load sharing criterion for the link aggregation group as the destination IP addresses of packets. [FirewallA] interface bridge-aggregation 2 [FirewallA-Bridge-Aggregation2] link-aggregation load-sharing mode destination-ip [FirewallA-Bridge-Aggregation2] quit # Assign ports GigabitEthernet 0/3 and GigabitEthernet 0/4 to link aggregation group 2. [FirewallA] interface gigabitethernet 0/3 [FirewallA-GigabitEthernet0/3] port link-aggregation group 2 [FirewallA-GigabitEthernet0/3] quit [FirewallA] interface gigabitethernet 0/4 [FirewallA-GigabitEthernet0/4] port link-aggregation group 2 [FirewallA-GigabitEthernet0/4] quit # Configure Layer 2 aggregate interface Bridge-Aggregation 2 as a trunk port and assign it to VLAN 20. [FirewallA] interface bridge-aggregation 2 [FirewallA-Bridge-Aggregation2] port link-type trunk [FirewallA-Bridge-Aggregation2] port trunk permit vlan 20 Please wait... Done. Configuring GigabitEthernet0/3... Done. Configuring GigabitEthernet0/4... Done. [FirewallA-Bridge-Aggregation2] quit b. Configure Firewall B in the same way Firewall A is configured. (Details not shown.) 3. Verify the configuration # Display summary information about all aggregation groups on Firewall A. [FirewallA] display link-aggregation summary Aggregation Interface Type: BAGG -- Bridge-Aggregation, RAGG -- Route-Aggregation Aggregation Mode: S -- Static, D -- Dynamic Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing Actor System ID: 0x8000, 000f-e2ff-0001 AGG AGG Partner ID Select Unselect Share Interface Mode Ports Ports Type BAGG1 S none 2 0 Shar BAGG2 S none 2 0 Shar The output shows that link aggregation groups 1 and 2 are both load-sharing-capable Layer 2 static aggregation groups and each contains two Selected ports. # Display all the group-specific load sharing criteria on Firewall A. [FirewallA] display link-aggregation load-sharing mode interface 167

175 Bridge-Aggregation1 Load-Sharing Mode: source-ip address Bridge-Aggregation2 Load-Sharing Mode: destination-ip address The output shows that the load sharing criterion for link aggregation group 1 is the source IP addresses of packets and that for link aggregation group 2 is the destination IP addresses of packets. Layer 3 static aggregation configuration example 1. Network requirements As shown in Figure 76, configure a Layer 3 static aggregation group on both Firewall A and Firewall B and configure IP addresses and subnet masks for the corresponding Layer 3 aggregate interfaces. Enable traffic to be load-shared across aggregation group member ports based on source and destination IP addresses. Figure 76 Network diagram 2. Configuration procedure a. Configure Firewall A: # Create Layer 3 aggregate interface Route-Aggregation 1, and configure an IP address and subnet mask for the aggregate interface. <FirewallA> system-view [FirewallA] interface route-aggregation 1 [FirewallA-Route-Aggregation1] ip address [FirewallA-Route-Aggregation1] quit # Assign Layer 3 interfaces GigabitEthernet 0/1 through GigabitEthernet 0/3 to aggregation group 1. [FirewallA] interface gigabitethernet 0/1 [FirewallA-GigabitEthernet0/1] port link-aggregation group 1 [FirewallA-GigabitEthernet0/1] quit [FirewallA] interface gigabitethernet 0/2 [FirewallA-GigabitEthernet0/2] port link-aggregation group 1 [FirewallA-GigabitEthernet0/2] quit [FirewallA] interface gigabitethernet 0/3 [FirewallA-GigabitEthernet0/3] port link-aggregation group 1 [FirewallA-GigabitEthernet0/3] quit # Configure the global link-aggregation load sharing criteria as the source and destination IP addresses of packets. [FirewallA] link-aggregation load-sharing mode source-ip destination-ip b. Configure Firewall B in the same way Firewall A is configured. (Details not shown.) 3. Verify the configuration 168

176 # Display summary information about all aggregation groups on Firewall A. [FirewallA] display link-aggregation summary Aggregation Interface Type: BAGG -- Bridge-Aggregation, RAGG -- Route-Aggregation Aggregation Mode: S -- Static, D -- Dynamic Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing Actor System ID: 0x8000, 000f-e2ff-0001 AGG AGG Partner ID Select Unselect Share Interface Mode Ports Ports Type RAGG1 S none 3 0 Shar The output shows that link aggregation group 1 is a load-sharing-capable Layer 3 static aggregation group that contains three Selected ports. # Display the global link-aggregation load sharing criteria on Firewall A. [FirewallA] display link-aggregation load-sharing mode Link-Aggregation Load-Sharing Mode: destination-ip address, source-ip address The output shows that the global link-aggregation load sharing criteria are the source and destination IP addresses of packets. Layer 3 dynamic aggregation configuration example 1. Network requirements As shown in Figure 77, configure a Layer 3 dynamic aggregation group on Firewall A and Firewall B, and configure IP addresses and subnet masks for the Layer 3 aggregate interfaces. Enable traffic to be load-shared across aggregation group member ports based on source and destination IP addresses. Figure 77 Network diagram 2. Configuration procedure a. Configure Firewall A: # Create Layer 3 aggregate interface Route-Aggregation 1, configure the link aggregation mode as dynamic, and configure an IP address and subnet mask for the aggregate interface. <FirewallA> system-view [FirewallA] interface route-aggregation 1 [FirewallA-Route-Aggregation1] link-aggregation mode dynamic [FirewallA-Route-Aggregation1] ip address [FirewallA-Route-Aggregation1] quit # Assign Layer 3 interfaces GigabitEthernet 0/1 through GigabitEthernet 0/3 to aggregation group 1. [FirewallA] interface gigabitethernet 0/1 [FirewallA-GigabitEthernet0/1] port link-aggregation group 1 [FirewallA-GigabitEthernet0/1] quit 169

177 [FirewallA] interface gigabitethernet 0/2 [FirewallA-GigabitEthernet0/2] port link-aggregation group 1 [FirewallA-GigabitEthernet0/2] quit [FirewallA] interface gigabitethernet 0/3 [FirewallA-GigabitEthernet0/3] port link-aggregation group 1 [FirewallA-GigabitEthernet0/3] quit # Configure Firewall A to use the source and destination IP addresses of packets as the global link-aggregation load sharing criteria. [FirewallA] link-aggregation load-sharing mode source-ip destination-ip b. Configure Firewall B in the same way Firewall A is configured. (Details not shown.) 3. Verify the configuration: # Display summary information about all aggregation groups on Firewall A. [FirewallA] display link-aggregation summary Aggregation Interface Type: BAGG -- Bridge-Aggregation, RAGG -- Route-Aggregation Aggregation Mode: S -- Static, D -- Dynamic Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing Actor System ID: 0x8000, 000f-e2ff-0001 AGG AGG Partner ID Select Unselect Share Interface Mode Ports Ports Type RAGG1 D 0x8000, 000f-e2ff Shar The output shows that link aggregation group 1 is a load-shared Layer 3 dynamic aggregation group and it contains three Selected ports. # Display the global link-aggregation load sharing criteria on Firewall A. [FirewallA] display link-aggregation load-sharing mode Link-Aggregation Load-Sharing Mode: destination-ip address, source-ip address The output shows that the global link-aggregation load sharing criteria are the source and destination IP addresses of packets. Layer 3 aggregation load sharing configuration example 1. Network requirements As shown in Figure 78, configure two Layer 3 static aggregation groups (1 and 2) on both Firewall A and Firewall B, and configure IP addresses and subnet masks for the corresponding Layer 3 aggregate interfaces. Configure link aggregation group 1 to perform load sharing based on source IP address and link aggregation group 2 to perform load sharing based on destination IP address. Figure 78 Network diagram 170

178 2. Configuration procedure a. Configure Firewall A: # Create Layer 3 aggregate interface Route-Aggregation 1, configure it to perform load sharing based on source IP address, and configure an IP address and subnet mask for the aggregate interface. <FirewallA> system-view [FirewallA] interface route-aggregation 1 [FirewallA-Route-Aggregation1] link-aggregation load-sharing mode source-ip [FirewallA-Route-Aggregation1] ip address [FirewallA-Route-Aggregation1] quit # Assign Layer 3 interfaces GigabitEthernet 0/1 and GigabitEthernet 0/2 to aggregation group 1. [FirewallA] interface gigabitethernet 0/1 [FirewallA-GigabitEthernet0/1] port link-aggregation group 1 [FirewallA-GigabitEthernet0/1] quit [FirewallA] interface gigabitethernet 0/2 [FirewallA-GigabitEthernet0/2] port link-aggregation group 1 [FirewallA-GigabitEthernet0/2] quit # Create Layer 3 aggregate interface Route-Aggregation 2, configure its link aggregation group to perform load sharing based on destination IP address, and configure an IP address and subnet mask for the aggregate interface. [FirewallA] interface route-aggregation 2 [FirewallA-Route-Aggregation2] link-aggregation load-sharing mode destination-ip [FirewallA-Route-Aggregation2] ip address [FirewallA-Route-Aggregation2] quit # Assign Layer 3 interfaces GigabitEthernet 0/3 and GigabitEthernet 0/4 to aggregation group 2. [FirewallA] interface gigabitethernet 0/3 [FirewallA-GigabitEthernet0/3] port link-aggregation group 2 [FirewallA-GigabitEthernet0/3] quit [FirewallA] interface gigabitethernet 0/4 [FirewallA-GigabitEthernet0/4] port link-aggregation group 2 [FirewallA-GigabitEthernet0/4] quit b. Configure Firewall B in the same way Firewall A is configured. (Details not shown.) 3. Verify the configuration # Display summary information about all aggregation groups on Firewall A. [FirewallA] display link-aggregation summary Aggregation Interface Type: BAGG -- Bridge-Aggregation, RAGG -- Route-Aggregation Aggregation Mode: S -- Static, D -- Dynamic Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing Actor System ID: 0x8000, 000f-e2ff-0001 AGG AGG Partner ID Select Unselect Share Interface Mode Ports Ports Type RAGG1 S none 2 0 Shar 171

179 RAGG2 S none 2 0 Shar The output shows that link aggregation groups 1 and 2 are both load-shared Layer 3 static aggregation groups and each contains two Selected ports. # Display all the group-specific load sharing criteria on Firewall A. [FirewallA] display link-aggregation load-sharing mode interface Route-Aggregation1 Load-Sharing Mode: source-ip address Route-Aggregation2 Load-Sharing Mode: destination-ip address The output shows that the load sharing criterion for link aggregation group 1 is the source IP address and the load sharing criterion for link aggregation group 2 is the destination IP address. 172

180 Configuring interface backup The term "router" in this document refers to both routers and routing-capable firewalls and firewall modules. Interface backup can be configured only at the CLI. Feature and hardware compatibility Hardware F1000-A-EI/F1000-S-EI F1000-E F5000 F5000-S/F5000-C VPN firewall modules 20-Gbps VPN firewall modules Interface backup compatibility Yes Yes Yes Yes Yes No Overview Interface backup increases network reliability. The active interface transmits services, and the standby interfaces are in the backup state. When the active interface fails or the link fails, or when the traffic on the active interface exceeds the configured threshold, a standby interface is activated to transmit services. As shown in Figure 79, interfaces Serial 2/0, Serial 2/1, and Serial 2/2 on Router A back up each other. Serial 2/0 transmits data, and Serial 2/1 and Serial 2/2 are standby interfaces that have different priorities. Figure 79 Diagram for interface backup When interface Serial 2/0 or its link to Router B fails, or when the traffic on Serial 2/0 exceeds the configured threshold, the standby interface with the highest priority is activated, ensuring uninterrupted data transmission. 173

181 Active and standby interfaces In interface backup, an interface can be an active interface or standby interface. Interfaces that can serve as active or standby interfaces are: Layer 3 Ethernet interfaces, Layer 3 Ethernet subinterfaces, dialer interfaces, and Tunnel interfaces. Ten-GigabitEthernet interfaces cannot serve as active or standby interfaces. An active interface transmits data, and can be configured with up to three standby interfaces (for example, Serial 2/0 in Figure 79). Up to 10 active interfaces can be configured on a device. Standby interfaces function as backups for active interfaces (for example, interfaces Serial 2/1 and Serial 2/2 in Figure 79), which are generally idle. One standby interface can only back up one active interface. How interface backup works Interface backup operates in active/standby mode or in load balancing mode. Active/standby mode As shown in Figure 80, interface Serial 2/0 on Router A acts as the active interface and interfaces Serial 2/1 and Serial 2/2 act as the standby interfaces. Figure 80 Diagram for active/standby mode In active/standby mode, only one interface transmits data at any given time. When the active interface is operating correctly, even if the traffic is overloaded, the standby interface is in a backup state. All traffic is transmitted by the active interface. If the active interface fails, the standby interface with highest priority takes over to transmit data. When the active interface is restored, it resumes data transmission. Load balancing mode As shown in Figure 81, interface Serial 2/0 on Router A acts as the active interface, and interfaces Serial 2/1 and Serial 2/2 act as the standby interfaces. 174

182 Figure 81 Diagram for load balancing mode S2/2 In load balancing mode, you can set an upper threshold (enable-threshold) and a lower threshold (disable-threshold). Traffic can be shared among multiple interfaces: When the traffic on the active interface exceeds the predefined enable-threshold, the highest priority standby interface is activated. Other standby interfaces are activated in descending priority order if exceeding traffic still exists. When the traffic on the active interface decreases below the predefined disable-threshold, the system shuts down the lowest priority standby interface first and then shuts down the other standby interfaces in ascending priority order depending on traffic size. NOTE: Adopt active/standby or load balancing mode depending on whether you have configured an upper or lower threshold for the active interface traffic. If this threshold is configured, load balancing mode is adopted. Otherwise, active/standby mode is adopted. If a dialer interface acts as the active interface, the load balancing mode does not take effect. Interface backup configuration task list Task Configuring interface backup Configuring load balancing Configuring active/standby mode Associating an interface with a track entry Remarks Optional Optional Configuring interface backup You can configure interface backup through active/standby mode or association between an interface and a track entry, but you cannot configure them at the same time. Configuring active/standby mode You can configure multiple standby interfaces for one active interface. The standby interfaces are activated depending on their priority, with the highest priority being activated first. 175

183 To prevent frequent interface switchover as a result of interface instability, you can configure a switchover delay. A standby interface then takes over only if the active interface remains down upon expiration of the delay. Follow these guidelines when you configure active/standby mode: To configure multiple standby interfaces for an active interface, execute the standby interface command multiple times. You can use the ip route-static command in system view to configure the routes for reaching a destination network through the active interface and its standby interfaces. For more information about the command, see Network Management Command Reference. If multiple standby interfaces have the same priority, when the active interface is down, the standby interface configured first is selected. To configure active/standby mode: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Specify a standby interface for the active interface. 4. Set switchover delays. interface interface-type interface-number standby interface interface-type interface-number [ priority ] standby timer delay enable-delay disable-delay N/A By default, no standby interface is specified for the active interface. Optional. Both thresholds are 0 by default, indicating immediate switchover without delay. Associating an interface with a track entry You can associate a standby interface with a track entry to enable the interface to monitor the state of the active interface through the track entry and change the backup state of the interface accordingly. If the state of the track entry is positive, the link connecting the active interface is normal and the standby interface stays in the backup state. If the state of the track entry is negative, the link connecting the active interface is not functioning correctly. The standby interface becomes the active interface to transmit data. When you associate an interface with a track entry, if the track entry is invalid, the interface keeps its forwarding state. After your configuration, if the state of the track entry changes to invalid, the standby interface will become the active interface. Follow these guidelines when you associate an interface with a track entry: One interface can be associated with one track entry only. If you execute the standby track command multiple times, the latter configuration overwrites the previous one. The track entry associated with an interface can be one you have not created yet. After you create a track entry with the track command, the association takes effect. For more information about the track module, see "Configuring Track." To associate an interface with a track entry: 176

184 Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Associate an interface with a track entry. interface interface-type interface-number standby track track-entry-number N/A By default, an interface is not associated with a track entry. Configuring load balancing Interface backup detects the data traffic on the active interface to determine whether to bring up or shut down the standby interface. When multiple standby interfaces are assigned the same priority, they are brought up or shut down depending on the order they are configured: The standby interface configured first is used first to participate in load balancing with the active interface. The standby interface configured later is shut down first and exits load balancing with the active interface. To configure load balancing: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter active interface view. 3. Configure the available bandwidth used for setting the thresholds. 4. Configure load balancing thresholds. 5. Configure the interval for detecting traffic size on the active interface. interface interface-type interface-number standby bandwidth size standby threshold enable-threshold disable-threshold standby timer flow-check interval N/A Optional. 0 kbps by default. No load balancing thresholds are configured by default. Optional. 30 seconds by default. Displaying and maintaining interface backup Task Command Remarks Display statistics about the traffic on the active interfaces enabled with load balancing. Display the state information of the active and standby interfaces. display standby flow [ { begin exclude include } regular-expression ] display standby state [ { begin exclude include } regular-expression ] Available in any view. Available in any view. 177

185 Interface backup configuration examples Multi-interface backup configuration example Network requirements Use interfaces GigabitEthernet 0/2 and GigabitEthernet 0/3 on Firewall A to back up the active interface GigabitEthernet 0/1, assigning interface GigabitEthernet 0/2 a higher priority, and configure switchover delays. Figure 82 Network diagram Configuration procedure 1. Configure IP addresses: Follow Figure 82 to configure the IP address and subnet mask for each interface. (Details not shown.) 2. Configure a static route: # On Firewall A, configure a static route to the segment /24 where Host B resides. <FirewallA> system-view [FirewallA] ip route-static gigabitethernet 0/ [FirewallA] ip route-static gigabitethernet 0/ [FirewallA] ip route-static gigabitethernet 0/ # On Firewall B, configure a static route to the segment /24 where Host A resides. <FirewallB> system-view [FirewallB] ip route-static gigabitethernet 0/ [FirewallB] ip route-static gigabitethernet 0/ [FirewallB] ip route-static gigabitethernet 0/ Configure the standby interfaces and switchover delays on Firewall A: # Specify interfaces GigabitEthernet 0/2 and GigabitEthernet 0/3 on Router A to back up GigabitEthernet 0/1, and assign them the priorities 30 and 20, respectively. [FirewallA] interface gigabitethernet 0/1 [FirewallA-GigabitEthernet0/1] standby interface gigabitethernet 0/2 30 [FirewallA-GigabitEthernet0/1] standby interface gigabitethernet 0/3 20 # Configure switchover delays to 10 seconds. [FirewallA-GigabitEthernet0/1] standby timer delay

186 4. Verify the configuration on Firewall A: # Display the state of the active and standby interfaces. [FirewallA-GigabitEthernet0/1] display standby state Interface Interfacestate Standbystate Standbyflag Pri Loadstate GigabitEthernet0/1 UP MUP MU GigabitEthernet0/2 STANDBY STANDBY BU 30 GigabitEthernet0/3 STANDBY STANDBY BU 20 Backup-flag meaning: M---MAIN B---BACKUP V---MOVED U---USED D---LOAD P---PULLED # Manually shut down the active interface GigabitEthernet 0/1. [FirewallA-GigabitEthernet0/1] shutdown # 10 seconds after the active interface was shut down, standby interface GigabitEthernet 0/2 with a higher priority is enabled. Then you can view the state of the active and standby interfaces. [RouterA-GigabitEthernet0/1] display standby state Interface Interfacestate Standbystate Standbyflag Pri Loadstate GigabitEthernet0/1 DOWN MDOWN MU GigabitEthernet0/2 UP UP BU 30 GigabitEthernet0/3 STANDBY STANDBY BU 20 Backup-flag meaning: M---MAIN B---BACKUP V---MOVED U---USED D---LOAD P---PULLED Multi-interface load balancing configuration example Network requirement Use interfaces GigabitEthernet 0/2 and GigabitEthernet 0/3 on Firewall A to back up the active interface GigabitEthernet 0/1, assigning interface GigabitEthernet 0/2 a higher priority. Configure the available bandwidth used for setting the thresholds and the enable-threshold and disable-threshold of load balancing. Figure 83 Network diagram 179

187 Configuration procedure 1. Configure IP addresses: Follow Figure 83 to configure the IP address and subnet mask for each interface. (Details not shown.) 2. Configure a static route: # On Firewall A, configure a static route to the segment /24 where Host B resides. <FirewallA> system-view [FirewallA] ip route-static gigabitethernet 0/ [FirewallA] ip route-static gigabitethernet 0/ [FirewallA] ip route-static gigabitethernet 0/ # On Firewall B, configure a static route to the segment /24 where Host A resides. <FirewallB> system-view [FirewallB] ip route-static gigabitethernet 0/ [FirewallB] ip route-static gigabitethernet 0/ [FirewallB] ip route-static gigabitethernet 0/ Configure the standby interfaces and load balancing on Firewall A: # Specify interfaces GigabitEthernet 0/2 and GigabitEthernet 0/3 on Firewall A to back up GigabitEthernet 0/1, and assign them the priorities 30 and 20, respectively. [FirewallA] interface gigabitethernet 0/1 [FirewallA-GigabitEthernet0/1] standby interface gigabitethernet 0/2 30 [FirewallA-GigabitEthernet0/1] standby interface gigabitethernet 0/3 20 # Configure the available bandwidth used for setting the thresholds to kbps. [FirewallA-GigabitEthernet0/1] standby bandwidth # Configure the enable-threshold of load balancing to 80 and the disable-threshold to 20. [FirewallA-GigabitEthernet0/1] standby threshold Verify the configuration on Firewall A: # Display the traffic statistics for the active interface taking part in load balancing. [FirewallA-GigabitEthernet0/1] display standby flow Interfacename : GigabitEthernet0/1 Flow-interval(s) : 30 LastInOctets : 139 LastOutOctets : InFlow(Octets) : 0 OutFlow(Octets) : 0 BandWidth(b/s) : UsedBandWidth(b/s) : 0 # Display the state of the active and standby interfaces. [FirewallA-GigabitEthernet0/1] display standby state Interface Interfacestate Standbystate Standbyflag Pri Loadstate GigabitEthernet0/1 UP MUP MUD TO-HYPNOTIZE GigabitEthernet0/2 STANDBY STANDBY BU 30 GigabitEthernet0/3 STANDBY STANDBY BU 20 Backup-flag meaning: M---MAIN B---BACKUP V---MOVED U---USED D---LOAD P---PULLED 180

188 # When the data traffic on the active interface GigabitEthernet 0/1 exceeds 8000 kbps (that is, kbps 80%), standby interface GigabitEthernet 0/2 with a higher priority is enabled first. Then you can view the state of the active and standby interfaces. [FirewallA-GigabitEthernet0/1] display standby state Interface Interfacestate Standbystate Standbyflag Pri Loadstate GigabitEthernet0/1 UP MUP MUD GigabitEthernet0/2 UP UP BU 30 GigabitEthernet0/3 STANDBY STANDBY BU 20 Backup-flag meaning: M---MAIN B---BACKUP V---MOVED U---USED D---LOAD P---PULLED 181

189 Configuring load balancing Feature and hardware compatibility Hardware F1000-A-EI/F1000-S-EI F1000-E F5000 F5000-S/F5000-C VPN firewall modules 20-Gbps VPN firewall modules Load balancing compatibility Supports only outbound link load balancing Supports only server/firewall load balancing Supports server/firewall load balancing and inbound/outbound link load balancing Supports only server/firewall load balancing Supports only server/firewall load balancing Supports only server/firewall load balancing Overview Load balancing (referred to as LB hereinafter) is a cluster technology to distribute specific services such as network services and network traffic among multiple network devices (for example servers and firewalls) or multiple links, enhancing service processing capability and ensuring high availability of services. LB delivers the following advantages: High performance LB distributes services to multiple network devices or links, enhancing the performance of the whole system. Scalability LB facilitates the addition of network devices or links in a cluster, meeting the ever-increasing service requirements for servers without decreasing service quality. Reliability Failure of a single or multiple devices or links will not result in service interruption, enhancing the reliability of the entire system. Manageability Administration is performed only on LB-enabled devices, and devices or links need only common configuration and maintenance. Transparency A cluster is like a device or link with high availability and performance, and users are not aware of and do not care the specific network structure. In addition, increasing or decreasing devices or links will not affect normal services. LB typically includes the following types: Server load balancing Data centers generally adopt server load balancing for networking. Network services are distributed to multiple servers to enhance service processing capabilities of the data centers. Firewall load balancing In networks where firewall processing capabilities have become the bottleneck, firewall load balancing can be adopted to balance the network traffic among multiple firewalls to enhance the processing capabilities of firewalls. Link load balancing Link load balancing applies to a network environment where there are multiple carrier interfaces to implement dynamic selection of links, enhancing the service reliability. 182

190 Working mechanism of server load balancing Server load balancing is implemented based on streams. It distributes packets in the same stream to the same server. Server load balancing cannot distribute HTTP-based Layer 7 services based on contents, restricting the application scope of load balancing services. It can be classified into Network Address Translation (NAT)-mode server load balancing and direct routing (DR)-mode server load balancing. NAT-mode server load balancing Figure 84 Network diagram Cluster Server A IP A Host IP network VSIP LB device Server B IP B Server C IP C NAT-mode server load balancing comprises the following elements: Cluster A cluster that provides specific services, including an LB device and multiple servers. LB device A device that distributes different service requests to multiple servers. Server A server that responds to and processes different service requests. VSIP Virtual Service IP address of the cluster, used for users to request services. Server IP IP address of a server, used for an LB device to distribute service requests. 183

191 Figure 85 Work flow of NAT-mode server load balancing NAT-mode server load balancing operates in the following way: 1. The host sends a request, using the host IP as the source IP and VSIP as the destination IP. 2. Upon receiving the request, the LB device uses an algorithm to calculate to which server it distributes the request. 3. The LB device uses the Destination NAT (DNAT) technology to distribute the request, using the host IP as the source IP and Server IP as the destination IP. 4. The server receives and processes the request and then sends a response, using the server IP as the source IP, and the host IP as the destination IP. 5. The LB device receives the response, translates the source IP, and forwards the response, using VSIP as the source IP, and the host IP as the destination IP. The work flow shows that NAT is used in server load balancing, and NAT-mode server load balancing is thus called. 184

192 DR-mode server load balancing Figure 86 Network diagram Cluster LB device Server A VSIP/IP A Host IP network VSIP General device Server B VSIP/IP B Server C VSIP/IP C DR mode is different from NAT mode in that NAT is not used in load balancing. This means that besides its local IP address, a server must have the VSIP configured. DR-mode server load balancing comprises the following elements: Cluster A cluster consists of an LB device, a general device, and multiple servers to provide specific services. LB device A device that distributes different service requests to multiple servers. General device A device that forwards data according to general forwarding rules. Server A server that responds to and processes different service requests. VSIP Virtual service IP address of the cluster, used for users to request services. Besides configuring the VSIP on the LB device, you need to configure it on servers. (Because the VSIP on the server cannot be contained in an ARP request and response, you can configure the VSIP on a loopback interface.) Server IP IP address of a server, used by the LB device to distribute requests. Figure 87 Work flow of DR-mode Layer 4 server load balancing DR-mode Layer 4 server load balancing operates in the following way: 185

193 1. The host sends a request, using VSIP as the destination address. 2. Upon receiving the request, the general device forwards it to LB device. The VSIP cannot be contained in an ARP request and response, so the general device only forwards the request to the LB device. 3. Upon receiving the request, the LB device uses an algorithm to calculate to which server it distributes the request. 4. The LB device distributes the request. The LB device encapsulates VSIP as the destination IP address, and the server's MAC address (obtained through ARP) as the destination MAC address. In this way, the request can be forwarded correctly to the server. 5. The server receives and processes the request, and then sends a response. The destination IP address of the response is the host IP. 6. After receiving the response, the general device forwards the response to the host. The response is addressed to the host rather than the LB device, so DR-mode server load balancing is called. Working mechanism of firewall load balancing Firewall load balancing supports IPv4 and IPv6. Figure 88 Network diagram Firewall load balancing comprises the following elements: Cluster A cluster consists of LB devices and firewalls to provide network traffic load balancing. LB device A device that distributes traffic from the request sender to multiple firewalls. LB devices include level 1 LB devices and level 2 LB devices. In Figure 88, if traffic is from Host A to Host B, LB device A is level 1, and LB device B is level 2. If traffic is from Host B to Host A, LB Device B is level 1, and LB Device A is level 2. Firewall A firewall filters packets. 186

194 Figure 89 Work flow of firewall load balancing LB device A Firewall LB device B (1) Traffic from source (2) Scheduler & Forward (3) Forward (4) Record & Forward to destination (5) Traffic from destination (6) Forward (7) Forward (8) Forward to source Firewall load balancing operates in the following way: 1. LB device A receives the traffic from the source. 2. LB device A forwards the traffic to a firewall based on the destination IP address range and the pre-configured load balancing rules of the traffic. 3. The firewall forwards the traffic to LB device B. 4. As a level 2 LB device, LB device B records the firewall that forwards the traffic and then forwards the traffic to the destination. 5. LB device B receives the traffic sent from the destination. 6. LB device B forwards the traffic to the firewall recorded in step The firewall forwards the traffic to LB device A. 8. LB device A forwards the traffic back to the source. The load balanced firewalls between two LB devices perform network traffic load balancing, and thus network performance is increased. This load balancing mode is also called sandwich load balancing. Firewall load balancing can be used together with server load balancing, as shown in Figure

195 Figure 90 Network diagram Cluster A adopts firewall load balancing, and Cluster B adopts NAT-mode server load balancing. This networking mode not only prevents firewalls from becoming the bottleneck in the network, but also enhances the performance and availability of multiple network services such as HTTP and FTP. Working mechanism of link load balancing Link load balancing includes outbound link load balancing and inbound link load balancing: Outbound link load balancing Helps internal users select the best path to access the external resources through an LB device according to the destination IP address of packets and outbound link load balancing configurations. Inbound link load balancing Helps external users select the best path for accessing an LB device according to the domain name of DNS requests and inbound link load balancing configurations. Inbound link load balancing can be used in combination of server load balancing. Outbound link load balancing Figure 91 Network diagram Cluster ISP1 Router A VSIP ISP2 IP network Source LB device Router B Destination ISP3 Router C Outbound link load balancing comprises the following elements: 188

196 Cluster A cluster that provides network traffic load balancing, consisting of an LB device and physical links LB device A device that distributes traffic to multiple physical links. Physical links Links provided by carriers. VSIP Virtual service IP address provided by the cluster, or, the destination segment of the packets sent by users. Figure 92 Work flow of outbound link load balancing Source LB device Destination (1) Traffic from source (2) Scheduler (3) Distribute (4) Traffic from destination (5) Forward Outbound link load balancing operates in the following way: 1. The LB device receives the traffic from the internal users. 2. The LB device selects a link according to the destination IP address and the outbound link load balancing rules configured. 3. The LB device forwards the traffic to the selected link. 4. The LB device receives the traffic sent from the external users. 5. The LB device forwards the traffic to the internal users. Inbound link load balancing Figure 93 Network diagram Cluster ISP1 Router A Local DNS server A IP network ISP2 Router B LB device Local DNS server B ISP3 Router C Inbound link load balancing comprises the following elements: 189

197 Cluster A cluster that provides network traffic load balancing, consisting of an LB device, physical links, and local DNS servers. LB device Operating as an authoritative name server of the domain name to be resolved, an LB device is used to select an optimal path for the traffic from the internal network to the external network. Physical links Links provided by carriers. Local DNS server A local DNS server that resolves the DNS requests sent by a host. Figure 94 Work flow of inbound link load balancing Inbound link load balancing operates in the following way: 1. An external user sends a DNS request to its local DNS server for DNS resolution before resource access. 2. The local DNS server converts the source IP address of the DNS request to its own IP address, and forwards it to the authoritative name server (the LB device). 3. The LB device resolves the domain name according to the domain name of the DNS request and the configured inbound link load balancing rules. 4. The LB device sends the DNS response to the local DNS server according to the DNS resolution result. 5. The local DNS server forwards the DNS resolution result to the user. 6. The user uses the selected link to access the LB device. Configuring server/firewall load balancing IPv4 firewall load balancing and Layer 4 server load balancing are configured in the same way. This section describes how to configure Layer 4 server load balancing. configuration considerations The server load balancing module comprises a real service group consisting of real services and a virtual service, as shown in Figure

198 Figure 95 Relationship between the components of the server load balancing module Real service group A group of real services. Real services Entities that process services in a cluster (such as servers in Figure 84, and Figure 86, and firewalls Figure 88. A real service group comprises multiple real services. Virtual service A logical entity that faces users. For server load balancing and firewall load balancing, a virtual service corresponds to one real service group. Server load balancing operates in the following way: 1. After a user sends a request to the virtual service of the LB device, if a persistence method is specified in the virtual service, and matched persistence entries exist, the request is distributed according to the persistence entries. Otherwise, the virtual service obtains the information of the related real service group, and then continues the following procedure. For more information about persistence methods, see Table Real services are matched against ACL rules specified in the real services one by one according to the weights of the real services. Requests allowed by the ACL are distributed to the corresponding real service; if requests are not allowed by the ACL or no matched real services exist, the following procedure is continued. 3. Distributes the request to a real service in the group based on the algorithm configured in the real service group. Recommended configuration procedure Step 1. Saving of the last hop information 2. Configuring a health monitoring method Remarks Saving of the last hop information must be enabled on a level 2 LB device in firewall load balancing. This task is optional in other cases. For more information, see "Configuring public parameters." A health monitoring method must be configured if you adopt SSL health monitoring. This task is optional in other cases. 3. Creating a real service group Required. IMPORTANT: 4. Creating a real service Required. Creating a virtual service for server load balancing Required. The maximum number of real service groups, real services, and virtual services depends on the resource configuration of the virtual device. For more information, see System Management and Maintenance Configuration Guide. 191

199 To implement server load balancing, enable virtual fragment reassembly on the zone to which the interfaces that process LB packets belong. For more information, see "Managing sessions." To implement forced load balancing of server load balancing, enable virtual fragment reassembly on the zone to which the interfaces that process LB packets belong. For more information, see "Managing sessions." NOTE: For an LB device configured with DR-mode server load balancing, you must select Firewall > Session Table > Configuration from the navigation tree to enable unidirectional traffic detection. For more information, see Access Control Configuration Guide. Configuring public parameters 1. Select High Reliability > Load Balance > Public Setting from the navigation tree. The public parameter configuration page appears. Figure 96 Public parameter configuration 2. Set whether to enable the saving last hop information function. Enabling this function makes sure responses can be returned on the original path. This function must be enabled on level 2 LB devices in firewall load balancing. 3. Click Apply. Configuring a health monitoring method Load balancing supports multiple health monitoring types. This section describes only the types supported by server load balancing and physical links. The following health monitoring types, unless otherwise stated, are only supported by server load balancing. ARP Monitors the availability of a server through ARP. DNS Monitors the availability of a DNS server through DNS. FTP Monitors the availability of an FTP server through FTP. HTTP Monitors the availability of an HTTP service through HTTP access. ICMP Monitors the reachability of a server by sending ICMP messages. SIP Monitors the availability of a SIP server through the SIP application. SNMP Monitors the availability of an SNMP server through SNMP. TCP Monitors the availability of an application port by establishing TCP connections. RTSP Monitors the availability of an RTSP server through RTSP. 192

200 UDPNORMAL Monitors the availability of an application port by sending UDP packets. UDPNORMAL health monitoring does not require server response, so HP recommends that you use it together with the ICMP health monitoring type. The reachability of the server is determined through ICMP detection. To configure a health monitoring method: 1. Select High Reliability > Load Balance > Health Monitor from the navigation tree. The heath monitoring page appears. Figure 97 Health monitoring 2. Click Add. The page for adding a health monitoring method appears. Figure 98 Adding a health monitoring method 193

201 3. Configure the parameters as described in Table Click Apply. Table 14 Configuration items Item Name Health Monitoring Check Interval Timeout Retry Times Description Health monitoring method name. Health monitoring type. Interval at which health monitoring is performed. Timeout for a health monitoring operation. When the number of retry times is n, if health monitoring is performed for n times and the corresponding server or port is unavailable, the health monitoring is considered failed. Hostname Host IP Username Password File Name URL Response Content Real Service Domain Name Protocol Allowed Status Code Domain name to be resolved in DNS health monitoring. The default hostname is A.ROOT-SERVER.NET. A DNS health monitoring is considered successful only when the specified host IP address is contained in the received DNS result packet (if the host IP address is specified), enhancing the precision of DNS health monitoring. Case-sensitive username and password used for logging in to an FTP server in FTP health monitoring. Name of the file to be downloaded from the FTP server in FTP health monitoring, which is case-sensitive. The file with this name must be put in the main directory of the login host. URL to be accessed in HTTP health monitoring. It must begin with "/", and is case-sensitive. For example, /test.html. Content of a user's response that HTTP health monitoring detects. If the response that the user returns contains the specified content, the HTTP health monitoring succeeds. Otherwise, the HTTP health monitoring fails. Domain name of the server or network device that is processing services. The domain name is filled into the HOST header of a request in HTTP health monitoring. If you do not configure this parameter, the IP address of the server is filled into the HOST header of the request. Transmission protocol used by SIP health monitoring. When the response message returned by the SIP server is within the allowed status code range, the SIP health monitoring succeeds. Otherwise, the SIP health monitoring fails. If you select Any, the SIP health monitoring succeeds no matter what response message is returned by the SIP server. If you select Status Code List, you must further specify status codes. The parameters are available only on the page for setting DNS health monitoring parameters. The parameters are available only on the page for setting FTP health monitoring parameters. The parameters are available only on the page for setting HTTP health monitoring parameters. The parameters are available only on the page for setting SIP health monitoring parameters. 194

202 Item Source Port Version Read-only Community Name Description Source port that sends detection packets for SIP health monitoring. Version and read-only community name used in SNMP health monitoring. Read-only community name takes effect on SNMPv1 and SNMPv2c. By default, the version is v1, v2c, and v3, and the read-only community name is public. The parameters are available only on the page for setting SNMP health monitoring parameters. Destination IP Destination IP address for health monitoring. If this parameter is not specified, the IP address of the real service is adopted. Destination port number for health monitoring. Destination Port IMPORTANT: ARP health monitoring and ICMP health monitoring do not support this parameter. If this parameter is 0 (not specified), the port number of the real service is used for heath monitoring (except SIP health monitoring). HP recommends that you specify a non-zero destination port number for health monitoring based on the network environment. For UDPNORMAL health monitoring, if both this parameter and the port number of the real service are 0, the health monitoring fails. Creating a real service group 1. Select High Reliability > Load Balance > Server Load Balance from the navigation tree. The Real Service Group tab appears. Figure 99 Real service group If you click the Number of Real Services link for a real service group, the Real Service tab appears, displaying information about the real services that belong to the real service group. 2. Click Add. The real service group configuration page appears. 195

203 Figure 100 Adding a real service group 3. Configure the parameters as described in Table Click Apply. Table 15 Configuration items Item Real Service Group Name Description Set a real service group name, which uniquely identifies a real service group. 196

204 Item Scheduler Description Select an algorithm that a real service group uses to distribute services and traffic: Round Robin Assigns new connections to each real service in turn. Weighted Round Robin Assigns new connections to real services based on the weights of real services. A higher weight indicates more new connections will be assigned. Least Connections New connections are always assigned to the real service with the fewest number of active connections. Weighted Least Connections New connections are always assigned to the real service with the fewest number of weighted active connections (the number of active connections/weight). Random Assigns new connections to real services randomly. Weighted Random Assigns new connections randomly to real services based on their weights. A higher weight indicates more new connections will be assigned. Source Address Hashing Assigns a new connection to a specific real service based on the source address of the connection. This algorithm make sure new connections with the same source address can be assigned to the same real service. Source Address Port Hashing Assigns a new connection to a specific real service based on the source address and port of the connection. This algorithm makes sure new connections with the same source address and port can be assigned to the same real service. Destination Address Hashing Assigns a new connection to a specific real service based on the destination address of the connection. UDP Packet Load Hash Assigns a new connection to a specific real service based on the value of a specific field in the UDP packet payload. This algorithm can make sure that new connections with the same UDP packet payload can be assigned to the same real service. Local Priority Available real services with the same priority are assigned to a subgroup. The real services are selected by subgroup according to the specified minimum active real service number, and round robin scheduling is performed among the selected real services. Suppose a real service group has two real services with priority 10 and three real services with priority 5, and all real services are available. If the minimum active real service number is 2, only two real services with priority 10 participate in scheduling. If the minimum active real service number is 3, the real services with both priority 10 and 5 participate in scheduling. IMPORTANT: Destination address hashing is applicable to firewall load balancing mode and other algorithms are applicable to server load balancing. Select a health monitoring method that a real service group uses to monitor its real services. Health Monitoring Method IMPORTANT: The health monitoring method specified for the real service group takes effect for a real service that has the same health monitoring method specified. Otherwise, the health monitoring method specified for the real service takes effect. 197

205 Item Health Monitoring Success Criteria Offset Length Minimum Active Real Service Number Real Service Troubleshooting Description Specify the health monitoring success criteria. If you select All, health monitoring succeeds only when all the selected health monitoring methods succeed. If you select At Least and specify a value, health monitoring succeeds when the number of succeeded health monitoring methods reaches the specified value. If you select UDP Packet Load Hash as the algorithm, this field sets the payload for performing hash algorithm. The payload field is determined by offset and length. Offset refers to the relative position of the payload content with respect to the whole payload of a packet; length refers to the length of the payload content starting from the offset. You can specify up to 10 payload fields. Specify the minimum number of active real services to participate in scheduling when you select Local Priority for Scheduler. Select a method that the real service group uses to handle existing connections when it detects that a real service fails, including the following: Keep Connection Does not actively terminate the connection with the failed real service. Keeping or terminating the connection depends on the timeout mechanism of the protocol. Disconnection Actively terminates the connection with the failed real service. Redirection Redirects the connection to another available real service in the real service group. IMPORTANT: Redirection is applied to firewall load balancing mode and other methods are applied to server load balancing. 198

206 Item Description Identification of a real service group in Layer 7 server load balancing, that is, the common characteristics of all the real services in the real service group. Character The character configuration depends on the real service group method specified in the virtual service. The virtual service selects an appropriate real service group for different packets according to the real service group method and characters of the real services. If no character is specified, the real service group matches all packets. In case that other real service groups configured with characters do not match any packets, the packets match this real service group. If the real service group method is Accept-Encoding, configure the character as the compression mode that the client browser can accept, for example, gzip. If the real service group method is Accept-Language, configure the characters as the language code that the client browser supports and understands, for example, zh-cn. If the real service group method is Host, configure the character as the host name, for example, If the real service group method is Request-Method, configure the character as the method taken on the resources identified by Request-URI, for example, GET. If the real service group method is URL-File, configure the character as file type, for example, txt. If the real service group method is URL-Function, configure the character as the directory for obtaining resources, for example, /wcn/loadbalance. Configure the character as the root directory first. If the real service group method is User-Agent, configure the character as the client browser type, for example, Mozilla/5.0. If the real service group method is another field in the HTTP header, configure the character as the field in the HTTP header that a user is interested in. For example, if a user types a real service group match criterion Cookie, you need to configure the character as the value of the Cookie field. If the real service group method is RTSP URL, configure the character as the directory for obtaining resources, for example, /wcn/loadbalance. If the real service group method is DHCP Relay Agent IP, configure the character as the IP address of the DHCP Relay, for example, IMPORTANT: This configuration only takes effect on server load balancing. ACL Advanced Configuration Enable Slow-Online Standby Time Ramp-Up Time Apply an ACL to restrict clients' access to the real service group. When you add a server or a network device to a cluster, some servers or network devices cannot take on a large amount of services immediately, so you can enable the slow-online function. With slow-online enabled, after the server or network device goes online, the LB device will not assign services to it in the standby time. After the standby time is reached, the LB device will assign services to the server or network device gradually within the slow-online time. After the slow-online time is reached, the LB device will assign services to the server or network device correctly. 199

207 Creating a real service 1. Select High Reliability > Load Balance > Server Load Balance from the navigation tree. 2. Click the Real Service tab. The real service page appears. Figure 101 Real service To view the configurations and statistics of a real service, click the Real Service Name link of the real service. When a real service is available, and is neither enabled with slow-offline nor stopping service, its status is displayed as. When a real service is available, and is enabled with slow-offline, its status is displayed as. When a real service is unavailable or enabled with stopping service, its status is displayed as. 3. Click Add. The real service configuration page appears. Figure 102 Creating a real service 4. Configure the parameters as described in Table Click Apply. Table 16 Configuration items Item Real Service Name Real Service IP Description Set a real service name, which uniquely identifies a real service. Specify the IP address (IPv4 address) of a server or network device that processes services. 200

208 Item Port Weight Priority Connection Limit Real Service Group ACL Description Set a port number that is related to the following parameters: Health monitoring method for a real service group If this parameter is 0, the port number of the real service is used for heath monitoring (except RADIUS and SIP health monitoring). For TCP and UDPNORMAL health monitoring, if both this parameter and the port number of the real service are 0, the health monitoring fails. Forwarding mode for a virtual service If the forwarding mode is set to NAT, the port number is taken as the destination port of a packet after NAT translation, and the port number must be consistent with that of the server; if the forwarding mode is set to direct routing or firewall forwarding, the port number is used only for health monitoring. Set the weight to be used in the weighted round robin and weighted least connections algorithms. A smaller weight indicates that the real service is less scheduled. Specify the priority of the real service when the real service group adopts the local priority scheduling algorithm. The larger the value, the greater the priority. Set the maximum number of concurrent connections of the real service. Specify the real service group to which the real service belongs. ACL specified for a real service. To configure ACL rules, select Firewall > ACL. Advanced Configuration Health Monitoring Method Health Monitoring Success Criteria Select one of the following health monitoring methods: No Monitoring Same As Real Service Group Specified Use the health monitoring method specified by the real service to perform health monitoring. If you select this option, you must specify a health monitoring method for the real service (add one or more items in the Available Health Monitoring Methods field to the Selected Health Monitoring Methods field), and specify the health monitoring success criteria. When you select Specified for Health Monitoring Method, you must specify the health monitoring success criteria. If you select All, health monitoring succeeds only when all the selected health monitoring methods succeed. If you select At Least and specify a value, health monitoring succeeds when the number of succeeded health monitoring methods reaches the specified value. Stopping service or enabling slow-offline To remove the server or network device corresponding to a real service from a cluster, or temporarily stop a real service, you can stop the service or enable slow-offline: If you stop the service, the LB device does not assign any traffic to the real service. If you enable slow-offline, the real service continues to process the traffic previously assigned to it, but the LB device does not assign any new service to the real service. Remove the server or network device from the cluster after the original services are processed to avoid service interruption. 201

209 To stop service or enable slow-offline: 1. Select High Reliability > Load Balance > Server Load Balance from the navigation tree. 2. Click Real Service. The real service page appears. 3. Click the icon of the target real service. The Modify Real Service page appears. 4. Click the Advanced Configuration expansion button. Figure 103 Modifying real service 5. Select the Enable Slow-Offline or Stop Service option. 6. Click Apply. If you select both the Enable Slow-Offline and Stop Service options for a real service, the LB device immediately stops assigning traffic to the real service, and the slow-offline function does not take effect. Creating a virtual service for server load balancing 1. Select High Reliability > Load Balance > Server Load Balance > IPv4 from the navigation tree. 2. Click Virtual Service. The virtual service page appears. 202

210 Figure 104 Virtual service To view the configurations and statistics of a real service, click the Real Service Name link of the real service. To view the configuration information of a real service group, click the Real Service Group link of a virtual service. If you click the Number of Real Services link of a real service group, the page will go to the Real Service tab, which displays only information about the real services that belong to the virtual service group. 3. Click Add. The virtual service configuration page appears. Figure 105 Creating a virtual service for Layer 4 server load balancing 4. Configure the parameters as described in Table Click Apply. 203

211 Table 17 Configuration items Item Virtual Service Name VPN Instance Virtual Service IP Mask Protocol Description Set a virtual service name, which uniquely identifies a virtual service. Select the VPN instance to which the virtual service belongs. Specify the VSIP of the cluster. In server load balancing, users request services with this IP address as the destination IP address. For firewall load balancing, you can configure only one VSIP. For NAT- and DR-mode server load balancing, you can configure multiple VSIPs. Specify the VSIP mask. For NAT- and DR-mode server load balancing, the mask length must be 32 bit. Select the protocol used by the cluster to provide services. When you select UDP as the protocol, set whether to enable the mechanism of distributing services based on packets. Enable Forced LB Packet exchange for some UDP-based services, such as DNS, RADIUS, and so on, can be completed in one exchanging process, and in some specific scenarios, the quintuple of packets is the same. In this case, load balancing cannot be implemented on service packets based on the session-based load balancing mode. Therefore, forced load balancing needs to be enabled to implement load balancing of service packets according to the mechanism of distributing services based on packets. IMPORTANT: Forced load balancing of fragmented packets is implemented based on virtual fragment reassembly. Therefore, you must enable virtual fragment reassembly on the zone to which the interfaces that process LB packets belong. For more information, see "Managing sessions." Port Forwarding Mode Set the port number used by the cluster to provide services. Load balancing mode adopted: NAT NAT-mode server load balancing. Direct Routing DR-mode server load balancing. Firewall Firewall load balancing. IMPORTANT: For NAT-mode server load balancing, to implement NAT internal server on the LB device's interface attached to the user network, do not configure the VSIP as the external IP address of the internal server. Otherwise, the two functions might conflict with each other. Enable source address NAT translation, which changes the source address of a packet during load balancing. This option can be set only when the forwarding mode is NAT. Enable SNAT IMPORTANT: After you enable SNAT for the virtual service, do not configure NAT on the LB device's interface connecting the real server for traffic matching the virtual service. Otherwise, the two functions might conflict with each other. 204

212 Item Description Configure an SNAT IP address pool. The option can be set when Enable SNAT is selected. Its default value is the virtual service IP address. SNAT IP Pool The start IP address and end IP address must be both configured or both empty, and the end IP address must be greater than the start IP address. IMPORTANT: The SNAT address pool cannot have overlapping address spaces with the address pool configured for dynamic NAT on the interface that connects the device to the real server. Otherwise, TCP packet checksum calculation error might occur. Select a method for associating real services with connections that access the same virtual service. Persistence Method Using a persistence method can reduce times that LB device distributes traffic and services. If you do not select a persistence method, no real services or connections are associated. Source IP Connections that have the same source address will be associated with the same real service. In this mode, if the service port number is configured as any, then any connection with the same source address and protocol type indicates access of the same real service. Source Port Connections that have the same source port will be associated with the same real service. Destination Port Connections that have the same destination port will be associated with the same real service. Source IP + Port Connections that have the same source address and port will be associated with the same real service. Destination IP + Port Connections that have the same destination address and port will be associated with the same real service. Set the aging time of a persistence entry. Persistence Timeout When a persistence method is configured, persistence entries are generated according to the persistence method. If a persistence entry is not matched within the persistence timeout time, the persistence entry is deleted. This option is not available if you do not select a persistence method. Connection Limit Set the maximum number of concurrent connections of the virtual service. Reference a real service group for the virtual service. Real Service Group Enable Virtual Service IMPORTANT: HP recommends not referencing a real service group with the scheduling algorithm Least Connections or Weighted Least Connections for the virtual service enabled with forced load balancing. Otherwise, load balancing might not operate correctly. Whether to enable a virtual service after it is configured. This option is not available if you do not select a real service group. Displaying server load balancing statistics 1. Select High Reliability > Load Balance > Server Load Balance from the navigation tree. 2. Click Statistics. 205

213 Statistics of all the virtual services of server load balancing are displayed on the page, including total number of connections, average of active connections/peak of active connections, connection average rate/peak rate, number of forwarded/ignored packets in the inbound direction, and number of forwarded packets in the outbound direction. If you click the link of a virtual service name, the statistics of all the real services of the virtual service will be displayed on the lower part of the page, including total number of connections, average of active connections/peak of active connections, connection average rate/peak rate, packets received, and packets sent, as shown in Figure 106. Figure 106 Statistics Configuring link load balancing Configuration considerations Outbound link load balancing The outbound link load balancing module comprises physical links, a logical link group consisting of logical links, and a virtual service, as shown in Figure 107. Figure 107 Relationship between the components of the outbound link load balancing module 206

214 Physical links Entities that forward packets. Logical link group A group of logical links. Logical links Physical link-based logical entities to process services. Virtual service A logical entity. A virtual service can correspond to multiple logical links. Outbound link load balancing operates in the following way: 1. After a user sends a request to the destination segment specified by the virtual service of the LB device, if a persistence method is specified in the virtual service, and matched persistence entries exist, the request is distributed according to the persistence entries. Otherwise, the following step is performed. See Table 25 for the introduction to the persistence method. 2. The virtual service obtains the information of the corresponding logical link group and matches the ACLs specified in the logical links one by one based on the logical link weights from high to low. For the packets allowed by ACL, the virtual service distributes the packets to the corresponding logical links; for the logical links that are denied by ACL or no matched logical links are found, the LB device goes to the following step. 3. If Internet Service Provider (ISP) routing is enabled for a virtual service, a best link is selected based on the matched ISP entry. If no match is found, the following step is performed. 4. If best performing link is enabled in the virtual service, a best link is selected based on the matched best performing link entry. If no match is found, best performing link detection is performed to generate a best performing link entry, and the LB device goes to the following step. 5. The virtual service distributes the packets to a logical link (corresponding to a unique physical link) according to the link scheduling algorithm configured in the logical link group. When the link busy protection function is enabled, if there is an idle link, best-performing link, ISP routing, and algorithm scheduling do not take effect on busy links. If a logical link is configured with the stop scheduling function, best-performing link, ISP routing, and algorithm scheduling do not take effect on the logical link. Inbound link load balancing Inbound link load balancing resolves a domain name according to inbound link load balancing DNS entries. Two types of inbound link load balancing DNS records are available: MX and A. A DNS A record comprises four parts: domain name, IP address, physical link, and ACL. Their relationship is as shown in the following figure: Figure 108 Relationship between the components of inbound link load balancing DNS A records Domain name IP address 1 IP address 2 IP address n ACL 1 Physical link 1 Physical link 2 ACL n Physical link n 207

215 A DNS MX record defines the mapping between a domain name and mail server name. When an Internet user sends an , the local mail server typically sends a DNS request to the LB device first to query the MX record of the mail recipient address. Inbound link load balancing operates in the following way: 1. Upon receiving a DNS request sent by the local server (local DNS server or local mail server), if the request is an MX record query request, the LB device searches a match, resolve the domain name suffix of the recipient address to a mail server name, and goes to the following step to search an A record by using the mail server name as the requested domain name. If the request is an A record query request, it goes to the following step. To reduce packet exchanges, the LB device uses the MX query result to query A records, and adds the A record query result as an appended record into the MX response to send to the local server. When querying MX records, if finding multiple matches, the LB device returns at most 10 matches to the local server, which selects one according to the priority of the MX records. 2. The LB device uses the requested domain name to search the inbound link load balancing DNS A record for a match. If the source IP address of the DNS request matches the ACL in the DNS record, the LB device responds with the IP address in the DNS record. Otherwise, it goes to the following step. 3. The LB device matches the source IP address of the DNS request against the best performing link entry, uses the physical link in the matched best performing link entry, and responds with the IP address in the corresponding DNS A record. If no match is found, the LB device performs best performing link detection on all the physical links corresponding to the DNS A records that match the domain name to generate a best performing link entry, and goes to the following step. 4. If ISP routing is enabled, the LB device matches the source IP address of the DNS request against the ISP entry, uses the physical link in the matched ISP entry, and responds with the IP address in the corresponding DNS A record. If ISP routing is not enabled or no match is found, the LB device does not add the search result of the A record when the request is an MX record query request. The LB device uses the physical link that corresponds with the first DNS record that matches the requested domain name, and responds with the IP address of the DNS record if the request is an A record query request. Recommended configuration procedure Configuring outbound link load balancing Step 1. Saving of the last hop information 2. Configuring a health monitoring method Remarks Optional. For more information, see "Configuring public parameters." Optional. 3. Creating a physical link Required. 4. Configuring the best performing link function Optional. Configure dynamic best performing link parameters and static best performing link entries. For outbound link load balancing, this function is available only when enabling of best performing link is configured for a virtual service. 208

216 Step Remarks 5. Creating a logical link group Required. IMPORTANT: 6. Creating a logical link Required. 7. Creating a virtual service Required. 8. Displaying link load balancing statistics 9. Stopping service or enabling slow-offline 10. Stopping scheduling for a logical link Optional. Optional. Optional. The maximum number of real service groups, real services, and virtual services depends on the resource configuration of the root virtual device. For more information, see "Managing VDs." Configuring inbound link load balancing Step 1. Configuring a health monitoring method Remarks Optional. 2. Creating a physical link Required. 3. Configuring the best performing link function 4. Configuring DNS redirection and DNS TTL 5. Configuring a DNS entry Optional. Configure dynamic best performing link parameters and static best performing link entries. Required. Inbound link load balancing takes effect only after DNS redirection is enabled. Required. To implement inbound link load balancing, configure a DNS A record. To implement Simple Mail Transfer Protocol (SMTP) inbound link load balancing, you must additionally configure a DNS MX record. Configuring public parameters 1. Select High Reliability > Load Balance > Public Setting from the navigation tree. The public parameter configuration page appears. Figure 109 Public parameter configuration 209

217 2. Set whether to enable the saving last hop information function. Enabling this function makes sure responses can be returned on the original path. Configuring a health monitoring method You can configure the health monitoring method for a physical link and the best performing link function: 1. Load balancing supports the following health monitoring types for a physical link: ICMP Monitors the reachability of a server by sending ICMP messages. TCP Half Open Monitors the availability of an application port through a TCP half open connection. 2. The system defines the following health monitoring methods for the best performing link function: proxim_dns Monitors the reachability of a remote address and obtains the best performing link parameters by sending DNS messages. It is not supported by outbound link load balancing. proxim_icmp Monitors the reachability of a remote address and obtains the best performing link parameters by sending ICMP messages. proxim_tcp_half_open Monitors the reachability of a remote address and obtains the best performing link parameters through a TCP half open connection. Configuring the health monitoring method for a physical link 1. Select High Reliability > Load Balance > Health Monitor from the navigation tree. The heath monitoring page appears. Figure 110 Health monitoring 210

218 2. Click Add. The page for adding a health monitoring method appears. Figure 111 Adding a health monitoring method 3. Configure the parameters as described in Table Click Apply. Table 18 Configuration items Item Health Monitoring Check Interval Timeout Retry Times Destination IP Destination Port Description Health monitoring type. Interval at which health monitoring is performed. Timeout for a health monitoring operation. When the number of retry times is n, if health monitoring is performed for n times and the corresponding server or port is unavailable, the health monitoring is considered failed. Destination IP address for health monitoring. If this parameter is not specified, the next hop IP address of the physical link is adopted. Destination port number for health monitoring. This parameter is not supported by ICMP health monitoring. Configuring the health monitoring method for the best performing link function 1. Select High Reliability > Load Balance > Health Monitor from the navigation tree. The heath monitoring page appears. 2. Click the icon corresponding to the proxim_dns, proxim_icmp, or proxim_tcp_half_open health monitoring method. The page for modifying health monitoring parameters appears. 211

219 Figure 112 Modifying health monitoring parameters 3. Configure the parameters (proxim_dns) as described in Table 19. Configure the parameters for the proxim_icmp and proxim_tcp_half_open in the same way you configure the ICMP and TCP half open health monitoring methods. 4. Click Apply. Table 19 Configuration items Item Check Interval Timeout Hostname Host IP Destination IP Destination Port Description Interval at which health monitoring is performed. Timeout for a health monitoring operation. Domain name to be resolved in DNS health monitoring. The default hostname is A.ROOT-SERVER.NET. DNS health monitoring is considered successful only when the specified host IP address is contained in the received DNS result packet (if the host IP address is specified), enhancing the precision of DNS health monitoring. Destination IP address for health monitoring. Typically this parameter is not required for the best performing link function. Destination port number for health monitoring. Creating a physical link 1. Select High Reliability > Load Balance > Link Load Balance > Physical Link from the navigation tree. The physical link page appears, displaying the configuration information for a physical link and the status and outgoing interface of the physical link when it is available. 212

220 Figure 113 Physical link 2. Click Add. The page for creating a physical link appears. Figure 114 Adding a physical link 3. Configure the parameters as described in Table Click Apply. Table 20 Configuration items Item Physical Link Name VPN Instance NextHop Health Monitoring Type Health Monitoring Success Criteria Description Set the physical link name, which uniquely identifies a physical link. Specify the VPN instance to which the physical link belongs. Specify the IP address of the next hop corresponding to the physical link. Select a health monitoring method to monitor a physical link. Specify the health monitoring success criteria. If you select All, health monitoring succeeds only when all the selected health monitoring methods succeed. If you select At Least and specify a value, health monitoring succeeds when the number of succeeded health monitoring methods reaches the specified value. 213

221 Item Health Monitoring Type Uplink BandWidth Uplink BandWidth Busy Rate Downlink BandWidth Downlink BandWidth Busy Rate Cost ISP Description Health monitoring type of the physical link: ICMP Detects the reachability of the next hop of the physical link through ICMP messages. TCP Half Open Detects the reachability of the next hop of the physical link through a TCP half open connection. Maximum uplink bandwidth allowed by the physical link. When the percentage of the actual uplink bandwidth of a physical link to maximum uplink bandwidth reaches this busy rate, the physical link is busy. Maximum downlink bandwidth allowed by the physical link. When the percentage of the actual downlink bandwidth of a physical link to maximum downlink bandwidth reaches this busy rate, the physical link is busy. Cost of the physical link. ISP to which the physical link belongs. If no ISP is specified, the physical link does not participate in ISP routing. The following matrix shows the ISP and hardware compatibility: Hardware F1000-A-EI/F1000-S-EI F1000-E F5000 F5000-S/F5000-C VPN firewall modules 20-Gbps VPN firewall modules Compatibility No No Yes No No No Configuring the best performing link function For outbound link load balancing, the best performing link function allows you to forward packets whose destination address matches the best performing link entry over the link in the entry. If no matched entry is found, best performing link detection is performed. The device selects the best link to the destination segment from among multiple links according to the network delay, router hops, bandwidth, cost, and weight of the links, and generates a dynamic best performing link entry. For inbound link load balancing, the best performing link function allows you to use the IP address of the DNS entry to which the corresponding physical link belongs (domain name matching) as the DNS resolution result. If no matched entry is found, best performing link detection is performed. The device selects the best link to the destination segment from among multiple links according to the network delay, router hops, bandwidth, cost, and weight of the links, and generates a dynamic best performing link entry for DNS resolution. Network delay, router hops, bandwidth, and cost refer to the following: Network delay and router hops are obtained through health monitoring. 214

222 Bandwidth is the available bandwidth of the links. Cost is specified in the configuration of the physical links. You can also manually add a static best performing link entry, which has a higher priority than a dynamic best performing link entry. Configuring dynamic best performing link parameters 1. Select High Reliability > Load Balance > Link Load Balance > Best-Performing Link from the navigation tree. The Parameters of Dynamic Best-Performing Link configuration page appears. Figure 115 Best performing link parameters 2. Configure the parameters as described in Table Click Apply. Table 21 Configuration items Item Description Mask length of the dynamic best performing link entry generated based on the best performing link algorithm. Mask Length If you select Natural Mask, the mask length of the generated dynamic best performing link entry is determined by the IP address of the entry. If the IP address is a class A address, the mask length is 8. If the IP address is a class B address, the mask length is 16. If the IP address is a class C, class D, or class E address, the mask length is 24. Aging time of the dynamic best performing link entry. Aging Time RTT Weight TTL Weight After a dynamic best performing link entry is generated, if no matched traffic passes within the aging time, the dynamic best performing link entry will be deleted; static best performing link entries do not age out. Round trip time (RTT) weight in the dynamic best performing link algorithm. Time to live (TTL) weight in the dynamic best performing link algorithm. 215

223 Item Uplink Bandwidth Weight Downlink Bandwidth Weight Link Cost Weight Detection Interval Timeout Inbound Method Outbound Method Description Uplink bandwidth weight in the dynamic best performing link algorithm. Downlink bandwidth weight in the dynamic best performing link algorithm. Link cost weight in the dynamic best performing link algorithm. The interval at which best-performing link detection is performed. Timeout for a best-performing link detection operation. Specify a health monitoring method (proxim_dns, proxim_icmp, or proxim_tcp_half_open) for inbound link load balancing to obtain the best performing link parameters (network delay and router hops). Specify a health monitoring method (proxim_icmp or proxim_tcp_half_open) for outbound link load balancing to obtain the best performing link parameters (network delay and router hops). Configuring a static best performing link entry 1. Select High Reliability > Load Balance > Link Load Balance > Best-Performing Link from the navigation tree. 2. Click the Best Performing Link Table tab. The best performing link table displays all the dynamic and static best performing link entries. Figure 116 Best performing link table 3. Click Add. The page for creating a static best performing link entry appears. Figure 117 Creating a static best performing link entry 4. Configure the parameters as described in Table Click Apply. 216

224 Table 22 Configuration items Item IP Address Mask Physical Link Remarks IP address of the static best performing link entry It is the destination IP address of packets for outbound link load balancing and source IP address of DNS requests for inbound link load balancing. Mask length of the static best performing link entry Name of the physical link corresponding to the static best performing link entry Creating a logical link group 1. Select High Reliability > Load Balance > Link Load Balance > Outbound from the navigation tree. The Logical Link Group tab appears. Figure 118 Logical link group If you click the Number of Links link of a logical link group, you enter the Logical Link tab, where only information about the logical links that belong to the logical link group is displayed. 2. Click Add. The page for creating a logical link group appears. Figure 119 Creating a logical link group 3. Configure the parameters as described in Table Click Apply. 217

225 Table 23 Configuration items Item Logical Link Group Name Scheduler Minimum Active Logical Link Service Number Remarks Logical link group name, which uniquely identifies a logical link group. A scheduling algorithm that a logical link group uses to distribute traffic. Round Robin Assigns new connections to each logical link in turn. Weighted Round Robin Assigns new connections to each logical link based on the weights of logical links; a higher weight indicates more new connections will be assigned. Least Connections New connections are always assigned to the logical link with the fewest number of active connections. Weighted Least Connections New connections are always assigned to the logical link with the fewest number of weighted active connections (the number of active connections/weight). Random Assigns new connections to logical links randomly. Weighted random Assigns new connections randomly to logical links based on their weights; a higher weight indicates more new connections will be assigned. Source Address Hashing Assigns a new connection to a specific logical link based on the source address of the connection. This algorithm makes sure new connections with the same source address can be assigned to the same logical link. Source Address Port Hashing Assigns a new connection to a specific logical link based on the source address and source port of the connection. This algorithm make sure new connections with the same source address and port can be assigned to the same logical link. Destination Address Hashing Assigns a new connection to a specific logical link based on the destination address of the connection. This algorithm make sure new connections with the same destination address can be assigned to the same logical link. Weighted Bandwidth Assigns new connections to each logical link based on the product of the available bandwidth of the current physical link and the weights of logical links. A higher product value indicates more new connections will be assigned. Max Bandwidth Assigns new connections to logical links that have greatest physical link available bandwidth. Local Priority Available logical links with the same priority are assigned to a subgroup. The logical links are selected by subgroup according to the specified minimum active logical link number, and scheduling is performed among the selected logical links. Suppose a logical link group has two logical links with priority 10 and three logical links with priority 5, and all logical links are available. If the minimum active logical link number is 2, only two logical links with priority 10 participate in scheduling. If the minimum active logical link number is 3, the logical links with both priority 10 and 5 participate in scheduling. Specify the minimum number of active logical links to participate in scheduling when you select Local Priority for Scheduler. 218

226 Item Logical Link Troubleshooting Remarks A method that a logical link group uses to handle existing connections when it detects that a logical link fails, including the following: Keep connection Does not actively terminate the connection with the failed logical link. Keeping or terminating the connection depends on the timeout mechanism of the protocol. Disconnection Actively terminates the connection with the failed logical link. Redirection Redirects the connection to another available logical link in the logical link group. Advanced Configuration Enable Slow-Online Standby Time Ramp-Up Time When you add a link to a cluster, because the link cannot take on a large amount of services upon going online, you can enable the slow-online function. With slow-online enabled, when the link goes online, the LB device does not assign services to it in the standby time. After the standby time is reached, the LB device will assign services to the link gradually within the slow-online time. After the slow-online time is reached, the LB device assigns services to the link. Creating a logical link 1. Select High Reliability > Load Balance > Link Load Balance > Outbound from the navigation tree. 2. Click the Logical Link tab. The logical link list page appears. Figure 120 Logical link To view the configurations and statistics of a logical link, click the Logical Link Name link of the logical link. When a logical link is available, and is neither enabled with slow-offline nor stopping service, its status is displayed as. When a logical link is available, and is enabled with slow-offline, its status is displayed as. When a logical link is unavailable or enabled with stopping service, its status is displayed as. When a logical link is configured with stopping scheduling, its status is displayed as. 3. Click Add. The page for creating a logical link appears. 219

227 Figure 121 Creating a logical link 4. Configure the parameters as described in Table Click Apply. Table 24 Configuration items Item Logical Link Name Weight Priority Connection Limit Logical Link Group Physical Link ACL Remarks Logical link name, which uniquely identifies a logical link. The weight of a logical link when the scheduling algorithm of the logical link group to which the logical link belongs is weighted round robin, weighted least connection, weighted random or bandwidth. A smaller weight indicates that the logical link is the less scheduled. Specify the priority of the logical link when the logical link group adopts the local priority scheduling algorithm. The larger the value, the greater the priority. Maximum number of concurrent connections on a logical link. Logical link group to which a logical link belongs. Physical link corresponding to a logical link. ACL configured for a logical link. To configure an ACL, select Firewall > ACL. Stopping service or enabling slow-offline To remove the server or network device corresponding to a logical link from a cluster, or temporarily stop a logical link, you can stop the service or enable slow-offline: If you stop the service, the LB device does not assign any traffic to the logical link. If you enable slow-offline, the logical link continues to process the traffic previously assigned to it, but the LB device does not assign any new service to the logical link. Remove the server or network device from the cluster after the original services are processed to avoid service interruption. To stop service or enable slow-offline: 1. Select High Reliability > Load Balance > Link Load Balance > Outbound from the navigation tree. 2. Click Logical Link appears. The logical link list page appears. 3. Click the icon of the target logical link. 220

228 The Modify Logical Link page appears. 4. Click the Advanced Configuration expansion button. Figure 122 Modifying logical link 5. Select the Enable Slow-Offline or Stop Service option 6. Click Apply. If you select both the Enable Slow-Offline and Stop Service options for a logical link, the LB device immediately stops assigning traffic to the logical link, and the slow-offline function does not take effect. Stopping scheduling for a logical link Best-performing link, ISP routing, and algorithm scheduling do not take effect on a logical link configured with the stop scheduling function, but persistence method and ACL still take effect on the logical link. The logical link can be used as a dedicated line for specific users. To stop scheduling for a logical link: 1. Select High Reliability > Load Balance > Link Load Balance > Outbound from the navigation tree. 2. Click Logical Link. The logical link list page appears. 3. Click the icon of the target logical link. The Modify Logical Link page appears. 4. Click the Advanced Configuration expansion button. 5. Select Stop Sched. 6. Click Apply. 221

229 Creating a virtual service Outbound link load balancing supports the following virtual service match modes: Match IP Matches virtual services according to IP address/mask, protocol type, and port number. Match ACL Matches virtual services based on basic or advanced ACL. The match criteria include source IP address/wildcard, destination IP address/wildcard, protocol type, source port number, and VPN instance. Creating a virtual service (match IP) 1. Select High Reliability > Load Balance > Link Load Balance > Outbound from the navigation tree. 2. Click the Virtual Service tab. 3. Select Match IP. All virtual services with the match type Match IP are displayed. Figure 123 Virtual service (match IP) To view the configurations and statistics of a virtual service, click the Virtual Service Name link of the virtual service. To view the configuration information of a logical link group, click the Logical Link Group link of the virtual service. If you click the Number of Links link of a virtual service, you will enter the Logical Link tab, where only information about the logical links that belong to the virtual service is displayed. 4. Click Add. The page for creating a virtual service appears. Figure 124 Creating a virtual service (match IP) 5. Configure the parameters as described in Table

230 6. Click Apply. Table 25 Configuration items Item Virtual Service Name Virtual Service Match Type VPN Instance Virtual Service IP Mask Protocol Port Remarks Virtual service name, which uniquely identifies a virtual service. Select the virtual service match type as Match IP. Specify the VPN instance to which the virtual service belongs. Destination segment of the packets to be load balanced. Protocol type of the provided services. Port number of the provided services. Select a method for associating links with connections that access the same virtual service. Persistence Method Using a persistence method can reduce times that an LB device distributes traffic and services. If you do not select a persistence method, no links or connections will be associated. Source IP Connections that have the same source address will be associated with the same link. Destination IP Connections that have the same destination address will be associated with the same link. Source Port Connections that have the same source port will be associated with the same link. Destination Port Connections that have the same destination port will be associated with the same link. Source IP + Port Connections that have the same source address and port will be associated with the same link. Destination IP + Port Connections that have the same destination address and port will be associated with the same real service. Set the aging time of a persistence entry. Persistence Timeout When a persistence method is configured, persistence entries are generated according to the persistence method. If a persistence entry is not matched within the persistence timeout time, the persistence entry is aged out. This item cannot be set if you do not select a persistence method. Connection Limit Logical Link Group Enable Virtual Service Enable Best-Performing Link Enable Link Busy Protection Maximum number of concurrent connections of a virtual service. Logical link group referenced by a virtual service. Whether to enable virtual service after it is configured. Whether to enable best performing link. Whether to enable link busy protection. Creating a virtual service (match ACL) 1. Select High Reliability > Load Balance > Link Load Balance > Outbound from the navigation tree. 2. Click the Virtual Service tab. 223

231 3. Select Match ACL. All virtual services with the match type as Match ACL are displayed. Figure 125 Creating a virtual service (match ACL) To view the configurations and statistics of a virtual service, click the Virtual Service Name link of the virtual service. To view the configuration information of a logical link group, click the Logical Link Group link of the virtual service. If you click the Number of Links link of a virtual service, you will enter the Logical Link tab, where only information about the logical links that belong to the virtual service is displayed. 4. Click Add. The page for creating a virtual service appears. Figure 126 Creating a virtual service (match ACL) 5. Configure the parameters as described in Table Click Apply. Table 26 Configuration items Item Virtual Service Name Virtual Service Match Type Description Virtual service name, which uniquely identifies a virtual service. Select it as Match ACL. 224

232 Item Description ACL number. ACL Priority To configure ACL rules, select Firewall > ACL. For more information, see "Configuring ACLs." IMPORTANT: Only the source IP address/wildcard, destination IP address/wildcard, protocol type, source port number, destination port number, and VPN instance match criteria are effective to a virtual service. Priority of a virtual server. A higher value represents a higher priority. A virtual service with a higher priority will be matched first. Select a method for associating links with connections that access the same virtual service. Persistence Method Using a persistence method can reduce times that an LB device distributes traffic and services. If you do not select a persistence method, no links or connections will be associated. Source IP Connections that have the same source address will be associated with the same link. Destination IP Connections that have the same destination address will be associated with the same link. Source Port Connections that have the same source port will be associated with the same link. Destination Port Connections that have the same destination port will be associated with the same link. Source IP + Port Connections that have the same source address and port will be associated with the same link. Destination IP + Port Connections that have the same destination address and port will be associated with the same link. Set the aging time of a persistence entry. Persistence Timeout When a persistence method is configured, persistence entries are generated according to the persistence method. If a persistence entry is not matched within the persistence timeout time, the persistence entry is aged out. This option cannot be set if you do not select a persistence method. Connection Limit Logical Link Group Enable Virtual Service Enable Best-Performing Link Enable ISP Routing Enable Link Busy Protection Maximum number of concurrent connections of a virtual service. Logical link group referenced by a virtual service. Whether to enable virtual service after it is configured. Whether to enable best-performing link. Whether to enable ISP routing. Whether to enable link busy protection. Displaying link load balancing statistics 1. Select High Reliability > Load Balance > Link Load Balance > Outbound from the navigation tree. 225

233 2. Click Statistics. Statistics of all the virtual services of link load balancing are displayed on the page, including total number of connections, average of active connections/peak of active connections, connection average rate/peak rate, number of forwarded/ignored packets in the inbound direction, and number of forwarded packets in the outbound direction. 3. Click the link of a virtual service name. The statistics of all the logical links of the virtual service are displayed on the lower part of the page, including total number of connections, average of active connections/peak of active connections, connection average rate/peak rate, packets received, packets sent, inbound rate, and outbound rate, as shown in Figure 127. Figure 127 Statistics Configuring DNS redirection and DNS TTL 1. Select High Reliability > Load Balance > Link Load Balance > Inbound from the navigation tree. The DNS redirection configuration page appears. Figure 128 Enabling DNS redirection 2. Specify whether to enable DNS redirection. The inbound link load balancing takes effect only after DNS redirection is enabled. 3. Specify whether to enable ISP routing. 4. Set the TTL in a DNS response, which determines the duration that DNS resolution results can be buffered by the client. 226

234 5. Click Apply. Configuring a DNS entry Configuring a DNS A record 1. Select High Reliability > Load Balance > Link Load Balance > Inbound from the navigation tree. The DNS redirection configuration page appears. 2. In the DNS Table area, select the A option. The DNS A record information is displayed on the page. 3. Click Add. The page for adding a DNS A record appears. Figure 129 Adding a DNS A record 4. Configure the parameters as described in Table Click Apply. Table 27 Configuration items Item Domain Name IP Address Physical Link ACL Description Domain name for external accesses. IP address corresponding to the domain name, or, the IP address that external users use to access the LB device. Physical link corresponding to the domain name. ACL of the DNS A record. To configure ACL rules, select Firewall > ACL. Configuring a DNS MX record 1. Select High Reliability > Load Balance > Link Load Balance > Inbound from the navigation tree. The DNS redirection configuration page appears. 2. In the DNS Table area, select the MX option. The DNS MX record information is displayed on the page. 3. Click Add. The page for adding a DNS MX record appears. 227

235 Figure 130 Adding a DNS MX record 4. Configure the parameters as described in Table Click Apply. Table 28 Configuration items Item Domain Name Mail Server Name Priority Description Domain name for external accesses. Mail server name corresponding to the domain name. Priority of the DNS record. A smaller value, a higher priority. Load balancing configuration examples Server load balancing configuration example Network requirements As shown in Figure 131, three servers Server A, Server B, and Server C can provide HTTP services. Server A has the highest hardware configuration, and Server B the second. Enable these three servers to provide HTTP services together, and all HTTP traffic is required to be filtered by the firewall. Cluster provides HTTP service. Server load balancing should be applied. All traffic will pass the firewall: NAT-mode server load balancing (Responses in DR mode do not pass the firewall). The performance of the three servers is different and therefore weighted round robin algorithm is adopted. 228

236 Figure 131 Network diagram Configuring the LB device Assume that the IP addresses of the interfaces on the LB device and the zone to which they belong have been configured. The following describes the configurations of load balancing in detail. 1. Create real service group HTTPGroup: a. Select High Reliability > Load Balance > Server Load Balance from the navigation tree. The Real Service Group tab appears. b. Click Add. The Add Real Service Group page appears. c. Enter the real service group name HTTPGroup, and select the algorithm Weighted Round Robin, heath monitoring method icmp, and troubleshooting method Keep Connection. d. Click Apply. Figure 132 Creating a real service group 229

237 2. Create real service ServerA for Server A: a. Click the Real Service tab. b. Click Add. The Add Real Service page appears. c. Enter the real service name ServerA, IP address , port number 8080, and weight 150, and select the real service group HTTPGroup. d. Click Apply. Figure 133 Creating a real service 3. Create real service ServerB for Server B: a. Click Add on the Real Service tab. The Add Real Service page appears. b. Enter the real service name ServerB, IP address , port number 8080, and weight 120, and select the real service group HTTPGroup. c. Click Apply. 4. Create real service ServerC for Server C: a. Click Add on the Real Service tab. The Add Real Service page appears. b. Enter the real service name ServerC, IP address , port number 8080, and weight 100, and select the real service group HTTPGroup. c. Click Apply. 5. Create virtual service VS: a. Click Virtual Service. b. Click Add. The Add Virtual Service page appears. c. Enter the virtual service name VS. d. Click Add next to Virtual Service IP, enter the IP address of the virtual service , and click Apply. 230

238 e. Select the mask 32 ( ) and protocol type TCP. f. Enter the port number 80. g. Select the forwarding mode NAT, real service group HTTPGroup, and the Enable Virtual Service option. h. Click Apply. Figure 134 Creating virtual service VS Verifying the configuration After the server runs correctly for a period of time, you can display the statistics to verify the configuration of load balancing. 1. Select High Reliability > Load Balance > Server Load Balance from the navigation tree. 2. Click the Statistics tab. 3. Click the virtual service name link of virtual service VS. You can see the statistics on the page. 231

239 Figure 135 Statistics Figure 135 shows that the total number of connections of Server A, Server B, and Server C is in a ratio of 15:12:10, which is the same as that of the configured weights. Therefore, the server load balancing function has taken effect. Firewall load balancing configuration example Network requirements As shown in Figure 136, two firewalls Firewall A and Firewall B each are connected to internal network and Internet through an LB device to balance load between the two networks to enhance network performance. Firewall load balancing is adopted. LB device A operates as the level 1 LB device, and LB device B the level 2 LB device. Figure 136 Network diagram 232

240 Configuring LB device A Assume that the IP addresses of the interfaces on LB device A and the zones to which they belong have been configured. 1. Create real service group FirewallGroup on LB device A: a. Select High Reliability >Load Balance > Server Load Balance from the navigation tree. The Real Service Group tab appears. b. Click Add. The Add Real Service Group page appears. c. Enter the real service group name FirewallGroup, select the algorithm Destination IP Hashing, health monitoring method icmp, and troubleshooting method Redirection. d. Click Apply. Figure 137 Creating a real service group 2. Create real service FirewallA for Firewall A on LB device A: a. Click the Real Service tab. b. Click Add. The Add Real Service page appears. c. Enter the real service name FirewallA and IP address , and select the real service group FirewallGroup. d. Click Apply. 233

241 Figure 138 Creating a real service 3. Create real service FirewallB for Firewall B: a. Click Add on the Real Service tab. The Add Real Service page appears. b. Enter the real service name FirewallB and IP address , and select the real service group FirewallGroup. c. Click Apply. 4. Create virtual service VS on LB device A: a. Click Virtual Service. b. Click Add. The Add Virtual Service page appears. c. Enter the virtual service name VS. d. Click Add next to Virtual Service IP, enter the IP address of the virtual service , and click Apply. e. Select the mask 24 ( ) and protocol type Any. f. Enter the port number 0, and select the forwarding mode Firewall Forwarding. g. Select the real service group FirewallGroup, and select the Enable Virtual Service option. h. Click Apply. 234

242 Figure 139 Creating virtual service VS Configuring LB device B Assume that the IP addresses of the interfaces on LB device B and the zones to which they belong have been configured. 1. Select High Reliability > Load Balance > Public Setting from the navigation tree. The public parameter configuration page appears. 2. Select Keep Last-hop Information. 3. Click Apply. Figure 140 Saving the last hop information Verifying the configuration A period of time after the hosts in the internal network access the Interface, you can display the statistics on LB device A to verify load balancing configuration. To view the traffic from Network A to Network B on LB device A: 1. Select High Reliability > Load Balance > Server Load Balance from the navigation tree. 2. Click the Statistics tab. 3. Click the virtual service name link of virtual service VS. 235

243 You can see the statistics on the page. Figure 141 Statistics on LB device A Figure 141 shows that the traffic from the internal network to Internet is balanced by Firewall A and Firewall B. Outbound link load balancing configuration example Network requirements A user has rent two physical links ISP1 and ISP2 from a carrier. The router hops, bandwidth and cost of the two links are the same, but the network delay of ISP2 is smaller than that of ISP1. It is hoped that packets destined to the IP address in the /24 segment are transmitted on ISP1, and packets destined to other addresses use the optimal link between the two links. Configuration considerations Outbound link load balancing is required. Packets are transmitted to the destination over the best link: Best performing link detection is adopted. Packets with the destination in the /24 segment are transmitted on physical link ISP1: ACL is adopted. Based on the above analysis, the networking scheme as shown in Figure 142 is adopted. 236

244 Figure 142 Network diagram Configuring the LB device Assume ISP1 and ISP2 have been deployed successfully and their status is healthy, and other features such as the IP addresses of the interfaces, the zone to which the interfaces belong, and routing of the LB device have been configured. The following describes the configuration of outbound link load balancing. 1. Create ACL 3000, allowing packets with the destination /24: a. Select Firewall > ACL from the navigation tree. b. Click Add. c. Enter the ACL number 3000, and select Config from the Match Order list. d. Click Apply. Figure 143 Creating ACL 3000 e. Click the icon of ACL 3000, and then click Add. f. Select Permit from the Operation list, select the Destination IP Address option, and enter the destination IP address and destination wildcard g. Click Apply. 237

245 Figure 144 Configuring rules for ACL Create the physical link corresponding to ISP1: a. Select High Reliability > Load Balance > Link Load Balance > Physical Link from the navigation tree. b. Click Add. c. Enter the link name ISP1 and next hop , and select the health monitoring type icmp. d. Click Apply. Figure 145 Creating the physical link corresponding to ISP1 3. Create the physical link corresponding to ISP2: 238

246 a. Click Add on the Physical Link tab. b. Enter the link name ISP2 and next hop , and select the health monitoring type icmp. c. Click Apply. 4. Create logical link group LogicalLinkGrp and adopt the bandwidth scheduling algorithm: a. Select High Reliability > Load Balance > Link Load Balance > Outbound from the navigation tree. The Logical Link Group tab appears. b. Click Add. c. Enter the logical link group name LogicalLinkGrp, and select the Bandwidth scheduling algorithm. d. Click Apply. Figure 146 Creating logical link group LogicalLinkGrp 5. Create logical link LogicalLink1 corresponding to ISP1: a. Click Logical Link. b. Click Add. c. Enter the logical link name LogicalLink1, select the logical link group LogicalLinkGrp and physical link ISP1, and enter the ACL number d. Click Apply. Figure 147 Creating logical link LogicalLink1 corresponding to ISP1 6. Create logical link LogicalLink2 corresponding to ISP2: a. Click Add on the Logical Link tab. b. Enter the logical link name LogicalLink2, and select the logical link group LogicalLinkGrp and physical link ISP2. 239

247 c. Click Apply. 7. Configure virtual service vs: a. Click the Virtual Service tab b. Select Match IP, and then click Add. c. Enter the virtual service vs and virtual service address d. Select the mask 0 ( ) and protocol type Any, and enter the port number 0. e. Select the logical link group LogicalLinkGrp. f. Select the Enable Policy and Enable Best-Performing Link options. g. Click Apply. Figure 148 Creating virtual service vs Verifying the configuration The internal users send packets with the destination in the /24 segment to the external network. 1. Select High Reliability > Load Balance > Link Load Balance > Best-Performing Link from the navigation tree. 2. Click the Best Performing Link Table tab. You can view the dynamic best performing link entries in the best performance link table. Figure 149 Best performance link table 3. After the system runs for a period of time, select High Reliability > Load Balance > Link Load Balance > Outbound from the navigation tree, and then click the Statistics tab. 240

248 4. Select Virtual Service Name, and enter the keyword vs. 5. Click Search. You will see the following statistics. Figure 150 Statistics (I) 6. Click the icon to clear the statistics of virtual service vs. 7. The internal users send packets with the destination in the /24 segment to the external network. 8. After the system runs for a period of time, click Refresh to see the statistics as shown in Figure 151. Figure 151 Statistics (II) The information shows that packets destined to /24 are distributed to the optimal link ISP2, and packets destined to /24 are distributed to link ISP1, and the outbound link load balancing function has taken effect. Inbound link load balancing configuration example The following matrix shows the configuration example and hardware compatibility: Hardware F1000-A-EI/F1000-S-EI F1000-E F5000 Compatibility No No Yes 241

249 Hardware F5000-S/F5000-C VPN firewall modules 20-Gbps VPN firewall modules Compatibility No No No Network requirements As shown in Figure 152, Server (with the domain name whatever.com.cn) provides Web services through two rent physical links ISP 1 and ISP 2. The router hops, bandwidth, and cost of the two links are the same, but the network delay of ISP 2 is smaller than that of ISP 1. It is hoped that users that correspond to local DNS server B use physical link 1 and users corresponding to local DNS server A use the optimal link between the two links. Configuration considerations Inbound link load balancing is required. Packets are transmitted to the destination over the best link. Best performing link detection is adopted. DNS requests with the source IP address /24 are transmitted over physical link ISP 1: Configure DNS A records, and reference ACL. Based on the above analysis, the networking scheme as shown in Figure 152 is used. Figure 152 Network diagram Configuring the LB device Assume ISP 1 and ISP 2 have been deployed successfully and their status is healthy, and other features such as the IP addresses of the interfaces on the LB device, the zone to which they belong, and routing of the LB device have been configured; DNS requests with the domain name whatever.com.cn can be distributed to the LB device. The following describes the configuration of inbound link load balancing. 1. Create ACL 3000, allowing packets with the source : a. Select Firewall > ACL from the navigation tree. b. Click Add. The Add ACL page appears. c. Enter the ACL number 3000, and select Config from the Match Order list. 242

250 d. Click Apply. Figure 153 Creating ACL 3000 e. Click the icon of ACL 3000, and then click Add. f. Select Permit from the Operation list, select the Source IP Address option, and enter the destination IP address and source wildcard g. Click Apply. Figure 154 Creating a rule for ACL Create the physical link corresponding to ISP 1: a. Select High Reliability > Load Balance > Link Load Balance > Physical Link from the navigation tree. The Physical Link page appears. b. Click Add. The Add Physical Link page appears. 243

251 c. Enter the link name ISP1 and next hop , and select the health monitoring type icmp. d. Click Apply. Figure 155 Creating the physical link corresponding to ISP 1 3. Create the physical link corresponding to ISP 2: a. Click Add on the Physical Link tab. The Add Physical Link page appears. b. Enter the link name ISP2 and next hop , and select the health monitoring type icmp. c. Click Apply. 4. Enable DNS redirection: a. Select High Reliability > Load Balance > Link Load Balance > Inbound from the navigation tree. The Inbound page appears. b. Select the Enable DNS Redirection option. c. Click Apply. Figure 156 Enabling DNS redirection 5. Create the DNS A record corresponding to ISP 1: a. Select type A in the DNS Table area. b. Click Add. 244