===========================
R E L E A S E N O T E S
===========================
Broadcom Advanced Server Program (BASP) Driver
for
Windows 2003, Windows XP, Windows 2000
X86, AMD-64, IA-64
Copyright (c) 2000-2009 Broadcom Corporation
All rights reserved.
Version 6.3.24 March 14, 2010
-----------------------------
1. CQ47714: BSOD is seen when team is present and Symantec Anti-Virus SEP is
installed
Problem: The system bsod's when a team is present and Symantec Anti-Virus
SEP is installed
Cause: The Symatec software is cloning a receive packet and not filling in
the OriginalPacketInfo field in the packet extensions. Basp
bugchecks when it reads and dereferences the null value stored
there.
Change: This is a bug in the Symantec software, but it was quicker to
implement a work around in basp then to ask Symantec to fix the
bug. Basp was changed to check for a null value in this field and
when detected, to use the packet passed to instead of the original
packet.
Impact: This change is in the receive path and affects all team teams.
The problem has been in basp since the first release, but is only
seen when using the Symantec software v11.0.6. This problem is not
seen when using the Symantec software v11.0.4. The only other field
basp uses in the packet extensions is the Ieee802QInfo. This field
is required for vlans. The Symantec software appears to be filling
in this field correctly, but using vlans with the Symantec software
should be monitored closely.
Version 6.3.23 February 10, 2010
--------------------------------
1. CQ45637: Bug check 0xD1 - basp!alloc_block_context
Problem: A bsod occured when the system performed a chimney offload to basp.
Cause: The offload request from the stack was incomplete and did not
contain all the information required to setup the offload. The
driver assumed incorrectly that this was an illegal request and
could not happen and consequently casued an illegal memory
reference when attempting to defrerence data that was not present.
Change: Basp was modified to detect this situation and obtain the info
needed to complete the chimney offload from other sources within
the driver.
Impact: This bug has been in the driver since version 1.0. Since this is
the first detection of this bug, it happens very rarely. This bug
only happens on slb team that are capabable of performing L4
offload. This bug can be worked around on older drivers that do
not have this fix by disabling chimney offloading in the system.
Version 6.3.22 December 21, 2009
--------------------------------
1. CQ45018: Indicate BASP Team Link Speed as the Sum of the Team Members
Problem: Basp would by default indicate the team's link speed as the
highest link speed of a single nic in the team. Basp could be
reconfiged by the user to indicate the aggregate link speed of
all the active load balaning nics in the team using a regsitry
key defined below in this document.
Cause: Displaying the hightest link speed of a sing nic in the team
instead of the aggregate link speed was a marketing requirement.
Change: The default configuration of basp was changed to display the
aggregate link speed of the team. The user can now override
this behaviour to display the highest link speed of a single nic
in the team using the same registry key and values as before.
Impact: This change applies to all team types.
Version 6.3.21 October 15, 2009
-------------------------------
1. CQ44118: When a team gets deleted, "Client for MS Networks" and "File and
Printer Sharing for MS Networks" remain unbound to the adapter
Problem: Shared printer and files cannot be accessed when a nic is removed
from the team unless the user manually checks the "Client for MS
Networks" and "File and Printer Sharing for MS Networks" boxes in
the properties page for the nic.
Cause: The basp installer was disabling these services when the team was
deleted.
Change: The basp installer no longer disables these services when the team
is disabled.
Impact: This problem is localized to the basp installer which only
executes when a team is created or deleted. No other basp
components have changed from the previous version.
Version 6.3.20 October 7, 2009
------------------------------
1. CQ44000: BSOD observed while passing sockdie L4 traffic and disabling eVBD
Problem: Basp indicated a nbl to ndis with a null handle.
Cause: Basp timed out after one minute waiting for a nbl to return from the
evbd driver. When the nbl didn't return within this time period,
basp timed out and disabled the interface to the evbd driver,
creating the null handle. Later the nbl was returned to basp and
basp tried to return it to ndis using the null handle. This caused
a bsod in ndis when ndis dereferenced the handle.
Change: The time out to wait for a nbl to be returned was incresed from one
minute to five minutes.
Impact: This change only impacts slb teams with L4 offloading enabled while
failing over.
Version 6.3.19 August 26, 2009
------------------------------
1. CQ42969: 5709C - Customer experiencing occasional system hang condition
Problem: There were actually two bugs associated with this problem. The
first bug, the "deadlock bug", was fixed in #1 of v6.3.18. This
is the fix for a second bug releated to this problem report.
This problem is that an L4 flow could be prematurely deleted from
the internal arp cache. Prematurely deleting an L4 flow may result
in dropping connections that are being L4 offloaded.
This problem is related to the deadlock bug because it allowed the
deadlock code to execute on an L4 offload capable team, when the
deadlock bug should only have been possible on teams capable of
L2 offloading only.
Cause: Deleting flows in the internal arp table is disabled on teams that
are L4 offload capable. However, there was a bug in the driver
that allowed flows to be deleted when the flow manager executed more
than once on the same kernel tick.
Change: Basp was modified to not delete L4 flows when the flow manager
executes multiple times on the same kernel tick.
Impact: This problem only occurred on slb teams that are L4 offload
capable.
Version 6.3.18 August 24, 2009
------------------------------
1. CQ42969: 5709C - Customer experiencing occasional system hang condition
Problem: Servers running w2k3 would occasionally hang when running a basp
slb team.
Cause: A 3-way deadlocks was created by basp when calling ndis to send an
internal array of packets while holding a spinlock.
Change: Basp was modified to release the spinlock before sending internal
packets.
Impact: This problem only occured on slb teams with two or more primaries
and more than 64 active remote endpoints to the basp team.
2. CQ39535: Causes NLB cluster to ARP flood network if a remote host pings
cluster
Problem: This is a back-port of a problem reported on basp6.
When a basp team in an nbl cluster was arp'ed by another basp team,
the basp arp/ndp state machine became unstable and oscillated
sending arps on the network until the machine was reset or the team
deleted.
Cause: Basp would receive arp replies to fixup arp that had a different
source mac address in the ethernet header than the original arp.
This caused basp to re-arp using the new source mac address,
wherein the reply to this arp would be with a different source mac
address, and the process would repeat ad nauseam.
Change: Throughout this process, the source mac address in the arp/ndp would
remain constant, and so basp was changed to use this field instead
of the volatile address in the ethernet header.
Impact: This change applies only to slb teams, and to both ipv4 and ipv6
protocols.
Version 6.3.17 June 30, 2009
----------------------------
1. CQ42257: Add Support for McAfee Host Intrusion Protection Server to BASP
Helper DLL
Problem: Customer's using McAfee's Host Intrusion Protection Server (HIPS)
report that their SLB team does not work correctly after reboot when
the HIPS software is installed. If the user manually disables the
HIPS intermediate driver from the NIC hardware and only allows it to
bind to the BASP Virtual NIC then the system works as expected.
This request is to modify the BASP helper DLL to automatically
unbind the HIPS driver from the BASP controlled NICs.
Cause: The Basp Notifier Object (basp.dll) did not unbind HIP from the
underlying miniport driver when a nic is added to the team.
Change: Supported was added to the Notifier Object to remove the binding
to the HIP driver when a nic is added to the team.
Impact: Effects all team types when a team is created or a nic is added to
the team and HIP has already been installed. Support also needed to
be added to bmapi, and so the correct version of bmapi is required
to full support this feature.
2. CQ38832: NWLink Netbios protocol still bound to adapter when team is created
Problem: NWLink Netbios protocol does not get unbound from an adapter when a
team is created with that adapter. All protocols and services,
except Broadcom Advanced Server Program Driver, should be unbound
from the adapter when said adapter is part of a team. In the failing
scenario, ipx/spx, ipv4, and ipv6 protocols get unbound, it's only
the NWLink protocol that reamins bound along with client for MS
network, File and printer sharing for MS networks. Issue is not
seen when ipx/spx is not installed in system.
Cause: The Basp Notifier Object (basp.dll) did not unbind NWLink Netbios
from the underlying miniport driver when a nic is added to the team.
Change: Supported was added to the Notifier Object to remove the binding
to the NWLink Netbios driver when a nic is added to the team.
Impact: Effects all team types when a team is created or a nic is added to
the team and NWLink Netbios has already been installed. Support
also needed to be added to bmapi, and so the correct version of
bmapi is required to full support this feature.
Version 6.3.16 June 22, 2009
----------------------------
1. CQ42082: Restoring IPv4 address not bound in OS until reboot occurs
Problem: Static IPv4 address would not be active when restoring a saved
LACP team configuration containg static ip addresses until the
sut was rebooted.
Cause: Regression testing identified the change between v6.3.4 and 6.3.5
that caused this problem to occur.
Change: Since 1) this problem only happened on LACP teams, 2) the change that
caused this problem to occur is only need for L4 offloaded and 3)
only slb teams do L4 offloading, the change that caused this
problem to occur was conditionalized to only execute on SLB teams.
This fixed the problem.
Impact: This change applies to non-slb team types, eg. LACP and GEC.
Version 6.3.15 June 18, 2009
----------------------------
1. CQ42066: No data for NW utilization or Link Speed in TaskMgr for 802.3ad
team running traffic
Problem: The link speed was reported as 0 on lacp and gec team types.
Cause: Some debug code was inadverently left in the driver that blocked
the link speed calculation on non-slb team types.
Change: Remove the debug code.
Impact: This change only applies to lacp and gec team types.
Version 6.3.14 June 18, 2009
----------------------------
1. CQ36892: Tx Packet counter does not increment for the TOE Team.
Problem: Basp returns the internal L2 Basp counters to BACS. These counters
do not included the L4 counters.
Cause: This was working as designed.
Change: Basp was changed to query the underlying miniport drivers in the
team for both the L2 and L4 counters and return the sum of these
counters for the team's counters for BACS requests.
Impact: Impacts all team types.
Version 6.3.13 May 22, 2009
---------------------------
Fixes:
======
1. CQ41070: Adding VLAN team causes non-team NIC to also send out VLAN tag
packet
Problem: Adding VLAN team causes non-team NIC to also send out VLAN tag
packet
Cause: Basp was not clearing the vlan id field when it returned a send
packet to ndis. The os would reuse the packet to send a frame
on the non-team nic. The non-team nic would see the stale vlan id
and send the packet with a vlan tag.
Change: Basp now clears the vlan id field when returning send packets to
ndis.
Impact: Affects all vlan team and msvs.
Version 6.3.12 May 8, 2009
--------------------------
Fixes:
======
1. CQ38160: Need Event log notice when LiveLink detects loss of connection
Problem: No message is logged by LiveLink the connection to the target
system changes.
Cause: Messages were only logged when the physical link status changed.
Change: LiveLink now logs a message to the event log whenever the
connection to the target system changes.
Impact: This change only applies to LiveLink teams.
Version 6.3.11 Feburary 5, 2009
-------------------------------
Fixes:
======
1. CQ39446: Sockdie traffic auto fallsback in AFD team when both primaries
are re-enabled
Problem: The team would fallback to a load balancing nic when the standby
nic was active in an AFD team with Live Link enabled when the
load balancing nic was reenabled. The team should only fallback
when the standby nic is disabled, loses link, or when a user
initiates a fallback in BACS.
Cause: The Live Link modules uses a separate set of flags to control
AFD. One of these flags was not being checked to see if the
standby was active when a nic was reenabled.
Change: Basp was changed to not add a nic to the ready map when when a
nic is reenabled and the standby nic is active in a Live Link AFD
team.
Impact: This change only applies to Live Link AFD teams.
2. The standby nic is active after booting a system with a AFD team.
Problem: The standby nic will be active when load balancing nics are
ready when the system is first booted. The user is required to
initiate a failover to active the load balancing nics. The team
then behaves correctly after the first failover.
Cause: An internal failover event would happen when the standby nic was
the first nic bound in the team
Change: Enabling AFD is delayed for ten seconds when a team is created to
prevent premature AFD activation and allow a second load balaning
nic to be bound to the team second delay was added
Impact: This change applies only to AFD and Live Link AFD team types.
3. CQ39411: The message file in basp5 driver is broken.
Problem: Messages are not displayed correctly in the event log.
Cause: The message file was broken fixing cq37379 in v6.3.9.
Change: Repaired the message file.
Impact: This change applies to most messages displayed in the event log.
Version 6.3.10 January 5, 2009
------------------------------
Fixes:
======
1. CQ37378: Discarded packet counter
Problem: The basp discard packet counter behaved differently in Ndis 5.x
and Ndis 6.x
Cause: The discard packet counter in Ndis 5.x did not included
packets discarded by the policy engine.
Change: The discard packet counter was changed to include packets
filtered by the policy engine.
Impact: This change applies to all team types and platforms.
Version 6.3.9 December 22, 2008
-------------------------------
Fixes:
======
1. CQ37379: System eventlog entries after deleteing a team.
Problem: Basp logged a warning message when a team was deleted.
Cause: The message severity was warning and not informational.
Change: The message severity was changed to informational.
Impact: This message is logged when any team type is deleted.
2. CQ38507: Bsod occurred when deleting SLB team after passing sockdie
traffic overnite
Problem: The team was deleted before a failover had completed.
Cause: This problem was caused because the failover that happens when a
team is deleted took an excessive amount of time. The timers
between the unbind and failover were not coordinated which
allowed the unbind to timeout and delete the team before the
failover attempt had timed out and exited. The unbind timeout is
2 minutes, and the failover timeout is a sum of timeouts which if
they all timedout, can be up to 5 minutes.
Change: The unbind timer was changed from 2 minutes to 5 minutes.
Impact: This change only impacts slb teams.
Version 6.3.8 October 28, 2008
------------------------------
Fixes:
======
1. CQ38183: Bsod occured when updating vbd fre to vbd chk with team present.
Problem: This is a another manifestation of cq37782. Basp was sending a
queued arp on a nic that had just been unbound.
Cause: There was a logic sequencing error that allowed new sends to be
posted after the nic being unbound was paused.
Change: Basp was changed to block new sends before waiting for pending
sends to complete.
Impact: This was an L2 send problem in all team types and platforms.
Version 6.3.7 October 17, 2008
------------------------------
Fixes:
======
1. CQ37949: Chariot traffic auto falls back in a mixed mode team when
disable/enable primaries
Problem: The problem was introduced in v6.3.5 and would occur on SLB-AFD
teams with any nic configuration. This happened when the standby
became active due to one or more or primaries becoming disabled.
When the primary was later enabled, the team would fallback to
the primary even though AFD was enabled.
Cause: The primary was becoming active because some code add in v6.3.5
to disable offloads while binding a nic was causing a failover to
occur at the end of the binding process when offloads were again
enabled.
Change: L4 offloads are still disabled during the binding process, but a
change was made to not cause a failover event at the end of the
binding process when offloading was enabled.
Impact: This change is only applied when nics are bound to the team and
should only impact SLB-AFD team types.
Version 6.3.6 October 14, 2008
------------------------------
Fixes:
======
1. CQ37782: Bsod occured while passing L4 sockdie traffic to SLB team while
disabling 1 port in team
Problem: This problem was caused by basp trying to send a packet on a nic
that had just been unbound.
Cause: A nic was assigned to send a packet, but the send routine was
preempted before the packet could be sent, and the nic closed
and unbound from the team. When the send routine resumed,
dereferencing the mif->handle caused a bug check on the call to
NdisSend().
Change: Basp was changed to allow all pending sends to complete when a
nic is unbound from the team.
Impact: This was an L2 send problem in all team types and platforms.
Version 6.3.5 October 8, 2008
-----------------------------
Fixes:
======
1. CQ37822: Bsod occured while deleting SLB team
CQ37306: Assert occured passing traffic to SLB w/3vlans
Problem: Basp was calling ndis with a null handle.
Cause: Ndis was offloading a connection when no nics were ready.
Change: Basp was changed to fail offload requests when not nics are
ready.
Impact: Applies to slb teams that are L4 offload capable.
Version 6.3.4 September 24, 2008
--------------------------------
Fixes:
======
1. CQ37016: BSOD is observed while passing L4 sockdie_stress traffic while
causing traffic to failover
CQ37165: Assert occurred while passing L4 sockdie traffic to SLB with
6 vlans
CQ37503: Assert occurred while adding 5708 to Everest team with chariot
traffic
Problem: Basp would indicate an offload initiate connection complete or
return an nbl using a null handle while unbinding a nic from the
team.
Cause: #1 There was a race condition in basp that allowed a nic to be
unbound and the handle nulled while a toe connection was still
offloaded.
#2 Receive nbls were being returned after all the connections
had been terminated
Change: #1 Removed the race condition to guarentee all toe connections
have been uploaded before unbinding a nic from the team.
#2 Wait for all nbls to be returned after all connections have
been uploaded before unbinding a nic from the team.
Impact: Impacts only slb team types, but occurs on all platforms when
unbinding a nic from the team.
Version 6.3.3 September 17, 2008
--------------------------------
Fixes:
======
1. CQ37189: Does not wake from S4 with 64 VLANS
CQ37199: VLANS: Fails ACPI stress tests
Problem: Basp would take to long to complete initialization when configured
for many vlans. These problems were reported on ndis6 and fix was
backported to ndis5.
Cause: iSCSI adapters that are not configured for an IP address broadcast
arps with a source ip of zero. Multiple unconfigured iSCSI
adapters where on the network. When basp receives these arps
broadcasted from different stations, it sees that the mac address
associated with IP address zero has changed. This cause basp to
perform a delete/add/rearp operation which is expensive and causes
basp's initialziation time to increase.
Change: A filter was added to basp to not add arp and ndp packets to
basp's internal cache when the source ip address of these packets
is zero. Basp still indicates these packets to the os, but does
not add them to its internal cache.
Impact: This problem happens only on SLB team types on any network with
unconfigured iSCIS adapters.
2. CQ37362: Bacs displays LACP team type as TOE capable.
CQ37360: LSO does not increment in LACP team config
Problem: Basp was advertising toe capability when all the underlying nics
supported toe, regardless of the team type.
Cause: Only slb teams types support toe.
Change: Changed basp to only allow advertisment and setting toe
capabilities on slb teams.
Impact: This problem only impacts LACP and GEC team types.
3. CQ37372: BSOD (C5 stop code) is observed during a reboot test with SLB team
with 6 vlans
CQ37122: Bsod observed when booting into OS
(basamd64!reg_read_team_registry+453)
Problem: Basp was reading the registry while holding a spinlock.
Cause: While holding a spinglock, the os cannot handle page faults.
Reading the registry can sometimes cause a page fault. If page
fault happens while holding the spinlock, the system will BSOD.
This is what was happening.
Change: Basp was changed to read the registry after the spinlock was
released.
Impact: This problem change happen whenever a team is created or edited.
It will not happen when the team is deleted.
Version 6.3.2 August 29, 2008
-----------------------------
Enhancements:
=============
1. CQ13925: IPv6 support is not avaiable with Basp5.
Extended IPv6 support to include IPv6 LiveLink.
Fixes:
======
1. CQ37013: Bacs:Basp5:NX2:E1.0: Basp is not reporting the OL cap of team to
bacs. Bmapi is not using the correct header size to validate the
offloading capabilities returned by basp due to a bug in the ddk. Basp was
modified to return the incorrect header size in order to pass bmapi
validation.
2. Fixed a bug the would cause inbound flows to be deleted prematurely from
basp's internal cache in team with 1-primary and 1-standby nic.
Version 6.3.1 August 20, 2008
-----------------------------
1. Changed the driver directory strucutre. The new directory names are listed
below.
Old New Description
--- --- -----------
xp32 i386 This is the Ndis 5.1/5.2 x86 driver.
amd64 amd64 This is the Ndis 5.1/5.2 amd64 driver.
xp64 ia64 This is the Ndis 5.1 ia64 driver.
w2k This is the Ndis 5.0 x86 driver for Windows 2000. This
is a new directory. This driver was previously stored in
the xp32 directory.
Version 6.3.0 August 18, 2008
-----------------------------
Enhancements:
=============
1. CQ13925: IPv6 support is not available with Basp5.
IPv6 support for load balancing and failover support was added to Basp.
This includes the following features.
- IPv6 Outbound load balancing for SLB, LACP and GEC teams
- IPv6 Inbound load balancing for SLB teams
- IPv6 Checksum offload
Note that the following IPv6 features are not supported.
- IPv6 Large send offload (LSOv2) is not supported by Ndis 5.x
- IPv6 Connection offload (TOE/Chimney) is not supported by Ndis 5.x
- IPv6 LiveLink (probe packets) is not support in this release.
2. CQ35559: Mismatch in jumbo mtu size for team and team members. The
maximum mtu size was changed from 9000 to 9600. The team's mtu size is set
to the smallest mtu size supported by all the nics in the team.
3. CQ34714: Task manager shows wrong link max speed for teaming adapter.
Basp reports the team's link speed as the highest link speed of all the
nics in the team. To address the problem reported, a new registry key was
added to configure basp to report the team's link speed as the aggregate
link speed of all ready nics in the team. The registry key to enable
aggregate link speed reporting is as follows.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Blfp\Parameters]
"AggregateLinkSpeed"=dword:00000001
Adding this key and setting it to 1 will enable aggregate link speed
reporting. Deleting the key or setting it to 0 will enable the current
behavior. This registry key is global and its setting applies to all
teams. The registry key is deleted when any team is deleted. After adding
the registry key, the system must be rebooted for the change to take
effect.
4. CQ36495: Task mgr shows link speed as 10Mbps when there is no link. Basp
was modified to report the last non-zero link speed when all links in a
team are down. If a team has never established a link, the link speed
will still be reported as 10Mbps
5. CQ34330/CQ33128: Toe license limited to 1024 connections. Basp offloading
module was modified to support an unlimited number of offload connections.
The following registry key must be created to configure the number of
offload connections supported by the hardware.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Blfp\Parameters\
{team_id}] "ToeMaxConns"=dword:00000400
This registry key must be created after the team has been created. The
{team_id} field must be replaced with the numeric identifier for the team,
e.g. 1. After the registry key has been created, the system must be
rebooted for the change to take effect. The registry key is deleted
when the team is deleted. If the registry key is not present and the team
is TOE capable, the default value for ToeMaxConns is 1024. If a team is
TOE capable, ToeMaxConns must be set to the smallest number of TOE
connections supported by any one nic in the team.
Version 6.2.36 July 25, 2008
----------------------------
Fixes:
======
1. Problem: Multicast streaming stops when using the Device Manager to
failover and then failback a nic in the team.
Cause: Basp stopped receiving multicast packets on the failback because
the multicast address list was not being forwarded to the nic
when it was reenabled. Disabling a nic from the Device Manager
causes it to be unbound from the team and reset. The nic loses
its current multicast list when it is reset. When the nic is
later reenabled, basp should forward its current multicast
address list to the nic, but it wasn't doing this. This resulted
in the nic dropping all multicast packets and caused the test to
fail.
Change: This problem was fixed by forwarding basp's multicast address
list to a nic whenever it is bound to the team.
Impact: This change applies to all team types whenever a team is
disabled and reenabled using the Device Manager, or a nic is hot
added to the team.
Version 6.2.35 June 6, 2008
----------------------------
Fixes:
======
1. Problem: CQ35743: Cannot get max TOE connections with BASP SLB team
Cause: Basp was distributing the L4 offload connections across the total
number of vnics plus one instead of just the total number of
vnics.
Change: Distributed the L4 offload connections across the actual number
of vnics in the team.
Impact: This change applies to teams that are L4 offload capable and have
multiple vnics.
Version 6.2.34 April 1, 2008
----------------------------
Fixes:
======
1. Problem: CQ34028: Oversubscription of L4 offload connection on team
with more than 1 VNIC
Cause: Basp was not distributing the L4 offload connections across the
vnics. This would cause offloading of L4 connections to fail and
the system to become unstable.
Change: Statically and evenly distribute L4 connections across the vnics.
Impact: This change applies to teams that are L4 offload capable and have
multiple vnics.
2. Problem: CQ34079: Changing MTU size of physical adapter in a team will
result in a "grayed out" team.
Cause: Basp was indicating the incorrect frame size indicated when nics
have different mtu sizes. Basp was incorrectly setting the team
mtu size to the size of by the nic with the greatest mtu. Nics in
the team with a smaller mtu size would fail sending packets with
the larger mtu size.
Change: Basp now sets the mut size to the smallest mtu size of the nics
in the team.
Impact: This impacts all team types where the mtu size of the nics in the
nics in the team are not the same, eg. 1500.
3. Problem: Arps may not be sent when the system is in a low resource
condition.
Casue: Basp overwrote an index that would cause it to skip sending arps
to some stations when it a low resource condition.
Change: Basp no longer overwrites the index.
Impact: This problem would only happen rarely on slb teams when the
system was in a low resource state for multiple interations of
the slb worker thread executing.
4. Problem: Disabled L4 debug messages.
Version 6.2.33 December 10, 2007
--------------------------------
Fixes:
======
1. Problem: CQ32976: BSOD on NDIS.sys on Magnum blade.
Cause: There is a race condition between Ndis offloading connections and
Basp posting a link status indicating that the link is down. If
this race condition occurs as the link goes down on the last
active nic in the team while Ndis is trying to offload a new L4
connection that isn't in Basp's internal arp cache, Basp may try
and offload the connection using a data struture for an unused
nic. The unused nic data structure has a null miniport handle and
when Ndis derefereences the handle, a BSOD occurs.
Change: Basp was changed to assign new connections to the last active nic
when no nics are active. This way Basp will always have a
valid handle to operate on.
Impact: This bug may also occur when sending a unicast arp to a new
destination and the race condition occurs as the link goes down
for the last nic in the team with a nic. The change fixes both
manisfestations of this bug.
2. Problem: CQ32457: BSOD is observed while pass traffic through slb team
with 5 vlans, TOE enabled
Cause: Basp exhausted all entries in an internal array required for L4
offloading. This could occur if Ndis tried to offload more
connections than supported in the hardware.
Change: Basp now fails an offload request when it is unable to allocate
an entry in its internal array.
Impact: Failing an offload request should only occur when the maximum
number of offload connections the hardware supports is exceeded.
Version 6.2.32 November 7, 2007
-------------------------------
Fixes:
======
1. Problem: CQ31823: Fixed problem where SLB team would incorrectly
respond to gratuitious ARP REPLYs.
Version 6.2.31 October 4, 2007
---------------------------------
Fixes:
======
1. Problem: CQ30534 Add support for "no Auto Fallback" with Livelink.
Cause: New feature
Change: Implemented the requested feature for w2k3.
Impact: To use this functionality you need BACS 10.7.11 or later and
BMAPI 7.8.4 or later.
Version 6.2.30 September 11, 2007
---------------------------------
Fixes:
======
1. Problem: CQ28853, CQ31290: After hot removal of an adapter from a team
the team is either not active or not all remaining members of
the team are active.
Cause: When the team is being reinitialized, NDIS is not ready for
BASP's call to NdisIMInitializeDeviceInstance.
Change: Modified BASP to retry calls to NdisIMInitializeDeviceInstance
if the function does not return success.
Impact: none.
Version 6.2.29 September 07, 2007
---------------------------------
Fixes:
======
1. Problem: CQ31283: System BSOD during boot with iSCSI
Cause: Race condition between BASP initialization in DriverEntry and
the handling of protocol binding calls was causing access to a
unitialized variable.
Change: Reordered the initialization sequence in DriverEntry to avoid
race condition.
Impact: none.
Version 6.2.28 September 04, 2007
---------------------------------
Fixes:
======
1. Problem: CQ31135: System hangs when running BACS diagnostics.
Cause: The fix for CQ30877 did not account for a potential deadlock
condition on OID passlock.
Change: Removed deadlock condition on OID passlock.
Impact: none.
2. Problem: CQ31020: SLB teaming stops working with MSFT NLB after
disconnecting the network cable.
Cause: BASP did not account for the case where an ARP for the NLB
team has not been added to the inbound hash.
Change: Modify BASP to assign inbound ARPs for the NLB team to the
primary adapter.
Impact: none.
Version 6.2.27 August 13, 2007
--------------------------------
Fixes:
======
1. Problem: CQ30877: Blue Screen during reboot test.
Cause: An OID was being processed and a physical nic was being loaded
concurrently. This would cause the OID to intermittently process
an OID with invalid data.
Change: Synchronized the affected OIDs with the protocol bind routine.
Impact: none.
Version 6.2.26 August 8, 2007
--------------------------------
Fixes:
======
1. Problem: CQ30877: Blue Screen during reboot test.
Cause: An OID was being processed and a physical nic was being unloaded
concurrently. This would cause the OID to intermittently process
an OID with invalid data.
Change: Synchronized the affected OIDs with the protocol unbind routine.
Impact: none.
Version 6.2.25 July 30, 2007
--------------------------------
Fixes:
======
1. Problem: CQ28132: Converting from SLB to SLB AFD team when LiveLink is
Present Does Not Reinitialize Virtual Adapter Successfully
When changing the team type from SLB with LiveLink to SLB with
Auto-Fallback Disabled (no LiveLink), the team will be disabled
until the system is rebooted or the team is deleted and
re-created.
Cause: LiveLink doesn't support Auto-Fallback Disable. When the team
was reconfigured to AFD, an internal flag disabling LL was not
being cleared. Consequently, LL tried to initialze but failed,
causing the binding operation to fail and the team to become
disabled.
Change: LiveLink is disabled for all team types execpt SLB with LL.
Impact: This change fixes the problem that occurs when the team type is
changed from LL to any other team type, i.e. AFD, LAG, or
GEC/FEC.
2. Problem: CQ28289: BASP driver 6.2.22 copyright year in incorrect
Cause: Copyright was incorrect.
Change: Updated copyright to 2000-2007
Impact: The copyright is now correct on Basp's property page.
3. Problem: CQ28346: Cannot create team with BASP v6.2.22 on w2k3/IA64 system.
Blue screen when creating a SLB team with BASP v6.2.22 on
w2k3/IA64 system.
Cause: Data mis-aligment on IA-64 systems.
Change: Re-aligned data.
Fixed incorrect address arithmetic in tdi.c.
Impact: Only impact is on IA-64 systems running basp.
4. Problem: CQ28958: BSOD when disabling LSO/CO in team configuration.
CQ30248: Intermittent Check 0x7f during system reboots.
Cause: BASP's protocol bind/unbind routines did not handle
multi-threaded re-entrancy properly.
Change: Added a semaphore and spinlock to properly synchronize
the binding and unbinding of the underlying miniport.
Impact: none.
Version 6.2.24 January 26, 2007
-------------------------------
Fixes:
======
1. Problem: CQ28200: BACS ver. 10.0.8.0 did not complete the Delete A Team
task.
This problem was traced to Basp and addressed there. No changes
were made to BACS to fix this problem.
Cause: Basp will pause when deleting a team when it detects it has
outstanding requests to Ndis that have not yet completed. Basp
waits for up to 1 minute for the requests to complete before
continuing with halting the team and unbinding from the
underlying miniport driver. When Basp unbound the miniport
driver, the minport driver also detected it had outstanding
requests to Ndis and would wait about 2.5 minutes for the
requests to complete before continuing.
This problem was traced to Ndis 5.2 not returning receive packets
when packet stacking was enabled. This problem was not seen when
using Ndis 5.1, or when packet stacking was disabled. It is
unknown at this time why Ndis 5.2 does not always return receive
packets when packet stacking is enabled, though it is thought
that this problem may be a bug in Ndis 5.2.
Change: To work around this problem, packet stacking was disabled in Basp
for Ndis 5.1 and 5.2.
Impact: Not enabling packet stacking results in about 2% lower throughput
of L2 traffic. This change is not in the L4 code path and does
not impact L4 performance.
Version 6.2.23 January 19, 2007
-------------------------------
Fixes:
======
1. Problem: CQ28129: BASP needs to send out CTP packets on each VLAN.
Cause: The purpose of CTP frames is to notify the switch that the team's
MAC address is now connected to another port. Basp always sent
CTP frames untagged. Switches configured to accept only tagged
frames would discard the untagged CTP frames and not remap the
team's MAC address to the new port. This can result in frames
sent to the team being dropped until a _tagged_ packet is sent
from the team that causes the switch to reassociate the team's
MAC address with the new port.
Change: Basp now sends a tagged or untagged CTP frame for each VNIC in
the team.
Impact: Teams with VNIC's using tagging may unnecessarily lose packets on
on failover without this change, though they'll recover as soon
as the team sends some tagged packets.
2. Problem: No CQ: Packets can be sent on the wrong VLAN.
Cause: There were two problems.
1. The vlan id field was not being cleared in the packet
extensions when sending untagged packets. This caused some
untagged packets to be tagged with a stale tag from the
tagged packet that previously used the packet extension.
2. A tagged VNIC would send directed ARPs untagged when failing
over or rebalancing inbound traffic. This happens when NDIS
clones a packet, such as when packet stacking or MSVS is used,
but does not clone the miniport reserve field in the packet.
When this happened, Basp would incorrectly calculate that the
vlan id was 0 and use this value when sending all subsequent
ARPs for this particular flow.
Change: 1. The vlan id in the packet extension field is now always
cleared before sending untagged packets.
2. Basp now obtains the vlan id from the original packet, not the
cloned packet.
Impact: 1. This problem only occurred on teams that had an untagged vnic
and one or more tagged vnics. This problem resulted in a
leaking of data from an untagged vlan to a tagged vlan, and
caused packets to have to be retransmitted.
2. This problem could result in connections on a tagged VLAN
being dropped. This problem did not require an untagged VNIC
to be a team member.
Version 6.2.22 January 10, 2007
-------------------------------
Fixes:
======
1. Problem: CQ28054: Running multiple of clients of sockdie/nslicer
against SLB team in a multi-processor system caused bsod
during overnight test.
Cause: There was a race condition in which multiple threads were
processing a global structure variable. This structure's
reference count gets decremented to zero. However, the
non-atomic nature of the usage of the variable caused un-due
processing of house-keeping functions causing system blue screen.
Change: Changed the usage of InterlockDecrement function to use the
returned value of the decremented reference count variable.
This returned value is then used by caller functions to perform
tasks.
Impact: This change affects only Layer 4 TOE Offload functionality only.
Version 6.2.20 January 5, 2007
------------------------------
Fixes:
======
1. Problem: CQ27871: Windows NLB Failover Unreliable with SLB Teams
Cause: Basp was adding the cluster's IP address to its ARP cache table.
When a failover occurred, Basp would send an ARP redirecting
the cluster's clients to use the team's MAC address instead of
the cluster's MAC address. This would break connections to other
servers that were members of the cluster.
Change: Basp no longer adds a cluster's IP address to its ARP cache
table. This prevents Basp from sending ARPs using the cluster's
IP/MAC addresses on failovers.
Basp identifies cluster addresses by looking at the source MAC
address. If the source MAC address is a multicast, then the
IP/MAC address pair is determined to be a cluster address and not
added to the ARP cache.
Impact: Basp now works with Microsoft NLB Clustering in multicast mode.
It does not work (and never has worked) when NLB is configured in
unicast mode.
Version 6.2.19 January 2, 2007
------------------------------
Fixes:
======
1. Problem: CQ26580: Layer 2 teaming causes high number of retransmissions
on the clients
Cause: Basp occasionally indicated packets to NDIS out of order. This
could happen when Basp's receive packet handler was reentered.
When this happened, the interrupting process would indicate its
packets before the preempted process, resulting in packets being
indicated out of order to the overlying protocol stack.
Ndis guarantees that Basp's receive handler will not be reentered
for a particular nic in the team, but it can be reentered from
different nics that are team members. Basp used a single receive
queue to queue packets from all underlying miniport drivers
before indicating the entire queue to Ndis.
Packets would be indicated out of order in the following
scenario.
1. Nic1 queues some packets, but not enough to trigger an
indication to Ndis and exits the receive handler
2. Nic2 queue some more packets which meets the threshold to
trigger an indication to Ndis. All driver spinlocks are
(must be) released before calling Ndis.
3. When the spinlocks are released, but before indicating the
packets to Ndis in the context of Nic2, the receive handler is
reentered by Nic1.
4. Nic1 queues sufficient packets in a new queue to trigger
another indication to Ndis. These packets from Nic1 are
indicated before the indication from Nic2 in step 2. that
contains packets from both Nic1 and Nic2. This results in
Nic1's packets being indicated out of order.
Change: Basp was changed to always indicate packets from a particular
nic in the order received. A separate receive queue was allocated
for each nic in the team. This guarantees Basp will indicate
receive packets for a particular miniport driver in the same
order that that miniport indicates them to Basp.
Impact: This change lowers cpu utilization and increases throughput with
Layer 2 traffic. Packet retransmission should no longer occur
under normal network conditions and should only be seen under
heavy network load. This problem only occurs with L2 teaming, and
will occur both with and without 3rd party NICs in the team.
2. Problem: CQ27173: Disabling Standby Adapter with MS Virtual Server 2005
causes Guest OS to Lose Connection
Cause: Basp only supports MSVS using SLB teams with one primary and one
standby NIC. When disabling the standby NIC, the standby NIC
is internally deleted from the team and the team reconfigured
to have only one primary NIC in the team. Basp did not support
MSVS with teams having only one primary.
Change: Basp was changed to support MSVS using teams that have only a
single primary NIC, in addition to the team type of one primary
and one standby that was already supported.
Impact: The change applies to SLB teams configured to have either one
primary and one standby, or one primary NIC in the team,
regardless of if MSVS is running.
3. Problem: CQ27547: The newly teamed adapter(s) was not participating in
the team's traffic
Two problems are described in the problem description for
CQ27547.
1. A hot added adapter did not participate in load balancing a
team's outbound traffic until a failover occurred.
2. Chariot test scripts would fail when a hot added nic was added
to the team and the cable to one or more nics was
disconnected.
Cause: 1. Dynamic re-balancing of outbound L2 traffic was disabled when
running with Ndis 5.2. This resulted in no existing outbound
flows being migrated to the hot added nic until a failover
occurred or a new flow was created. Dynamic rebalancing of
outbound flows was disabled when Ndis 5.2 was present because
it was believed (incorrectly) that L2 and L4 outbound flows
to a particular station must be sent using the same nic. Only
L2 and L4 _inbound_ flows from remote station must be sent to
the same nic.
2. All inbound flows were being deleted when hot adding a nic.
When adding a nic to the team, basp was notified to delete
the IP address that the new nic uses when it's NOT a member of
the team. When basp received this notification, it deleted all
inbound flows so that it wouldn't send arps using an unused
source IP address. Because of this, no arps would be sent to
remote station's redirecting their traffic to nics that are up
when a failover happened. This resulted in the remote station
still sending traffic to the failed nic and causing TCP/IP
disconnections. This situation would persists until the remote
stations sent out a broadcast arp request and received a new
inbound address.
Change: 1. Two changes were made to address this problem.
a. Dynamic rebalancing of outbound L2 traffic is now enabled on
both Ndis 5.2 and 5.1. This allows L2 outbound traffic to be
balanced over time across all nics in a team, including hot
added nics.
b. All L2 and L4 outbound and inbound flows are rebalanced when a
nic is hot added to a team. This is in addition to change a.
above that allows for dynamic rebalancing of L2 outbound
traffic. Note that all traffic is rebalanced when a nic is
removed from a team - this has not changed.
2. When basp receives a notification that an IP address has been
deleted from the system, it now only deletes all flows with a
source address that matches the deleted IP address. This will
only result in TCP/IP disconnections to the deleted IP address
(this is okay!) on failovers.
Impact: L2 outbound flows are now dynamically rebalanced on Ndis 5.2.
Inbound and outbound L2 and L4 flows are rebalanced whenever a
nic is added to a team. After hot adding a nic, previously
existing connections to remote stations will not be lost on
failovers.
4. Problem: CQ27374: A Guest OS's Virtual Network bound to a BASP Team
Virtual Adapter for a Tagged VLAN Will Not Pass Traffic
Cause: MSVS does not copy the MiniportReserve fields when cloning an
NDIS_PACKET. Basp and its underlying miniport drivers store the
vlan id and priority of a packet in the MiniportReserve field of
an NDIS_PACKET. When transferring packets between Basp and the
miniport driver, MSVS makes a copy of the NDIS_PACKET and gives
the copied NDIS_PACKET to the IM/MP drivers. However, MSVS does
not copy the MiniportReserve field of the NDIS_PACKET when coping
the packet, and so the vlan id and priority are not present in
the copied NDIS_PACKET that's given to the IM and MP drivers.
Change: Using the Miniport Reserve field was the only method available in
Ndis 5.0 to pass per packet information between the IM and MP
drivers. With Ndis 5.1 and above, a field in the
NDIS_PACKET_EXTENSIONS is available for passing the vlan id and
priority between the IM and MP drivers.
When sending packets, Basp was changed to store the vlan id in
the packet extensions field for Ndis 5.1 and above systems. Basp
still stores the vlan id in the MiniportReserve field for all
versions of Ndis.
For receive packets, Basp was changed to first locate the
original receive packet (not the copy made by MSVS) and look in
the MiniportReserve field of the packet for the vlan id. If the
vlan id is not found in the MinportReserve field, Basp will then
look for it in the packet extension field.
Impact: This method of passing the vlan id to and from the miniport works
with both the NX I and NX II drivers. Both drivers have used this
method for many years and so will work un-modified. Using the
packet extensions for the vlan id also opens up the possibility
of Basp supporting vlans using 3rd party nics.
5. Problem: CQ27497: Chariot 1Kbuffer test with toggle Chimney and Failovers
will cause system hangs.
Cause: The Microsoft NDIS API MiniportTcpOffloadSendHandler does not
allow inline send completion within this call. It expects the
send completion to come asynchronously from a different thread.
Change: Removed check for failover state to fail a packet send in
mp_TcpOffloadSendHandler as this is redundant. The passed in
ProviderContext has legitimated the existing offload connection.
Impact: The change applies to SLB teams configured in L4 TOE offload mode
only.
Version 6.2.18 November 3, 2006
-------------------------------
Fixes:
======
1. Problem: CQ27203: Running Chariot 4k buffer size of High Performance
Script detects Error 245.
CQ27321: L4 BASP could return a receive buffer to an underlying
miniport instance for the wrong physical adapter.
Cause: BASP can return underlying miniport owned received
NetBufferList(s) to the wrong miniport in a team. This occurred
as NDIS can pool multiple NetBufferLists from multiple underlying
miniport drivers and returned them all at once.
Change: De-linked the NetBufferLists and performed multiple returns to
return the lists to individual miniports.
Impact: This change applies to all BASP configurations where there are
more than one primary adapter in a SLB L4 offload team.
Version 6.2.17 October 19, 2006
-------------------------------
Fixes:
======
1. Problem: No CQ: Fix 1. in 6.2.16 re-introduced problem 1. in 6.2.5
[CQ23867: Basp works sporadically with IPX/SPX
When only the IPX protocol is enabled (TCP/IP is disabled) on
a Basp team, and the link is disconnected on a team's true
primary NIC, all IPX connections and drive mappings are lost
until the link is reestablished on the true primary NIC.]
Cause: The primary NIC's mac address is not added to the snoop table
unless an ARP request or reply is sent. When TCP/IP is not
enabled on the host OS, no ARPs will be sent, so the primary's
address is never added to the snoop cache. This results in
no CTP frames being sent for the primary on failover/failback and
erratic behavior.
Change: The primary's MAC address is always added to the snoop cache,
regardless of which protocols are enabled.
Impact: This change applies to all configurations when not running MSVS.
When running MSVS, this change only applies to the Host OS. This
problem still exits when TCP/IP is not enabled on Guest OS's
running MSVS.
2. Problem: No CQ: Incorrect source MAC address assigned to L4 flows
Cause: When the primary nic in a team fails, another nic in the team is
promoted and becomes the new primary nic. As the primary nic, it
is now assigned the team's MAC address. In this senario, when a
new L4 flow was offloaded, the L4 flow would use the orignial MAC
address of the promoted NIC instead of the team's MAC address.
Change: When an L4 flow is offload, Basp now checks if the NIC it has
selected is a promoted primary and selects the correct MAC
address to use.
Impact: This change only applies to systems with L4 offloading enabled
and there is more than one primary in the system and all NICs in
the team are Broadcom NICs.
3. Problem: CQ26905: Basp falls back to the primary nic when using the
network connection manager to enable a primary nic and
"Auto-Fallback-Disable" is enabled.
Cause: Even when Auto-Fallback-Disable was enabled, basp would ignore
the setting unless all nics in a team had completed binding to
the virtual nic. This was done to prevent the standby nic from
becomming the primary at initialialization when the primary nics
were ready, simpbly because the standby was bound to the vnic
first.
Disabling a nic using the network connection manager causes the
nic to be unbound from the team and causes Basp to ignore the
Auto-Fallback-Disable setting.
Change: When Auto-Fallback-Disable is enabled, it is now ignored only
until all nics in a team are bound to the vnic for the first
time. Afer all the nics have been bound once, the setting for
Auto-Fallback-Disable is honored even when nics are disabled and
enabled using the network connection manager.
Note however, that if all nics in a team are disabled using the
network connection manager, the internal flag indicating that
all nics have been bound once will be cleared, and hence all
nic in the team must be reenabled for the Auto-Fallback-Disable
setting to be hornored.
Impact: There must be two or more primary nics in the team in the team
and at least two primaries have been disabled using the network
connection manager and the standby nic is active.
4. Problem: CQ25025: network utilization isn't showing the correct % for L4
teaming
Cause: Previous versions of BASP did not support some of the new
statistics OIDs that were added in the NDIS 5.2 spec.
Specifically, previous versions of BASP did not support the
following new OIDs:
OID_TCP4_OFFLOAD_STATS
OID_IP4_OFFLOAD_STATS
OID_GEN_BYTES_XMIT
OID_GEN_BYTES_RCV
CQ 25025 was caused by not supporting the last 2 of the above
OIDs.
Change: BASP now supports these 4 new NDIS 5.2 statistics OIDs.
Impact: BASP will now have added statistics support for L4 enabled TOE
chimney environments. There should be no side effect from this
change.
5. Problem: CQ27028: L4 BASP improperly holds spinlock while calling certain
NDIS routines
Cause: A spinlock was acquired before pausing, uploading and resuming
offloaded connections on failover.
Change: The spin lock in now acquired after pausing and uploading
offloaded connections, and released before resuming.
Impact: This problem was found during a code review and no specific test
was used to create a problem caused by this defect. The area
impacted in the driver by this change is in the area of failover
for both L2 connections, as well as L4 connections that are being
offloaded.
6. Problem: CQ26437: LiveLink vlan will hang during failover (disable/enable
method)
Cause: Basp hung trying to acquire a spinlock needed to calculate the
correct MAC address to use in probe packets in the LinkLink
thread.
Change: The method used to calculate the correct MAC address has changed
the former function acquiring the spinlocked was removed.
Impact: Any SLB team using LiveLink with more than two members.
7. Problem: CQ26714: Failover doesn't work with Multi-vendor (Intel) Team
Cause: ARPs were sent on the wrong NIC (the disabled NIC) when failing
over using a MVT.
Change: The fixup ARPS are now sent on the promoted primary when the link
status changes for any team member.
Impact: The change applies to both Multi-vendor and all Broadcom nic
SLB teams, though the problem only occured on a MVT.
8. Problem: CQ26759: Very low traffic on standby memeber after livelink
failover on Dell Montreal
Cause: A version mismatch between the bxvbdx.sys and bxnd52x.sys driver
caused the problem. Both drivers must have the same major.minor
version.
Change: After correcting the version mismatch of the underlaying drivers,
no change was required for Basp.
Impact: None
9. Problem: CQ26945: In SLB team type with LiveLink enable, the probe
client's ARP table will have one MAC address for both primaries
when disable/enable primaries.
Cause: There is a code path in basp where it will change the mac address
of a Broadcom nic in a multi-vendor team when re-enabling nics
using the network connections manager in a different order then
what they were originally brought up in. Basp should never change
the mac address of any NIC in a MVT, since there is no way to
reprogram the mac address of other vendors NICs. Since the
Broadcom NIC mac address was reprogrammable, it was being changed
to the Intel NIC's mac address, but the Intel NIC's mac address
wasn't being changed.
Change: Basp was modified to never change mac addresses on Multi-Vendor
Teams.
Impact: This bug has been in Basp for awhile, probably starting with the
introduction of LiveLink. The bug would only occur when LL was
enabled, the Intel NIC was the true primary when the team
started, the Intel and Broadcom NIC were disabled, and then the
Broadcom NIC was enabled.
Version 6.2.16 September 15, 2006
---------------------------------
Fixes:
=====
1. Problem: CQ25241: Failover not working properly on 5704-based blade [when
running Microsoft Virtual Server]
Cause: Each virtual machine is assigned a new MAC address when it's
created. The VM is bound to Basp and will use this address when
sending and receiving data through BASP.
When a failover event occurs, Basp sends a CTP frame to notify
the switch that the team's MAC address is now connected to
another port on the switch. All frames sent to Basp's team
address are now forwarded through the new port.
Since no CTP was sent using the VM's MAC address, it remains
associated with disconnected switch port. This prevents all
frames sent to the VM from reaching it until a frame is sent from
the VM that causes the switch to reassociate its MAC address with
the new port.
Change: Basp now snoops the MAC source address in the ethernet header of
all ARP frames it transmits, and caches all the source MAC
addresses it sees in an interal cache. Using the cache, Basp now
sends a CTP frame for each entry in the cache when a failover
event occurs.
Impact: Basp supports MSVS only on teams that have one primary and one
secondary nic. Basp supports a maximum of 32 virtual machines.
Basp requires each VM to send an ARP request or reply frame at
least once before the first failover. This works only on OS's
running IPv4.
2: Problem: During failover recovery, L4 Basp sent out packets on the 1st
primary teamed NIC, who has the team MAC address, with the
ethernet header source MAC address of the 2nd primary teamed NIC.
This causes the switch mistakenly forwards all packets destined
to the 2nd primary teamed NIC going to the 1st primary team NIC.
Cause: Upon offloading a TCP connection, the L4 offload stack does not
initialize the source MAC address in the L4 offload state when it
hands this state information to the miniport/firmware. In this
case, the miniport/firmware will fill in its source MAC address
for all outbound packets.
Changes: The L4 Basp driver filled in the designated source MAC address
for the TCP connection at the time of offload before forwarding
this offload state to the miniport. The designated source
MAC address is based on the L4 load balancing algorithm which
has pre-assigned a particular teamed NIC to the TCP connection.
This MAC address will correspond to the corresponding underlying
NIC where the packet will go out.
Version 6.2.15 August 24, 2006
------------------------------
Fixes:
======
1. Problem: CQ22837: Multicast Filtering of the Standby Adapter Should Extend
to Multi-Vendor Teams.
Cause: Multicast/broadcast frame filtering was only enabled on teams
supporting advanced failover. Teams only support advanced
failover only when all miniport drivers in the team support the
Broadcom NIC Extensions (BNICE) interface. Since other vendor's
miniport drivers don't support BNICE, Basp disables advanced
failover and hence multicast filtering was also disabled when
other vendors NICs were in the team.
Change: The fix was to assign one primary NIC in a team as the multicast
NIC. The multicast NIC is the only NIC allowed to accept
multicast frames; multicast frames will be filtered (dropped) on
all other NICs in the team. If the multicast NIC fails (link
loss, disabled, etc.), another primary NIC in the team is
selected as the multicast NIC. If there are no primary NICs
available, then a secondary NIC is selected. If a secondary NIC
is the multicast NIC and a primary becomes available, then the
new primary becomes the multicast NIC.
Impact: Multi-vendor teams should now only indicate one copy of
multicast frame up to the stack, whereas previously, a copy of
the multicast frame would be indicated by each NIC in the team.
Also, any NIC in a team of Broadcom only NICs may be assigned to
receive multicast frames. Previously, the NIC assigned to
receive multicast frames was always the current primary NIC (the
one with the team's MAC address).
2. Problem: CQ25760: Lower Network throughput with 4 port TOE team using
Chariot
Cause: Inbound flows from remote clients can become unbalanced and
not evenly distributed across all NICs in a team when broadcast
ARPs are transmitted by the team.
Sending a broadcast ARP causes all remote clients to update
their ARP caches to point to primary NIC in a team. Basp would
correct this problem by immediately sending a directed ARP to
each remote client with a MAC address for that client to use to
balance the inbound flows.
The problem is that the broadcast ARP is always sent on the
primary NIC, and the unicast ARPs are sent on (other) NICs that
were assigned in the previous balancing process. The number of
packets queued for transmition varies for each NIC in a team at
any given time. This can result in the unicast/fixup ARP being
transmitted before the broadcast ARP and the remote client
receiving the fixup ARP before the broadcast ARP. When this
happens, the remote client's ARP cache will end up pointing to
the primary NIC instead of the assigned NIC. This causes an an
imbalance in the number of clients assigned to a specific NIC in
team and can cause some NICs in a team to become overloaded and
others underloaded, resulting in a lower overall performance for
the team.
Fix: Three changes were made to basp to fix this problem. Change 1.
is the major change that fixed the problem, while changes 2-3
correct minor logic errors in the balancing algorithm.
1. All unicast/fixup ARPs sent after a broadcast are are sent on
the same NIC as the broadcast ARP. This insures that the ARPs
are transmitted in the correct order from the team.
2. An error in the inbound state machine logic could cause a
fixup ARP to not be transmitted in some cases was fixed.
3. An error in the logic to set a load balancing flag could
cause load balancing to become disabled was fixed.
Impact: This impacts both L4 and L2 teaming, though the imbalance is
more noticeable on L4 teaming because of the static assignment
of flows to NICs. It is less visable in an L2 environment
because the flows can be dynamically moved between NICs.
3. Problem: Basp will not load on Windows Vista
Cause: Basp checked the OS version and would only load when the OS
version was 5.x
Fix: Allow Basp to load when the OS version is 6.x
Impact: Basp now runs on Vista using the NDIS 5.x wrapper.
Version 6.2.14 July 14, 2006
----------------------------
Fixes:
======
1. Problem: CQ25328: Running two nslicer across 2 vlan with single
sockdie will cause crash
Cause: Stack calling Basp's MiniportTcpOffloadReceive() with NULL
ProviderContext caused blue screen. There is a race
condition between the offload initiation completion and the
host stack starts posting receive data buffer to Basp on a TCP
connection.
Change: Basp pre-fill the Basp ProviderContext during offload initiation
rather than during offload initiation complete as specified in
the Microsft MSDN documentation.
Impact: This bug would affect some offload connections if it hits that
window of vulnerability as described above although the
possibility is small.
Version 6.2.13 July 12, 2006
----------------------------
Fixes:
======
1. Problem: CQ25558: Bugcheck encountered while running 1c_InitTime NDIS
test script on SLB team
Cause: Basp was trying to send a frame using a NIC that had just been
un-bound from the team.
Change: Basp now checks if the NIC is bound and ready before sending
frames that are generated internally.
Impact: This bug has been in basp for a long time, but was only
uncovered by change 1. in version 6.2.12. This problem only
occurs when a team with more than one NIC is deleted using
basp v6.2.12.
2. Problem: CQ25745 - L2 - SLB Failover Causes Errors in Chariot/Nettack
cause: Change intriduced in 6.2.12 to balance new layer 4 connection
has broken layer 2 failover. The ARP cache should not be
flushed arbitrarily.
Change: Layer 2 connections in the ARP cache are now shuffled during
a failover, but the ARP cache is not cleared. This effectively
distributes all connections equally when a NIC becomes
available.
Impact: None
3. Problem: CQ25756 SLB team doesn't fail over properly in 2K3
Cause: See fix for CQ25745
Change: See fix for Cq25745
Impact: None
4. Problem: CQ25717 - Team becomes unreachable w/multiple IP addresses
as SLB ports are unplugged
Cause: There has been a long standing bug where some of the connections
were not reassigned to available NICs when a NIC goes offline.
Change: All connections are now re-assigned to available NICs when a NIC
goes offline.
Impact: None
5. Problem: CQ25604 - Stress Sockdies with Single NIC team with multiple
virtual BASP instances (vlan) will BSOD during vlan removal
Cause: Basp attemts to offload layer 4 connections to NICs unbound
from the team.
Change: Upload all layer 4 connections before unbinding a NIC from the
team.
Impact: None
Version 6.2.12 June 23, 2006
----------------------------
Fixes:
======
1. Problem: CQ24182: Groucho: After BASP SLB team fail-over, remote ping
takes several minutes to resume
Cause: When failing back to the primary adapter because the link status
has changed from down to up, basp sends CTP frames to notify
neighboring and downstream switches that primary adpater has
switched ports. Some switches (in this case the ESM) will
indicate the link is up before they are able to accept or pass
traffic when first powering up, causing them to miss the CTP
frame and not detect that the primary MAC address has switched
ports. Once the switch has finished booting, it does not forward
traffic to the primary adapter until a packet is sent on the
primary adapter to a remote station.
Change: Basp was modified to send a CTP frames every five seconds for a
period of 135 seconds when the primary NIC changes. This gives
switches sufficent time to initialize and begin accepting
traffic, and correctly detect which port the primary is
connected to.
Impact: This change impacts teams that have only two Broadcom NICS, with
one NIC configured as a primary and the other as a secondary.
Also, the problem only occurs when a failback occurs and the
switch basp is failing back to is off or in the process of
powering up. This problem does not occur when LiveLink is
enabled.
2. Problem: New layer 4 connections are not load balanced.
Cause: In prior Basp versions, layer 2 entries in Basp's ARP cache
determined the adapter assigned to new layer 4 connections to
the same destination. As a result, new layer 4 connections were
not load balanced.
Change: This version flushes Basp's ARP cache during failover to allow
new layer 2 and layer 4 connections to be redistributed.
Impact: None.
Version 6.2.11 June 09, 2006
----------------------------
Fixes:
=====
1. Problem: CQ25271: Creating a GEC/3AD team with TOE enabled adapter, team
is offloaded
Cause: Basp advertises offload capabilty for all team types.
Change: Only advertise offload capabilty for SLB teams.
2. Problem: CQ24979: Stress Vlan with Chariot causes system blue screen.
Cause: NetbufferList link list contained in the TcpOffloadForwarding
completion call has NetBufferLists that are designated to
different NdisMiniportHandles. They are forwarded in separate
ndis calls per NdisMiniportHandle. This processing erronously
extracted a null NdisMiniportHandle.
Change: Subsequent netbufferlists are processed with its correct
NdisMiniportHandle.
3: Problem: CQ25291: Multi vendor Team member stops receiving after
simulated failure.
Cause: Basp's merging for L4 offload and L2 flows negates the expected
L2 failover behavior.
Change: Provided conditional checks upon the presence of L4 offload to
preserve the original L2 flow algorithm.
Version 6.2.10 May 31, 2006
--------------------------
Fixes:
=====
1. Problem: CQ24069: BASPTOE Can not offload 1024 tcp connections
Cause: Bug in the Microsoft NDIS offload stack as it mis-recognizes the
number of tcp connections that the BASP driver has advertised.
This problem manifests itself from 2 Microsoft bugs:
1. Microsoft NDIS_TASK_OFFLOAD structure is not 32-bit aligned.
2. Microsoft sizeof operator does not compute the correct size.
It rounds up to the next 4 bytes.
Change: Fix in the driver by recomputing the data structure offsets in
which the Microsoft stack can identify.
Version 6.2.9 May 25, 2006
--------------------------
Fixes:
=====
1. Problem: Failover is still too long
Cause: A experimental delay of 2s was left in the code
Change: Removed this delay
2. Problem: CQ24667: BASPTOE is not symmetrically balancing the traffic
between the team members LOW performance is seen.
Cause: The NICS assigned to L2 inbound flows were being asymetrically
randomized when no L4 flows were being offloaded. When L4 flows
were later offloaded, they were assigned the NIC from the
existing L2 flow, resulting in the same asymetric (random)
NIC assignment used for the L2 flow.
Note however that the NICS for L2 and L4 flows were initially
assigned in a round-robin fashion which resulted in the inbound
flows being symetrically balanced. The inbound flows only
became unbalanced after the system was quiet for a short period
and the idle L2 flows randomized.
Change: This problem was fixed by not randomizing L2 flows on SNP
(ndis >= 5.2) capable systems.
Impact: This change applies to teams that have TOE enabled and are
running on a SNP capable system.
Version 6.2.8 May 23, 2006
--------------------------
Fixes:
=====
1. Problem: Invalid assertion is hit in the debug build (recv.c)
Cause: This assertion is not handled properly in a multiproc
environment.
Change: Removed the assetion from the code.
2. Problem: CQ24710: Failure in BASP failover, with Chariot's validate data
upon receipt option on
Cause: There were a several problems with L4 teaming failover,
1) L2 NIC driver drops link on all NICs during failover. This
is fixed in the latest L2 NIC driver.
2) Hard hang condition during failover. This is fixed with the
latest L4 tcpip.sys patch from MSFT.
3) There was an error in the Basp code which would cause
communication with the clients to be interrupted permanently.
This coding error is fixed in this version.
4) The chariot test script do not use the normal TCP
timeout/retry mechanism. Sniffer traces show the client
aborting the session if communication is lost for 200ms. We
would like all tests to use the longer default TCP timeout
value. Please retest with other tools which use the TCP
timeout/retry mechanism (for example, copy files to/from a
network drive).
Change: See "Cause" section.
3. Problem: CQ23580: BASPTOE Reporting CO Capability Only When Trunk-type
Team Members Show LSO/CO Capabilities
Cause: Task offload capabilities were only advertised for SLB teams
Change: Implemented task offload for all team types.
Version 6.2.7 May 15, 2006
--------------------------
Fixes:
=====
1. Problem: CQ24790 BASPTOE ran into assertion when the nexthop mac address
is 0
Cause: L4 offloadblock can be a linker block which is not a block that
contains a new offload state. In this case, the block will not
contain a invalid mac address of all zero.
Change: Prevents a call to insert a new entry into the flow table when
this case exists.
2. Problem: CQ23851 CQ24159 Running Charriot script in extended 72 hrs.
testing would cause the network services fail to work after the
test has failed.
Cause: Extended testing caused memory leak in BASPTOE because netbuffer
list
contexts were not deallocated over time.
Change: Deallocated these contexts upon netbufferlist received returned
back to the BASPTOE driver. Previously not all contexts were
deallocated becaused the receivedreturned netbufferlist were
batched up.
Version 6.2.6 May 3, 2006
-------------------------
Fixes:
======
1. Problem: CQ23835 BASPTOE freezes system when failing and reconnect
several times under stress in L4.
Cause: L4 offloading was not being notified when an inbound flow moved
from one NIC to another when failing back to the original
primary NIC.
Change: Modified Basp to terminate and restart L4 flows on failback
event
Impact: Applies only to teams containg all NIC's that are capable of
offloading L4 flows running on a W2K3 server with SNP
installed.
Version 6.2.5 April 21, 2006
----------------------------
Fixes:
======
1. Problem: CQ23867: Basp works sporadically with IPX/SPX
When only the IPX protocol is enabled (TCP/IP is disabled) on
a Basp team, and the link is disconnected on a team's true
primary NIC, all IPX connections and drive mappings are lost
until the link is reestablished on the true primary NIC.
Cause: ARP frames are only sent when there are IP flows associated
with a NIC. When there are no IP flows, such as when only the
IPX protocol is enabled, no ARPs will be sent. Because no ARPs
are sent the switch still directs all IPX traffic from remote
stations to the disconnected port which causes all IPX
connections and drive mappings to be broken.
Change: Send a L2 frame to the switch to notify it of the change in
the MAC address whenever a failover or failback happens.
Impact: This problem should only impact systems using only the IPX/SPX
Protocol.
Enhancements:
=============
1. Added support for sending ARP frames when an L4 flow is offloaded.
2. Disabled re-balancing of inbound flows when L4 flows are offloaded.
3. Changed inbound hashing algorithm to accommodate L4 offloading.
4. Modified DriverEntry to correctly report the ndis minor version for
ndis 5.0, 5.1, and 5.2.
Version 6.2.4 March 27, 2006
----------------------------
Fixes:
======
1. Problem: CQ23756: BASP 6.2.2 doesn't offload all Sockdie connections,
BSOD with Stress.
Change : Changed the algorithm which assigns connections to the NICs in
the team. The previous algorithm did not work for all cases.
Impact: None
Version 6.2.3 March 13, 2006
----------------------------
Fixes:
======
1. Problem: CQ23633: BASP 6.2.2 does not LSO Offload with any LSO capable
team. The ioctl handler does not report task offload if the
team is not SNP capable.
Change: Report the other offload capabilities even if the team is not
SNP capable.
2. Problem: Global data structure is not protected with a spinlock. This
can lead to the corruption of this global data structure and
ultimately a system failure.
Change: Protect this data structure (SGBlockList) with a spinlock.
Impact: None
Version 6.2.2 March 7, 2006
---------------------------
Fixes:
======
1. Problem: CQ23556: BASPTOE will BSOD with running a Untagged Vlan team
in less then 10min
CQ23503: BASPTOE will BSOD when attemting to make a change in
BACS while sending traffic
CQ23495: BASPTOE will cause system to rebot when running
chariot traffic
CQ23471: BASPTOE caused blue screen when running two offloaded
teams
CQ23376: L4 BASP will not load on a non-snp environment
CQ23515: BASPTOE will BSOD when failing over
Change: Changed the offloaded blocks linked list recovery algorithm.
2. Problem: CQ?????: L4 failover causes all connections to remain in the
"Uploading" state.
Change: Changed the offloaded connection count management algorithm
Impact: None
Version 6.2.1 March 4, 2006
---------------------------
Enhancements:
=============
1. Read the registry to determine the TOE capabilty for the team
2. Fix for CQ??? where disabling a NIC stops all network for the team
Impact:
=======
1. This version requires the latest BMAPI to enable TOE support. TOE will
not be enabled if used with older BMAPI dlls.
Version 6.2.0 Feb 27, 2006
--------------------------
Enhancements:
=============
1. Added TCP offload support for layer 4 teaming. This feature requires
Broadcom BCM5706 or BCM5708 converged NICs to be operational.
2. This version requires Microsoft Windows Vista with SNP (Scalable Network
Pack) build 6021 or later which contains NDIS5.2 library installed.
Impact:
=======
1. This version is not backward compatible with systems with Windows Vista
that do not have the SNP (NDIS5.1 or older) installed.
2. This version does not support teaming between BCM5706/08 and other
Broadcom and/or third party NICs.
Version 6.1.20 Jan 19, 2006
---------------------------
Fixes:
======
1. Problem: CQ22826: Driver Ver dates in incorrect format.
Cause: Month in .inf should use two digits
Change: Changed the .infs.
Impact: None.
Version 6.1.19 Jan 17, 2006
---------------------------
Fixes:
======
1. Problem: CQ22765: Teaming with 3rd party will not pass traffic to
standby when the primary link is broken.
Cause: The load balancing algorithm must always run whenever there is
a non-broadcom NIC in the team. Otherwise, connection can be
interrupted during failover. The logic added to support MSFT
Virtual Server should not disable load balancing for the one
standby/one active configuration when there are non-broadcom
NICs in the team. This error was corrected once before, but
crept back in the last version Change: Enable the load
balancing algorithm whenever there is a non-broadcom NIC
present in the team. Impact: This means MSFT Virtual Server
is not supported with non-broadcom NICs.
2. Problem: CQ14018, CQ 22622: The Basp intermediate driver indicates
duplicate multicast packets to the OS.
Cause: The previous Basp versions did not attempt to filter multicast
packets the NICs in the team receive. This led to duplicate
indication to the OS.
Change: In this version, Basp only indicates multicast packets
received on its primary NIC (For SLB teams, this is the NIC
programmed with the team's MAC address).
Impact: This fix applies only to SLB teams, and the problem still
exists when there are non Broadcom NICs present in the SLB
team.
Version 6.1.18 November 30, 2005
--------------------------------
Fixes:
======
1. Problem: CQ21470: Errors during failover on SLB teams.
CQ22276: BASP: SLB-LoadBalance does not send out direct ARPs
when adapter fails.
Cause: Due to a bug in the Basp code, directed ARPs are not always
sent. As a result, network connectivity can be lost for an
extended period of time during failover. Change:
There is optimization code in Basp which avoids sending
directed ARPs when one was sent recently. But there are cases
when the directed ARP must be sent reguardless of what was
sent previously. In this version, this optimization is
disabled.
Impact: Duplicate ARP messages may be sent to hosts, which is
harmless.
Version 6.1.17 October 13, 2005
-------------------------------
Fixes:
======
1. Problem: CQ14345 creating / deleting team will cause BSOD when Driver
Verifier is turned on.
Cause: Called passive level NDIS API at dispatch level.
Change: Make the call at passive level as required.
Impact: None.
Version 6.1.16 September 29, 2005
---------------------------------
Fixes:
======
1. Problem: CQ14219 Need to remove DbgPrint calls from BASP 6.1.15.
Cause: One debug print was left in the code.
Change: Removed the debug print.
Impact: None.
Version 6.1.15 September 22, 2005
---------------------------------
Fixes:
======
1. Problem: CQ13809 SLB team (Intel NIC + 5708/5751) fails to pass traffic
when adapter is brought down. Fail over not working.
Cause: The code added to support MSFT Virtual Server is causing this
problem. The load balancing algorithm should execute for non
advanced_failover teams, even if there is only one active NIC
in the team. Since NIC MAC addresses are not changed for these
teams, the packet must always be tweaked to contain the
intended source/destination MAC address.
Change: Restored the old logic when a non Broadcom NIC is present in
the team.
Impact: MSFT Virtual Server is _not_ supported when there are non
Broadcom NICs in the team.
2. Problem: CQ14068 using 3rd party adapter as standby in the team,
clients no longer able to connect after fail over.
Cause: This problem is caused by a fix introduced back in July 2003
(CQ8153). Basp caches information about IP conversations
between the host (where Basp is running) and remote computers.
Code was added back then to clear this cache when an IP
address is being deleted on the host. Without this fix,
customers complained that Basp would continuously send ARPs
about IP addresses no longer active on the host. When the
cache is cleared, Basp no longer sends directed ARPs to remote
hosts to redirect inbound traffic among the NICs in the team.
When the TCP/IP6 stack is loaded on the host, Basp receives
unexpected notifications that IP6 addresses are being removed
and wrongly clears this cache (I did not investigate why these
notifications occurs since Basp does not support IP6 yet).
Clearing the cache in turn disables the code which sends ARP
notifications during failover. This introduces random failures
to send these ARPs when they are required. Change:
To fix this problem, I enable the CQ8153 fix for IPV4 address
removal notifications only
Impact: None.
Version 6.1.14 September 13, 2005
---------------------------------
Fixes:
======
1. Problem: CQ13940 Basp does not block multicast packets.
Cause: Packets received from standby adapter(s) (while assuming the
standby role) are submitted to the OS. This causes packet
duplication, and confuses the application layer.
Change: Added code to filter packets received by the standby
adapter(s). Packets from one of the stanby adapters is
allowed through in failover mode. Impact:
The problem reported still exists for teams with more than one
active NIC. A better solution will be implemented in future
Basp releases.
Version 6.1.13 August 30, 2005
------------------------------
Fixes:
======
1. Problem: CQ13246 References to Whistler in the driver properties.
Cause: xp32 and xp64 drivers should have the same description.
Change: xp32 and xp64 drivers now have the same description.
Impact: None.
2. Problem: CQ13109 Probe retries counter in BACS 8.22 for Basp 6.1.1 does
not reflect accurate probe retries.
Cause: Previous fix does not work for all cases. Specifically, the
probe retried counters now goes up and down.
Change: Maintain a separate counter for probe missed, rather than
calculate the number of probe missed by subtracting the number
of probes received from the number of probe sent.
Impact: None.
3. Problem: CQ13548 LSO support should also be enabled for an SLB (Auto
Fallback Disabled).
Cause: LSO processing was run for SLB teams only. The fix advertised
in 6.1.12 was not in the release.
Change: Allow LSO processing for SLB (Auto Fallback Disabled) teams.
Impact: None.
4. Problem: CQ13154 Dynamic ARP cache reset feature for LiveLink team
member should be immediate.
Cause: Previous fix for this problem broke LiveLink. Probe targets
can no longer be pinged.
Change: Forward ARP responses from the probe target to the OS. The
previous fix broke this functionality.
Impact: See 6.1.12.
Version 6.1.12 August 15, 2005
------------------------------
Fixes:
======
1. Problem: CQ13149 Add Basp failover compatibe with MSFT Virtual Server.
Cause: MAC address fields are corrupted in all sent and received
packets. Also, ARP cache entries are corrupted on the hosts.
Change: When the team contains a single active NIC, Basp only performs
fail over. All load balancing related processing is disabled.
Impact: This only works when there is a single active (passing
traffic) NIC in the team. Normal Basp behavior resumes as soon
as there are more than one active NIC.
2. Problem: CQ13246 References to Whistler in the driver properties.
Cause: There are reference to old Windows builds in the Basp codes.
Change: Removed the stale references.
Impact: None.
3. Problem: CQ13109 Probe retries counter in BACS 8.22 for Basp 6.1.1 does
not reflect accurate probe retries.
Cause: The counter should be checked against limits to make sure
bogus values are not reported. This could happen for example
if a probe request generates multiple responses from a probe
target.
Change: Add code to clamp the counters to values greater than zero.
Impact: None.
4. Problem: CQ13548 LSO support should also be enabled for an SLB (Auto
Fallback Disabled).
Cause: LSO processing was run for SLB teams only.
Change: Allow LSO processing for SLB (Auto Fallback Disabled) teams.
Impact: None.
5. Problem: CQ13154 Dynamic ARP cache reset feature for LiveLink team
member should be immediate.
Cause: In prior LiveLink implementations, the probe targets were
managed with a single state machine per NIC instance. As a
result, keeping track of the status of all probe targets
became convoluted and difficult to extend.
Change: In this implementation, each NIC instance dedicates a state
machine to manage each probe target (for a maximum total of 4
state machines per NIC).
Impact: The code changes to implement this feature are significant, so
testing should be done accordingly.
6. Problem: CQ13490 Removing VLAN on port 1 of 5704C failed.
Cause: The error message of concern is logged into the event log by
design, and should not be removed. The error message is non
fatal, and is merely the byproduct of the technique used to
create VLAN type teams.
Change: The error message severity is reduced to Warning.
Impact: None.
7. Problem: Probe packets should have a user defined VLAN tag.
Cause: In prior implementations, all LiveLink probe packets were
untagged.
Change: The user can optionally associate a VLAN tag to each probe
packets. The tag is specified with a special (Basp private)
key in the registry.
Impact: The special registry key is an interim solution, in the future
the tag will be modified with the BACS GUI.
8. Problem: Under some scenario, Basp may not indicate some packets to the
OS.
Cause: There is a coding error in the previous version. Some received
packets are not submitted to the OS.
Change: Submit all received packets to the OS.
Impact: This bug fix was not documented when 6.1.12 was released. This
entry in the readme.txt file has been added while releasing
6.1.18.
Version 6.1.11 June 9, 2005
---------------------------
Fixes:
======
1. Problem: CQ12393 BASP Poor performance throughput with BASP SLB.
Cause: This features were advertised in 6.1.10 but were not included.
Change: Added the following,
1) Batch receive indication to NDIS
2) Use NDIS 5.1 packet stacking on receive
Impact: None.
2. Problem: CQ11590 The Link for a BASP Team Is Established Based on the
Probe Interval Time in the LiveLink Configuration. Cause:
The probe interval is used while determining the probe target
mac addresses.
Change: Use a fixed value of 1s while sending probes to resolve the
probe target mac addresses.
Impact: None.
Enhancements:
=============
1. Problem: OEM has requested the addition of link up/down statistics
counters (see release 8.2 MRD).
Change: Added the statistics counters.
Impact: Requires BACS 8.2.2 or later.
Version 6.1.10 May 9, 2005
--------------------------
Fixes:
======
1. Problem: CQ12393 BASP Poor performance throughput with BASP SLB.
Cause: Basp 6.0.x did not provide support for task offload.
Change: The 8.2 MRD requires a Basp for Windows performance level
comparable to Basp for Linux. This requirement is aready met
in 6.1.x. This version contains additional enhancements to
improve performance further in some configuration (chariot
benchmarks collected on FSC-TX600 platform show a 30%
improvement in performance when compared to 6.1.9). Basp 6.1.9
in turn shows a 70% improvement in performance when compared
to 6.0.12. The enhancements in this version are, 1) Batch
receive indication to NDIS 2) Use NDIS 5.1 packet stacking on
receive
Impact: None.
Version 6.1.9 March 11, 2005
----------------------------
Fixes:
======
1. Problem: CQ12393 BASP SLB team send out directed unicast ARP contains
old IP address. This is a a reincarnation of CQ8153.
Cause: BASP caches the old IP address, then uses this information to
send the directed arps. The fix was not applied to the IA64
architecture.
Change: Trap IP address change notifications from the protocols, and
use this info to flush BASP cache. Apply this fix to the IA64
and AMD64 as well.
Impact: None.
Version 6.1.8 March 4, 2005
---------------------------
Fixes:
======
1. Problem: CQ12315 BASP AMD64 sending mismatched data while running
2c_OffloadLargeSend test.
Cause: 5705 and later devices only support the unspecified and 802.3
task offload encapsulation. Basp was advertising all
encapsulations to the test suite.
Change: Only advertise the two encapsulations supported by the 5705
and later chips.
Impact: The 2c_OffloadLargeSend executes as it would with 5705 and
later chips (the test terminates quickly).
Version 6.1.7 March 2, 2005
---------------------------
Fixes:
======
1. Problem: CQ12178 Running RAW UDP packet smaller than 40 bytes causes
BSOD.
Cause: The driver attempts to use a null mdl while scanning packets to
transmit.
Change: If a null mdl is seen, the packet is submitted to the default
nic for transmit.
Impact: None.
2. Problem: CQ12250 Need symbol file for BASP AMD64.
Cause: The driver was compiled with an old ddk.
Change: The driver is recompiled with ddk 3790 build 1433.
Impact: None.
Version 6.1.6 Dec 14, 2004
--------------------------
Fixes:
======
1. Problem: CQ11541 BSOD during disable/enable of primary team members.
Cause: Uninitialized variable content is used in the Basp code. This
problem was introduced in 6.1.x.
Change: Initialized the variable properly.
Impact: None.
2. Problem: CQ11638 System hang during enable/disable if primary team
members.
Cause: Improper use of NDIS spinlocks can lead to hang condition when
NICs are enabled/disabled.
Change: Use the NDIS spinlock properly.
Impact: None.
Version 6.1.5 Dec 7, 2004
-------------------------
Fixes:
======
1. Problem: CQ11544 After configuring LiveLink, the team stays
disconnected.
Cause: The interface change between the application and the driver
was not implemented properly in the intermediate driver. In
particular, the IP addresses byte ordering has been reversed
in 6.1.4 and later.
Change: Implemented the change properly.
Impact: None.
Version 6.1.4 Dec 6, 2004
-------------------------
Fixes:
======
1. Problem: CQ11511 BSOD upon resuming from hibernate.
Cause: A bug in the code causes Basp to report LSO supported when the
machine boots, then reports LSO not supported when the machine
resumes from hibernate. This causes inconsistencies within the
IP stack and BSODs. These inconsistencies can also occur
whitout suspending the machine.
Change: Fixed the code to be consistent in reporting task offload
features.
Impact: None.
2. Problem: The team configuration parameters (task offload and LiveLink)
are not always read properly from the registry. Also added
better protection against invalid parameters. There is no CQ
entry for this issue.
Change: Fixed the code to read the parameters properly.
Impact: None.
Enhancements:
=============
1. Problem: The probe interval is now received in the unit of millisecond
from the application. In prior basp versions, the units were
seconds which limited the resolution.
Change: The intermediate driver now receives its probe interval in
milliseconds
Impact: Requires BACS 7.7.2 or later.
Version 6.1.3 Nov 24, 2004
--------------------------
Fixes:
======
1. Problem: CQ11413 Team goes down with certain Live Link parameters.
Cause: The team does not report link if the number of retries is set
to 1. The code checking the number of retries is off by 1.
Change: Fixed the code.
Impact: None.
2. Problem: CQ11403 Basp 6.1.2 .inf version info is incorrect.
Cause: Released the wrong .inf.
Change: Corrected the .inf.
Impact: None.
3. Problem: CQ11404 System gets blue screen while configuring team.
Cause: Did not check the return value from one of the Ndis calls, and
attempted to set the fields of a non existant NDIS packet.
This bug was introduced while fixing CQ11388.
Change: Fixed the code to check for NDIS return error code.
Impact: None.
Version 6.1.2 Nov 19, 2004
--------------------------
Fixes:
======
1. Problem: CQ11388 BAsp 6.1.0 fails 2c_OffloadChecksum NDIS test script.
The test also fails with Basp 6.1.1.
Cause: Basp needs to propagate the extension fields of ndis packet on
packet received. This extension contain the checksum info and
is used by the HCT to verify that the NIC/miniport driver
calculated checksums properly.
Change: Propagate the extension fields on NDIS packet received.
Impact: None.
Version 6.1.1 Nov 18, 2004
--------------------------
Fixes:
======
1. Problem: CQ11371:When we configure live link, the team stays
disconnected.
Cause: Logic error in the live link code. If the probe target is not
resolved after the first broadcast, basp incorrectly sends all
subsequent probes to the null MAC address.
Change: Fixed the logic error.
Impact: None.
2. Problem: Task Offload is not working correctly (this bug is not in
clearquest).
Cause: Error in reading and decoding the team task offload
capabilities in the registry.
Change: The team task offload capabilities are now processed correctly.
Impact: None.
Version 6.1.0 Nov 12, 2004
--------------------------
Fixes:
======
1. Problem: CQ10668:BASP Remove calls to MmMapLockedPage in win2k basp.
Cause: 6.2.11 only addressed winxp. This version addresses w2k and
later.
Change: Removed call for win2k and xp-64.
Impact: No NT4.
Enhancements:
=============
1. Problem: Support for Live Link
Impact: New version of bmapi and control suite required. No NT4
2. Problem: Support for task offload
Impact: New version of bmapi and control suite required. No NT4
Version 6.0.11 July 12, 2004
----------------------------
Fixes:
======
1. Problem: CQ10564:BASP v6.0.10 fails 1c_SetMulticast and
2c_RecvMulticast NDIS Test.
Cause Error in the new multicast list handling code (off by one in
max list size check).
Change: Fixed the new multicast list handling code.
Impact: None.
Enhancements:
=============
1. Problem: Created single .infs and installation executables for win2k
and winXP
Impact: The win2k directory has been removed from this distribution.
All the files for win2k are now in the xp32 directory.
Version 6.0.10 July 1, 2004
---------------------------
Fixes:
======
1. Problem: Multicast is not supported with VLANs.
Cause: BASP maintains a single multicast list for the team.
Change: A multicast list is assigned to each virtual NIC, the physical
NIC is given the union of all virtual NIC multicast entries.
Impact: None.
Version 6.0.9 Feb 4, 2004
-------------------------
Fixes:
======
1. Problem CQ9254 Intermittent network failure. This problem was reported
by several OEMs. Cause:
BASP is running out of receive buffers and can no longer
receive packets
Change: Instruct the OS to return the receive buffers ASAP.
Impact: None.
Enhancement:
============
1. Problem: Add support for AMD64.
Change: AMD64 support added.
Impact: None
Version 6.0.8 October 16, 2003
------------------------------
Fixes:
======
1. Problem: CQ8660 unable to pass traffic after secondary members loose
link (auto fallback disable mode).
Cause: With the new mode, BASP was reporting link down to the OS when
it should not have.
Change: Do not report link down to the OS if there are at least one
NIC with link.
Impact: None.
2. Problem: CQ8659 BASP not reporting correct speed of team when a member
fails (all modes).
Cause: BASP is using the highest speed reported by the team members.
A NIC with no link reports a speed of 1G. Note: this problem
can be found in all versions prior to 6.0.8.
Change: Only use the team members with link when reporting the speed.
If all the NICs are down, report a don't care value of 100Mbs.
Impact: Need to run all HCT tests to make sure there are no side
effects
Version 6.0.7 October 13, 2003
------------------------------
Enhancements:
=============
1. Problem: CQ6410 Provide ability to disable auto fallback when primary
port recovers.
Change: Implemented new auto fallback disable mode.
Impact: The new mode is not supported in NT4
Version 6.0.6 September 26, 2003
--------------------------------
Fixes:
======
1. Problem: CQ8523 BASP vlan tags don't work in NT4.
Cause: This feature was broken in version 6.03 while adding support
for 802.1p. Some of the #ifdef to disable this new feature for
NT4 are incorrect.
Change: Fixed the #ifdefs
Impact: None
Version 6.0.5 July 22, 2003
---------------------------
Fixes:
======
1. Problem: CQ8173 BASP 6.0.4 fails 1c_KernelCalls NDIS Test.
Cause: Calls to DbgPrint() are not allowed for WHQL
Change: Removed calls to DbgPrint()
Impact: None
2. Problem: CQ7847, Windows: Driver Verifier on BASP causes Blue Screen
Cause: This problem is due to a check detected by driver verifier, in
which driver verifier ensures the "Cancel routine" is being
zero before the request is completed. Having "cancel routine"
un-zero does not affect functionality nor performance. It's a
sanity type checking.
Change: Ensure the "Cancel routine" is zero before completing the
request.
Impact: None
Version 6.0.4 July 9, 2003
--------------------------
Fixes:
======
1. Problem: BASP SLB team sends out directed unicast ARP containing old IP
address (CQ8153)
Cause: BASP caches the old IP address, then uses this information to
send the directed arps.
Change: Trap IP address change notifications from the protocols, and
use this info to flush BASP cache.
Impact: Does not work with NT4. Is not implemented for IA64.
CHANGES in v6.0.1
-----------------
- 6827: User specified team name won't bind to virtual
adapter when creating BASP teams. The problem happened
when QoS is installed, the team/vlan name in 'Network
Connections' page is not set properly. The solution is
to get around the problem by setting the name later,
raising the 'Network Connections' page to foreground
and send 'F5' to force the 'Network Connections' page
to refresh after team/vlan name are set.
=====================================================
ATTENTION: Sometimes the 'Network Connections' did
not refresh properly. Users may need to manually hit
'F5' to refresh.
=====================================================
CHANGES in v3.0.21
------------------
- Fixed the loss of connectivity problem when creating a
802.3ad team on Windows 2003 Server.
CHANGES in v3.0.20
------------------
- Fixed the binding problem of QoS packet scheduler to the
BASP virtual adapter.
CHANGES in v3.0.19
------------------
- 6073: Unable to unbind protocol when BASP is installed.
CHANGES in v3.0.18
------------------
- 5484: Support Microsoft Network Load Balancing.
CHANGES in v3.0.17
------------------
- 5568: W2K BASP App can add a turbo team into a BASP team.
- 5264: BASP v3.0.16 Should not be loaded in IA-64 system.
CHANGES in v3.0.16
------------------
- Changed to use differnt APIs to accomodate the new WHQL
requirements.
- Added support of additional Broadcom NetXtreme based NICs
and LOMs.
CHANGES in v3.0.15
------------------
- Added support of additional Broadcom NetXtreme based NICs
and LOMs.
CHANGES in v3.0.14
------------------
- Added support of additional Broadcom NetXtreme based NICs
and LOMs.
CHANGES in v3.0.13
------------------
- Fixed Prod00004015: System bugcheck after created 802.3ad team
on a .NET IA64 system.
CHANGES in v3.0.11
------------------
- Fixed Prod00003790: fails 2c_PMHibernate NDIS test on XP32.
CHANGES in v3.0.10
------------------
- Fixed Prod00003745: fails 1c_reset NDIS test on W2K.
CHANGES in v3.0.9
-----------------
- Fixed Prod00003665: fails 1c_reset NDIS test on XP32.
CHANGES in v3.0.8
-----------------
- Fixed Prod00003609: fails 1c_kernelcalls test.
- Fixed Prod00003666: fails to add multiple cards with identical
names into the teams.
CHANGES in v3.0.7
-----------------
- Fixed 2c_Simultaneous test script failure with BASP on XP32.
CHANGES in v3.0.6
-----------------
- Fixed Prod00003600: Windows XP Professional BASP teaming does
not WOL from ping
CHANGES in v3.0.5
-----------------
- Fixed Prod00003107: Load balancing does not occur on multiple
hot-standby adapters.
- Fixed signability errors with INF files.
CHANGES in v3.0.4
-----------------
- Fixed few minor IEEE 802.3ad interoperability issues.
CHANGES in v3.0.3
-----------------
- Enhance event notification mechanism.
- Fixed system crash with the IEEE 802.3ad team in NT 4.0.
- Add Trouble-shooting section to document known issues.
CHANGES in v3.0.2
-----------------
- Fixed second port blocking problem in the IEEE 802.3ad team.
CHANGES in v3.0.1
-----------------
- Support IEEE 802.3ad link aggregation.
CHANGES in v2.0.6
-----------------
- Minor textual changes in INF and DLL.
CHANGES in v2.0.5
-----------------
- Fixed Prod00002106: System Crashes after Deleting Vlan with
ID 0 and another Vlan.
CHANGES in v2.0.4
-----------------
- Fixed Prod00001753: loss of static IP address problem when
disconnect all the NICs in a team and then only connect
the hot-standy NIC.
- Fixed Prod00001694: the BASP installer does not indicate the
if the BASP already installed.
- Fixed Prod00001779: BASP installation process is asking for
BASPXPI.EXE while running BASPI64I.EXE install program.
CHANGES in v2.0.3
-----------------
- Minor fix in installation and configuration GUI.
CHANGES in v2.0.2
-----------------
- Enhanced installation and configuration GUI.
CHANGES in v2.0.1
-----------------
- Updated teaming configuration.
- Improved error reporting when configuring more than 8 physical
NICs in a team.
CHANGES in v1.3.3
-----------------
- Fixed the driver update issue on NT 4.0. This issue was introduced
by v1.3.2.
CHANGES in v1.3.2
-----------------
- Improved the reset operation on the virtual miniport instances.
CHANGES in v1.3.1
-----------------
- Added support of IA-64 version of Windows.NET Beta 2.
CHANGES in v1.3.0
-----------------
- Improved Windows 2000 userability by reducing traffic interruption in
reconfiguring the team. In case of HotSwap, users can simply remove the
adapter without reconfiguring the team if the replacement adapter carry the
plug and play ID and the replaced adapter will not plug into network again.
In case of HotRemove, users can remove the adapter without changing team
configuration if the removed adapter will not plug into network. Team
configuration will automatically adjusted when team configuration software
launched.
CHANGES in v1.2.11
------------------
- Fix: error in re-installing BASP for Windows 2000.
In version 1.2.10, the first time installation works fine without
any error. However, if the BASP is removed and then re-installed again,
a message box will be poped up during installation and display
following message:
"Unknown Installation Error".
Despite this message, BASP is still installed properly. To configure
the teaming, the user is required to manually bring up the BASP
configuration dialog.
- Fix: removal of a NIC from a Generic Trunking team may result duplicated
MAC addresses on a network.
CHANGES in v1.2.10
------------------
- Fix: unable to resume from hibernation on Windows 2000.
CHANGES in v1.2.9
-----------------
- Fix the failure in re-enabling the virtual miniport instances on
Windows 2000.
CHANGES in v1.2.8
-----------------
- Fix: loss of network connectivity when performance monitor is monitoring
VLAN network segment.
CHANGES in v1.2.7
-----------------
- Improved SNMP trap support in the BASP driver.
CHANGES in v1.2.6
-----------------
- Fix: Individual adapters maintain team MAC address after a FEC/GEC team
is removed on Windows 2000. [0798]
- Fix: Description on virtual adapter is shown incorrectly when running
ipconfig /all on Windows NT 4.0. [0803]
CHANGES in v1.2.5
-----------------
- Fix: BASP W2K configuration GUI allows up to 39 characters for a team name.
[0795].
- Fix: BASP W2K configuration GUI is updated to allow all 64 VLANs properly
configured and functional. [0780]
CHANGES in v1.2.4
-----------------
- Fix: Intermitten recovery failure with fiber network adapters. [0093]
CHANGES in v1.2.3
-----------------
- Fix W2K INF files to pass signability test.
CHANGES in v1.2.2
-----------------
- BASP is enhanced to work better with multiple protocols. [0608], [0671]
- Fix: system bugcheck when NetXray is executed. [0305]
CHANGES in v1.2.1
-----------------
- Added support of SNMP trap in the BASP driver.
- Fix: Installing both BASP and PPTP on NT 4.0 causes "Exception error".
[0573]
- Rename the driver and DLLs files with BASP prefix. [0559], [0557], [0550]
- Minor changes in configuration GUI dialog. [0529], [0250]
- New upgrade procedure for Windows 2000: [0050], [0040]
BASP in W2k can not be updated as the 'Description' section. Users need to
save the original configuration through the driver configuration page,
uninstall BASP, reboot machine, install new BASP and restore the origial
team configuration.
There are two new buttons added to the configuration GUI. One is to save
configuration and the other is to restore configuration previously saved.
There are some limitations/rules for the upgrade procedure.
1. The protocol related information like IP address will not be saved and
restored. users need to reconfigured again after teams restored.
2. The physical NICs on the system should not be changed during the upgrade
procedure. If any NIC can not matched during restoration, the NIC will be
dropped.
3. If any team configuration can not be parsed, the restoration procedeure
will be aborted.
The format of the saved configuration is as following:
a. The team configuration key word 'Load Balance Team Configuration' has to
be at the start of a line followed by 0x0D and 0x0A (line break).
b. Next line should contain the key word 'Team Name : ' followed by the team
name which followed by 0x0D and 0x0A. Note that the spaces in the key word
are expected and this rule will apply to other key words too. Team name can
not be empty.
c. Next line should contain key word 'Team type : ' followed by team type.
The supported team types are 'Smart Load Balance and Fail Over' and 'Generic
Trunking (FEC/ GEC)'. Team type will be followed 0x0D and 0x0A. Team type
can not be empty.
d. Next line should contain key word 'Load Balance Member : ' or 'Stand By
Member : ' followed by the NIC name. NIC name has to match a NIC on the
system, otherwise it will be dropped. NIC name will be followed by 0x0D and
0x0A.
e. Next line should either repeat the same format as description for team
member/stand by NIC or 0x0D 0x0A to end the team member/stand by section.
f. After team member/stand by section, next line should contain key word
'VLAN Member : ' followed by VLAN name or 0x0D 0x0A if the team does not
have VLAN configured. If VLAN name exists, it should be ended by 0x0D 0x0A.
g. Next line should contain key word 'VLAN ID : ' followed by VLAN tag (a
number) or 0 if no VLAN configured. the line should be ended by 0x0D 0x0A.
h. Next line should be the beginning of another VLAN confuration (with key
word 'VLAN Member : ') or 0x0D 0x0A to end the VLAN configuration.
i. Next line should be the beginning of another team configuration (with key
word 'Team Name : ') or 0x0D 0x0A to end 'Load Balance Team Configuration'
section.
4. All team configuration rules will apply to the parsed configuration. Any
disqualified team configuration will be dropped. Users should always check
the parsed configuration and modify if they want.
5. If no valid team configuration parsed, the original configuration should
remain.
CHANGES in v1.1.10
------------------
- Fix: Unnecessary dialog box in team configuration. [0443]
CHANGES in v1.1.9
-----------------
- New feature: Support protocol independent failover on Broadcom 5700 only
team. For team which contains not only Broadcom 5700 adapters, there is
still IP protocol failover as existed in previous release. No user
configuration is required to activate this feature.
- Fix: System crash when primary adapter is either disabled (on W2K) or
removed (on NT 4.0 and W2K), AND after system reboots. [0046], [0098],
[0106], [0120].
- Fix: Netmon stops capturing after disconnect the cable of the primary NIC.
[0053].
- Fix: Not all 64 VLAN are working. [0245], [0269]
CHANGES in v1.1.8
-----------------
- Fix: Update the BASF driver with older version caused error. [0096]
- Fix: FEC/GEC Property dialog does not show MAC address after reboot. [0270]
- Fix: The standby adapter of FEC/GEC team receives inbound traffic from
switch. [0297]
- Fix: VLANs are not functional with BCM5700 A1 boards. [0298]
- Fix: Failover does not occur to hot-standby adpater after all load-balancing
adapters are removed and system reboots. [0046], [0098], [0106], [0120]
- Fix: Recovery does not occur to load-balancing adapters when there is hot-
standby adapter in the team. [0055], [0093]
- Fix: System crash when NetXRay is run. [0305]
CHANGES in v1.1.7
-----------------
- Fix: Unable to configure a FEC/GEC team with Tigon 2 and third party
adapters.
- Fix: Grammatical error of the message displayed during FEC/GEC team
configuration.
CHANGES in v1.1.6
-----------------
- Various fixes to address UI, installation and software update issues.
- Support up to 64 VLAN per team.
CHANGES in v1.1.5
-----------------
- Fix: NT 4.0 bugchecks with multiple Tigon 2 adapters on a Multi-Processor
system.
CHANGES in v1.1.4
-----------------
- Fix: BASF NT 4.0 driver bugchecks with multiple network adapters in a
team during system boot.
CHANGES in v1.1.3
-----------------
- Added 15 VLAN support per team.
- Added Generic Trunking/FEC/GEC load balancing support.
- Fixed a problem in distributing traffic to the network adapters that
recover from link loss.
CHANGES DETAILS in v1.1.3
-------------------------
- VLAN
Starting from this release (v1.1.3), VLAN support is added to BASF
driver. In each team, up to 15 VLAN can be added. Each added VLAN
will result in a virtual adapter appearing in the protocol stack.
In the case of TCP/IP, each VLAN corresponds to a network interface.
VLAN support is orthogonal to the existing load balancing and failover
features, which means customers who want VLAN will enjoy the same
Smart Load Balancing <tm> and newly added Generic Trunking support.
VLAN support is only available with following network adapters
(1) BCM5700 gigabit adapter
(2) Alteon Tigon 2 gigabit adapter
VLAN addition will fail if an unlisted network adapter is added to
the team.
- Generic Trunking/FEC/GEC
In addition to the original switch-independent Smart Load Balancing
algorithm, a switch dependent load balancing algorithm, Generic
Trunking or Cisco FEC/GEC compatible, is added.
To properly configuring Generic Trunking, an unique MAC address is
required. During Generic Trunking configuration, BASF will query
one of the network adapter in the team and present its MAC address
to the user for modification. The resultant MAC address will be
written to the NDIS "NetworkAddress" registry key of all network
adapters which belong to the team. A reboot is required to make
this change effective. However, since the NDIS "NetworkAddress"
registry key support is not a mandatory feature of NDIS driver,
it is possible that some network adapters do not support. Most of
the popular network adapters, as we verified, support this feature.
When there is any question, please consult the corresponding
network adapter vendors for details.
Generic Trunking also REQUIRES network switches to support Cisco
FEC/GEC and to be PROPERLY configured. Consult the switch documentation
for setting up trunking.
TROUBLE SHOOTING SECTION
------------------------
(1) 802.3ad team member links disconnect and reconnect continuously when
connects to the HP2524 switch.
This is a 3rd party issue. It is seen only when configuring an 802.3ad
team with greater than 2 members on the server and connecting an HP2524
switch, with lacp enabled as passive or active. The HP switch will show
an lacp channel being brought up successfully with only 2 members.
All other member's links will disconnect and reconnect. This does not occur
with a Cisco Catalyst 6500.
Download Driver Pack
After your driver has been downloaded, follow these simple steps to install it.
Expand the archive file (if the download file is in zip or rar format).
If the expanded file has an .exe extension, double click it and follow the installation instructions.
Otherwise, open Device Manager by right-clicking the Start menu and selecting Device Manager.
Find the device and model you want to update in the device list.
Double-click on it to open the Properties dialog box.
From the Properties dialog box, select the Driver tab.
Click the Update Driver button, then follow the instructions.
Very important: You must reboot your system to ensure that any driver updates have taken effect.
For more help, visit our Driver Support section for step-by-step videos on how to install drivers for every file type.