Dell Broadcom NetXtreme Family of Adapters Broadcom NetXtreme 57XX User Guide - Page 8

SLB Auto-Fallback Disable, Limitations of Smart Load Balancing and Failover/SLB Auto-Fallback

Get Dell Broadcom NetXtreme Family of Adapters PDF manuals and user guides View all Dell Broadcom NetXtreme Family of Adapters manuals
Add to My Manuals
Save this manual to your list of manuals

Page 8 highlights

approach is much simpler, in that there is not a formalized link aggregation control protocol (LACP). As with the other types of teams, the creation of teams and the allocation of physical adapters to various teams is done statically through user configuration software. The Generic Trunking (FEC/GEC/802.3ad-Draft Static) type of team supports load balancing and failover for both outbound and inbound traffic. SLB (Auto-Fallback Disable) The SLB (Auto-Fallback Disable) type of team is identical to the Smart Load Balancing and Failover type of team, with the following exception-when the standby member is active, if a primary member comes back on line, the team continues using the standby member, rather than switching back to the primary member. If any primary adapter assigned to a team is disabled, the team functions as a Smart Load Balancing and Failover type of team in which auto-fallback occurs. All primary interfaces in a team participate in load-balancing operations by sending and receiving a portion of the total traffic. Standby interfaces take over in the event that all primary interfaces have lost their links. Failover teaming provides redundant adapter operation (fault tolerance) in the event that a network connection fails. If the primary adapter in a team is disconnected because of failure of the adapter, cable, or switch port, the secondary team member becomes active, redirecting both inbound and outbound traffic originally assigned to the primary adapter. Sessions will be maintained, causing no impact to the user. Limitations of Smart Load Balancing and Failover/SLB (Auto-Fallback Disable) Types of Teams Smart Load Balancing™ (SLB) is a protocol-specific scheme. The level of support for IP, IPX, and NetBEUI protocols is listed below. Table 2. Smart Load Balancing Operating System Failover/Fallback-All Broadcom Failover/Fallback-Multivendor Protocol IP Windows Server 2003 Y Windows Server 2008 Y NetWare 5.1/6.5 Y Red Hat Linux 4 Y IPX Y Y Y N/S NetBEUI N/S N/S N/S N/S IP IPX Y N Y N Y N Y N/S NetBEUI N/S N/S N/S N/S Operating System Load Balance-All Broadcom Load Balance-Multivendor Protocol IP Windows Server 2003 Y Windows Server 2008 Y NetWare 5.1/6.5 Y Red Hat Linux 4 Y IPX Y Y Y N/S NetBEUI N/S N/S N/S N/S IP IPX Y N Y N Y Y Y N/S NetBEUI N/S N/S N/S N/S Legend: Y = yes N = no N/S = not supported Drivers for third-party network adapters must be NetWare Event Service Layer (NESL) compliant for NetWare to be faulttolerant and load-balanced in a multivendor team. The Smart Load Balancing type of team works with all Ethernet switches without having to configure the switch ports to any special trunking mode. Only IP traffic is load-balanced in both inbound and outbound directions. IPX traffic is load-balanced in the outbound direction only. Other protocol packets are sent and received through one primary interface only. Failover for non-IP traffic is supported only for Broadcom network adapters. The Generic Trunking type of team requires the Ethernet switch to support some form of port trunking mode (for example, Cisco's Gigabit EtherChannel or other switch vendor's Link Aggregation mode). The Generic Trunking type of team is protocol-independent, and all traffic should be load-balanced and fault - tolerant.

  • 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
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
approach is much simpler, in that there is not a formalized link aggregation control protocol (LACP). As with the other types of
teams, the creation of teams and the allocation of physical adapters to various teams is done statically through user
configuration software.
The Generic Trunking (FEC/GEC/802.3ad-Draft Static) type of team supports load balancing and failover for both outbound
and inbound traffic.
SLB (Auto-Fallback Disable)
The SLB (Auto-Fallback Disable) type of team is identical to the Smart Load Balancing and Failover type of team, with the
following exception—when the standby member is active, if a primary member comes back on line, the team continues using
the standby member, rather than switching back to the primary member.
If any primary adapter assigned to a team is disabled, the team functions as a Smart Load Balancing and Failover type of
team in which auto-fallback occurs.
All primary interfaces in a team participate in load-balancing operations by sending and receiving a portion of the total traffic.
Standby interfaces take over in the event that all primary interfaces have lost their links.
Failover teaming provides redundant adapter operation (fault tolerance) in the event that a network connection fails. If the
primary adapter in a team is disconnected because of failure of the adapter, cable, or switch port, the secondary team
member becomes active, redirecting both inbound and outbound traffic originally assigned to the primary adapter. Sessions
will be maintained, causing no impact to the user.
Limitations of Smart Load Balancing and Failover/SLB (Auto-Fallback Disable) Types of Teams
Smart Load Balancing™ (SLB) is a protocol-specific scheme. The level of support for IP, IPX, and NetBEUI protocols is listed
below.
Table 2. Smart Load Balancing
Operating System
Failover/Fallback—All Broadcom
Failover/Fallback—Multivendor
Protocol
IP
IPX
NetBEUI
IP
IPX
NetBEUI
Windows Server 2003
Y
Y
N/S
Y
N
N/S
Windows Server 2008
Y
Y
N/S
Y
N
N/S
NetWare 5.1/6.5
Y
Y
N/S
Y
N
N/S
Red Hat Linux 4
Y
N/S
N/S
Y
N/S
N/S
Operating System
Load Balance—All Broadcom
Load Balance—Multivendor
Protocol
IP
IPX
NetBEUI
IP
IPX
NetBEUI
Windows Server 2003
Y
Y
N/S
Y
N
N/S
Windows Server 2008
Y
Y
N/S
Y
N
N/S
NetWare 5.1/6.5
Y
Y
N/S
Y
Y
N/S
Red Hat Linux 4
Y
N/S
N/S
Y
N/S
N/S
Legend:
Y = yes
N = no
N/S = not supported
Drivers for third-party network adapters must be NetWare Event Service Layer (NESL) compliant for NetWare to be fault-
tolerant and load-balanced in a multivendor team.
The Smart Load Balancing type of team works with all Ethernet switches without having to configure the switch ports to any
special trunking mode. Only IP traffic is load-balanced in both inbound and outbound directions. IPX traffic is load-balanced in
the outbound direction only. Other protocol packets are sent and received through one primary interface only. Failover for
non-IP traffic is supported only for Broadcom network adapters. The Generic Trunking type of team requires the Ethernet
switch to support some form of port trunking mode (for example, Cisco's Gigabit EtherChannel or other switch vendor's Link
Aggregation mode). The Generic Trunking type of team is protocol-independent, and all traffic should be load-balanced and
fault-tolerant.