< Home

Function Availability for Virtual Systems

This section describes the function availability for virtual systems.

Table 1 describes the function availability for virtual systems.

Table 1 Function availability for virtual systems

Function

Supported or Not

Description

System

Administrators

Supported

-

  

Time

Not supported

-

  

SNMP

Not supported

-

  

Across-Layer-3 MAC Identification

Supported

The SNMP server access interval and timeout period can be set only on the public system, not on virtual systems.

  

Information Push

Supported

-

  

Information Center

Supported

Configure the function in the root system. After the configuration is complete, the configuration takes effect on the virtual systems.

  

File System

Supported

Configure the function in the root system. After the configuration is complete, the configuration takes effect on the virtual systems.

  

Signature Database Update

Supported

Configure the function in the root system. After the configuration is complete, the configuration takes effect on the virtual systems.

  

System Upgrade

Supported

Configure the function in the root system. After the configuration is complete, the configuration takes effect on the virtual systems.

  

Configuration File Management

Supported

Configure the function in the root system. After the configuration is complete, the configuration takes effect on the virtual systems.

  

POE

Not supported

-

  

NetStream

Not supported

-

  

TWAMP Light

Supported

Configure the function in the root system. Bind the TWAMP Light responder test session to the VPN instance with the same name as a virtual system.

  

Flow Probe

Not supported

-

Virtual system log ending

Session log sending

Supported

The device can send session logs of the virtual system to the log hosts of the virtual system and root system. The session-log send-to-public command determines whether to send session logs to the log host of the root system.

When the log function in the security policy of the virtual system is enabled and traffic matches the policy, session logs can be generated in the virtual system. The session log function must be enabled in both the root system and virtual system so that the session logs of the virtual system can be sent to the log host of the root system. For example, to configure the device to send session logs when sessions in the virtual system are created to the log host of the root system, enable the function of sending session logs upon session creation in both the root system and virtual system. When session logs of the virtual system are sent to the log host of the root system, log sending information (including how logs are sent, for example, destination log hosts, source IP address and port used for log sending, whether logs are sent to multiple log hosts, whether logs are encrypted, and log format) depends on the configuration of the root system.

  

Packet discard log sending

Supported

The device can send packet discard logs of the virtual system to the log hosts of the virtual system and root system. The session-log send-to-public command determines whether to send packet discard logs to the log host of the virtual system and root system.

The packet discard log function must be enabled in both the root system and virtual system so that the packet discard logs of the virtual system can be sent to the log host of the root system. When packet discard logs of the virtual system are sent to the log host of the root system, log sending information (including how logs are sent, source IP address and port used for log sending, whether logs are sent to multiple log hosts, whether logs are encrypted, and log format) depends on the configuration of the root system.

  

Service log (dataflow type) sending

Supported

Service logs of the dataflow type can be sent to the log hosts of the virtual system and root system. The session-log send-to-public command determines whether to send service logs to the log host of the root system.

  

Service log (syslog type) sending

Supported

Service logs of the syslog type can be sent to the log hosts of the virtual system and root system. The info-center loghost vsys-to-public enable command determines whether to send service logs to the log host of the root system.

  

System log sending

Supported

System logs, including administrator login/logout logs and command operation logs, can be sent only to the log host of the root system. The log host is configured in the root system using the info-center loghost command.

  

Port range log sending

Supported

Port range logs can be sent only to the log host of the root system. In the virtual system, configure a NAT address pool and NAT policy; in the root system, enable the logging function and configure a log host.

High Availability

Hot Standby

Supported

Configure the function in the root system. After the configuration is complete, the configuration takes effect on the virtual systems.

Hot standby can be configured on two physical devices, but not on two virtual systems. For example, if an interface in the virtual system of the active device is Down, the standby device will take over all services.

  

Link-group

Supported

-

  

IP-Link

Supported

-

  

Interworking Between Hot Standby and IP-Link

Supported

-

  

BFD

Not supported

-

Networks

Interfaces

Supported

-

  

Security Zones

Supported

-

  

DNS

Not supported

-

  

DHCP

Supported

-

  

DHCPv6

Not supported

-

  

PPP

Not supported

-

  

PPPoE

Not supported

-

  

802.1x

Not supported

-

Intelligent Uplink Selection

Global Route Selection Policies

Not supported

-

  

ISP Link Selection

Not supported

-

  

PBR

Supported

Only PBR with a single outbound interface is supported.

The virtual system supports the IPv4 and IPv6 PBR.

Router

IPv4 Static Route

Supported

-

  

IPv6 Static Route

Supported

The ipv6 route-static vpn-instance command can be used in the root system to specify a static route for a virtual system.

  

ISP Route

Not supported

-

  

RIP

Supported

In the root system, bind the RIP process to the VPN instance with the same name as a virtual system.

  

RIPng

Supported

In the root system, bind the RIPng process to the VPN instance with the same name as a virtual system.

  

OSPF

Supported

In the root system, bind the OSPF process to the VPN instance with the same name as a virtual system.

  

OSPFv3

Supported

In the root system, bind the OSPFv3 process to the VPN instance with the same name as a virtual system.

  

IS-IS

Supported

In the root system, bind the IS-IS process to the VPN instance with the same name as a virtual system.

  

IPv6 IS-IS

Supported

In the root system, bind the IS-IS process to the VPN instance with the same name as a virtual system.

  

BGP

Supported

In the root system, bind the BGP IPv4 address family to the VPN instance with the same name as a virtual system.

  

BGP4+

Supported

In the root system, bind the BGP IPv6 address family to the VPN instance with the same name as a virtual system.

Object

User

Supported

SSO functions and user-defined portal authentication are not supported.

  

Address and Address Group

Supported

The virtual system supports the IPv4 and IPv6 addresses and address groups.

  

Domain Group

Supported

-

  

Region and Region Group

Supported

-

  

Service and Service Group

Supported

The virtual system supports the IPv4 and IPv6 services and service groups.

  

Application and Application Group

Supported

-

  

Devices and Device Groups

Not supported

-

  

Certificate

Supported

-

  

Schedule

Supported

-

  

Tag

Supported

-

  

IPv4 ACL

Supported

-

  

IPv6 ACL

Supported

-

  

Health Check

Supported

-

Policy

Security Policy and Security Profile

Supported

  • Spam filtering is not supported.
  • URL category server can not be configured on virtual systems.

In virtual systems, security policies and content security check apply to both IPv4 and IPv6 traffic.

  

Policy Redundancy Analysis

Not supported

-

  

Policy Matching Analysis

Not supported

-

  

Application Policy Tuning

Not supported

-

  

Authentication Policy

Supported

In virtual systems, only IPv4 users can be authenticated.

  

Audit Policy and Audit Profile

Supported

In virtual systems, only IPv4 traffic can be audited.

  

NAT Policy

Supported

-

  

Server load balancing

Supported

-

  

Bandwidth Management Policy

Supported

In virtual systems, bandwidth management applies to both IPv4 and IPv6 traffic.

  

Quota Control Policy

Supported

In virtual systems, quota control applies only to IPv4 users.

Proxy Policy

Supported

-

SSL-Encrypted Traffic Detection

Supported

-

VPN

IPSec

Supported

-

  

L2TP

Supported

-

  

GRE

Supported

The function can be configured based on VPN instances.

  

BGP/MPLS IP VPN

Supported

The function can be configured based on VPN instances.

  

SSL VPN

Supported

-

CGN

NAT444

Supported

-

  

PCP

Supported

-

  

Static Mapping

Supported

-

  

Port Pre-allocation and Incremental Allocation

Supported

-

  

NAT64

Supported

-

  

DS-Lite

Not supported

-

Security Protection

Attack Defense

Supported

-

  

Blacklist

Supported

-

  

Whitelist

Supported

-

  

IP-MAC Binding

Supported

-

  

IPv4 ASPF

Supported

-

  

IPv6 ASPF

Supported

-

  

IDS Interworking

Not supported

-

  

HiSec Insight interworking

Not supported

-

  

Web Reputation

Not supported

-

  

IP Reputation

Supported

-

  

Ping Proxy

Supported

-

  

Network Deception-DecoySensor

Supported

The deception decoy command that sets the IP address of a Decoy can be used only in the public system.

  

Network Deception-Decoy

Not supported

-

IP Multicast

Multicast and multicast NAT

Not supported

-

Monitoring

Logs and Reports

Supported

-

  

Session Table

Supported

-

  

Server Map

Supported

-

  

System Statistics

Not supported

-

  

5-Tuple Packet Capture

Supported

The 5-tuple packet capture functions of the virtual system and root system differ as follows:

  • In the root system, the captured packet data is permanently stored in the memory, unless you run the reset packet-capture queue command to manually delete the data.

    In the virtual system, the captured packet data is directly stored in the CF card as a .txt file for only 30 minutes. Afterwards, the data is automatically deleted.

  • In the root system, the packet-capture queue queue-id to-file file-name command exports the data in the memory as a .cap file and saves the file in the CF card.

    In the virtual system, the packet-capture queue queue-id to-file file-name command converts the .txt file that stores the captured packet data to a .cap file and saves the file in the CF card.

  • The root system has four packet capture queues, and each virtual system has two packet capture queues.

    The packet capture queue stores the captured packet data. In the root system, the packet capture queue is a block in the memory. In the virtual system, the packet capture queue is a .txt file that stores the captured packet data.

  

Collect 5-Tuple Packet Discarding Statistics

Not supported

-

  

Diagnosis Center

Supported

-

Maintenance

Port Mirroring, System Restart, NTP, LLDP, and NQA

Not supported

-

Copyright © Huawei Technologies Co., Ltd.
Copyright © Huawei Technologies Co., Ltd.
< Previous topic Next topic >