Steven King wrote:
Very true Eric. Microsoft even acknowledges the issue, and still has not
fixed it. I have had a few customers use NLB and have this issue.
Eric Gauthier wrote:
Brian,
The first is preventing it in the first place.
As annoying as this might sound, this is one of the
Very true Eric. Microsoft even acknowledges the issue, and still has not
fixed it. I have had a few customers use NLB and have this issue.
Eric Gauthier wrote:
> Brian,
>
>
>> The first is preventing it in the first place.
>>
>
> As annoying as this might sound, this is one of the
> standa
Brian,
> The first is preventing it in the first place.
As annoying as this might sound, this is one of the
standard operating modes for load balancing within
a Microsoft server cluster (see NLB). We've tried
to avoid it, but it seems to come up around once a
year from someone on our campus...
Relying on a TCN would yield very inconsistent results.
Lee wrote:
> On 6/18/09, Brian Shope wrote:
>
>> Thanks for all the good info..
>>
>> So it sounds like changing my CAM timeout to 4 hours is the best
>> suggestion. Anyone have any problems when implementing this?
>>
>
> Not as lon
On 6/18/09, Brian Shope wrote:
> Thanks for all the good info..
>
> So it sounds like changing my CAM timeout to 4 hours is the best
> suggestion. Anyone have any problems when implementing this?
Not as long as all the user ports have portfast enabled. Without
portfast, when a port goes up or d
Holmes,David A wrote:
> In a layer 3 switch I consider unicast flooding due to an L2 cam table
> timeout a design defect. To test vendors' L3 switches for this defect we have
> used a traffic generator to send 50-100 Mbps of pings to a device that does
> not reply to the pings, where the L3 swit
Thanks for all the good info..
So it sounds like changing my CAM timeout to 4 hours is the best
suggestion. Anyone have any problems when implementing this?
entry timeout interval, but not an elegant
> solution.
>
> -Original Message-
> From: Matthew Huff [mailto:mh...@ox.com]
> Sent: Wednesday, June 17, 2009 2:58 PM
> To: 'Brian Shope'; 'nanog@nanog.org'
> Subject: RE: Unicast Flooding
>
> Un
In a message written on Wed, Jun 17, 2009 at 02:32:44PM -0700, Brian Shope
wrote:
> Anyone have any suggestions on either prevention/monitoring?
If you control the servers, writing a small program to emit a packet
every 300 seconds or so out every interface should be nearly trivial,
and will insu
Huff [mailto:mh...@ox.com]
Sent: Wednesday, June 17, 2009 2:58 PM
To: 'Brian Shope'; 'nanog@nanog.org'
Subject: RE: Unicast Flooding
Unicast flooding is a common occurrence in large datacenters especially with
asymmetrical paths caused by different first hop routers (via HSRP, VRRP
> After debugging the problem we added "mac-address-table aging-time
> 14400" to our data center switches. That syncs the mac aging time to
> the same timeout value as the ARP timeout
This helps, seconded.
Deepak Jain
AiNET
I have had the same issue in the past. The best fix for this has been to
set the Layer2/3 aging timers to be the same.
Matthew Huff wrote:
> Unicast flooding is a common occurrence in large datacenters especially with
> asymmetrical paths caused by different first hop routers (via HSRP, VRRP,
>
Unicast flooding is a common occurrence in large datacenters especially with
asymmetrical paths caused by different first hop routers (via HSRP, VRRP, etc).
We ran into this some time ago. Most arp sensitive systems such as clusters,
HSRP, content switches etc are smart enough to send out gratui
13 matches
Mail list logo
