cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1888
Views
0
Helpful
14
Replies

Connecting Foundry to a 3560 - STP issue?

Trying to connect a Catalyst 3560 to a Foundry SX1600.

If I put port Fa 0/1 in VLAN 10 (Cisco) and unttag eth 1/1 to VLAN 101 (Foundry we get VLAN 101 blocked with inconsistent port type errors on the 3560. This setup puts both ports as access ports.

We got around that blocking issue by trunking Fa 0/1 with a trunk native VLAN 10 and allowed VLANs of 1 & 10. On the Foundry side eth 1/1 is tagged in VLAN 101. STP is not blocking anything.

The problem is that we can not ping the VLAN 10 interfaces on the 3560.

Any ideas?

2 Accepted Solutions

Accepted Solutions

In that case, cisco switch won't tag packet in vlan 10 since it's native vlan. If Foundry does tag packet in vlan 10, it could be a issue. Could you please try this:

1. make sure both sides permit the same vlan set.

2. Change the native vlan on cisco side to the vlan other than vlan 10 so that Cisco will tag the packet in vlan10.

View solution in original post

this is clearly a mismatch of native vlan in cisco terms. the cisco device is expecting untagged packets to be packets destined to vlan 10 and sending out untagged packets that came from vlan 10 and when the Foundry rx'd this untagged packet it will not send those packet out to vlan 10 thus vlan 10 is not working. If you are only interested in making this work, make the natvie vlan in 3550 to be anything else otehr than vlan 10, preferrably a non-working vlan or dummy vlan, for example vlan 99. Try it let me know if you are able to ping in vlan 10 between the foundry and the cisco.

View solution in original post

14 Replies 14

Yudong Wu
Level 7
Level 7

In general, "Inconsistent port type" indicates that one side of the link is in "trunk" mode" and the other is in "access" mode.

Use "show interface fa x/y switchport" to check which mode(trunk or access) it is. Did you add "switchport mode access" under the interface?

Also make sure that the port on Foundry switch has the same mode.

Why wouldn't I be able to ping the VLAN 10 interface on the 3560? The two ports are trunked now with VLAN 101 as an allowed VLAN so it should be layer two across that trunk. But I still can't reach the IP address for VLAN 10.

Thanks for your reply.

If you configured port as trunk on both sides, what's the native vlan? By default, Cisco switch won't tag native vlan in trunk. Did you permit vlan 10 on the trunk? Is your ping across vlan or just within one vlan?

On the Cisco side VLAN 1 & 10 are allowed across the trunk. On Foundry VLAN 10 is allowed in the trunk. I learned this morning that tagging (Foundry trunk term) doesn't apply to the default VLAN and now I just learned it doesn't apply to the default VLAN in Cisco either.

This ping request is sourcing from a VLAN 10 interface.

Can you please post the related configuration from both Cisco and Foundry switch?

Cisco:

Int Fa 0/1

switchport trunk encapsulation dot1q

switchport trunk native vlan 10

switchport trunk allowed vlan 1,10

switchport mode trunk

no ip address

Foundry:

VLAN 10

tag eth 0/1

Is vlan 1 included in trunk on Foundry switch by default? What's the output of "show interface trunk"? I am not sure how Foundry configure it's native vlan on the trunk.

Can you ping your vlan 10 interface locally on both sides?

Foundry does not allow you to tag/trunk the default VLAN...VLAN 1 in this case.

Yes, I can ping the VLAN 10 interface locally on both switches.

Port Mode Encapsulation Status Native vlan

Fa0/1 auto 802.1q trunking 10

Port Vlans allowed on trunk

Fa0/1 1,10

Port Vlans allowed and active in management domain

Fa0/1 1,10

Port Vlans in spanning tree forwarding state and not pruned

Fa0/1 1,10

Can you confirm with Foundry engineer that vlan 10 won't be tagged if it is configured by your way. I am suspecting that vlan 10 packet is tagged by Foundry switch.

I am the Foundry guy as well.

tag eth 0/1 puts the dot1q tag on the the traffic, thus creating a "trunk" in Cisco terms.

We have a 4507 connected to this same switch using the same setup and it works. The only minute difference is that we don't have VLAN 1 as an allowed VLAN.

In that case, cisco switch won't tag packet in vlan 10 since it's native vlan. If Foundry does tag packet in vlan 10, it could be a issue. Could you please try this:

1. make sure both sides permit the same vlan set.

2. Change the native vlan on cisco side to the vlan other than vlan 10 so that Cisco will tag the packet in vlan10.

this is clearly a mismatch of native vlan in cisco terms. the cisco device is expecting untagged packets to be packets destined to vlan 10 and sending out untagged packets that came from vlan 10 and when the Foundry rx'd this untagged packet it will not send those packet out to vlan 10 thus vlan 10 is not working. If you are only interested in making this work, make the natvie vlan in 3550 to be anything else otehr than vlan 10, preferrably a non-working vlan or dummy vlan, for example vlan 99. Try it let me know if you are able to ping in vlan 10 between the foundry and the cisco.

Okay...in my next change window I will address and this and report back in a couple of days. It makes complete sense now that I know it.

Thanks for your help.

Thanks for your help. The native VLAN was in fact the issue.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card