Test Case #2 Results

Test Case #2 was performed successfully, with no issues. The Brocade VCS fabric interoperates with the Network File System (NFS) Protocol using Red Hat Enterprise Linux NFS server.

This validation demonstrates that existing deployments using NFS will interoperate with Brocade VCS fabrics and exhibit resiliency to input/output (I/O) between clients and servers in a non-disruptive manner.

This is a summary of the tests conducted for Test Case #2.

1. Test 1 validated that baseline I/O is using the shortest equal-cost paths in the fabric. NFS clients on RB3 and RB4 will access the Linux NFS server on the active vLAG interface on RB1.

2. Test 2 validated that I/O flows are not impacted between the NFS clients emulated by Spirent Avalanche and Red Hat Enterprise Linux NFS server while introducing a link failure on one link in the Brocade trunk, which is an active shortest path in the fabric.

3. Test 4 validated that I/O flows are not impacted between the NFS clients emulated by Spirent

Avalanche and Red Hat Enterprise Linux NFS server while introducing a switch failure in the active path of the Brocade VCS fabric.

This summarizes the test results for Test Case #2.

Test Description Results

1 Baseline of shortest paths and traffic distribution in the Brocade VCS fabric

Pass

2 Perform link failure within a Brocade ISL trunk Pass

3 Perform multiple switch failures within the Brocade VCS fabric Pass

3.2 Topology

Figure 7. Red Hat Enterprise Linux NFS server validation topology and components for Test Case #2.

3.3 Hardware Resources

The following equipment was used in this configuration:

Description Quantity Revisions

Brocade VDX 6720-24 3 Brocade NOS 2.1.1 Brocade VDX 6730-32 1 Brocade NOS 2.1.1

Linux NFS Server 1 Red Hat Enterprise Linux Server Release 5.2 (Tikanga)

Spirent Avalanche 1 3.6.0

3.4 Compute Resources

The following equipment was used in this configuration:

Description Quantity Revisions

Linux NFS Server 1 HP Proliant DL380G5p 320 GB HD 4 GB RAM & 1020 CNA

3.5 Software Resources

The following software was used in this configuration:

Description Revision

Brocade NOS Brocade NOS 2.1.1

Linux NFS Server Red Hat Enterprise Linux Server release 5.2 (Tikanga)

3.6 Test 1: I/O Verification

The purpose of test 1 is to validate baseline I/O is using the shortest equal-cost paths in the fabric. NFS clients on RB3 and RB4 will access the Linux NFS server on the active vLAG interface on RB1.

Figure 8. Red Hat Enterprise Linux NFS server validation topology for test 1.

3.6.1 Test Procedure

Step 1: Execute the following command on all Brocade VDX ISLs and VDX vLAG interfaces to confirm traffic flow and that the I/O path is distributed as expected.

The following is an example:

VDX6730-RB3# show in te 3/0/24 | in rate

Step 2: Run Spirent Test Center, which emulates the NFS clients on RB3/RB2.

3.6.2 Expected Results

The expected results for test 1 is that all I/Os from each of the NFS clients on RB3 and RB4 will be spread evenly across the Brocade trunks going into RB1, where the active vLAG on the server is located.

3.6.3 Actual Results

The actual results for test 1 confirm that all I/Os from each of the NFS clients on RB3 and RB4 are spread evenly across the Brocade trunks going into RB1, where the active vLAG on the server is located.

The total bandwidth from the 95 Spirent clients on RB3 (3/0/24) and RB4 (4/0/24) are received on the Egress port going to the NFS server (1/0/23).

3.7 Test 2: Link Failure

The purpose of test 2 is to validate that I/O flows are not impacted between the NFS clients emulated by Spirent Avalanche and Red Hat Enterprise Linux NFS server while introducing a link failure on one link in the Brocade trunk, which is an active shortest path in the fabric. The links that are failed as part of this test are highlighted below in red.

Figure 9. Red Hat Enterprise Linux NFS server validation topology for test 2.

The NFS clients on RB3 and RB4 continue to access the Red Hat Enterprise Linux NFS server on the active vLAG interface on RB1.

3.7.1 Test Procedure

Step 1: Execute the following command on the desired Brocade VDX switches to validate baseline traffic prior to failure. The following is an example:

VDX6730-RB3# show in te 3/0/1 | in rate

VDX6730-RB3# show in te 3/0/2 | in rate

Step 2: Run Spirent Avalanche for the duration of the test to emulate the NFS clients.

Step 3: Now that active traffic on both Brocade ISLs is confirmed, an ISL in the trunk is failed. In this example, Interface TenGigE3/0/1 on RB3 is failed, which is one of the active ISLs in the trunk between RB3 and RB1.

VDX6730-RB3# conf t

Entering configuration mode terminal VDX6730-RB3(config)# in te 3/0/1 VDX6730-RB3(conf-if-te-3/0/1)# shut

Step 4: Execute the following command on the desired Brocade VDX switches to observe traffic levels after interface failure. The following is an example:

VDX6730-RB3# show in te 3/0/1 | in rate

VDX6730-RB3# show in te 3/0/2 | in rate

Step 5: Execute the following command on the desired Brocade VDX switches to re-enable the failed ISL between RB3 and RB1.

VDX6730-RB3# conf t

Entering configuration mode terminal VDX6730-RB3(config)# in te 3/0/1 VDX6730-RB3(conf-if-te-3/0/1)# no shut

Step 6: Execute the following command on the desired Brocade VDX switches to observe traffic levels after interface re-enabling. The following is an example:

VDX6730-RB3# show in te 3/0/1 | in rate

VDX6730-RB3# show in te 3/0/2 | in rate

Repeat Steps 1–6: Steps 1–6 were also performed for the other Brocade ISLs, highlighted in red under section 3.5.1.

3.7.2 Expected Results

The expected results for test 2 are to confirm that distributed I/O is not impacted while failing an active Brocade member ISL within the fabric.

The NFS clients on RB3 and RB4 continue to access the Red Hat Enterprise Linux NFS server on the active vLAG interface on RB1.

All I/Os from each of the NFS clients on RB3 and RB4 fail over to the remaining link on the Brocade trunk that goes into RB1, where the active vLAG on the server is located. The total bandwidth from the clients on RB3 (3/0/24) and RB4 (4/0/24) are received on the Egress port going to the NFS server (1/0/23). There should be no loss in I/O, with the exception of “in-flight” frames during the failure of the link. When the links in the trunk are re-enabled, the I/Os should be evenly redistributed to all of the active links in the trunk.

The same results should be observed between other Brocade ISL trunk link failures in the fabric. These failures were performed for the other Brocade ISLs highlighted in red under section 3.5.1.

3.7.3 Actual Results

The actual results for test 2 confirm that distributed I/O is not impacted while failing an active Brocade member ISL within the fabric.

During the link failure in the Brocade trunk while I/O was evenly distributed between the two 10 GbE links on the 20 GbE trunk; all I/O was immediately switched to the remaining 10 GbE link. When the link was re-enabled, all I/O was immediately rebalanced between both links again.

The same results were observed between other Brocade ISL trunk link failures in the fabric. These failures were performed for the other Brocade ISLs highlighted in red under section 3.5.1.

Again, there was no disruption of I/O from the perspective of the Windows VM/NFS client.

All I/Os from each of the NFS clients on RB3 and RB4 fail over to the remaining link on the Brocade trunk that goes into RB1, where the active vLAG on the server is located. The total bandwidth from the clients on RB3 (3/0/24) and RB4 (4/0/24) are received on the Egress port going to the NFS server (1/0/23).

When the links in the trunk are re-enabled, the I/O is evenly redistributed to all of the active links in the trunk.

It appears that there was a loss of “in-flight” NFS frames during the failure, as highlighted in the output below.