[j-nsp] Network, trouble after customer created a loop *inside* a VM host

[Jeff Meyers]

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 bridge id 16k
>             |
>       ProCurve 2824     RSTP bridge id 32k
>             |
>         Windows Host    no RSTP
>      (virtual switch)
>          /   \
>         /     \
>     VM-host1  VM-host2  virtual hosts with bridging potential (no RSTP)
>           \  /
>            \/           loop via clients bridging causing ARP 'move'
>                         broadcast storm
>
>
> So your problem is that the final two virtual-switch layers don't
> participate in your RSTP but can be looped causing your ARP storm.

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 required for the router to see this "mac move" 
thing? Since there is only one physical port (ae0) towards the L2 
infrastructure, this can only be macs moving between Vlans, right?

But the windows host connects to an access-port and the trouble spread 
over the whole network, even to uninvolved vlans not present on the 
ProCurve or the EX4200 above.

> You can prevent it by fiat (limit that pro-curve port to only 1 or 2
> MAC addresses). Force the user to run in VM-nat mode or only run
> one VM at a time.

I'm afraid that's hard to achieve, especially with customers of 
customers.. :(

> You may be able to control the damage by limiting the broadcast/storm
> thresholds on the leaf ports.

It's currently set to 85% on the EX4200, the ProCurve doesn't even 
support that feature. I guess this will require a value much smaller in 
the 10% region?

> I don't think that the "mac-move-limit" feature will help you as the
> mac changes are all coming in on the same physical port. The switches
> don't care about ARP MAC<->IP flapping, only the router cares about it.

No, doesn't sound suitable for this case - I agree.

> Good luck

Thanks!


Regards,
Jeff