I have a question about switching. I have two devices connected to a switch with IP addresses and Both devices have the same prefix, /24. That means they are on the same subnet.

If I split these devices on different VLANs (10 and 20) on the switch, it will not communicate although they are on same subnet. Why does that happen?

  • 3
    You need a router to route between different Vlans. Also, when doing that, you cannot have the same IP subnet on those two Vlans.
    – user36472
    Commented Apr 11, 2019 at 11:34
  • 5
    Hello Jim Pap and welcome ... It's like you plugged your two hosts into two different switches, one labelled "LAN 10" and the other labelled "LAN 20". Configuring VLANs on your switch divides your switch into multiple, virtual, switches.
    – jonathanjo
    Commented Apr 11, 2019 at 11:44
  • 3
    This question is somewhat of a tautology. They can't because they can't, by design. The creation of separate VLANs logically segments the switched internetwork. You now need to use some form of inter-VLAN routing for these devices to communicate. Commented Apr 11, 2019 at 16:19
  • 1
    @Cown it is not possible on a Cisco router to have addresses from the same subnet on different interfaces, but this has little to do with the VLAN themselves which don't care about IP addresses (and could be use with, say, IPX/SPX). And... Cisco is sill an important actor but far from the only one.
    – JFL
    Commented Apr 12, 2019 at 17:17
  • 1
    @Cown how would different VRFs help? They would not communicate anyway then, and to answer your question simply bridge the vlans, as simple as that. Bridging has been available in Cisco routers since long before I took my CCIE and that was over 20 years ago Commented Apr 12, 2019 at 17:21

9 Answers 9


One of the things VLAN's do is take a physical switch and break them up into multiple smaller "virtual" switches.

Meaning this Physical depiction of One switch and Two VLANs:

enter image description here

Is identical in operation to this Logical depiction of the same topology:

enter image description here

Even if the IP addresses in the 2nd image were in the same Subnet, you'll notice there is no "link" between the two virtual switches (i.e., VLANs), and therefore no possible way Hosts A/B can communicate with Hosts C/D.

In order for the hosts in the 2nd image to communicate with one another, you would need some sort of device to facilitate the communication from one "switch" to the other. The device that exists for that purpose is a Router -- hence, a Router is required for traffic to cross a VLAN boundary:

enter image description here

And due to how Router's work, each router interface must have it's own, unique IP Subnet. That is why every VLAN traditionally requires it's own unique IP subnet -- because if any communication is to happen between those VLANs, unique subnets will be required.

The images above are from my blog, you can read more about VLANs as a concept here, and about Routing between VLANs here.

  • 2
    Trap for the unwary: Do not try to actually split a switch that way, THEN connect VLANs via untagged ports - unless you know exactly how the STP and CAM implementations in that switch are set up. Commented Apr 11, 2019 at 15:31
  • 2
    @rackandboneman That is good advice. But, a point of clarity, the images in my post represent only one physical switch. The "two switch image" is the logical representation of one physical switch with two VLANs.
    – Eddie
    Commented Apr 11, 2019 at 20:48
  • 2
    " each router interface must have it's own, unique IP Subnet.", that may be true for some router implementations, it's not universally true. At least on Linux you can assign the same subnet to multiple interfaces, then use a combination of proxy arp and /32 routes to make traffic flow between them. Commented Apr 12, 2019 at 16:55
  • @PeterGreen Exceptions always exist. Just because something can be done, doesn't mean it should be done -- nor does it make it relevant for the question at hand.
    – Eddie
    Commented Apr 13, 2019 at 17:38

The whole point of Virtual LAN, is to create separate Layer 2 LANs on a single physical device.

It is like building an armored and sonic-proof wall in a room to create 2 rooms. The people in each half of the room can no longer communicate with the people in the other half of the former room.

So you have two hosts on two distinct L2 networks without anything to allow them to communicate.

Note that in most cases it makes no sense to use the same subnet on two different VLANs. The standard case is to associate an IP network with a VLAN.

  • I'm hard-pressed to think of any case where using the same subnet on two different VLANs makes sense. Pretend you're a router, and you get a packet destined for Which VLAN is that? Commented Apr 11, 2019 at 15:58
  • @MontyHarder Depends. From which network (virtual or not) does it come? Commented Apr 11, 2019 at 19:33
  • 1
    @Deduplicator I'm not sure why it matters what the source IP of the packet is. How do you know what VLAN an IP is if you're using the same IP range for two or more VLANs? It just doesn't make sense. Commented Apr 11, 2019 at 19:42
  • @MontyHarder I do have the case: I have interconnections to providers that use the same addressing, and those are made on the same switches. Since I talk to both (via different routers) and they do not talk to each other that is just fine.
    – JFL
    Commented Apr 12, 2019 at 6:32
  • @MontyHarder Actually, it is very common to have the same subnet on many different LANs (and hence VLANs). RFC1918 private addresses are re-used in millions of LANs. You could very well have several separately NATed networks on the same VLAN. This probably happens ad nauseam in hosting environments. But those networks are indeed considered completely independent.
    – jcaron
    Commented Apr 12, 2019 at 8:50

Complementary to the existing answers, which cover the question from a design and theory point of view ...

Instead of asking "why don't they communicate?", let's ask "what happens when they try to communicate?"

First, what does it mean to configure a VLAN on a switch? In our example there are some sockets configured as VLAN 10, and some configured VLAN 20. The definition of a VLAN is that only sockets on the same VLAN are connected. What that means is that a frame received on a port in a given VLAN is only ever sent to ports of the same VLAN.

  10  10  20  20  10  20       VLAN of port
   1   2   3   4   5   6       Port number
   |   |   |   |   |   |
   A   B   C   D   E   F       Hosts

In this diagram we have six hosts, ports 1, 2, 5 are on VLAN 10, ports 3, 4, 6 are on VLAN 20.

Suppose host A is statically configured as and F is statically configured as, from the question. Suppose B to E have other static configuration addresses (doesn't matter what they are).

If A pings, it determines it's in the same /24, so the first thing that happens is an ARP request: WHO HAS, sent as an ethernet broadcast.

The switch receives the broadcast on port 1. This is VLAN 10, so it sends the broadcast out of ports 2 and 5, the other ports in VLAN 10. Hosts B and E receive the ARP request and ignore it as it's not their address.

That's it.

There will be no ARP reply; the next thing that happens will be a timeout on A, followed by subsequent repeat ARP requests, until the application gives up.

A host plugged into anything other than a VLAN 10 port will see nothing at all, whatever its IP address. This obviously includes F, which is


IP subnets logically group hosts - hosts within the same subnet use their layer-2 connection to directly talk to each other. Talking to hosts on another subnet requires the use of a gateway/router.

VLANs physically group hosts - hosts within the same VLAN/broadcast domain/L2 segment can talk to each other directly. Hosts in different VLANs can't. (Don't beat me up - physically group isn't really correct but it marks my point.)

So, when two hosts are in the same IP subnet but on different VLANs/broadcast domains/L2 networks, they can't communicate: the source host assumes the destination in within its local L2 network and therefore it tries to ARP the destination address (or NDP resolve for IPv6).

ARP works by sending a request as broadcast to the local L2 network and the host with the requested IP address answers with its MAC address. Since the destination host is outside the local network (=VLAN) it never receives the ARP request and ARP fails.

Even if the source would somehow know the destination's MAC address and build a frame addressed to that MAC it would never reach the destination since it's outside the L2 network still. MACs from outside the local L2 network are meaningless and useless.


I expect you to have good understanding about Subnet masking. When you have separate VLANs you have to have unique ip address range with subnets.It is not essential.

VLANs is a separate LAN but it is a virtual.Additionally Virtual LAN for separating Networks in Same Switch.It will create separate broadcast domain in your switch. But when you create virtual LANs with Same ip it is useless.

In addition to that you need to configure Intervlan Routing on your switch.

  • 2
    No it's not impossible to have multiple VLANs with same subnet . It's unusual and somewhat discouraged but it's totally possible.
    – JFL
    Commented Apr 11, 2019 at 11:42
  • @JFL True, it is possible, using either VRF's or some other form of separator, but i've yet to see any use case for this. Please enlighten me.
    – user36472
    Commented Apr 11, 2019 at 11:51
  • @JFL same issue for me as well. I just now tried in cisco packet tracer, with intervlan routing. I don't know whether issue with Cisco packet tracer. It is not work. I agree with cown. it is possible in VRF.
    – infra
    Commented Apr 11, 2019 at 11:54
  • 1
    @Cown I didn't say it was a good idea nor it was possible to made them communicate togtether (but still it's possible with NAT). But I have some use cases. For example I have interconnection with providers that pass through some overlapping RFC1918 networks. Those are connected to the same switches in different VLANs and don't communicate with each others.
    – JFL
    Commented Apr 11, 2019 at 12:38
  • @JFL Sorry man i just dont see how that compares to what the initial question was. Yes it's possible using overlapping IP addresses for interlinks or using NAT, but i just don't think it reflects a real life scenario.
    – user36472
    Commented Apr 11, 2019 at 12:45

Consider what happens when you have a LAN at home and a computer with IP Your friend down the road also has a LAN at his home and a computer with IP They're on the same subnet, so why can't they talk to each other?

In such an example, the cause is different than you're asking about.

But a VLAN achieves the same result — it segments a network, at the second layer.

My point is that we can easily see that the fact "IP addresses are in the same subnet" is not sufficient for determining whether packets may route between them. The underlying topology has a part to play as well.

Taking this to its extreme, at the lowest layer you need some physical material (well, okay, or air :D) to actually transport the data. Your computers can be in the same house on the same subnet but not be physically connected (or have a wireless link) and then you wouldn't expect packets to be routed.


The point of the VLANs is to have network segmentation. You could also achieve the same (some caveats aside) using subnets. Since your subnet is split into 2 different VLANs, your devices can not communicate on L2 network. You can setup IRB interface on the switch to allow communication between the VLANs. Alternatively, you can route the traffic via a firewall and allow selective communication between the VLANs. Ideally, you should design your network to have different subnets for each of the VLANs and then Firewall the traffic between VLANs. Hope this helps.

  • 2
    Nonononono don’t use IRB in this situation... the problem is that the switch should never have been configured with two vlans across the same subnet. The best answer is put all hosts in one subnet in the same vlan. Commented Apr 11, 2019 at 22:11

When an Ethernet connection carries more than a single VLAN, all but one of those VLANs must be tagged. The IEEE 802.1Q conformant VLAN tag is placed in the Ethernet frame in the location where the EtherType of the frame would normally be. The first part of the VLAN tag is a tag protocol identifier, which is a constant value of 0x8100. As a result, a device that is unaware of IEEE 802.1Q tags or configured to not expect them will see the tagged frames and think "this is neither IPv4, ARP nor IPv6; this Ethertype 0x8100, which is something completely different and I don't think I understand it at all. Best to just ignore it."

A VLAN-supporting switch can filter packets going out to each port by their VLAN tags, and can optionally strip the VLAN tag from one selected VLAN on outgoing traffic from that port (and reciprocally add the VLAN tag to incoming traffic on that port), so that any traffic of the selected VLAN appears as plain pre-802.1Q Ethernet traffic for the device connected to that particular port. Such a selected VLAN is known as the native VLAN for that port.

The 802.1Q standard allows an Ethernet port to support a single native VLAN and any number of tagged VLANs at the same time, but I understand having a port pass both tagged and untagged Ethernet frames at the same time is a somewhat disfavored configuration: you'll need to remember that one of the VLANs in a port/NIC is different from all the others and needs to be configured differently. Prone to mistakes.

In Cisco terminology, a switch port can be configured as either an access port or as a trunk port. An access port will only provide access to a single VLAN and has the VLAN tags automatically stripped from outgoing traffic and added on incoming traffic for that port. A trunk port, on the other hand, will pass traffic on a configurable set of VLANs, but all the traffic will be VLAN-tagged.

So, to your case of two devices in two different VLANs on the same switch, both using addresses on the same IP subnet. What happens will depend on how the switch ports (and the network interfaces on the devices) are configured regarding VLANs.

1.) Switch ports as access ports, devices not VLAN-aware: the switch port will filter out the traffic of the "opposite" VLAN, and so the devices will never see each other's traffic. This raises the question whether or not it makes sense to think of them as "being on the same network segment" at all.

2.) Switch ports as trunk ports set to pass both VLANs, devices not VLAN-aware: each device will think "Why does that other device keep sending me that strange Ethertype 0x8100 stuff??? I don't speak that."

3.) Switch ports as trunk ports set to pass only one VLAN each, devices VLAN-aware: you'll need to specify the VLAN numbers in the network configuration of the devices too, but the end result is essentially the same as in case #1: the devices won't see each other's traffic.

4.) Switch ports as trunk ports set to pass both VLANs, devices VLAN-aware but configured to different VLANs: now it's the VLAN support layer in the devices themselves doing the filtering, but the practical result is the same as in cases #1 and #3: the traffic of the "opposite" device will never reach the IP protocol layer in the device's network protocol stack.

5.) Switch ports as trunk ports set to pass both VLANs, device configured with VLAN awareness, both VLANs configured in the device. This is above and beyond what you asked for. Now the device will be effectively present on both VLANs.

Since both VLANs pretend to be distinct on the Ethernet level, but are using the same IP subnet, what happens will depend on how the devices' IP routing has been implemented. The main important detail will be whether the IP stack is designed to use a strong host model or a weak host model, and exactly how the concept of VLANs has been integrated to the system.

For example, Linux will present any configured tagged VLANs as extra virtual NICs, that reflect the link state of the underlying physical NIC but otherwise act as independent as technically possible. So it will be just like you had two NICs plugged into two separate physical network segments with 100% overlapping IP subnets: the system might receive incoming traffic just fine, but will assume that any NIC connected to the destination IP subnet is good for talking to any other host in that IP subnet, and will use which ever (virtual, VLAN-specific) NIC occurs first in the routing table... and so the configuration might or might not work depending on the order in which the various parts of the NIC and VLAN configuration have been initialized. You'd need to use Linux's advanced routing functionality and create custom routing rules to handle this case well.

Using the same IP subnet on two distinct segments is a layer-3 problem, no matter what the segment separation at layer-2 is physical (= actual separate NICs) or logical (= created with VLANs). A layer-3 problem will need a layer-3 solution: using a router or some other box to symmetric-NAT one of the subnets to remove the IP subnet overlap would be much more elegant than trying to handle it at the individual devices.


My dear friend, Because switch is layer 2 device , which can't understand ip address. It's just creat arp broadcast every time and transfer packet to each PC which are connected to that switch , and makes entry in Mac table then it refer Mac table and transfer to that destination device. But in this process switch faced broadcast problems and goes into hang state. And my dear friend To avoid this problem vlan came into picture , switches has multiple vlan ports (1- 1005) we can used any no. between this to create vlan ID / subnets. By default all the ports of switch are member of vlan 1. And switches only understand this vlan.

  • 3
    You have a lot of inaccurate information here, and you miss the most important points. VLANs divide the switch into "virtual " switches and there is no communication between VLANs in a switch. ARP is a feature of IP addressing, which switches have no knowledge of. There is no hang state.
    – Ron Trunk
    Commented Dec 21, 2021 at 16:14
  • 1
    I don't think your post really answers the question... You might want to reread the question and improve your answer.
    – Zac67
    Commented Dec 21, 2021 at 16:14
  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Dec 25, 2021 at 14:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.