Hi Matt,
conf t
fault-finder broadcast-storm
sorry should be "fault-finder broadcast-storm sensitivity high"
I think the ProCurve-proprietary "loop-protect" on the downstream port
of the 2824 might be a better fit here.
See eg
http://larsmichelsen.com/monitoring/hp-procurve-network-lo
Hi Patrick,
The problem is that any broadcast packets across the loop get amplified
pretty quickly and this propagates across the entire broadcast domain
(all related switches that have trunks containing affected vlans for
transit).
of course, I always forget the 3rd party broadcasts when talk
Hi Alex,
I think we are missing some important details here.
AFAIK, in order to detect MAC moves, the port must be in a
bridge-domain/VPLS instance.
So Your MX480 ae0 must be a L2/"bridged" port, not a L3/routed one.
yes, that is the case - historically actually. In the past we migrated
from
> From: "Patrick Okui"
> The problem is that any broadcast packets across the loop get amplified
> pretty quickly and this propagates across the entire broadcast domain
Yes, that's probably what Jeff saw: his switches were not part of the loop, but
were nonetheless in the same broadcast domain(s
On 09/11/2014 07:49, Patrick Okui wrote:
On 9-Nov-2014 00:59:34 (+0200), Patrick Okui wrote:
so ...
conf t
fault-finder broadcast-storm
sorry should be "fault-finder broadcast-storm sensitivity high"
I think the ProCurve-proprietary "loop-protect" on the downstream port
of th
On 9-Nov-2014 00:59:34 (+0200), Patrick Okui wrote:
> so ...
>
> conf t
> fault-finder broadcast-storm
sorry should be "fault-finder broadcast-storm sensitivity high"
--
patrick
signature.asc
Description: OpenPGP digital signature
___
On 8-Nov-2014 14:56:27 (+0200), Jeff Meyers wrote:
> alright, but why would the ProCurve and everything above care? Isn't the
> loop only inside the Windows Host since from the perspective of the
> ProCurve, packets come in the same interface where they were sent out?
> Furthermore, what is requir
Hello,
I think we are missing some important details here.
AFAIK, in order to detect MAC moves, the port must be in a
bridge-domain/VPLS instance.
So Your MX480 ae0 must be a L2/"bridged" port, not a L3/routed one.
So the question would be - are there any other ports on this MX480 in
same brid
Hi David,
Once you draw your diagram correctly you'll see what you're up against
(and it ain't pretty).
Juniper MX480 no RSTP
||
ae0
||
Juniper EX4550 VC RSTP bridge id 0
||
ae0
||
Juniper EX4200 VC RSTP bri
Hi Michele,
So STP didn't protect you and you faced the loop.
okay, but how is this a loop from the perspective of the switches in the
higher levels? The Procurve sees packets coming in from the same port
where they were sent out. Isn't that by definition not a loop?
When the loop occurs
|
ProCurve 2824RSTP bridge id 32k
|
Windows Host
...
Because of a mistake, the customer accidentally bridged his two VMs
together as well which caused a loop inside the Host. So far, so good.
The trouble begins at this point because immediately we saw part
From: Jeff Meyers
Subject: [j-nsp] Network, trouble after customer created a loop
*inside* a VM host
Hello everybody,
I'm writing to this list because I can't seem to find the reason for
what we saw twice meanwhile. Here is the setup:
Juniper MX480
Hello everybody,
I'm writing to this list because I can't seem to find the reason for
what we saw twice meanwhile. Here is the setup:
Juniper MX480no RSTP
||
ae0
||
Juniper EX4550 VC RSTP bridge id 0
||
ae0
||
Juniper E
13 matches
Mail list logo