Is spanning tree disabled on vlan 2? harbor235
On Sun, Sep 12, 2010 at 4:10 AM, George B. <[email protected]> wrote: > All of those units have been in service for over a year passing traffic > without problems. We recently added the second metroE and I wanted to use > MRP as I have had good results with it elsewhere. MRP works fine as long as > I have at least one unit that is NOT configured for MRP. One thing I > noticed today is that two of the units (the bottom two in the diagram) are > running 4.0.0 and the top two are running 5.0.0 so my next step is to get > them all up to current (though a new release for MLX/XMR is due on or about > Wednesday, Sept 15, according to my little birdies so I might delay for a > couple of days). > > The configuration is as simple as I can get it ... one single vlan running > MRP, no topology group, only ports in the vlan are the ports running MRP > (two ports per unit). > > Thanks for your response, Jan. > > George > > > > On Sun, Sep 12, 2010 at 12:46 AM, Jan Pedersen < > [email protected]> wrote: > >> Hi George, >> >> >> >> We once had a similar issue, and that was caused by a faulty 4X10G XMR >> Module. >> >> >> >> Have you checked that you have valid PBIF, XPP and XGMAC versions on all >> 10GE modules in the ring? >> >> >> >> Can you pass normal (non-mrp) traffic across that ring without problems. >> Do you have a topology group and member-vlans attached to that metro-ring? >> If yes, double check that the topology group is equally configured on all >> nodes. >> >> >> >> You might want to enable byte accounting on the MRP master vlan on all >> nodes or try the “dm metro-rhp” debug command to get more information from >> the nodes. >> >> >> >> >> >> *Best regards >> >> **Jan Pedersen >> **Senior Network Specialist >> D: +45 7730 2932 >> M: +45 2550 7321 >> >> * >> >> *From:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Heath Jones >> *Sent:* 11. september 2010 21:39 >> *To:* George B. >> *Cc:* foundry-nsp >> *Subject:* Re: [f-nsp] Odd MRP problem >> >> >> >> Hi George >> >> >> >> I'm really quite a newbie when it comes to MRP. RHP rcvd / sent = 8.22 >> (close to 8). Is that worth noting? >> >> 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?? >> >> >> >> Packet captures might be the way to go, if we can find the protocol spec >> from foundry.. >> >> >> >> Heath >> >> On 11 September 2010 20:02, George B. <[email protected]> wrote: >> >> See this diagram for reference: >> >> http://tinypic.com/r/kb93lj/7 >> >> 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: >> >> RHPs sent RHPs rcvd TC RBPDUs rcvd >> 509883 4193162 3684318 >> >> As you can see, it has sent about a half a million RHPs but received over >> 4 million of them! >> >> 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! >> >> Anyone else seen anything like this? It is just plain wacky! >> >> George >> >> >> _______________________________________________ >> foundry-nsp mailing list >> [email protected] >> http://puck.nether.net/mailman/listinfo/foundry-nsp >> >> >> > > > _______________________________________________ > foundry-nsp mailing list > [email protected] > http://puck.nether.net/mailman/listinfo/foundry-nsp >
_______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
