Mailing List Archive: nsp: foundry

Odd MRP problem

Index | Next | Previous | View Threaded

georgeb at gmail

Sep 11, 2010, 12:02 PM

Post #1 of 14 (1996 views)
Permalink

Odd MRP problem

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

Peter.Olsen at GlobalConnect

Sep 11, 2010, 12:31 PM

Post #2 of 14 (1948 views)
Permalink

Re: Odd MRP problem [In reply to]

Strange,

We have 150+rings active, never seen anything like this.

Except for the very strange numbers, is the ring working ? (is it only
a 'counting' issue)

Br,

Peter

From: foundry-nsp-bounces [at] puck
[mailto:foundry-nsp-bounces [at] puck] On Behalf Of George B.
Sent: 11. september 2010 21:02
To: foundry-nsp
Subject: [f-nsp] Odd MRP problem

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

hj1980 at gmail

Sep 11, 2010, 12:39 PM

Post #3 of 14 (1948 views)
Permalink

Re: Odd MRP problem [In reply to]

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> 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
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

georgeb at gmail

Sep 11, 2010, 12:41 PM

Post #4 of 14 (1950 views)
Permalink

Re: Odd MRP problem [In reply to]

I have MRP in production without this issue, too. I have never seen
anything like it. I can't understand how I can receive more RHP packets
than I send. CPU goes up on the line cards, the state of the secondary
interface flaps between blocking and forwarding, it just gets into a bad
state. As long as I don't have all the members configured and leave at
least one not configured with MRP, it works as expected. The one thing I
haven't done is to try to make a different unit the master.

On Sat, Sep 11, 2010 at 12:31 PM, Peter Olsen
<Peter.Olsen [at] globalconnect>wrote:

> Strange,
>
>
>
> We have 150+rings active, never seen anything like this.
>
> Except for the very strange numbers, is the ring working ? (is it only a
> �counting� issue)
>
>
>
> *Br,*
>
> *Peter*
>
> * *
>
>
>
> *From:* foundry-nsp-bounces [at] puck [mailto:
> foundry-nsp-bounces [at] puck] *On Behalf Of *George B.
> *Sent:* 11. september 2010 21:02
> *To:* foundry-nsp
> *Subject:* [f-nsp] Odd MRP problem
>
>
>
> 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
>

georgeb at gmail

Sep 11, 2010, 12:45 PM

Post #5 of 14 (1950 views)
Permalink

Re: Odd MRP problem [In reply to]

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.

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.

George

On Sat, Sep 11, 2010 at 12:39 PM, Heath Jones <hj1980 [at] gmail> wrote:

> 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> 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
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>
>

hj1980 at gmail

Sep 11, 2010, 1:01 PM

Post #6 of 14 (1946 views)
Permalink

Re: Odd MRP problem [In reply to]

So for it to be flapping between blocking / forwarding, the unit would have
to either be receiving (or thinking its receiving) tcn's?

On 11 September 2010 20:45, George B. <georgeb [at] gmail> wrote:

> 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.
>
> 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.
>
> George
>
>
>
> On Sat, Sep 11, 2010 at 12:39 PM, Heath Jones <hj1980 [at] gmail> wrote:
>
>> 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> 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
>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>
>>
>>
>

Jan.Pedersen at GlobalConnect

Sep 12, 2010, 12:46 AM

Post #7 of 14 (1940 views)
Permalink

Re: Odd MRP problem [In reply to]

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
[mailto:foundry-nsp-bounces [at] puck] 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> 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
http://puck.nether.net/mailman/listinfo/foundry-nsp

georgeb at gmail

Sep 12, 2010, 1:10 AM

Post #8 of 14 (1943 views)
Permalink

Re: Odd MRP problem [In reply to]

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> 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 [mailto:
> foundry-nsp-bounces [at] puck] *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> 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
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>

harbor235 at gmail

Sep 12, 2010, 5:39 AM

Post #9 of 14 (1938 views)
Permalink

Re: Odd MRP problem [In reply to]

Is spanning tree disabled on vlan 2?

harbor235

On Sun, Sep 12, 2010 at 4:10 AM, George B. <georgeb [at] gmail> 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 <
> Jan.Pedersen [at] globalconnect> 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 [mailto:
>> foundry-nsp-bounces [at] puck] *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> 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
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>>
>>
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

georgeb at gmail

Sep 12, 2010, 12:09 PM

Post #10 of 14 (1939 views)
Permalink

Re: Odd MRP problem [In reply to]

Oops, meant to reply all. No spanning tree anywhere on that vlan. In this
case it is vlan 111 and metro ring 2

On Sun, Sep 12, 2010 at 5:39 AM, harbor235 <harbor235 [at] gmail> wrote:

> Is spanning tree disabled on vlan 2?
>
> harbor235
>
>
> On Sun, Sep 12, 2010 at 4:10 AM, George B. <georgeb [at] gmail> 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 <
>> Jan.Pedersen [at] globalconnect> 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 [mailto:
>>> foundry-nsp-bounces [at] puck] *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> 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
>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp [at] puck
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>
>

mike at linx

Sep 13, 2010, 3:23 AM

Post #11 of 14 (1943 views)
Permalink

Re: Odd MRP problem [In reply to]

--On 12 September 2010 12:09 -0700 "George B." <georgeb [at] gmail> wrote:

> Oops, meant to reply all. No spanning tree anywhere on that vlan. In
> this case it is vlan 111 and metro ring 2

Is there any link-aggregation present on this ring?

It could be something like source-port suppression failing on a LAG group.

Mike
--
Mike Hughes Chief Technical Officer London Internet Exchange Ltd.
mike [at] linx http://www.linx.net/
Registered in England 3137929 at Trinity Court, Peterborough, PE1 1DA

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

georgeb at gmail

Sep 27, 2010, 1:26 AM

Post #12 of 14 (1875 views)
Permalink

Re: Odd MRP problem [In reply to]

On Mon, Sep 13, 2010 at 3:23 AM, Mike Hughes <mike [at] linx> wrote:

> --On 12 September 2010 12:09 -0700 "George B." <georgeb [at] gmail> wrote:
>
> > Oops, meant to reply all. No spanning tree anywhere on that vlan. In
> > this case it is vlan 111 and metro ring 2
>
> Is there any link-aggregation present on this ring?
>
> It could be something like source-port suppression failing on a LAG group.
>
> Mike
>
>
Yes, there is a LAG in the ring. There are two 1G ports aggregated between
two routers at one site.

George.

mike at smashing

Sep 27, 2010, 2:04 AM

Post #13 of 14 (1878 views)
Permalink

Re: Odd MRP problem [In reply to]

--On 27 September 2010 01:26:31 -0700 "George B." <georgeb [at] gmail> wrote:

> Yes, there is a LAG in the ring. There are two 1G ports aggregated
> between two routers at one site.

Okay, so what this could be is either:

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.

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.

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.

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.

Just some ideas to investigate.

Mike

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

georgeb at gmail

Feb 5, 2011, 2:13 PM

Post #14 of 14 (1552 views)
Permalink

Re: Odd MRP problem [In reply to]

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.

On Mon, Sep 27, 2010 at 2:04 AM, Mike Hughes <mike [at] smashing> wrote:

> --On 27 September 2010 01:26:31 -0700 "George B." <georgeb [at] gmail>
> wrote:
>
> Yes, there is a LAG in the ring. There are two 1G ports aggregated
>> between two routers at one site.
>>
>
> Okay, so what this could be is either:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Just some ideas to investigate.
>
> Mike
>

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads