I have a couple of comments about this which I hope may be helpful. Fundamentally the environment given here with Switch 1 having vlan 13 on Fa1/3 and Switch 2 having vlan 14 on Fa1/3 breaks several fundamental aspects of how networks should operate.

First we should remember that while we have called tis two vlans (vlan 13 and vlan 14) the reality is that there is a single broadcast domain that spans both switches and therefore really there is only one vlan here.

There is an assumption that when you connect an access port in some vlan to an access port of another switch that the other switch will use the same vlan on that access port. That is not the case in this example. On the surface this does not seem to be a big deal. But it does have potential impacts including an impact on Spanning Tree. When Switch 1 sends a Spanning Tree BPDU our Fa1/3 it is looking for possible loops in the network. But the BPDU does identify the vlan for which it operates. So Switch 2 sees a BPDU in vlan 14 with an ID of vlan 13 and does not process the BPDU. So there could be a true Spanning Tree loop in this network and Spanning Tree would not find it. (I learned this lesson the hard way)

Also there is an assumption that an IP subnet should exist in only one place in a network. But here we are saying that subnet 192.0.0.0 exists in vlan 13 and also exists in vlan 14.

This thread asks a question of how something did work that the original poster thought would not work. And the reality is that if the network were correctly designed and correctly configured then it would not work.

HTH

Rick

Rick,

your explanation makes perfect sense !

I missed that both hosts and VLANs are configured with the same IP address range...:(

Hi Rick!

Thanks for your time to find out the answer to my question.

Today I notice about during my testing I configured both vlans in each SW (vlan database); so today I removed the vlan 14 from SW1 and vlan 13 from SW2 and then, there is no ping connectivity and ARP. How does this fit into your previous analysis?

To be honest the previus behavior was very confusing to me, and now it's taking sense.

ESW1#sh vlan-switch brief

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa1/0, Fa1/1, Fa1/2, Fa1/4
Fa1/5, Fa1/6, Fa1/7, Fa1/8
Fa1/9, Fa1/10, Fa1/11, Fa1/12
Fa1/13, Fa1/14, Fa1/15
13 VLAN0013 active Fa1/3
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active

ESW1#ping 192.0.0.2 source 192.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.0.2, timeout is 2 seconds:
Packet sent with a source address of 192.0.0.1
.....
Success rate is 0 percent (0/5)

ESW1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.0.0.1 - cc01.1738.0000 ARPA Vlan13
Internet 192.0.0.2 0 Incomplete ARPA

ESW2#sh vlan-switch brief

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa1/0, Fa1/1, Fa1/2, Fa1/4
Fa1/5, Fa1/6, Fa1/7, Fa1/8
Fa1/9, Fa1/10, Fa1/11, Fa1/12
Fa1/13, Fa1/14, Fa1/15
14 VLAN0014 active Fa1/3
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active

Cheers,

Jose

Georg

It is easy to miss that detail. With two vlans involved we assume different subnets. And with no default gateway in the description, then proxy arp would be the logical explanation.

Jose

I am puzzled at the effect of the change. In my experience it is not necessary for both vlans to exist on both switches. So I have a few questions to try to find why it is acting in this way:

- are these real switches or is this in a software simulated  network?

- what kind of switches are these?

- can you post the output on both switches of these commands

   show ip interface brief

   show interface status

   show cdp neighbor

HTH

Rick

Hi Rick,

 I don't know why but today when I was ready to gather the outputs, the ping worked (without configuration change). Maybe yesterday it was just a bug or interface block after change...

Just to clarify, it is a GNS3 simulation.

Anyway your previous explanation is right in spite of the general idea. I guess that this practice is not recommended.

Thanks,

Jose 

Jose

Thanks for letting us know that the ping between vlans is working now with just the single vlan on a switch.I am not sure why it did not work yesterday. Perhaps GNS3 was still adapting to the changes.

You are correct that this practice is not recommended. While it did work in the small scale of your current configuration, it would have caused problems if you attempted this practice in a larger and more complex network.

I believe that originally you expected that this would not work. And based on normal network configuration principles it would not have worked. Perhaps the most important thing to understand here is that while you gave the vlans different names that in fact there was a single vlan that was on both switches. Remembering that a vlan is a broadcast domain and there was a single broadcast domain in what you configured. It just had two names.

HTH

Rick

There is another point I would like to make about the fact that really there was a single vlan that was present on both switches. When you have two devices connected in a single vlan then these devices should be able to communicate directly, without needing gateways, or routers, or anything else. This is the single most important thing about why your configuration allowed the two switches to communicate.

HTH

Rick

Hi Rick!

Thanks for your full explanation.

If for example we add a trunk between the SW1 and SW2 then there is no way to get connectivity right ? as tagging is comming on the scene.

for example:

[SW1] <---Access (vlan 13)---> [SW3] <---Trunk---> [SW4] <--Access (vlan 14)--> [SW2]

Thanks,

Jose,

Jose

You are welcome. Yes if you add a trunk in the connection between SW 1 and SW 2 then the vlan ID is part of the tag on the trunk and then there are clearly two vlans (two separate broadcast domains) and to get the ping from vlan 13 into vlan 14 would require a layer 3 forwarding device (and at that point having the same subnet in two different places becomes more of an issue). So the bottom line is that if there was a trunk in the connection between SW 1 and SW 2 then the ping would not work.

HTH

Rick