HP Brocade 8/12c Brocade Fabric OS Troubleshooting and Diagnostics Guide v6.2. - Page 93

FCIP links

Page 93 highlights

10 FCIP links Symptom FCIP tunnel goes online and offline. Probable cause and recommended action A bouncing tunnel is one of the most common problems. This issue is usually because of an over commitment of available bandwidth (trying to push 1 Gbps through a pipe that can only sustain 0.5 Gbps). • Too much data tries to go over the link. • Management data gets lost, queued too long, and timeouts expire. • Data exceeds timeouts multiple times. • Verify what link bandwidth is available. • Confirm the IP path is being used exclusively for FCIP traffic. • Confirm that traffic shaping is configured to limit the bandwidth to available (portshow fciptunnel). 1. If committing a rate, generally recommend setting a little below available to allow for bursting 2. Type the portShow fciptunnel all -perf -params command. Examine data from both routers. This data is not in the supportshow output and shows retransmissions indicating, input and output rates on the tunnels. Gather this information for both data and management TCP connections. 3. Run the following commands on both sides of the tunnel: • portCmd --ipperf -s -d -R • portCmd --ipperf -s -d -S 4. Confirm the throughput using the portCmd --ipperf command. This command must be run on both sides of the tunnel, simultaneously. Let IPPERF run for at least 3 minutes in both directions. The last 30 second output will include good recommended committed rates for the tunnel in that direction from the -S side. If necessary, issue the portCfg fcipTunnel slot/geX modify -b NEWRATE command to reset the committed rate for the tunnel to the discovered reliable maximum from IPPERF. On local side: portcmd --ipperf -s -d -R On Remote side: portcmd --ipperf -s -d -S 5. Repeat each step in the opposite direction to get throughput FCIP links The following list contains information for troubleshooting FCIP links: • When deleting FCIP links, you must delete them in the exact reverse order they were created. That is, first delete the tunnels, then the IP interfaces, and finally the port configuration. The IP route information is removed automatically at this point. Fabric OS Troubleshooting and Diagnostics Guide 77 53-1001187-01

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144

Fabric OS Troubleshooting and Diagnostics Guide
77
53-1001187-01
FCIP links
10
Symptom
FCIP tunnel goes online and offline.
Probable cause and recommended action
A bouncing tunnel is one of the most common problems. This issue is usually because of an over
commitment of available bandwidth (trying to push 1 Gbps through a pipe that can only sustain 0.5
Gbps).
Too much data tries to go over the link.
Management data gets lost, queued too long, and timeouts expire.
Data exceeds timeouts multiple times.
Verify what link bandwidth is available.
Confirm the IP path is being used exclusively for FCIP traffic.
Confirm that traffic shaping is configured to limit the bandwidth to available (portshow
fciptunnel).
1.
If committing a rate, generally recommend setting a little below available to allow for bursting
2.
Type the
portShow fciptunnel <GePort> all -perf –params
command.
Examine data from both routers. This data is not in the supportshow output and shows
retransmissions indicating, input and output rates on the tunnels.
Gather this information for both data and management TCP connections.
3.
Run the following commands on both sides of the tunnel:
portCmd
--
ipperf <slot/GePort> -s <local IP> -d <remote IP> -R
portCmd
--
ipperf <slot/GePort> -s <local IP> -d <remote IP> -S
4.
Confirm the throughput using the
portCmd
--
ipperf
command. This command must be run on
both sides of the tunnel, simultaneously.
Let IPPERF run for at least 3 minutes in both directions. The last 30 second output will include
good recommended committed rates for the tunnel in that direction from the -S side.
If necessary, issue the
portCfg fcipTunnel slot/geX modify <tunnel> -b NEWRATE
command to
reset the committed rate for the tunnel to the discovered reliable maximum from IPPERF.
On local side:
portcmd --ipperf <slot/GBPort> -s <local IP> -d <remote IP> -R
On Remote side:
portcmd --ipperf <slot/GBPort> -s <local IP> -d <remote IP> -S
5.
Repeat each step in the opposite direction to get throughput
FCIP links
The following list contains information for troubleshooting FCIP links:
When deleting FCIP links, you must delete them in the exact reverse order they were created.
That is, first delete the tunnels, then the IP interfaces, and finally the port configuration. The IP
route information is removed automatically at this point.