Cisco WS-C3560X-48P-S can't communicate to its uplink Meraki switch

[bilal-elkadi89]

Here’s a rephrased version of your text:

---

Hello Cisco community, I hope you're doing well.

I have a Cisco core switch connected to a Meraki switch via EtherChannel with LACP. The Meraki switch is then connected to a Cisco WS-C3560X-48P-S, which is managed with an IP address on VLAN 9 ( VLAN9 is the management VLAN on the network )

I recently encountered an STP issue between the Meraki switch and the Cisco C3560X, which I managed to resolve. However, since fixing the issue, the Cisco C3560X cannot ping the Meraki switch or the core switch using VLAN 9.

To troubleshoot, I created another SVI on VLAN 410, and with this VLAN, the C3560X could ping both the Meraki and the core switch. For reference, the default VLAN is 1. During the STP issue, I changed the default VLAN on the port channel between the core switch and the Meraki switch from VLAN 1 to VLAN 9. and the VLAN9, 1 is tagged between Meraki and Cisco C3560X 

Core IP :172.30.9.1

Cisco C3560X  IP :172.30.9.83

ICMP debug :

.Dec 10 19:12:58.859: IP: s=0.0.0.0 (Vlan9), d=255.255.255.255, len 337, input feature, MCI Check(63), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
.Dec 10 19:12:58.859: IP: s=0.0.0.0 (Vlan9), d=255.255.255.255, len 337, rcvd 1.
.Dec 10 19:13:00.259: IP: s=0.0.0.0 (Vlan9), d=255.255.255.255, len 332, input feature, MCI Check(63), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
.Dec 10 19:13:00.268: IP: s=0.0.0.0 (Vlan9), d=255.255.255.255, len 332, rcvd 1
.Dec 10 19:13:00.721: IP: s=0.0.0.0 (Vlan9), d=255.255.255.255, len 332, input feature, MCI Check(63), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
.Dec 10 19:13:00.721: IP: s=0.0.0.0 (Vlan9), d=255.255.255.255, len 332, rcvd 1
.Dec 10 19:13:01.417: IP: s=172.30.9.83 (local), d=172.30.9.1 (Vlan9), len 100, encapsulation failed
.Dec 10 19:13:01.417: IP: s=0.0.0.0 (local), d=172.30.9.1, len 100, local feature, RCLI(7), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
.Dec 10 19:13:01.417: IP: s=0.0.0.0 (local), d=172.30.9.1, len 100, local feature, Local Clustering(8), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
.Dec 10 19:13:01.417: IP: tableid=0, s=0.0.0.0 (local), d=172.30.9.1 (Vlan9), routed via RIB
.Dec 10 19:13:01.417: IP: s=172.30.9.83 (local), d=172.30.9.1 (Vlan9), len 100, sending
.Dec 10 19:13:01.417: IP: s=172.30.9.83 (local), d=172.30.9.1 (Vlan9), len 100, output feature, Check hwidb(72), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE .
.Dec 10 19:13:03.556: IP: s=0.0.0.0 (Vlan9), d=255.255.255.255, len 332, input feature, MCI Check(63), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
.Dec 10 19:13:03.556: IP: s=0.0.0.0 (Vlan9), d=255.255.255.255, len 332, rcvd 1
.Dec 10 19:13:04.437: IP: s=172.30.9.83 (local), d=172.30.9.1 (Vlan9), len 100, encapsulation failed
.Dec 10 19:13:04.437: IP: s=0.0.0.0 (local), d=172.30.9.1, len 100, local feature, RCLI(7), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
.Dec 10 19:13:04.437: IP: s=0.0.0.0 (local), d=172.30.9.1, len 100, local feature, Local Clustering(8), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
.Dec 10 19:13:04.437: IP: tableid=0, s=0.0.0.0 (local), d=172.30.9.1 (Vlan9), routed via RIB
.Dec 10 19:13:04.437: IP: s=172.30.9.83 (local), d=172.30.9.1 (Vlan9), len 100, sending
.Dec 10 19:13:04.437: IP: s=172.30.9.83 (local), d=172.30.9.1 (Vlan9), len 100, output feature, Check hwidb(72), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE .
.Dec 10 19:13:07.473: IP: s=172.30.9.83 (local), d=172.30.9.1 (Vlan9), len 100, encapsulation failed
.Dec 10 19:13:07.473: IP: s=0.0.0.0 (local), d=172.30.9.1, len 100, local feature, RCLI(7), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
.Dec 10 19:13:07.473: IP: s=0.0.0.0 (local), d=172.30.9.1, len 100, local feature, Local Clustering(8), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
.Dec 10 19:13:07.473: IP: tableid=0, s=0.0.0.0 (local), d=172.30.9.1 (Vlan9), routed via RIB
.Dec 10 19:13:07.473: IP: s=172.30.9.83 (local), d=172.30.9.1 (Vlan9), len 100, sending
.Dec 10 19:13:07.473: IP: s=172.30.9.83 (local), d=172.30.9.1 (Vlan9), len 100, output feature, Check hwidb(72), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
.Dec 10 19:13:08.438: IP: s=0.0.0.0 (Vlan9), d=255.255.255.255, len 338, input feature, MCI Check(63), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
.Dec 10 19:13:08.438: IP: s=0.0.0.0 (Vlan9), d=255.255.255.255, len 338, rcvd 1.
Success rate is 0 percent (0/5)
SW-4F-TrainingRoom1#
.Dec 10 19:13:10.451: IP: s=0.0.0.0 (Vlan9), d=255.255.255.255, len 332, input feature, MCI Check(63), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
.Dec 10 19:13:10.451: IP: s=0.0.0.0 (Vlan9), d=255.255.255.255, len 332, rcvd 1
.Dec 10 19:13:10.502: IP: s=172.30.9.83 (local), d=172.30.9.1 (Vlan9), len 100, encapsulation failed

---

Let me know if you need further adjustments!

[Flavio Miranda]

@bilal-elkadi89 

Can you run the command "show spanning-tree vlan 9" on both core  and C3560X ?

[bilal-elkadi89]

Hello Flavio

For VLAN 9 the root bridge is the C3560X, on the core switch it shows itself as the root bridge
FYI : ping from SVI VLAN 410 to the core its working 

 C3560X :

VLAN0410
Spanning tree enabled protocol rstp
Root ID Priority 33178
Address 0006.f69f.2c80
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 33178 (priority 32768 sys-id-ext 410)
Address 0006.f69f.2c80
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/4 Desg FWD 4 128.52 P2p

VLAN0009
Spanning tree enabled protocol rstp
Root ID Priority 32777
Address 0006.f69f.2c80
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32777 (priority 32768 sys-id-ext 9)
Address 0006.f69f.2c80
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/4 Desg FWD 4 128.52 P2p Peer(STP)

[Flavio Miranda]

Core and 3560 is root for vlan 9?

[bilal-elkadi89]

As you can see yes, I think because there's no communication between them, so they can't communicate BDPU packets to force core as root bridge

[Flavio Miranda]

That´s a good point. But, the lack of communication can be related to spanning-tree. If you are using more than one spanning-tree flavor, I would recommend to check the config first and try to use one flavor only.

[ammahend]

as recommended most likely its STP issue, adjust the priority on Meraki Switch and make sure right switch is the root for all vlans, under switch>Swich Settings

once done verify on Meraki switch by clicking on switch and looking under RSTP root

[bilal-elkadi89]

Thank you for your reply

The Core switch STP priority is the lowest one for all vlans : 4096

On Meraki its :

[ammahend]

can you confirm its actually working that way by making sure the Meraki switch sees Core as root ?

[bilal-elkadi89]

Do you know how to check that pls ?

[ammahend]

When you click on Meraki switch, scroll down half way to the page on the left you will see rstp root. Follow this documentation about using third party switch with Meraki 

https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Configuring_Spanning_Tree_on_Meraki_Switches_(MS)

[paul driver]

Hello
You running two spanning modes and what you encountered suggests you ran into a pvst simulation.where switchs(s) running Rstp/pvst spanning tree interconnecting switch(s) running MST spanning-tree didnt not agree on the port roles between themselves so went into inconsistent state

Note:
MST =per instance stp
Pvst/Rstp = pervlan stp

So the switch(s) interconnecting these two stp domains can only really speak to each other via their respective vlan1 or msti0  instance so the RSTP/PVST switches can determine a port state for all it per stp vlans.

Most simplistic way to avoid this simulation is to make the MST switch the stp root and you can do this by giving the mst0 instance of the mst switch the lowest preferred stp priority for all of the rstp/pvst switch vlans

[bilal-elkadi89]

Hello Paul

my question, if what you suggest is the problem, why could I ping the core switch with source vlan 410 and cannot do it with vlan 9 ?

[bilal-elkadi89]

FYI I'm running 3 stp mode type

Core switch : MSTP

Meraki : RSTP

Cisco switch : Rapid-PVST

[bilal-elkadi89 · Accepted solution]

Hello everyone

I got the problem resolved, I checked with the IT on-site, and after many tries, I found that the cable was inserted into the wrong physical port , after plugging it into the correct port I had the ping back and SVI VLAN 9 up

Thank you everyone