Riverbed 830-01 RCPE Certified Professional WAN Optimization Exam Practice Test

No data is sent across this connection

Yes, only after 60 seconds

Yes, when the peer Steelhead appliance requests information

Yes, when the connection is setup

Yes, every 30 seconds

Yes, every 30 minutes

Traffic will be interrupted

The Steelhead stops the interception of new connections for optimization for as long as it is in admission control

This is just a report and the Steelhead will continue to optimize traffic

The Steelhead will start optimizing faster any new connections

The Steelhead will shut down in less than a minute

Port 7800 is being blocked between the Steelhead Mobile Controller and the Steelhead appliance

Port 7810 is being blocked between the Steelhead Mobile client and the Steelhead appliance

Port 7801 is being blocked between the Steelhead Mobile client and the Windows TCP Stack

Port 7850 is being blocked between the Steelhead Mobile Controller and the Steelhead appliance

Port 7801 is being blocked between the Steelhead Mobile Controller and the Steelhead appliance

Remove the upgrade license and restart the virtual Steelhead appliance

Reinstall the original model license

Reduce the amount of CPU and RAM allocated to the Virtual Steelhead appliance and it will automatically downgrade at the next startup

It is not possible to downgrade after an upgrade

Connection counts

Total packets in and out

Bytes and packets redirected to each neighbor Steelhead appliance

Scalable Data Referencing (SDR) Status

Nortel VPN

Cisco VPN client

Check Point

OpenVPN

Riverbed VPN client

When upgrading a Virtual Steelhead appliance, it is not possible to preserve the existing datastore

Detach the existing datastore and re-attach to the new Virtual Steelhead appliance

Run vMotion and move the datastore to a different ESX host before performing the upgrade and then bring it back afterwards

Move the existing datastore to an NFS share and move it back after the upgrade

7800 outbound, 7801 inbound, 7870 outbound

7800 inbound, 7870 inbound, 7870 outbound

7800 inbound, 7801 outbound, 7870 outbound

None of the above

When no user defined Load Balancing rules matches AND peer neighbors are defined

When no user defined Load Balancing rules matches AND no peer neighbors are defined

When no peer Interceptor appliances are defined

When a user-defined Load Balancing rule matches AND a target Steelhead appliance is available

Enable the “no in-path accept new” CLI command

Create an in-path rule on the Steelhead appliance to bypass the connections

On the Interceptor appliance, click on “Pause” for that particular Steelhead appliance

Schedule a job on the Steelhead appliance to remove itself from the cluster

All of the above

In-path

Out-of-path

Logical in-path

Physical in-path Hybrid Mode

Source Port

Source IP Subnet

Destination IP Subnet

Destination Port

VLAN ID

Using profiles

Using multiple Steelhead Mobile Controllers

Using Group IDs

Using policies

Organization of groups

Configuring individual Steelhead Mobile client users with different license groups

Configuration of fixed-target rule groups

Configuration of pass-through rule groups

All of the above

verify interceptor deployment

service verify

debug validate deployment

config checker

SSH over Primary interface IP

SSH over AUX interface IP

SSH over in-path interface IP

Serial cable connection

Password recovery can not be done on a Steelhead appliance

Microsoft Silverlight.

Adobe HTTP Dynamic Streaming.

Youtube.com video.

Adobe Flash.

The connection is forwarded for auto-discovery.

The connection is passed-through.

The connection is rejected.

The connection is reset.

2

1, 2

2, 3

2, 4

2, 4, 5

no in-path enable

restart clean

reload

no service enable

no interface in-path0_0 enable

Set IP next-hop address to the virtual IP address of the Steelhead appliance cluster

Set IP next-hop addresses for each Steelhead appliance

Check the state level information on each Steelhead appliance via SLA or CDP

Auto-detect the Steelhead appliance clustering protocol

Check the state level information on the virtual IP address of the Steelhead appliance cluster

In-path fixed-target rule on site B Steelhead appliance pointing to Site A Steelhead appliance

Peering rule on site B Steelhead appliance passing through probes from site C

Peering rule on site B Steelhead appliance passing through probe responses from site A

Both A and C

Both B and C

For each load-balancing rule, including the default rule.

For each load-balancing rule, excluding the default rule.

Only for the default rule.

For each load-balancing rule and in-path rule

For each load-balancing rule, in-path rule, including the default rule.

Set the WCCP weight of SH10 to be higher than that of SH11

Use fixed-target rules explicitly at SH12 to peer to SH10

Enable destination IP hash and destination port hash

Enable destination IP hash and source port hash

Enable destination IP hash and source IP hash

Enable Connection Forwarding

Default , RiOS SDR- L, RiOS SDR-M

Default , RiOS DSR- Adaptive, RiOS DSR-M

Default , RiOS SDR- Adaptive, RiOS SDR-M

Default , RiOS SDR- Adaptive, RiOS SDR-L

RiOS SDR- Adaptive, RiOS SDR-L, RiOS DSR-M

optimize TCP IPv6

optimize UDP IPv6

optimize UDP IPv4

optimize TCP IPv4

From the GUI, under Connections, select the connection and click on the Reset button

From the GUI, under Connections, select the connection and click on the Drop button

From the CLI: tcp connection send reset local-only local-addr 192.168.5.10:9999 remote-addr 192.168.5.90:80

From the CLI: tcp connection send reset remote-only local-addr 192.168.5.10 local-port 7800 remote-addr 192.168.5.90 remote-port 80

From CLI: tcp reset user 192.168.5.10

1 second

3 seconds

5 seconds

10 seconds

15 seconds

Issue the clear affinity command

Restart the service

Clear the fair peering flag

Pause the Interceptor

Physical in-path and WCCP

Physical/virtual in-path and server-side out-of-path

Physical/virtual in-path and PBR

A and B

A, B, and C

Use the Steelhead in an out-of-path deployment using fixed-target rules in the Steelhead appliance

Use the Steelhead in a hybrid in-path/out-of-path deployment using fixed-target rules in the Steelhead Mobile client

Put the Steelhead appliance in-path on the VPN concentrator segment using a multi-port NIC

Install the Steelhead Mobile Controller on the VPN segment

tcpdump –p lan0_0 –S 300 –w lancap.cap

tcpdump –i lan0_0 –s 300 –w lancap.cap

tcpdump –i lan0_0

tcpdump –I lan0_0 –s 300

tcpdump –i lan0_0 -3 300 –r lancap.cap

service = rbt-exec {local-user-name = "monitor"}

service = wan-accel {local-user-name = "monitor"}

service = rbt-exec {local-user-name = "admin"}

service = wan-accel {local-user-name = "admin"}

service = rbt-exec {local-user-name = "su"}

Optimized, Pass-through, Blocked

Interactive, RBT-Proto, Secure

RBT-Proto, Enabled, Disabled

Named differently from those on the Steelhead appliance

Port labels do not exist on an Interceptor appliance

In-path interface

AUX interface

WAN interface

Primary interface

LAN interface

Email

RADIUS

SNMP traps

Syslog

View Logs

Current Connections

Alarm Status

Interface Statistics

Monitored Ports

Default login used by the CMC appliance for each appliance

Last hour of throughput across all managed appliances

Status of each individual alarm for each managed Steelhead appliance

Last 20 lines of a Steelhead appliance's system log file

Lost Opportunistic Lock

SMB Signing

Fixed-target rule is needed

Asymmetric Route

Packet Ricochet

Create new peering rule(s) on your Steelhead appliances

Create new in-path rule(s) on your Steelhead appliance

Create IPSec tunnels between all of your Steelhead appliances

Reload all of your Steelhead appliances

Reload only the data center Steelhead appliance

Incorrect in-path rules at the data-center

Incorrect in-path rules at the new branch office

Duplex mismatch between the new branch Steelhead and a connected device

Duplex mismatch between the data-center Steelhead and a connected device

Incorrect peering rules at the data-center

Incorrect peering rules at the new branch office

They are text file snapshots of the current running configuration taken at 3 a.m. (by default)

The CMC appliance creates hyperlinks of the backups for easy viewing with a Web browser

The configurations can be copied from the CMC appliance back to the Steelhead appliance via SCP

There is a limit of five configurations per Steelhead appliance that can be stored at any one time in a rolling queue

The Steelhead configuration files can be edited on the CMC appliance

I_SEE_YOU

HERE_I_AM

REMOVAL_QUERY

REMOVAL_ACK

When the Steelhead appliance in Corp-B opens the outer connection, it is using the source IP of 172.16.2.x instead of 192.168.1.x

On the Steelhead appliance in Corp-B, there is a missing static route for the 192.168.1.0/25 network

On the Steelhead appliance in Corp-A, there is a missing static route for the 172.16.2.0/24 network

When the Steelhead appliance in Corp-B opens the outer connection, it is using the source IP of 192.168.1.x instead of 172.16.1.x

None of the above

Riverbed recommends you turn off URL Learning and Parse-and-Prefetch and only enable OPT

Riverbed recommends you enable URL Learning and Parse-and-Prefetch and turn off OPT

Riverbed recommends you turn off URL Learning and only enable Parse-and-Prefetch and OPT

Riverbed recommends you turn off URL Learning, Parse-and-Prefetch, and OPT

Riverbed recommends you enable URL Learning, Parse-and-Prefetch, and OPT

The Steelhead appliance is only receiving HTTP traffic from the router.

All traffic will be sent from the router to the Steelhead appliance.

The Steelhead appliance will not receive HTTP traffic from the router.

There is no need to use access-lists on the router to select HTTP traffic.

The Steelhead appliance is only receiving traffic on port TCP 1741.

Physical In-path (with Riverbed bypass NIC)

Virtual In-path

Out-of-path

Server-side Out-of-Path

All of the above

132.245.24.82

172.16.38.222

Not enough information. You would need the output of show service cloud geodns

132.245.92.226

Problem: Max BW % on the default class. Fix: increase Min BW %

Problem: Max BW % on the default class. Fix: increase Max BW %

Problem: Max BW % on the default class. Fix: disable QOS

Problem: Min BW % on the default class. Fix: increase Min BW %

Domain Controllers should not be used for file sharing as they are always slower than domain member servers.

The server-side SteelHead should be joined to the domain in Workstation mode, enable CIFS SMB Signing and Transparent Mode.

Both the client-side and server-side SteelHeads should be joined to the domain in Active Directory Integrated mode.

The client-side SteelHead should be joined to the domain in Workstation mode, enable CIFS SMB Signing and Transparent Mode.

The server-side SteelHead should be joined to the domain in Active Directory Integrated mode, enable CIFS SMB Signing and Transparent Mode.

The connection to Server 2 is optimized. The performance should be good.

The connection to Server 2 is optimized, with errors, the performance should be poor.

The connection to Server 1 is optimized. The performance should be good.

The connection to Server 1 is optimized, with errors, the performance should be poor.

The connection to Server 1 is not being optimized.

The connection from client 172.16.12.99 to server 172.19.88 was optimized by Steelhead appliance 172.16.10.101.

The connection from client 172.16.19.88 to server 172.16.12.99 was optimized by Steelhead appliance 172.16.10.101.

The connection was not optimized because of the GRE tunnel.

The connection was optimized because of the GRE tunnel.

1

100

200

No configuration is necessary as LAN and WAN interfaces are on access ports

It will require an in-path interface for each VLAN

(ip[40:4] = and ip[44:4] = )

(host and host )

(proto gre and ((ip[40:4] = and ip[44:4] = )

(host and host )

These users make use of NTLM authentication.

These users exclusively make use of Kerberos authentication.

Overlapping open is enabled.

SMB signing is required.

They are different Steelhead appliances models.

One of the Steelhead appliances currently has a lower number of TCP connections available.

The weight setting is being used on the WCCP configuration.

One of the Steelhead appliances is in admission control.

This connection started on USER1 and is being optimized between SH11 and SH12.

This connection started on USER1 and is being optimized between Steelhead Mobile Client on USER1 and SH11.

This connection started on USER1 and is being optimized between Steelhead Mobile Client on USER1 and SH12.

This connection will show as "passtrough" on SH12.

This connection will not appear on SH12.

The connection will be unsigned but allowed. The SteelHead does not need to have SMB signing enabled to accommodate this connection.

The connection will not be allowed, as signing is enabled on the client and disabled on the server.

The connection will be allowed and will be signed as the client determines whether SMB signing is used or not.

The connection will be allowed, and will be signed between the client and client-side SteelHead.

You cannot perform GRE encapsulation on packets which have the DF flag set.

The additional 24-byte overhead used by GRE encapsulation has pushed the packets over the MTU size.

GRE encapsulation has hidden the original IP header so the DF flag is no longer seen by the router and therefore it cannot forward the packet.

Having the DF flag set results in the Steelhead being unable to use the TCP flow to monitor the path state, and the path selection rules is set to ‘drop’ if the path is down.

There must be a resilient path between the SteelHeads to prevent a split brain situation.

The in-path IP addresses must be reachable from each other and connected physically in-path.

The SteelHeads must be the same model and run the same RiOS version.

The master must be the same or larger data store than the backup.

The SteelHeads must be in a serial cluster arrangement.