Re: Layer 2 Switching Loop

mparham6 · ‎08-22-2019

Current architecture/config is described in picture below. My issue is that I'm unable to ping Host B from Host A, and vice-versa. The two radios pictures are configured as a bridge. If I add Host A's MAC address statically on VLAN 42 associated with ports 1 and 47, as well as add Host B's MAC address statically on ports 2 and 48, then my pings are successful. However, this is apparently creating a switching loop, because after I initiate the ping I can see that RADIO1 is still receiving packets to forward from the switch. Removing the static MAC addressing and leaving it up to the switch to learn dynamically results in failure to ping alltogether.

My purpose for doing this is that I'm having to test traffic from Host A to Host B, and vice-versa. Wondering if there's a way I can continue to have this working but fix the looping error? I have tried other configurations of STP but with no luck. Either the loop continues to happen or the pings fail alltogether.

Am I able to create a bridge between ports 1 and 47, and separately 2 and 48? Thoughts?

Reza Sharifi · ‎08-22-2019

Ports connecting to hast A and B (1/0/1 and 1/0/2) should be configured as access ports.

example:

interface gi1/0/1

switchport mode access

switchport access vlan 42

Also, on the radio side if you use the same vlan (42) they could also be configured access port.

The only time you need a trunk port is when you have multiple vlans traversing the same interface.

HTH

mparham6 · ‎08-23-2019

Hi Reza,

Thanks for the reply! I'm currently VLAN tagging from the hosts themselves (the NICs are VLAN tagging capable). Additionally, the trunk ports are configured due to the fact that in other configurations I'm able to route traffic across this architecture via a separate VLAN, and I flip-flop between these configurations on the hosts/radios frequently. However, that setup works because in that particular configuration the radios have Default Gateway IP's. In this config, there are no DG's setup and the radios are setup to act as a simple bridge.

I'm able to pass traffic between hosts when cutting out the switch and connecting directly to the radios. Something about this switch config is not allowing the packets to reach their destination.

Reza Sharifi · ‎08-23-2019

Hi,

Thanks for the further explanation. For testing and to eliminate STP issues, can you disable one of the radios and run the same test?

HTH

mparham6 · ‎08-26-2019

Unsure what you mean by "disable one of the radios". I broke the RF connnection between the radios and the loop stopped. Not sure if that answers your question?

Giuseppe Larosa · ‎08-23-2019

Hello mparham6,

I think you should use a different lab setup to test your radio repeaters.

You should use two switches and you should interconnect them via the two radio repeaters

The more appropriate setup could be the following:

PCA --> wired on port 1/01 -- switch 1 --- gi1/47--- RP1 RF RP2 --- gi1/48 --- Switch2 --- gi1/0/2 -- PCB

You can eventually add a wired link between switch1 and switch2 and make the RF link a backup link by playing with spanning-tree commands using two other ports.

I think this is more near what is used in real world.

Also in your network setup you use MAC address based ACLs in outbound that could block STP BPDUs that are not permitted by your MAC ACLs and this is probably the reason why the loop is formed.

Hope to help

Giuseppe

mparham6 · ‎08-26-2019

Hi Giuseppe, thanks for the reply!

So I know for a fact that this will work if using your suggested setup, but unfortunately due to certain limitations I absolutely need to try and get this working across one physical switch.

Is there a way to exclude BPDU messages from being blocked by my MAC ACL's?

What I'm trying to accomplish may not be possible, but I'd honestly be surprised if the only solution is to put each radio onto their own physical switch.

Thanks

Giuseppe Larosa · ‎08-26-2019

Hello mparham6,

>> What I'm trying to accomplish may not be possible, but I'd honestly be surprised if the only solution is to put each radio onto their own physical switch.

Using RF links is done when it is not possible to pass fiber cables to interconnect switches.

Putting each radio onto their own physical switch is exactly the most common use case in real world networks.

And just as a side note in some cases these RF links create troubles to spanning tree if they are not stable.

I don't know why you would like to have two Radios on the same switch I don't see a practical use case for this.

Either you remove your MAC ACLs (but I am not sure this is enough to have a stable network) or you change the setup as I suggested.

Hope to help

Giuseppe

mparham6 · ‎08-29-2019

"I don't know why you would like to have two Radios on the same switch I don't see a practical use case for this."

-> I'm testing the capabilities of the radios in this network. The two hosts on either end are being used to test host-to-host traffic that traverses the radios, and I'm currently limited to one physical switch. I understand the more practical use would be to purchase a second switch for the second radio, but I do not have that option at the moment.

"Either you remove your MAC ACLs (but I am not sure this is enough to have a stable network) or you change the setup as I suggested."

-> I actually need the MAC ACLs in place to ensure that other types of traffic (SNMP, for example) are leaving the switch destined for the correct radio. Without the MAC ACL's in place, it's possible for traffic from Host 1 to reach Radio 2 and Host 2 to reach Radio 1.

Giuseppe Larosa · ‎08-29-2019

Hello mparham6,

>> > I'm testing the capabilities of the radios in this network. The two hosts on either end are being used to test host-to-host traffic that traverses the radios, and I'm currently limited to one physical switch. I understand the more practical use would be to purchase a second switch for the second radio, but I do not have that option at the moment.

OK you have not a second switch, but I think your lab setup does not provide any useful info: all issues you are seeing are caused by the lack of a second switch.

It is like connecting with a LAN cable two ports configured for spanning portfast + spanning-tree BPDU filter: you get a bridging loop.

Find a way to get another switch and you will be able to make meaningful tests.

Hope to help

Giuseppe