RSTP Root bridge with backup port Over VPLS backbone

[claudemarcel]

Hello everyone ,

Please i'm facing something which seems to be weird. I'm working for a service provider and i've encounter something . One customer were having hostflapping and there were high CPU utilization on our POPs see the attached file i draw just for giving you an image of the topology.

Before that POP2 was having g1/1 Desg (FWD) because PWID was missing on the PE's int eth 1/2, when i correc that the POP2's interface g1/1 went to Altn (Blk).

IOU1: represent the first POP1 and is the Root bridge

IOU2 is the othe POP2

IOU3 and IOU4 :represents our PEs which are non cisco PEs (redback) ( with pseudowire ID 34 configured on each interfaces).

SW1 and SW2 : are in vlan 100 and allowing vlan 100 on the trunk to POP1 and POP2 respectivelly.

When troubleshooting i've discovered that , the ROOT  with show spanning-tree vlan 100 that int g1/4 was playing Backup(Blocking) role and i see P2P on this interface at the end . my g1/4 interface is not negociating half-duplex this means is in full-duplex , the POP1 eth 1/1 is in full-duplex , the PWID34 is correctly configured on each interfaces of all my POPs.

According even though i'm passing through the VPLS network , my POPs see each other as if there directly connected so why i've a backup port on g1/4 ?

The theory about RSTP the proposal/agreement process is supposed to put all the interfaces of POP1 ( f2/1,g1/3 and g1/4 in Designated Forwarding).

On the other side POP2 curiosly i've the expected behavior of the ports roles : f1/3 Designated Forwarding,g1/2 Desg(FWD) ,g1/1 Altn (Blk).

Is it normal to have a backup port on the ROOT bridge ? I think it shouldn't be the cas but i don't understand what could have made such a behaviour.

Thank you in advance for you help.

[claudemarcel]

Correction : When troubleshooting i've discovered that , the ROOT  with show spanning-tree vlan 100 that int g1/4 was playing Backup(Blocking) role and i see P2P on this interface at the end . my g1/4 interface is not negociating half-duplex this means is in full-duplex , the POP1 eth 1/1 is in full-duplex , the PWID34 is correctly configured on each interfaces of all my POPs.

When troubleshooting i've discovered that , the ROOT  with show spanning-tree vlan 100 that int g1/4 was playing Backup(Blocking) role and i see P2P on this interface at the end . my g1/4 interface is not negociating half-duplex this means is in full-duplex , the POP1 eth 1/1 is in full-duplex , the PWID34 is correctly configured on each interfaces of all my PEs

[Peter Paluch · Accepted solution]

Hello,

The fact that POP1 g1/4 is in the Backup role means that POP1 hears its own BPDUs sent from g1/3 back on its g1/4 port. For some reason, BPDUs sent out from g1/3 on POP1 loop through the VPLS network and are delivered back to POP1's g1/4. This should not have happened.

Is it possible that all frames received from POP1 by one PE (IOU4) are forwarded to the other PE (IOU5) and thus back to POP1?

By the way, is the network in the middle truly a VPLS, or is it just a mesh of manually configured pseudowires? If it is VPLS then we should not be talking about individual pseudowires and their manual configuration. Remember that VPLS is a multipoint, LAN emulation service rather than a point-to-point interconnect.

The theory about RSTP the proposal/agreement process is supposed to put all the interfaces of POP1 ( f2/1,g1/3 and g1/4 in Designated Forwarding).

Not entirely true. First of all, the Proposal/Agreement process is not concerned with port role selection. The task of Proposal/Agreement is to put a link to a forwarding mode rapidly after it has been established that one end of the link is Designated Discarding and the other end is Root Discarding - that is, after the roles have already been determined. Second, whether all ports of a root switch are in Designated Forwarding state depends on the actual network topology, and it is possible even for a root switch to have one or more ports in Backup Discarding role and state.

Is it normal to have a backup port on the ROOT bridge ?

Yes if the BPDUs of the root switch loop back to the same switch. Remember, the Backup port role means that the port is worse than some other port on the same switch. This implies that the switch hears itself on two or more ports, or in other words, that two or more of its own ports have been connected to each other.

Feel welcome to ask further!

Best regards,
Peter

[claudemarcel]

@Peter Paluch,

Thank you for your reply ,  of course it is a mesh of manually configured pseudowires. We have some situations where we are making point-to-point LAN emulation when we only have customer on two sites and we have cases it is a Multipoint simulation.

Sorry could you please try to draw with arrows to explain me what happens so that g1/4 received his own BPDUs in case of as mesh of manually configured pseudowire.

Thank for correcting me about the theory of RSTP. 

I'm glad to share with you. 

I was thinking about the possibility that g1/4 receives his own BPDUs but i can't the reason why it is like that and i'm glad that you noticed that it shouldn't have happened.

Could you attached some scenarios with the file i've sent , to give an image of could have possibily happened.

Thank you in advance Peter.

Kind Regards

[Peter Paluch]

Hi,

You are welcome.

Sorry could you please try to draw with arrows to explain me what happens so that g1/4 received his own BPDUs in case of as mesh of manually configured pseudowire.

Perhaps a verbal description will suffice. I will use the terminology from the diagram you have attached to your original post.

Please keep in mind that I do not really know what is going on in your network - this is just an attempt to provide a scenario that would explain the behavior you're seeing. Take the following explanation in thise sense please.

So, assume that IOU1 sends a BPDU out of its g1/3 port. This BPDU will be received by IOU5 and forwarded both to IOU2 and IOU4. IOU4 takes this BPDU and forwards it to IOU2 and back to IOU1 on its g1/4 which causes IOU1 to receive its own BPDU.

Is this scenario plausible?

Best regards,
Peter

[claudemarcel]

Hi Peter,

This scenario is plausible. Another scenario is possible , IOU1 could send BPDUs on g1/3 and g1/4 at the same time . IOU4 forwards the BPDUs to both IOU2 and IOU5.

IOU5 forwards BPDUS to IOU2 and IOU 4. Then IOU4 and IOU5 forward those BPDUs back to IOU1 on g1/3 and g1/4. On this scenario IOU1 receives its own BPDUs on Both interfaces which means that thoses interfaces should take the Backup role. Or May be on this scenario, the IOU1 use the same process : the lowest RBID,the lowest SBID, the lowest RPC, the lowest PID to choose , the lowest sender BID to decide which port is going to be designated (in this case g1/3) and which port is going to be the Backup (in this case g1/4). 

Additionnal Information : On IOU4 and IOU5 excuse me i forgotten to tell you there is a loop detection mechanism. Does that change anything?

Best Regards

[Peter Paluch]

Hello,

This scenario is plausible.

I see. In that case, however, I wonder how is your "VPLS" network configured that it causes these phenomenons to occur. This looping does not occur in a common VPLS network. How are your pseudowires configured? Are they point-to-point pseudowires, or is there some kind of a multidestination pseudowire configured anywhere?

Another scenario is possible , IOU1 could send BPDUs on g1/3 and g1/4 at the same time . IOU4 forwards the BPDUs to both IOU2 and IOU5.IOU5 forwards BPDUS to IOU2 and IOU 4. Then IOU4 and IOU5 forward those BPDUs back to IOU1 on g1/3 and g1/4. On this scenario IOU1 receives its own BPDUs on Both interfaces which means that thoses interfaces should take the Backup role.

This should not be possible. A BPDU sent from IOU1 g1/3 should not be looped back to that port - otherwise the switch would put it in the BKN (broken) state and keep it blocked. In my original scenario, I focused only on a single possible loop of the superior BPDU from gi1/3 toward g1/4. It is certainly possible that BPDUs go from g1/3 over IOU5 to IOU4 to IOU1 g1/3, and vice versa. However, the loop I have described is responsible for causing g1/4 to become Backup Discarding.

Additionnal Information : On IOU4 and IOU5 excuse me i forgotten to tell you there is a loop detection mechanism. Does that change anything?

I am not sure. This description is too general. What kind of loop detection mechanism is that?

Best regards,
Peter

[claudemarcel]

Hello,

I see. In that case, however, I wonder how is your "VPLS" network configured that it causes these phenomenons to occur. This looping does not occur in a common VPLS network. How are your pseudowires configured? 

VPLS implementations on Redback PEs is a little bit different from VPLS implementation on Cisco. 

Are they point-to-point pseudowires, or is there some kind of a multidestination pseudowire configured anywhere?

Yes there is a multidestination pseudowire, I focused only on 2 PEs because it was where i  faced the issue.

Additionnal Information : On IOU4 and IOU5 excuse me i forgotten to tell you there is a loop detection mechanism. Does that change anything?

I am not sure. This description is too general. What kind of loop detection mechanism is that?

Please don't care about the mechanism of the loop detection , it has anything related with the problem i described earlier.

Thank you peter , you 've opened my eyes. It is important to have discussions like that , with differents point of view , It seems to me clear now about the behaviour. It was the first time to me to see such a thing and i was wondering enough about it.

Thanks again.

Best Regards.

Claude Marcel

[Peter Paluch]

Hi Claude,

Thank you for the kind words. You are always welcome. Here at Cisco Support Community, we will always be glad to help to the best of our abilities.

Best regards,
Peter