<div>So for it to be flapping between blocking / forwarding, the unit would have to either be receiving (or thinking its receiving) tcn's?</div>
<div><br><br> </div>
<div class="gmail_quote">On 11 September 2010 20:45, George B. <span dir="ltr"><<a href="mailto:georgeb@gmail.com">georgeb@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">They are all using the same ring ID (ring 2) and this is extremely simple as the vlan exists only on the units in the ring and the ring ports are the only members of the vlan.  That number ratio isn't going to mean anything as I have been running in a stable mode now with one of the units not configured for MRP for well over 24 hours now.  The topology keeps flapping if I have all members configured. As long as I leave one unconfigured, it works just fine.<br>
<br>The equipment involved has been in service without issues for a long time.  We recently added the second metroE and I wanted to run MRP as I have had good results with it everywhere else I have used it.  Never seen anything like this before.<br>
<font color="#888888"><br>George</font> 
<div>
<div></div>
<div class="h5"><br><br><br>
<div class="gmail_quote">On Sat, Sep 11, 2010 at 12:39 PM, Heath Jones <span dir="ltr"><<a href="mailto:hj1980@gmail.com" target="_blank">hj1980@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0pt 0pt 0pt 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>Hi George</div>
<div> </div>
<div>I'm really quite a newbie when it comes to MRP. RHP rcvd / sent = 8.22 (close to 8). Is that worth noting?</div>
<div>If the ring ID was different on all 4 devices, not converging so sending out both interfaces, that would mean that each device should show 8 times(ish) the figure of what is sending out??</div>
<div> </div>
<div>Packet captures might be the way to go, if we can find the protocol spec from foundry..</div>
<div> </div>
<div>Heath<br><br></div>
<div class="gmail_quote">
<div>
<div></div>
<div>On 11 September 2010 20:02, George B. <span dir="ltr"><<a href="mailto:georgeb@gmail.com" target="_blank">georgeb@gmail.com</a>></span> wrote:<br></div></div>
<blockquote style="BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>
<div></div>
<div>See this diagram for reference:<br><br><a href="http://tinypic.com/r/kb93lj/7" target="_blank">http://tinypic.com/r/kb93lj/7</a><br><br>This is pretty simple.  I have one vlan in an MRP ring through 4 MLX units.  I configure the master, and it works as expected.  I then configure the members.  The problem is when the last "member" (non-master) is configured in the ring, the master begins to receive thousands of RHP and TC RBPDUs per second.  It doesn't matter which one is the last member configured but as soon as I enable RHP on that last member, the count of RHP and TC RBPDUs goes haywire.  Here is what my master currently shows:<br>
<br>RHPs sent            RHPs rcvd            TC RBPDUs rcvd<br>509883               4193162              3684318<br><br>As you can see, it has sent about a half a million RHPs but received over 4 million of them!<br><br>
Only one unit is configured as "master".  As long as I have MRP unconfigured on one of the members, the ring works as expected. There is no spanning tree of any sort running on that vlan.  I am just in awe of how RHP packets can seemingly be created in the network somewhere at such an amazing rate!<br>
<br>Anyone else seen anything like this?  It is just plain wacky!<br><font color="#888888"><br>George<br><br></font><br></div></div>_______________________________________________<br>foundry-nsp mailing list<br><a href="mailto:foundry-nsp@puck.nether.net" target="_blank">foundry-nsp@puck.nether.net</a><br>
<a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" target="_blank">http://puck.nether.net/mailman/listinfo/foundry-nsp</a><br></blockquote></div><br></blockquote></div><br></div></div></blockquote></div><br>