156-551 Sample Questions & Answers

A Virtual Switch (VSW) operates at Layer 2 of the OSI model, just like a physical Ethernet switch. Its purpose is to forward frames between connected interfaces within the same broadcast domain. It does not have the capability to inspect IP headers and make Layer 3 routing decisions. For inter-VLAN or inter-subnet routing, a Virtual Router is required.

In the Expert mode, 'vsenv [ | ]' changes the shell context to the specified Virtual Device (no argument = VS0); the prompt then shows the context, e.g. [Expert@GW:4]#. 'set virtual-system ' is the equivalent in Gaia Clish, not in the Expert shell (R81.10 VSX Admin Guide).

VSLS adds a Backup state to the Active and Standby states. The Standby peer (priority 1) is state-synchronized with the Active peer and can take over without losing connections, but a Backup peer (priority 2 and lower) has only the latest configuration and policy and does not receive state table synchronization until a failover makes it Standby. If the Active and Standby peers fail together, the Backup becomes Active without the connection table, so existing connections are lost. (R81.10 VSX Administration Guide p192-194)

In R81.10 you open the Virtual System object, go to Topology, and in the Interfaces section click New > Regular. Then select the physical interface (eth2) and configure its IP address and topology. Clicking OK pushes the VSX configuration, and then you install the Access Control Policy on the Virtual System. The VSX Gateway object's Physical Interfaces page only lists the physical interfaces and marks VLAN trunks.

A Warp Link is a virtual point-to-point connection between a Virtual System and a Virtual Router or Virtual Switch. The interface on the Virtual System side gets the prefix wrp and the interface on the Virtual Router / Virtual Switch side gets the prefix wrpj, followed by a unique number. When a Virtual System connects to a Virtual Router through a Warp Link, the Virtual Router can route traffic between that Virtual System and other Virtual Systems or a shared (for example, Internet-facing) interface. Warp Links are not used for cluster synchronization and do not connect a Virtual System directly to a physical interface. (R81.10 VSX Administration Guide, Warp Links / Virtual Routers)

Logging destinations can be configured on a per-Virtual System basis. By editing the specific Virtual System object in SmartConsole and navigating to its 'Logs' tab, an administrator can override the global logging settings and direct logs to one or more specific Log Servers. This allows for granular control over log traffic and storage in a multi-tenant environment.

'cpstat vsx -f all' queries the VSX application statistics, whose flavors include stat, traffic, conns, cpu and memory, so it returns per-Virtual-System status, CPU, traffic and connection counters; add '-o ' to refresh it periodically (R81.10 CLI Reference Guide, cpstat). 'vsx stat -v' only shows a summary table (policy, install time, SIC status, connections), 'fw stat -l' shows policy status for one context, and 'top' is not VS-aware.

For a Virtual Router to learn about the networks connected to a Virtual System, the 'Perform route propagation from the Virtual System' option must be enabled in the properties of the Warp Link connecting that VS to the VR. If this is disabled, the VR will not have a route to the destination network behind VS_B and will not be able to forward the traffic. This is a common cause of inter-VS routing failures.

Two statements describe real differences. First, a VSX cluster can run Virtual System Load Sharing (VSLS). VSLS distributes the active Virtual Systems among the cluster members, so different members are active for different Virtual Systems at the same time. From R81.10, VSLS is the only mode for a newly installed VSX cluster. A physical Security Gateway cluster has no Virtual Systems to distribute: its ClusterXL Load Sharing spreads traffic among the members. Second, each Virtual System has its own kernel state tables (active connections, IPsec tunnels), and these tables are synchronized to the peers of that Virtual System on the other cluster members. So synchronization and failover happen for each Virtual System. The other statements are false. Physical ClusterXL clusters also support Load Sharing (Multicast and Unicast modes), not only High Availability. A VSX cluster doesn't have a single virtual IP address: each Virtual Device interface needs its own cluster virtual IP address.

Two statements describe real differences. First, a VSX cluster can run Virtual System Load Sharing (VSLS). VSLS distributes the active Virtual Systems among the cluster members, so different members are active for different Virtual Systems at the same time. From R81.10, VSLS is the only mode for a newly installed VSX cluster. A physical Security Gateway cluster has no Virtual Systems to distribute: its ClusterXL Load Sharing spreads traffic among the members. Second, each Virtual System has its own kernel state tables (active connections, IPsec tunnels), and these tables are synchronized to the peers of that Virtual System on the other cluster members. So synchronization and failover happen for each Virtual System. The other statements are false. Physical ClusterXL clusters also support Load Sharing (Multicast and Unicast modes), not only High Availability. A VSX cluster doesn't have a single virtual IP address: each Virtual Device interface needs its own cluster virtual IP address.

The most definitive way to ensure complete network isolation between Virtual Systems is to avoid any shared internal networking constructs like Virtual Routers or Switches. By assigning dedicated physical interfaces to each Virtual System, all traffic must exit the VSX Gateway physically to be routed. This forces routing decisions to be made by an external, physically separate routing device, providing the strongest possible architectural separation and preventing any possibility of internal traffic leakage due to a misconfiguration within VSX.