[f-nsp] Odd MRP problem

George B. georgeb at gmail.com
Sun Sep 12 04:10:25 EDT 2010


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 <
Jan.Pedersen at globalconnect.dk> 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:* foundry-nsp-bounces at puck.nether.net [mailto:
> foundry-nsp-bounces at puck.nether.net] *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. <georgeb at gmail.com> 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
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20100912/b918e70c/attachment.html>


More information about the foundry-nsp mailing list