Vlan connectivity between access mode ports

[SD-Human]

Hi all,

I was wondering about if can I have connectivity between two switchs directly connected using mode access and diferents VLANs in each one. I just try it in my lab and it works but I definitely don't know why, can someone help me to understand how it's possible?

SW1:

interface FastEthernet1/3
switchport access vlan 13
duplex full
speed 100

interface Vlan13

ip address 192.0.0.1 255.255.255.248

SW2:

interface FastEthernet1/3
switchport access vlan 14
duplex full
speed 100

interface Vlan14
ip address 192.0.0.2 255.255.255.248

Results:

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 100 percent (5/5), round-trip min/avg/max = 760/925/1128 ms

ESW1#sh mac-address-table
Destination Address Address Type VLAN Destination Port
------------------- ------------ ---- --------------------
cc01.1738.0000 Self 1 Vlan1
cc01.1738.0000 Self 13 Vlan13
cc02.10b8.0000 Dynamic 13 FastEthernet1/3

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 34 cc02.10b8.0000 ARPA Vlan13

Thanks,

Jose 

[Georg Pauwen]

Hello,

proxy arp could be the 'culprit' here. Depending on what platform and IOS version you run, it is either turned on or off. Check your configuration for a line that reads 'ip proxy-arp', or try to turn it off (no ip proxy-arp), then check if you still can ping the hosts...

[cofee]

A trunk connection can carry multiples vlans and access line will only carry traffic for the assigned vlan. You can connect two switches with an access port. In your case you can either have 1 trunk connection that will carry data for both vlans 13 and 14 or have two separate access connections for each vlan like you have.

I am not sure if this is what the question is.

[Richard Burts · Accepted solution]

What is going on here has nothing to do with proxy arp and does not involve trunking. It is actually quite simple. To understand this let us start with a review of basic concepts: a vlan is a layer 2 broadcast domain. So when a device in some vlan issues a broadcast frame then this frame is forwarded through every port in that vlan.

With that in mind let us think about what is going on here. Switch 1 (in vlan 13) has IP address 192.0.0.1 and wants to communicate with address 192.0.0.2. Since the destination is in the same logical subnet there is no need for a gateway and the switch issues an arp request in vlan 13. This is a broadcast frame and is forwarded through every port in vlan 13 including FA1/3. And since it is an access port it is sent with no vlan tag - it is just a simple Ethernet frame.

So port FA1/3 on Switch 2 receives this Ethernet broadcast frame and forwards it to every port and every device in vlan 14 on Switch 2. At this point Switch 2 has learned the MAC address of Switch 1 and adds it to the layer 2 forwarding table. So the vlan 14 interface in Switch 2 responds and sends a response to the arp request. Switch 2 FA1/3 sends that Ethernet frame with the arp response out the access port. So Fa1/3 on Switch 1 receives the arp request and forwards it to the vlan 13 interface. And at this point Switch 1 has learned the MAC address of Switch 2 and adds it to the layer 2 forwarding table.

Now both switch vlan interfaces have participated in the arp process and each has learned the MAC address of the other device. So now interface vlan 13 on Switch 1 sends a ping packet to 192.0.0.2 and in the packet puts in the MAC address of the destination, which the switch knows it learned on Fa1/3. So Switch 1 sends the ping packet out Fa1/3. Switch 2 receives the Ethernet frame and forwards to the destination MAC address, which is vlan 14.

As you see here the forwarding of broadcast frames over every port in the vlan and the sending of Ethernet frames over an access port with no vlan tag allows the ping to work, and allows each switch to learn the MAC address of the neighbor and include it in the layer 2 forwarding table, and allows each switch to participate in arp and to build arp entries with the neighbor address. And there is no need for proxy arp or for trunking.

HTH

Rick

[Richard Burts]

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

[Georg Pauwen]

Rick,

your explanation makes perfect sense !

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

[SD-Human]

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

[Richard Burts]

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

[SD-Human]

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 

[Richard Burts]

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

[Richard Burts]

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

[SD-Human]

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,

[Richard Burts]

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