Contents

Introduction· 1

Version information· 1

Version number 1

Version history· 1

Hardware and software compatibility matrix· 2

Upgrade restrictions and guidelines· 3

Hardware feature updates· 4

R9001P39· 4

Software feature and command updates· 4

MIB updates· 4

Operation changes· 5

R9001P39· 5

Restrictions and cautions· 5

Restrictions· 5

IRF· 5

NAT service and traffic redirecting· 5

User-defined contexts· 7

Attack defense· 7

Policies· 7

DPI services· 8

Redundancy groups and failover groups· 8

Forwarding· 9

Interface modules· 9

RBM·· 10

ISSU· 12

Performance· 12

Cautions· 13

Licensing· 13

About licensing· 13

Registering and installing licenses· 14

Open problems and workarounds· 14

List of resolved problems· 15

Resolved problems in R9001P39· 15

Troubleshooting resources· 15

Related documentation· 15

Technical support 15

Appendix A Feature list 1

Appendix B Fixed security vulnerabilities· 1

Vulnerabilities in R9001P39· 1

Vulnerabilities in versions earlier than R9001P39· 1

Appendix C Upgrading software· 2

Overview· 2

Software types· 2

Comware image redundancy· 3

Upgrade methods· 3

Upgrade restrictions and guidelines· 3

Network setup· 4

Upgrading on the Web management interface· 4

Upgrading from the CLI without using ISSU· 7

Preparing for the upgrade· 7

Upgrading the BootWare image· 10

Upgrading the Comware images· 11

Installing patches· 12

Handling software upgrade failures· 13

Appendix D Using BootWare menus· 14

Overview· 14

BootWare menus· 14

BootWare shortcut keys· 14

Using the BASIC-BOOTWARE menu· 15

Accessing the BASIC-BOOTWARE menu· 15

Modifying serial port parameters· 16

Upgrading the extended BootWare segment 17

Upgrading the entire BootWare· 17

Running the primary extended BootWare segment 17

Running the backup extended BootWare segment 18

Accessing the BASIC ASSISTANT menu· 18

Testing the memory· 18

Using the EXTENDED-BOOTWARE menu· 18

Accessing the EXTENDED-BOOTWARE menu· 18

Controlling the password recovery capability· 20

Running Comware images· 21

Accessing the Serial submenu· 21

Accessing the Ethernet submenu· 22

Managing files· 23

Restoring the factory-default configuration· 30

Skipping the configuration file· 31

Accessing the BootWare Operation submenu· 31

Skipping console login authentication· 32

Managing storage media· 32

Accessing the EXTEND ASSISTANT submenu· 32

Formatting the file system·· 33

Upgrading Comware images from BootWare menus· 33

Preparing for the upgrade· 33

Using TFTP to upgrade software images through the management Ethernet port 34

Using FTP to upgrade software images through the management Ethernet port 36

Upgrading BootWare from BootWare menus· 37

Preparing for the upgrade· 38

Using TFTP to upgrade BootWare through the management Ethernet port 38

Using FTP to upgrade BootWare through the management Ethernet port 40

List of tables

Table 1 Version history............................................................................................................................................................. 1

Table 2 Hardware and software compatibility matrix..................................................................................................... 2

Table 3 MIB updates................................................................................................................................................................. 4

Table 4 M9000-AI series hardware features...................................................................................................................... 1

Table 5 M9000 series software features............................................................................................................................. 2

Table 6 BootWare menus...................................................................................................................................................... 14

Table 7 BootWare shortcut keys......................................................................................................................................... 15

Table 9 BASIC ASSISTANT menu options......................................................................................................................... 18

Table 11 Serial submenu options....................................................................................................................................... 21

Table 14 File Control submenu options........................................................................................................................... 24

Table 15 BootWare Operation submenu options......................................................................................................... 31

Table 16 DEVICE CONTROL menu options...................................................................................................................... 32

Table 17 EXTEND ASSISTANT submenu options........................................................................................................... 33

Introduction

This document describes the features, restrictions and guidelines, open problems, and workarounds for version R9001P39. Before you use this version on a live network, back up the configuration and test the version to avoid software upgrade affecting your live network.

Use this document in conjunction with H3C SECPATH9000EM-BLADEFWM9000E-CMW710-R9001P39 Release Notes (Software Feature Changes) and the documents listed in "Related documentation."

Version information

Version number

Comware software, Version 7.1.064, Release 9001P39

Note: You can see the version number with the display version command in any view. Please see Note①.

Version history

Table 1 Version history

Hardware and software compatibility matrix

Table 2 Hardware and software compatibility matrix

Sample: To display the host software and BootWare version of M9000-AI-E8, perform the following:

RBM_P[M9KE-L] display version

H3C Comware Software, Version 7.1.064, Release 9001P39

Copyright (c) 2004-2022 New H3C Technologies Co., Ltd. All rights reserved.

H3C SecPath M9000-AI-E8 uptime is 0 weeks, 0 days, 20 hours, 47 minutes

Last reboot reason : User reboot

Boot image: flash:/M9000E-CMW710-BOOT-R9001P39.bin

Boot image version: 7.1.064, Release 9001P39

Compiled Jun 07 2022 14:00:00

System image: flash:/M9000E-CMW710-SYSTEM-R9001P39.bin

System image version: 7.1.064, Release 9001P39

Compiled Jun 07 2022 14:00:00

LPU 2:

Uptime is 0 weeks,0 days,21 hours,47 minutes

H3C SecPath M9000-AI-E8 LPU with 1 ARM Processor

BOARD TYPE:         NSQM5MBSHA1

DRAM:               2048M bytes

PCB 1 Version:      VER.C

SUBCARD 1 PCB Version:VER.A

Bootrom Version:    312

CPLD 1 Version:     002

SUBCARD 1 CPLD Version:001

Release Version:    H3C SecPath M9000-AI-E8-9001P39

Patch Version  :    None

Reboot Cause  :     UserReboot

PowChip Version:    NONE

Upgrade restrictions and guidelines

·            The vCPU monitoring command on an M9KE service module does not monitor the interrupted core vCPU3. After the upgrade, you must reconfigure monitoring the concerned cores.

·            Do not save the configuration if the IRF fabric splits during the upgrade process. If you do that, the configuration of the original dual-device IRF fabric will be lost.

·            SecPath M9000-AI-E8 and SecPath M9000-AI-E16 devices do not support ISSU.

Hardware feature updates

R9001P39

None.

Software feature and command updates

For more information about the software feature and command update history, see H3C SECPATH9000EM-BLADEFWM9000E-CMW710-R9001P39 Release Notes (Software Feature Changes).

MIB updates

Table 3 MIB updates

Operation changes

R9001P39

None.

Restrictions and cautions

Before performing an upgrade, see H3C SECPATH9000EM-BLADEFWM9000E-CMW710-R9001P39 Release Notes (Software Feature Changes) and related documentation to see the software feature changes and evaluate the influence on the service.

Restrictions

IRF

·            You must use transceiver modules and fibers for IRF links. The IRF physical interfaces must operate at 10 Gbps, 40 Gbps, or 100 Gbps.

·            You can bind a maximum of 16 physical interfaces to an IRF port.

·            In IRF mode, the IRF bridge MAC address of an IRF fabric does not change even after the address owner leaves the IRF fabric.

·            The physical interfaces on an interface module are grouped by interface number in order, starting from 1. Each group contains four physical interfaces. When you use the physical interfaces in a group for IRF links, follow these restrictions and guidelines:

¡  If you use one physical interface in a group as an IRF physical interface, the remaining physical interfaces in the group can only act as IRF physical interfaces. You cannot use them for any other purposes. To use a physical interface in a group for any purpose other than IRF physical interfaces, do not bind any of the interfaces in the group to an IRF port.

¡  You must shut down all physical interfaces in a group before you can assign or remove any of the interfaces to or from an IRF port. To bring up the interfaces after the assignment or removal is complete, execute the undo shutdown command.

NAT service and traffic redirecting

·            The capacity of flow entry learning is limited on each interface module. When the flow table is full, traffic redirecting goes abnormal. Make sure the flow table will not be full after the configuration is deployed. When the ACL resources are insufficient, a serial interface is not responding for a long time if the device deploys a large number of static NAT settings. Because the service module supports a limited number of flow entries, add address ranges with consecutive addresses in the NAT address pool. For example, specify the start IP address as 10.0.0.16 and the end IP address as 10.0.0.31.

·            The number of IP addresses in the NAT address pool cannot be less than the value of multiplying the number of failover groups by 2. A failover group can be automatic or manual. The type of the failover groups across the entire device must be the same.

·            If QoS traffic redirecting is used to redirect traffic to a Blade card, for successful traffic redirection, redirect the traffic to the automatic failover group instead of redirecting traffic to the card. The failover group, OpenFlow, and Blade card are in descending order of priority.

·            The hardware fast forwarding does not support forwarding based on VPN instance. This is because the switching chips on the interface modules are not VPN-aware, and the VPN instance information in OpenFlow entries is not deployed. If VPN instance information is configured in the QoS traffic redirection rule, the QoS rule cannot take effect. A packet arriving at an access port cannot match the VLAN information in the OpenFlow rules that carry VLAN information.

·            If NAT is configured on a Reth interface which is assigned to the user-defined context in shared mode, the device cannot issue OpenFlow entries.

·            In the software release, the public IP addresses in the static NAT mappings and the IP addresses in the public NAT address pool cannot overlap.

·            The NAT address pool members cannot include local interface address or virtual IP address of a VRRP group. In user context, when configuring VRRP groups for the subinterfaces of the same main interface, specify different VRIDs for the VRRP groups.

·            NAT ALG does not support ACG translation for fragments. For NAT ALG to function correctly, do not specify the GRE, ICMP, OSPF, TCP, or UDP protocol matching criteria in the ACL rules that are used to identify packet for NAT processing.

·            On an M9000, the interfaces with NAT hairpin configured does not deploy traffic redirection rules, therefore, load sharing among multiple Blade cards is not supported. The status of the interface that connects to the public network does not affect NAT hairpin. This is because the source and destination IP address of the packets are translated on the interface connected to the internal network.

·            AFT is not supported on VLAN interfaces, subinterfaces, Reth interfaces where a member interface is a subinterface, or interfaces that are assigned to a context in shared mode. If you configure AFT prefix translation, do not configure VPN instances on the interface. On one device, NAT and AFT cannot process the same packet. AFT does not support the previous hop keeping feature.

·            NAT66 prefix translation must be used together with QoS policies.

·            The device does not deploy flow entries for SSL VPN IP resources. Therefore, configure NAT or a traffic redirecting policy to enable the device to deploy flow entries for SSL VPN IP resources.

·            As a best practice, set the aging time for udp-ready no shorter than 3 seconds in the session aging-time state command.

·            When both the nat outbound address-group and bfd enable commands are executed on an interface, you must use the nat outbound acl command to perform NAT for only traffic matching the specified ACL and avoid performing NAT for BFD packets.

·            After you configure an IPv6-to-IPv4 source address translation policy in a non-default context and inject SIP-UDP traffic, the reverse packets of subsessions are lost because the relation entries and source port translation have exceptions.

User-defined contexts

·            Rebooting a context while a service module is in unstable state might cause exceptions. Before rebooting a context, use the display system stable state command to verify that all service modules are in Stable state.

·            The default Blade controller team must contain SecBlade security service modules in normal state. The multicast packets and broadcast packets are redirected to the default controller team. When the default controller team does not contain SecBlade service modules, multicast packets and broadcast packets cannot be processed. When multiple contexts exist on the device, if the security engine group used by contexts have multiple SecBlade service modules, the broadcast and multicast packets will be broadcast among each node, which causes high CPU usage. When contexts use shared interfaces, multicast traffic will be replicated among contexts, which causes high CPU usage.

·            When inband management is used, the controller or local manager will be stuck or lose management when the CPU usage is high because the forwarding services are busy.

Attack defense

·            For an M9000, the global statistics for a service is collected and displayed on a per-engine basis, and the threshold setting is deployed per engine. For example, if you want to limit the number of connections on the device, the threshold is the total number of connection limit divided by the number of engines.

·            If a static blacklist entry uses an object group, only IPv4 or IPv6 address object groups can be used.

Policies

·            Some configuration entries of interzone policies do not support policy acceleration, which affects the device forwarding performance. As a best practice, preferentially use security policies.

·            A security policy and a packet filter can be configured at the same time, but the former has higher priority over the latter.

·            An object policy and a packet filter can be configured at the same time, but the former has higher priority over the latter.

·            A security policy and an object policy cannot take effect at the same time. If the security-policy disable command is executed, the object policy takes effect. Otherwise, the security policy takes effect.

·            If an object policy is enabled with rule matching acceleration, an object policy rule takes effect even if the specified track entry is in Negative state.

·            Fast forwarding entries can be created for the following fields in a rule of an ACL used in a packet filter:

¡  Source/Destination IP address

¡  Source/Destination port number

¡  Protocol number

¡  VPN instance

¡  ICMP type

¡  ICMP code

If other fields that do not support fast forwarding are configured in the rule, the matching packets cannot be fast forwarded.

·            When acceleration is enabled for a security policy (acceleration is enabled by default) and object policy and a rule references nested service object groups, all source ports and destination ports are ORed. As a result, all traffic is forwarded.

DPI services

·            DPI services do not support stateful failover. DPI services cannot inspect packets correctly in a network that has asymmetric traffic.

·            After upgrading the software of a DPI service module, do not downgrade its signature library because earlier signature library versions might not be compatible with the software version. For successful signature library upgrade triggered at the CLI, make sure the device port used for the upgrade is not bound to a VPN instance.

·            It takes some time for the log and report data of DPI service modules to be displayed on the Web interface. The total size of the log and report data of a DPI service module is limited. When the limit is reached, new data will overwrite the oldest data by default.

·            APR cannot recognize the application layer protocol of packets transmitted across VPN instances. Signatures with regular expression-based match patterns in a user-defined NBAR rule cannot match packet data in the raw-body, raw-header, and raw-content fields that are transmitted in different TCP segments. The device starts APR statistics collection for packets after you configure ARP settings on it. However, the APR settings do not take effect on packets already processed by the device so application statistics collected for such packets might not be accurate.

·            Disabling the DPI engine on the default context also disables the DPI engine on all non-default contexts.

·            The display inspect status command can display the bypass by CPU busy state only on the default context. The bypass by cpu busy state indicates that the DPI engine is disabled because the device's CPU usage threshold is exceeded.

·            Deep packet inspection will be suspended in the following situations:

¡  The memory threshold is reached.

¡  The signature library is being upgraded.

¡  The CPU usage is high.

¡  The inspect active command is executed.

¡  The signature library is loaded during the active/standby switchover process.

Redundancy groups and failover groups

·            When you configure redundancy groups and failover groups on a system formed by two M9000-AI-E gateways, make sure the following requirements are met:

¡  The deployment of interface modules and services modules is exactly the same on the gateways, including the module models and slot numbers.

¡  The nodes in a redundancy group each host a member of a failover group, and the failover group member on the high-priority node must be assigned the primary role.

¡  If multiple failover groups exist, their primary members must be on the same chassis.

·            If multiple security engine groups exist on a system formed by two M9000-AI-E gateways, configure manual failover groups for all of them or do not configure manual failover groups. If you configure manual failover groups for some of the security engine groups, the NAT configuration of the security engine groups not configured with manual failover groups cannot be issued to the kernel. If you configure manual failure groups, you must assign all security engine groups to the failover groups. Do not use automatic and manual failover groups together. If manual failover groups exist, you must add engine cards to ensure that NAT traffic can be forwarded.

·            When a card in a failover group reboots or a new card is installed on a system formed by two M9000 gateways, a batch session backup is performed. During session backup, the number of sessions might be different on the two gateways.

·            Connection limits are not available on a stateful failover system.

·            SecPath M9000-AI-E8 and SecPath M9000-AI-E16 devices do not support hot plugging or redundancy of switching fabric modules. Make sure both switching fabric modules are in place. You cannot power off a switching fabric module at the CLI. Do not plug switching fabric modules in the last two switching fabric module slots. If a switching fabric module fails during the operating process, the traffic that has been processed on the faulty switching fabric module will be affected.

Forwarding

·            When tunneling and PBR are configured together, do not redirect the original packets or encapsulated packets to the tunnel interface through PBR. When packets are forwarded by the tunnel interface, they are considered as local packets after tunnel encapsulation. Therefore, they can match PBR and be redirected to the tunnel interface again.  Then, packets will be encapsulated by the tunnel again. No matter how many times the packets enter the tunnel, IP forwarding still sends the packets to the tunnel interface according to PBR, and packets are cyclically processed between PBR and tunnel encapsulation. To avoid stack overflow, the tunnel drops packets after performing encapsulation for these packets six times. Eventually, packets fail to be forwarded.

·            After the previous IPv4 hop is kept, the source MAC address in the reverse traffic is the destination MAC address of the forward traffic, rather than the MAC address of the device interface. For multichannel protocols, the previous IPv4 hop keeping feature supports only FTP and RTSP. Keeping previous IPv6 hops is not supported.

·            When there are multiple egress interfaces, different egress interfaces must be assigned to different security zones. Otherwise, sessions are not deleted when egress interface switchover occurs, which will interrupt services.

·            When the default-next-hop command is used in a routing policy, the traffic will not be forwarded through hardware, and the service performance will degrade. Please use the next-hop command.

Interface modules

·            All physical interfaces of the device are Ethernet interfaces. As a best practice, use the default network type (broadcast) for OSPF.

·            When adding interfaces to an aggregation group, add these interfaces one by one rather than in bulk through an interface range.

·            Mirroring restrictions and cautions

¡  The high-end security products support flow mirroring, and do not support port mirroring.

¡  The mirroring source ports and mirroring egress ports must be all physical ports.

¡  When a QoS policy is applied to an interface, the enhancement keyword must be specified.

¡  Flow mirroring is performed on interface cards, and does not affect service module performance.

¡  If traffic of multiple interfaces is mirrored to the same physical interface, the physical interface might operate at the full speed and generate back-pressure frames, which causes packet loss. No workaround through software is available for this problem in the current software version.

¡  Due to chip restrictions, you can configure up to four port mirroring configurations totally in the inbound and outbound directions on an interface module.

·            40-GE and 100-GE interfaces cannot be split.

·            10-GE interfaces on an interface module do not support autosensing 1000-Mbps transceiver modules or fiber-to-copper converters. When you use 1000-Mbps transceiver modules or fiber-to-copper converters, as a best practice to prevent the interfaces on both ends from failing to come up, execute commands to configure the 1000 Mbps speed and full duplex mode for the directly connected interface. When a fiber-to-copper converter is installed but no cable is installed in a 10-GE interface on an interface module, the local interface is displayed as up.

·            When using the port fec mode command on an interface, follow these restrictions and guidelines:

¡  If you need to replace a transceiver module after enabling FEC on an interface, as a best practice, change the FEC mode to autonegotiation unless you must enable FEC to meet the special requirements. This is because enabling RS-FEC by force on an interface will affect installing other transceiver modules in the interface subsequently. For example, after you enable RS-FEC on an interface, if you replace an ER4-100G transceiver module with an LR4-100G transceiver module for the interface, the interface still acts as when RS-FEC is forcibly enabled. As a result, the LR4-100G transceiver module cannot come up.

¡  When RS-FEC is enabled forcibly on an interface, FEC will restore to the default state after the card is cold/hot reset. In autonegotiation mode, you can re-configure FEC as needed.

RBM

·            RBM stateful failover requirements:

¡  RBM stateful failover is mutually exclusive with IRF stateful failover.

¡  The two devices forming a stateful failover system must be the same in the model, and the types, numbers, and locations of cards installed.

¡  The two devices must be the same in the following aspects: system software version, system patch version, dynamically loaded component packages, signature library version, hash selection CPU mode, and hash factors.

¡  Firewall interfaces on the two devices must be the same in type, number, and link layer protocol type. If logical interfaces are involved, their interface number and member interface numbers must also be the same.

¡  If the service interfaces of a firewall operate at Layer 2, you must configure the service interfaces to operate in bridge mode as Layer 2 interfaces and assign them to the same VLAN.

¡  If the service interfaces of a firewall operate at Layer 3, the IP addresses of the service interfaces must be fixed. Therefore, the stateful failover feature cannot be used together with features that automatically obtain IP addresses, for example, PPPoE dialup and DHCP client.

·            The configuration synchronization function takes effect on the primary device. More specially, the commands executed on the configured primary device can be synchronized to the configured secondary device, and the commands executed on the configured secondary device cannot be synchronized to the configured primary device. Therefore, execute related configuration commands on the configured primary device.

·            On an RBM network, for special requirements (the log host or other configurations that are synchronized by default but must be different on the two devices), when the active MPU is rebooted on a chassis or the whole chassis is rebooted, you must manually adjust the configurations.

·            During the system software upgrade or rollback process, the two devices can run different system software versions temporarily (D045SP24 and later, D060SP10 and later, and exception branches are completely compatible with only D045SP1214).

·            RBM channel requirements:

¡  The HA channel interfaces are only used to transmit stateful failover-related packets, for example, heartbeat packets and backup packets. You cannot configure VRRP on HA channel interfaces, or redirect service packets to HA channel interfaces.

¡  Additionally, as a best practice, bind multiple physical interfaces into an aggregate interface, and use the aggregate interface as the heartbeat interface. In this way, you can improve the link reliability and increase the backup channel bandwidth.

¡  To successfully send the HA configuration backup packets and service entry backup packets, make sure the RBM channel interfaces are directly connected and the MTU of the interfaces must be 1500 (the default value). 

¡  RBM management channels cannot be bound to VPN instances.

¡  When you convert an IRF fabric to a dual-active RBM+track interface network, follow these restrictions and guidelines: After you convert the IRF standby device to an RBM device, bring up the RBM channel interfaces, wait for 10 minutes, and then connect uplink and downlink service interfaces.

¡  On a network with symmetric traffic, the RBM data channel bandwidth depends on the number of service modules and the total session setup rate. As a best practice, configure the channel bandwidth as (N+3)*10-GE interfaces, where N is the number of service modules.

¡  On a network with asymmetric dual-host traffic, the RBM data channel bandwidth depends on not only the number of service modules and the total session setup rate, but also the information to be exchanged between the primary and secondary hosts for the service. For example, if the DPI service is enabled, the DPI service needs to synchronize the data of each packet to the secondary host on a network with asymmetric dual-host traffic. In the extreme conditions, make sure the heartbeat interface bandwidth is consistent with the bandwidth for the uplink service traffic and downlink service traffic.

·            Collaboration with NAT

¡  On the RBM stateful failover network, NAT address pool probe is not supported.

¡  In the load sharing scenario for the RBM stateful failover network, when the NAT mode is PAT, you must execute the nat remote-backup port-alloc primary command on one host and execute the nat remote-backup port-alloc secondary command on the other host to equally divide the port resources in the address pool for the two devices to avoid port conflicts in the NAT address pool. When the NAT mode is NO_PAT, you must use two address pools. If you use only one address pool, resource allocation conflicts will occur.

¡  In the RBM stateful failover scenario, the NAT address pool cannot contain IP addresses of interfaces on the primary and secondary hosts. If the NAT address pool contains IP addresses of these interfaces, when an uplink device requests the ARP entry of an IP address in the address pool, both the primary host and secondary host respond, causing ARP conflicts. In a NAT policy, make sure the source or destination addresses do not contain the heartbeat interface IP address. Otherwise, the heartbeat link communication will fail because NAT is performed for heartbeat packets. On an RBM stateful failover network, if you use different address pools, the primary host and secondary host select which address pool to use by 5-tuple. If a 5-tuple cannot uniquely identify a host, you must use the interface splitting function.

¡  On an RBM stateful failover network in load sharing mode, address pools do not support the EIM mode. On an RBM stateful failover network, the easy IP mode is not supported.

¡  In the NAT traffic redirection scenario, if an LPU is restarted or installed, bulk configuration backup must be performed on the device configured with the primary RBM role to ensure flow entry consistency on the primary and secondary devices. More specifically, follow these restrictions and guidelines:

-       On an RBM primary/secondary network, after an LPU is restarted on the secondary device, you must manually perform bulk configuration backup on the primary device.

-       On an RBM primary/secondary network, after an LPU is restarted on the primary device, you must manually perform bulk configuration backup on the primary device before traffic is switched back to the primary device. In this case, some services might be interrupted on the secondary device.

-       On an RBM dual-primary network, after an LPU is restarted on the secondary device, you must manually perform bulk configuration backup on the primary device before the secondary device is restored to dual-primary.

-       On an RBM dual-primary network, after an LPU is restarted on the primary device, you must manually perform bulk configuration backup on the primary device before the primary device is restored to dual-primary. In this case, some services might be interrupted on the secondary device.

-       When LPUs or interface cards are expanded on an RBM primary/secondary network or dual-primary network, you must expand them first on the primary device and then on the secondary device. After the expanded LPUs are restarted on the secondary device, you must manually perform bulk configuration backup on the primary device.

·            The RBM stateful failover feature supports vSystems.

¡  In a non-default vSystem, the configuration is inherited from the default vSystem, you can view the RBM state, but you cannot change the configuration.

¡  The VRRP role in a vSystem is the same as that in the default vSystem.

¡  On an RBM stateful network collaborating with VRRP or routing and tracking interfaces, the vSystems share an interface, and the interface is tracked in the default vSystem.

¡  In the RBM+exclusive context environment, creating or deleting contexts and interface on the compatible controller will cause RBM flapping, and this issue is followed and to be resolved. In the RBM+shared context environment, creating or deleting interfaces on the controller will cause RBM flapping, and this issue is to be resolved through optimizing the security controller.

¡  An RBM network cannot collaborate with services in a custom engine group.

·            Other restrictions on RBM

¡  Make sure the interval between executing the switchover request command on an RBM network is longer than one minute. Otherwise, the route convergence is slow.

¡  In the DPI scenario, as a best practice, do not deploy the dual-active mode, which will reduce the detection ratio.

¡  The RBM network cannot be used together with the AFT prefix traffic redirection.

-       On an RBM network, the transparent fragment forwarding function supports only pure Layer 3 forwarding and inline Layer 2 forwarding.

-       An RBM dual-primary network does not support the uplink/downlink per-packet mode.

-       Because the primary and secondary state machines are incomplete on an RBM network with asymmetric dual-host traffic, the FIN connection aging time is 30 seconds by default, which increases the concurrent connections by 30*connection setup rate and consumes more memory. If the number of concurrent connections exceeds 20 million, as a best practice, set the FIN connection aging time to 15 seconds on an asymmetric RBM network.

ISSU

SecPath M9000-AI-E8 and SecPath M9000-AI-E16 devices do not support ISSU.

Performance

·            The DNS aging time is modified to 30 seconds. You can modify the DNS aging time as needed to meet your special requirements.

·            On a Blade IV module, when the usage of a single core is high, the performance of the whole device will decrease suddenly. To resolve this issue, exclude the abnormal traffic and block packets dropped by QoS as soon as possible. If you cannot resolve this issue quickly, you can modify the forwarding mode to per-packet forwarding after evaluating the service.

·            The control plane rate-limits protocol packets on the local device. When attack packets appear on the live network or a large number of protocol packets are sent to the local device in the cloud multi-tenant scenario, packets will be dropped after they reach the rate limit. By default, the rate limit is 500 for ARP, each routing protocol, DHCP, management protocol to the local device, ICMP, multicast protocol, RADIUS, and VRRP separately, and the rate limit for all the other protocol packets matching the default rule is 1000.

Cautions

·            QinQ packets with two layers of VLAN tags are not supported. To use a VLAN interface, make sure the Layer 2 interfaces in the corresponding VLAN are trunk or hybrid ports and receive VLAN-tagged packets. BFD MAD cannot be configured on VLAN interfaces.

·            NTP in multicast mode supports only the network segment address with the multicast address 224.0.1.x.

·            To log in to the Web interface by using an IE browser, make sure the IE version is 9.0 or later. A feature module cannot be configured both at the CLI and in the Web interface.

·            A management interface on an MPU only supports local management and access. You cannot use a management interface on an MPU to send logs or forward traffic. When the device is configured with NAT/ATK/DPI logs, if neither userlog nor customlog is configured, the logs are sent in the syslog format by default, which will cause low sending performance and high CPU usage. Service logs must be configured as fastlog rather than syslog.

·            On an MPLS network, when the device acts as a PE, it supports only popping labels.

·            Do not apply interface-level MQC traffic redirecting to the physical interfaces of a logical interface (tunnel interface, VLAN interface, Reth interface, physical subinterface, aggregate subinterface, VT interface, or VP interface) or aggregate interfaces. Otherwise, the second traffic redirection on the logical interface fails. You must apply global MQC traffic redirecting.

·            SSL VPN cannot configure IPv6 range-related services.

·            On the online MAC authentication user list page of the Web interface, the online user information displayed is inaccurate when you configure the list to display 200 entries per page. As a best practice, do not configure the list to display 200 or more entries per page.

·            MAC authentication does not support authorization VLAN, authorization ACL, or user profile.

·            The default unicast packet drop threshold is 95% in the vCPU. This feature is enabled by default in R9001P3003 and later.

¡  To fix the CNVD-2019-27331 vulnerability, use the ssl version ssl3.0 tls1.0 disable command to manually disable ssl3.0 and tls1.0.

¡  To fix the CNVD-2019-38486 vulnerability, use the ssl version ssl3.0 tls1.0 disable command to manually disable ssl3.0 and tls1.0.

¡  To fix the CVE-2011-1473 vulnerability, use the ssl renegotiation disable command to manually disable renegotiation and then re-enable renegotiation to make related services take effect.

Licensing

About licensing

To use license-based features, you must purchase licenses from H3C and install the licenses.

For more information about license-based features and supported licenses, see H3C SecPath M9000 Series Products License Matrixes.

Registering and installing licenses

H3C License Management Platform provides product licensing services for H3C customers. You can access this system to obtain an activation file or transfer licenses.

H3C License Management Platform is accessible at http://www.h3c.com/en/License/.

For more information about license registration, activation file installation, and license transfer, see H3C Security Products Licensing Configuration Demonstration Video, H3C Security Products Licensing Configuration Demonstration, H3C Security Products Licensing Configuration Examples, and H3C Security Products Licensing Guide.

H3C provides license-related FAQ. For more information, see H3C Security Products Licensing FAQ.

Open problems and workarounds

201908210900

·            Symptom: IKE negotiation fails between the iNode client and the device.

·            Condition: The symptom occurs if local extended authentication and address pool authorization is performed.

·            Workaround: None.

202102050708

·            Symptom: When configuration consistency check is enabled, the device displays that no configuration consistency check has been performed.

·            Condition: This symptom occurs after the device reboots if the device performs configuration consistency check at intervals of 24 hours (the default interval).

·            Workaround: Change the default interval to another value, execute the undo config sync-check and config sync-check commands in sequence, and then save the configuration.

202206100707

·            Symptom: The state of an RBM member device falsely changes from standby to active after the member device becomes the standby device from the master device.

·            Condition: This symptom occurs if the following operations are performed:

a.    Configure VRRP master and backup devices in an RBM+context network. On the contexts, interfaces assigned to the VRRP group are shared interfaces.

b.    Delete the context on the RBM master device. The state of the RBM master device changes from active to standby. A timer is started immediately for master/backup switchover.

·            Workaround: Use shared contexts instead of exclusive contexts.

202205240456

·            Symptom: QoS policy configuration applied to interfaces is lost on an IRF member device.

·            Condition: This symptom might occur on a dual-active IRF fabric after you reboot an IRF member device.

·            Workaround: Do not reboot IRF member devices repeatedly. If this symptom has occurred, reconfigure QoS policy settings.

202205190654

·            Symptom: The state of an RBM member device falsely changes from standby to active after the member device becomes the standby device.

·            Condition: This symptom occurs if the following operations are performed:

a.    Configure VRRP on physical interfaces.

b.    Reboot the interface module where the VRRP physical interface resides on the RBM master device. The role of the RBM master device becomes backup.

c.    Start the switchback timer for switching traffic back to the device.

·            Workaround: Configure VRRP on aggregate interfaces.

List of resolved problems

Resolved problems in R9001P39

None.

Troubleshooting resources

To obtain troubleshooting resources for the product:

1.      Access Technical Documents at http://www.h3c.com/en/Technical_Documents.

2.      Select the device category and model.

3.      Select the Maintain or Maintenance menu.

Related documentation

·            H3C SecPath M9000-AI Multiservice Security Gateway Series Installation Quick Start

·            H3C SecPath M9000-AI Multiservice Security Gateway Series Installation Guides

·            H3C SecPath M9000 @CG@(V7)

·            H3C SecPath M9000 @CR@(V7)

Technical support

To obtain technical assistance, contact H3C by using one of the following methods:

·            Email:

h3cts@h3c.com (countries and regions except Hong Kong, China)

service_hk@h3c.com (Hong Kong, China)

·            Technical support hotline number. To obtain your local technical support hotline number, go to the H3C Service Hotlines website: https://www.h3c.com/en/Support/Online_Help/Service_Hotlines/

To access documentation, go to the H3C website at http://www.h3c.com/en/.

Appendix A Feature list

Hardware features

Table 4 M9000-AI series hardware features

Software features

Table 5 M9000 series software features

Appendix B Fixed security vulnerabilities

Vulnerabilities in R9001P39

·            [CVE-2022-0778] An attacker can exploit the OpenSSL BN_mod_sqrt DoS vulnerability.

·            [CVE-2011-1473] The renegotiation attack vulnerability is still detected even when the ssl renegotiation disable command is used. This command cannot take effect.

·            [Web vulnerability] A vulnerability that an attacker can exploit to launch Web-based HTTP slow attacks.

Vulnerabilities in versions earlier than R9001P39

·            [HSVD-201709-002] CVE-2019-3855: An attacker can exploit this vulnerability to execute unauthorized operations.

·            [HSVD-201903-017] CVE-2019-3855: An integer overflow flaw which could lead to an out of bounds write was discovered in libssh2 in the way packets are read from the server. libssh2 is a client-side C library implementing the SSH2 protocol. A remote attacker who compromises an SSH server may be able to execute code on the client system when a user connects to the server.

·            [HSVD-201904-001] TCP/IP SYN + FIN packet filtering vulnerability: A remote host does not discard TCP SYN packets with the FIN flag set. An attacker might bypass the firewall, depending on the type of firewall used.

·            [HSVD-201902-001] A remote host can exploit the TCP timestamp vulnerability to obtain the online time.

·            [HSVD-201901-016] CVE-2019-0548: A Linux kernel vulnerability that can cause information revealing.

·            [JavaScript library vulnerability]: Internal IP addresses in destination URLs might be revealed.

·            [CVE-2020-10188]: utility.c in telnetd in netkit telnet through 0.17 allows remote attackers to execute arbitrary code via short writes or urgent data, because of a buffer overflow involving the netclear and nextitem functions.

·            [Web JavaScript vulnerability]: A medium-risk vulnerability found during Web vulnerability scanning.

·            [Web CSRF vulnerability]: An CSRF vulnerability was found on the SSL VPN Web login interface.

·            [HTTP method vulnerability]: An attacker can use the OPTIONS method to determine the HTTP methods allowed by each directory.

·            [CRLF injection vulnerability]: This vulnerability can be exploited when an HTTP request contains a user-configured domain in the cookies or the request is GET /enterdomain.cgi?domain=%0d%0aSomeCustomInjectedHeader:%0d%0aset-cookie:iamyy HTTP1/1.

·            [CNVD-2019-38485] CVE-2019-1547: An attacker can exploit this vulnerability to obtain sensitive information.

·            [CNVD-2019-38486] CVE-2019-1563: In situations where an attacker receives automated notification of the success or failure of a decryption attempt, an attacker, after sending a very large number of messages to be decrypted, can recover a CMS/PKCS7 transported encryption key or decrypt any RSA encrypted message that was encrypted with the public RSA key.

·            [CNVD-2017-00450] CVE-2016-7056: A timing attack flaw was found in OpenSSL 1.0.1u and before that could allow a malicious user with local access to recover ECDSA P-256 private keys.

·            [CNVD-2018-06539] CVE-2018-0739: Constructed ASN.1 types with a recursive definition (such as can be found in PKCS7) could eventually exceed the stack given malicious input with excessive recursion. This could result in a Denial Of Service attack.

·            [CNVD-2019-05906] CVE-2019-1559: An attacker can exploit this vulnerability to bypass access controls and obtain sensitive information.

·            [CNVD-2018-09649] CVE-2018-0737: An attacker with sufficient access to mount cache timing attacks during the RSA key generation process could recover the private key.

·            [CNVD-2018-12153] CVE-2018-0732: An attacker can exploit this vulnerability to launch a DoS attack.

·            [CVE-2018-5407]: This vulnerability is related to OpenSSL. An attacker can exploit this vulnerability to obtain sensitive information and launch more attacks.

·            [X-Frame-Options vulnerability]: A missing X-Frame-Options header can cause a clickjacking attack.

·            [CVE-2014-3566]: The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which makes it easier for man-in-the-middle attackers to obtain cleartext data via a padding-oracle attack, also known as the "POODLE" issue.

·            [CVE-2021-23841/CVE-2021-23840/CVE-2020-1971]: This vulnerability is related to OpenSSL. The X.509 GeneralName type is a generic type for representing different types of names. One of those name types is known as EDIPartyName. OpenSSL provides a function GENERAL_NAME_cmp that compares different instances of a GENERAL_NAME to see if they are equal or not. This function behaves incorrectly and NULL pointer dereference might occur when both GENERAL_NAMEs contain an EDIPARTYNAME.

Appendix C Upgrading software

Overview

This chapter describes types of software and how to upgrade software for H3C SecPath M9000-AI-E8 from the CLI and BootWare menu.

Software types

The following software types are available:

·            BootWare image—A .btw file that contains a basic segment and an extended segment. The basic segment is the minimum code that bootstraps the system. The extended segment enables hardware initialization and provides system management menus. When the device cannot start up correctly, you can use these menus to load software and the startup configuration file or manage files.

·            Comware image—Includes the following image subcategories:

¡  Boot image—A .bin file that contains the Linux operating system kernel. It provides process management, memory management, file system management, and the emergency shell.

¡  System image—A .bin file that contains the Comware kernel and basic software features, including device management, interface management, configuration management, and routing.

¡  Feature image—A .bin file that contains advanced software features for users to purchase as needed.

¡  Patch image—A .bin file irregularly released to fix software bugs without rebooting the device. A patch image does not add new features.

The BootWare image, boot image, and system image are required for the system to operate. These images might be released separately or as a whole in one .ipe package file. If an .ipe file is used, the system decompresses the file automatically to load the software images.

Comware image redundancy

You can specify two sets of startup Comware software images: one main and one backup. The system always attempts to start up with the main images. If any main image does not exist or is invalid, the system tries the backup images.

Upgrade methods

Upgrade restrictions and guidelines

When you upgrade software, follow these restrictions and guidelines:

·            Do not power down or reboot the device during the upgrade.

·            Make the MPU and the service module use the same software version.

·            Typically, you do not need to upgrade LPUs and switching fabric modules separately from MPUs. LPUs and switching fabric modules automatically upgrade when you upgrade the active MPU (in standalone mode) or the global active MPU (in IRF mode). To upgrade the BootWare image of an LPU or switching fabric module separately from MPUs, contact H3C Support.

·            You must upgrade service modules separately from MPUs because they use independent BootWare and Comware images. The upgrade procedure is the same except that you must follow these guidelines:

¡  If CPU 1 is in absent state, you must connect to the console port on the service module or Telnet to the service module for an upgrade. To install patches for the service module's switching unit, you must use the CLI of the active MPU (in standalone mode) or global active MPU (in IRF mode).

¡  Store upgrade images to the root directory of a storage medium on the service module.

·            You can use the boot-loader file ipe-filename all main command to upgrade all firewall modules whose CPUs (CPU 1) are in normal state. To upgrade a firewall module whose CPU 1 is in absent state, you must Telnet to the firewall module or log in to the firewall module through its console port.

Network setup

All upgrade examples use the network setup shown in Figure 1:

·            Connect the PC to M-GigabitEthernet 0/0/0 on the device by using an Ethernet cable.

·            Connect the PC to the console port on the device by using a console (RS-232) cable:

a.    Connect the DB-9 connector of the RS-232 cable to the serial port on a USB to serial cable.

b.    Connect the RJ-45 connector of the RS-232 cable to the console port on the device.

c.    Plug the USB connector on the USB to serial cable to the USB port on the PC.

·            Use the factory default settings for software upgrade.

Figure 1 Network setup

Upgrading on the Web management interface

The administrator can access the Web management interface of the device for convenient device management, maintenance, and upgrade.

1.      Connect the PC to the MPU's management Ethernet port of the device.

2.      Assign a random IP address in subnet 192.168.0.0/24 (except 192.168.0.1) to the PC so that the PC and the device can reach each other.

3.      Access the Web management interface of the device.

a.    Open the browser on the PC, enter https://192.168.0.1, and then press the Enter key.

b.    Enter the default username and password, and then click Log in.

4.      Select System > Upgrade Center > Software Upgrade to access the software upgrade page.

5.      Select the upgrade location. In this example, the MPU is installed on slot 0.

Figure 2 Selecting the upgrade location

6.      Click Upgrade immediately. You are placed in the upgrade configuration page.

7.      Select the target .ipe or .bin startup file for the service module and the MPU separately.

Figure 3 Selecting startup files

8.      Click OK to start the software upgrade.

9.      Verify the software upgrade result.

a.    Access the Web management interface of the device again after the device finishes restarting.

b.    Verify that the current software images and the main startup software images are upgraded as expected.

Figure 4 Verifying the software upgrade result

Upgrading from the CLI without using ISSU

This example describes how to upgrade an M9000, M9000-S, M9000-AI, or M9000-X device in standalone mode.

Preparing for the upgrade

Assigning an IP address to M-GigabitEthernet 0/0/0 and configuring the file server

·            Assign IP address 192.168.0.1/24 to M-GigabitEthernet 0/0/0.

·            Assign an IP address to the file server and make sure the device can access the file server. For more information about route configuration, see Layer 3—IP Routing Configuration Guide.

·            Enable the file server to act as the TFTP or FTP server.

·            Open the command shell of the device.

·            Copy the upgrade Comware images to the file server and set a correct access path to the file server.

Verifying that the free storage space is sufficient for the upgrade file

1.      Telnet to the MPU or log in through the console port. (Details not shown.)

2.      Display device information.

<Sysname> display device

Slot No. Brd Type         Brd Status   Subslot Sft Ver                Patch Ver

 0       NSQM1SUPC0       Master       0       M9006-9120             None     

 1       NONE             Absent       0       NONE                   None     

 2       NSQ1GT48EA0      Normal       0       M9006-9120             None     

 3       NONE             Absent       0       NONE                   None     

 4       NSQM1FWDFG0      Normal       0       M9006-9120             None     

         CPU 1            Normal       0       M9006-9120            

 5       NONE             Absent       0       NONE                   None     

 6       NSQ1FAB04B0      Normal       0       M9006-9120             None     

 7       NONE             Absent       0       NONE                   None     

 8       NONE             Absent       0       NONE                   None     

 9       NONE             Absent       0       NONE                   None

The output shows that the device has one MPU in slot 0 and one firewall module in slot 4. CPU 1 of the firewall module is in normal state.

3.      Verify that the MPU has sufficient free storage space for the upgrade images:

If CPU 1 of the firewall module is in normal state, you can use the dir slotx.1#sda0:/ command to verify that the firewall module has sufficient storage space. The x represents the slot number of the firewall module.

<Sysname> dir

Directory of flash:

   0 -rw-     5447680 Apr 22 2016 08:50:25   BLADE4FWM9000-CMW710-BOOT-E9120.bin

   1 -rw-    58275840 Apr 22 2016 08:51:42   BLADE4FWM9000-CMW710-SYSTEM-E9120.bin

   2 -rw-    21125120 Apr 20 2016 10:27:16   M9000-CMW710-BOOT-E9117.bin       

   3 -rw-    13556736 Apr 22 2016 08:41:34   M9000-CMW710-BOOT-E9120.bin       

   4 -rw-      252928 Apr 20 2016 10:40:39   M9000-CMW710-DEVKIT-E9117.bin     

   5 -rw-       77824 Apr 20 2016 10:40:40   M9000-CMW710-MANUFACTURE-E9117.bin

   6 -rw-   202685440 Apr 20 2016 10:40:37   M9000-CMW710-SYSTEM-E9117.bin     

   7 -rw-   128371712 Apr 22 2016 08:43:32   M9000-CMW710-SYSTEM-E9120.bin     

   8 drw-           - Apr 14 2015 16:46:41   av                                

   9 -rw-         880 Dec 24 2015 19:12:45   certnew20150202.cer               

  10 drw-           - Feb 29 2016 07:55:03   core                              

  11 drw-           - Oct 21 2015 15:45:27   diagfile                          

  12 drw-           - May 21 2015 15:44:14   dpi                               

  13 -rw-         223 Apr 16 2015 16:28:29   ecdsakey                          

  14 -rw-         735 Dec 13 2015 22:05:55   hostkey                           

  15 -rw-        1716 Apr 27 2016 09:52:24   ifindex.dat                       

  16 drw-           - Apr 14 2015 16:46:46   ips                               

  17 -rw-           0 Jun 11 2015 18:33:38   lauth.dat                         

  18 drw-           - Sep 07 2015 11:17:43   license                           

  19 -rw-        2316 Dec 24 2015 19:14:26   local20150202.pfx                 

  20 drw-           - Mar 23 2016 09:10:50   logfile                           

  21 -rw-      418156 Aug 27 2015 17:21:35   m9000_fw4_v2.03.btw               

  22 -rw-      642452 Aug 27 2015 16:47:49   m9000_v1.32.btw                    

  23 -rw-         385 Apr 01 2016 13:32:41   manuinfo.dat                      

  24 drw-           - Dec 24 2015 19:14:27   pkey                              

  25 drw-           - Dec 24 2015 19:14:27   pki                                

  26 drw-           - Oct 17 2014 16:30:41   seclog                            

  27 -rw-         591 Dec 13 2015 22:05:55   serverkey                         

  28 -rw-        6416 May 04 2016 10:06:18   startup.cfg                       

  29 -rw-      124425 Apr 27 2016 09:52:24   startup.mdb                       

  30 -rw-      119071 Jul 23 2015 15:21:46   test.cfg                          

  31 drw-           - May 21 2015 15:44:21   versionInfo                       

503808 KB total (51316 KB free)

4.      If the free storage space is not sufficient, delete unused files:

# Delete unused files from the MPU.

<Sysname> delete /unreserved flash:/test.cfg

The file cannot be restored. Delete flash:/test.cfg?[Y/N]:y

Deleting the file permanently will take a long time. Please wait...

Deleting file flash:/test.cfg... Done.

Transferring the upgrade file to the device

The device can function as the TFTP client, FTP client, or FTP server. This procedure uses the device as an FTP client to download files from an FTP server. For more information about FTP and TFTP configuration and operations, see H3C SecPath M9000 Multi Service Security Gateway Fundamentals Configuration Guide.

To download the upgrade software files from the FTP server:

1.      Run the FTP server program on the PC. Set the username, password, and working directory, and save the upgrade file to the directory. (Details not shown.)

2.      Verify that the device and the FTP server can ping each other. (Details not shown.)

3.      Download the MPU’s upgrade file to the MPU:

# Log in to the FTP server.

<Sysname> ftp 192.168.0.2 vpn-instance management

Press CTRL+C to abort.

Connected to 192.168.0.2 (192.168.0.2).

220 Browser Ftp Server.

User (192.168.0.2:(none)): admin

331 Password required for this user.

Password:******

230 User logged in

Remote system type is UNIX.

Using binary mode to transfer files.

ftp>

# Set the file transfer mode to binary.

ftp> binary

200 Binary transfer mode active.

# Download the upgrade file M9000.ipe to the root directory of a storage medium on the MPU.

ftp> get M9000.ipe

227 Entering Passive Mode (192,168,0,2,6,173)

150 Opening data connection.

226 Transfer complete.

96260096 bytes received in 191.335 seconds (491.31 Kbytes/s)

ftp> bye

221 Goodbye.

4.      Download the firewall module’s upgrade file to the MPU:

# Log in to the FTP server.

<Sysname> ftp 192.168.0.2 vpn-instance management

Press CTRL+C to abort.

Connected to 192.168.0.2 (192.168.0.2).

220 Browser Ftp Server.

User (192.168.0.2:(none)): admin

331 Password required for this user.

Password:******

230 User logged in

Remote system type is UNIX.

Using binary mode to transfer files.

ftp>

# Set the file transfer mode to binary.

ftp> binary

200 Binary transfer mode active.

# Download the upgrade file M9000_fw4.ipe to the root directory of the storage medium on the MPU.

ftp> get M9000_fw4.ipe

227 Entering Passive Mode (192,168,0,2,6,173)

150 Opening data connection.

226 Transfer complete.

65297408 bytes received in 72.395 seconds (880.82 Kbytes/s)

Upgrading the BootWare image

This procedure uses M9000_v1.32.btw to upgrade the BootWare image.

# Specify the BootWare image for the MPU in slot 0.

<Sysname> bootrom update file flash:/M9000_v1.32.btw slot 0

This command will update the Boot ROM file on the specified board(s), Continue? [Y/N]:y

Now updating the Boot ROM, please wait........... ...........Done

# To prevent configuration loss at reboot, save the running configuration.

<Sysname> save

# Reboot the device to complete the upgrade.

<Sysname> reboot

Start to check configuration with next startup configuration file, please wait.........DONE!

Current configuration may be lost after the reboot, save current configuration? [Y/N]:y

Please input the file name(*.cfg)[flash:/startup.cfg]

(To leave the existing filename unchanged, press the enter key):

flash:/startup.cfg exists, overwrite? [Y/N]:y

Validating file. Please wait...

Saved the current configuration to mainboard device successfully.

This command will reboot the device. Continue? [Y/N]:y

Now rebooting, please wait...

Upgrading the Comware images

This procedure uses M9000.ipe and M9000_fw4.ipe to upgrade the Comware images.

# Specify the M9000.ipe file as the main startup file for the MPU.

<Sysname> boot-loader file flash:/M9000.ipe all main

Verifying the IPE file flash:/m9000.ipe on slot 0.................Done.

H3C SecPath M9006 images in IPE:

  M9000-CMW710-BOOT-E9120.bin      

  M9000-CMW710-SYSTEM-E9120.bin

This command will set the main startup software images. Continue? [Y/N]:y

Add images to slot 0.

Decompressing file M9000-CMW710-BOOT-E9120.bin to flash:/M9000-CMW710-BOOT-E9120.bin..............Done.

Decompressing file M9000-CMW710-SYSTEM-E9120.bin to flash:/M9000-CMW710-SYSTEM-E9120.bin

..................................................................

...................................................Done.

Verifying the file flash:/M9000-CMW710-BOOT-E9120.bin on slot 0...Done.

Verifying the file flash:/M9000-CMW710-SYSTEM-E9120.bin on slot 0.........Done.

The images that have passed all examinations will be used as the main startup software images at the next reboot on slot 0.

Decompression completed. 

Do you want to delete flash:/M9000.ipe now? [Y/N]:N

# Specify the M9000_fw4.ipe file as the main startup file for the firewall module.

<Sysname> boot-loader file flash:/M9000_fw4.ipe all main

Verifying the file flash:/M9000_fw4.ipe on slot 0.....Done.

Blade4fw-m9000 images in IPE:

  BLADE4FWM9000-CMW710-BOOT-E9120.bin

  BLADE4FWM9000-CMW710-SYSTEM-E9120.bin

This command will set the main startup software images. Continue? [Y/N]:y

Add images to slot 0.

File flash:/BLADE4FWM9000-CMW710-BOOT-E9120.bin already exists on slot 0.

File flash:/BLADE4FWM9000-CMW710-SYSTEM-E9120.bin    already exists on slot 0.

Overwrite the existing files? [Y/N]:y

Decompressing file BLADE4FWM9000-CMW710-BOOT-E9120.bin to flash:/BLADE4FWM9000-CMW710-BOOT-E9120.bin.......Done.

Decompressing file BLADE4FWM9000-CMW710-SYSTEM-E9120.bin to flash:/BLADE4FWM9000-CMW710-SYSTEM-E9120.bin....................................Done.

The images that have passed all examinations will be used as the main startup software images at the next reboot on slot 4.1.

Specify the startup software image files for Blade4fw to load from the parent device? [Y/N]:y

Decompressing file BLADE4FWM9000-CMW710-BOOT-E9120.bin to flash:/BLADE4FWM9000-CMW710-BOOT-E9120.bin......Done.

Decompressing file BLADE4FWM9000-CMW710-SYSTEM-E9120.bin to flash:/BLADE4FWM9000-CMW710-SYSTEM-E9120.bin................................Done.

The images that have passed all examinations will be used as the load software image files for Blade4fw.

Decompression completed.

Do you want to delete flash:/M9000_fw4.ipe now? [Y/N]:N

For more information about the boot-loader command, see H3C SecPath M9000 Multi Service Security Gateway Fundamentals Command Reference.

# To prevent configuration loss at reboot, save the running configuration.

<Sysname> save

# Reboot the device.

<Sysname> reboot

Start to check configuration with next startup configuration file, please wait..

.......DONE!

Current configuration may be lost after the reboot, save current configuration?

[Y/N]:y

Please input the file name(*.cfg)[flash:/startup.cfg]

(To leave the existing filename unchanged, press the enter key):

flash:/startup.cfg exists, overwrite? [Y/N]:y

Validating file. Please wait...

Saved the current configuration to mainboard device successfully.

This command will reboot the device. Continue? [Y/N]:y

Now rebooting, please wait...

Installing patches

This procedure uses the patch image file M9000-CMW710-SYSTEM-E9120.bin.

# Verify the patch status of the device.

<Sysname> display install active

# If the device has patches on any slots, uninstall the patches. (Details not shown.)

# Install the patch image on the MPU.

<Sysname> install activate patch flash:/M9000-CMW710-SYSTEM-E9120.bin slot 0

# For the patches to run after a reboot, commit the installed patches.

<Sysname> install commit

# Verify that the patch image has been installed on all cards except for service modules' security engines.

<Sysname> display install active

Active packages on slot 0:                                                     

  flash:/M9000-CMW710-BOOT-E9120.bin                                           

  flash:/M9000-CMW710-SYSTEM-E9120.bin                                         

Active packages on slot 2:                                                      

  flash:/M9000-CMW710-BOOT-E9120.bin                                           

  flash:/M9000-CMW710-SYSTEM-E9120.bin                                         

Active packages on slot 4:                                                      

  flash:/M9000-CMW710-BOOT-E9120.bin                                           

  flash:/M9000-CMW710-SYSTEM-E9120.bin                                         

Active packages on slot 4.1:                                                    

  sda0:/BLADE4FWM9000-CMW710-BOOT-E9120.bin                                    

  sda0:/BLADE4FWM9000-CMW710-SYSTEM-E9120.bin                                  

Active packages on slot 6:                                                     

  flash:/M9000-CMW710-BOOT-E9120.bin                                           

  flash:/M9000-CMW710-SYSTEM-E9120.bin

Handling software upgrade failures

If a software upgrade fails, the system runs the old software version. To handle a software failure:

1.      Check the physical ports for a loose or incorrect connection, and verify that the LEDs are reflecting the correct port status.

2.      If you are using the console port for file transfer, check the HyperTerminal settings (including the baud rate and data bits) for any incorrect setting.

3.      Check the file transfer settings:

¡  If TFTP is used, you must enter the same server IP addresses, file name, and working directory as those set on the TFTP server.

¡  If FTP is used, you must enter the same FTP server IP address, file name, working directory, and FTP username and password as those set on the FTP server.

4.      Check the FTP or TFTP server for incorrect settings.

5.      Verify that the MPU and service modules have enough storage space for the upgrade file.

6.      Verify that the upgrade file is available for the device and has correct file type.

7.      Verify that the BootWare image and software image are compatible. For more information, see the release notes.