Ok, wanted to follow up with the cause of this.   Vendor had used a single mode fiber cable between two SR 10G optics in a metro circuit we lease.<br><br><br><br><div class="gmail_quote">On Mon, Sep 27, 2010 at 2:04 AM, Mike Hughes <span dir="ltr"><<a href="mailto:mike@smashing.net">mike@smashing.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">--On 27 September 2010 01:26:31 -0700 "George B." <<a href="mailto:georgeb@gmail.com" target="_blank">georgeb@gmail.com</a>> wrote:<br>

<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Yes, there is a LAG in the ring.  There are two 1G ports aggregated<br>
between two routers at one site.<br>
</blockquote>
<br></div>
Okay, so what this could be is either:<br>
<br>
a) Failure of source-port suppression for the LAG - so usually, when a frame arrives to a broadcast, multicast, or unknown unicast address, it is forwarded out of all ports in that vlan other than the one it arrived on. This behaviour is obviously modified for a LAG, so that other ports in the same LAG as the incoming port do not get a copy of the frame.<br>

<br>
However, I have seen this behaviour fail on some Brocade equipment (Mostly Jetcore/MG8, I think once on RX), which causes the flooded frames to "trombone" along the LAG. This would create lots of extra copies of the RHPs.<br>

<br>
It's likely to break control protocols using broadcast/multicast DAs, and cause a lot of what looks like station movement, so look for high CPU, and MAC addresses flipping between source ports.<br>
<br>
b) The other option is a bad FID being programmed for the destination MAC address for the MRP RHP, which is causing the RHPs to be forwarded out of the wrong port on one of the switches.<br>
<br>
Just some ideas to investigate.<br><font color="#888888">
<br>
Mike<br>
</font></blockquote></div><br>