Share two subnet on same vlan?

Installing and Using OpenWrt Network and Wireless Configuration
1

Hello all,

after a lot of searches and lurking, I still can't figure out what I am doing wrong with an openwrt configuration.

I have a room with an unmanaged switch and some endpoints. The room is served with a single ethernet cable, coming from a WRT1200AC, which goes into the switch.
Then, all the endpoints in the room are connected to the switch.

My idea is to configure the WRT1200AC for two subnets, letting the router put an endpoint in a subnet or in another, by mac address (static lease?).

I created a new interface, so that two interfaces are to be shared with all the 4 switch ports:
LAN (eth0.1) 192.168.0.1/24 (the default br-lan)
LANB (eth0.1) 192.168.1.1/24 (the new interface created)
where eth0.1 is the VLAN1, which is made up of all the 4 switch ports (eth0+VLAN1)

I created the firewall zone 'LANB' with all permissions and forwardings (wan) set

Now, every client which connects to the unmanaged switch of the room gets the dhcp from 192.168.0.0/24 (the lowest metric one) even if I set a static lease on the 192.168.1.0/24 subnet, so the static leases seems useless in this scenario
if I set a client with static addressing, it doesn't even ping the gateway (192.168.1.1), neither can ping anything in wan, the openwrt router can't ping him

I tried to turn off DHCP on the LANB zone, but still the endpoints set for any 192.168.1.x ip can't ping the gw 192.168.1.1 because of "host unreachable"

so the question is, am I getting something wrong in this configuration? or am I trying something that isn't supported by openwrt?

thanks everyone for the help!

ps. I know that I could 'sacrifice' a router port so that the new interface (lanB), connected with the new vlan (es. eth0.3) would make the connected endpoints work straightforward with the separate subnet, but I can't get a second cable to the room and another switch (I used this solution in other networks without any problems).

2

You must have a managed switch to do what you want. We could go through the exercise of ensuring your OpenWrt configuration is correct, but is is irrelevant until you have a managed switch on the far end.

1 Like
3

Or to be more specific, VLAN1 is tagged with VLAN ID 1. There needs to be a switch on the other end that understands VLAN tags. However, there’s a way to do what you want to with your current unmanaged switch. You will have to create VLAN1 on the hosts that you want to be connected to VLAN1. Then, they will be able to either receive DHCP from VLAN1 or you could set a static IP from VLAN1 on those hosts.

4

You could get a cheap-ish Openwrt compatible device to sacrifice on the room switch side of things. You can make the single ethernet a trunk line from the WRT1200 and then untag the two vlans when they get to the room.

Something like a Meraki MX60 can do this at line speed, and is 20$ on ebay.

1 Like
5

Although this might actually work, it is not recommended (I'll go so far as to say that it is strongly discouraged). Aside from the extra configuration needed on the client devices (which may or may not be easily available/supported) and the lack of configuration capabilities, it is important to understand that unmanaged switches are not designed for VLANs. Sme unmanaged switches will work just fine, others may exhibit minor issues, and some may have severe issues that could even cripple your network.

IMO, it is just not worth the hassle trying to pass VLANs through an unmanaged switch because of the fact that you can end up with problems that are difficult to diagnose and resolve.

@t4thfavor has correctly stated that you can actually use a second OpenWrt device as a VLAN aware switch. You can also purchase a basic smart/managed switch for a relatively low cost -- a quick search on Amazon shows several around the range of $25-30 USD (brand new gigabit smart/managed switches).

2 Likes
6

Having two IPs on the same interface is called IP alias.
However doesn't provide any segregation between the interfaces.

2 Likes
7

It's not not recommended or strongly discouraged. It's just not the way it's normally done in an enterprise environment because there's little sense in having two L3 segments (IP subnets) sharing the same L2 segment (broadcast domain) in a switch. If this were strongly discouraged, there would be no VLAN tagging feature in consumer-oriented Operating Systems.

From the security and from the network-design perspective, however, two IP subnets coexisting on the same broadcast domain make little sense because the whole idea of containing the size of a broadcast domain goes out of the window with this sort of setup.

However, from a pure network-connectivity perspective, this will absolutely work. In fact, unmanaged switches don't understand VLAN tags, so they present absolutely no interference to tagged Ethernet frames and pass them happily just like they pass untagged frames.

The issue with tagged frames being blocked could come up in some managed switches where a particular switch port is configured as "untagged" and a tagged frame arrives in that port. Different switch manufacturers treat that kind of situation differently: some accept tagged frames on an "untagged" port, while others drop tagged frames from an untagged port.

It certainly makes sense for the OP to try to create tagged VLAN interfaces in his/her hosts to tag VLAN ID 1 out of the host interfaces before he/she needs to splurge more money on a managed switch, especially provided that the OP seems not to be very knowledgeable in how networks work. There is no reason to create more electronic waste around the world. If the OP were asking what kind of switch to buy for this scenario, your recommendation of purchasing a managed switch would be solid. However, since the OP already has a switch, it makes more sense to try to retrofit the existing network to serve his/her needs rather than buying a new piece of equipment. Additionally, the cheap managed switches you recommend have all sorts of problems (especially with VLAN1 - ironically); you should read the reviews of those switches on Amazon. So, if the OP wants to have a properly designed network at home, which - I agree - should have a managed switch to handle VLAN separation by creating several broadcast domains, then the OP should thoroughly research the managed switch he/she intends to invest in and probably choose a more expensive switch from a reputable network-equipment manufacturer and, thus, more likely to work properly switch for this purpose. However, there's doubt that the OP has enough networking knowledge to be able to select the proper managed switch for his/her purposes.

1 Like
8

Is this because of limitations in IPv4, for example that it uses broadcast instead of multicast? Because with IPv6 you almost always have multiple subnets (prefixes).

1 Like
9

This is because how IPv4 hosts communicate with each other. The hosts must know each other's MAC address (Layer 2 address) in order to send frames to each other. With TCP/IP, hosts only know each other's IP addresses; therefore, they need to discover each other's MAC addresses before they can properly build an Ethernet frame. Any Ethernet frame must have the destination MAC address and the source MAC address in it. When it comes to IP addressing, the Ethernet frame doesn't have to have an IP address. In fact, the IP address is a feature of the IP protocol, not a feature of the Ethernet protocol. Back in the 1980s and early 1990s, before Internet became pervasive, Microsoft used the NetBEUI protocol for LAN hosts to communicate with each other for file sharing. NetBEUI was not Layer 3 aware, and so there was no concept of Layer 3 addresses assigned to hosts in NetBEUI whatsoever, yet NetBEUI leveraged the same Ethernet protocol that we are using today with TCP/IP.

So, hosts using TCP/IP for communicating with one another use Address Resolution Protocol (ARP) to discover each other's MAC addresses. The ARP request protocol frame has the IP address of the host whose MAC address needs to be discovered in the payload of the frame, the broadcast destination MAC address in the Ethernet header of the frame and the MAC address of the host sending the ARP request as the source MAC address. The broadcast destination MAC address (FF:FF:FF:FF:FF:FF) has the following meaning: Every host in the broadcast domain must pay attention to such a frame. Therefore, each host on the same broadcast domain has to use its CPU cycles to look inside the frame and make sure that the IP address listed as the payload is not its own IP. If the IP address inside the frame doesn't belong to the host, the host discards the frame. However, if the IP address listed inside the frame belongs to the host, then the host must send an ARP response back to the host that originated the ARP request, using the sender's MAC address that was included in the ARP request. Back in the day of the NetBEUI protocol, hosts were identified on the LAN by their hostnames. However, because NetBEUI ran over Ethernet, for host "Fork" to communicate with host "Spoon", Fork needed to discover Spoon's MAC address, which was done similarly to the way ARP discovers MAC addresses, i.e. Fork would issue a broadcast requesting to resolve name Spoon into a MAC address. Once Fork knew Spoon's MAC address, Fork could build an Ethernet frame to send to Spoon, and the payload of that frame had no IP addresses in it at all. That's why NetBEUI was replaced with TCP/IP once hosts needed to communicate across the boundaries of their broadcast domain for accessing the Internet.

Here's the kicker. ARP only works within one broadcast domain. What is a broadcast domain? It's a collection of hosts that can see an Ethernet broadcast (destination MAC address FF:FF:FF:FF:FF:FF). An unmanaged Ethernet switch sends Ethernet broadcasts out of all of its ports, whereas a VLAN-aware switch (managed switch) forwards broadcasts only out of the ports assigned to the VLAN where the broadcast was originated.

If there is a network of unmanaged switches, then every switch in the network will send an Ethernet broadcast out of each of its ports. Therefore, in a theoretical scenario of 1 million hosts connected to a network of unmanaged switches, 999,999 hosts will receive one host's Ethernet broadcast. Provided that each host issues multiple Ethernet broadcasts, there will be tens or hundreds of millions of Ethernet broadcasts occurring on such a network. This means that every host on the network will have to use its precious CPU cycles to constantly process broadcast Ethernet frames because the destination MAC address in each of this frame will be FF:FF:FF:FF:FF:FF, which means that every host that receives such a frame must pay attention to this frame. Needless to say that most of the CPU cycles of each host on such a network will be dedicated to processing broadcast frames, so other tasks that the computers are supposed to perform will be performed extremely slowly (if at all). Additionally, it means that each of the Ethernet links (let's say they are 1 Gbps links) connecting hosts to the switches will be saturated with Ethernet broadcasts.

This is why the concept of broadcast domain was introduced. A broadcast domain is a certain number of hosts that can hear each other's Ethernet broadcast frames. To minimize the problems described in the previous paragraph, the entire network is segmented into smaller Ethernet chunks called broadcast domains. This is done with segmenting Ethernet networks into VLANs. The recommendation is to limit each broadcast domain to 254 hosts (or fewer) . Therefore, it's recommended to match a /24 subnet (a subnet with the network portion limited to 24 bits) to each VLAN. This makes the host portion of each subnet to be 8-bit long and the maximum number of hosts on each VLAN to be 256 (2^8=256). Because each subnet is supposed to have a "network IP" and a "broadcast IP" (this is not the same as broadcast MAC, by the way), the total number of usable hosts on each /24 subnet is 254.

Hosts on two different broadcast domains (VLANs) cannot directly communicate with each other because they cannot hear each other's ARP requests. Therefore, if you match a subnet to a VLAN, then in order for Host A on VLAN10 (192.168.10.10/24) to communicate with host B on VLAN20 (192.168.20.10/24), Host A will need to use a L3 routing device (router or L3 switch). Host A will compare its own IP address/mask combination to Host B's IP address and will discern the fact that Host B is on a different subnet. In this case, Host A will know that it cannot send its packet directly to Host B and instead it needs to involve its default gateway. The default gateway is an IP address on the router connected to the same broadcast domain (VLAN) as Host A. In this case, if Host A needs to send a packet to Host B, Host A cannot issue an ARP request to Host B (because Host B is on a different broadcast domain), but Host A can issue an ARP request for its default gateway, discover the default-gateway's MAC address and forward the packet destined for Host B as an Ethernet frame addressed to the default gateway. The destination MAC address in such a frame will be the MAC address of the default gateway (router or L3 switch), but the destination IP address in the TCP/IP packet (which is included within the Ethernet frame) will be the IP address of Host B. At this point, it will be the responsibility of the default gateway to figure out how to deliver the packet to Host B. As you may have guessed, if the default gateway has an interface on the IP subnet where Host B lives, then the default gateway will issue an ARP request for Host B's IP address, and once it receives Host B's MAC address, it will build an Ethernet frame with the Host B's MAC address as the destination address of the frame. Enclosed within that Ethernet frame will be the original IP packet (sent by Host A) with the destination IP address of Host B. If the default gateway has an Ethernet switch (as it's usually the case with consumer-grade routers), then this frame will be sent out of the Ethernet switch port where the ARP response from Host B was heard.

That, in a nutshell, is how IPv4 works. If the default gateway doesn't have an interface on the same subnet where Host B lives, then the default gateway will look at its routing table to figure out where to send this packet. The least the default gateway should have is a default route, which means that if the default gateway has no knowledge of the IP subnet where Host B lives, then it should use the next L3 hop specified as the destination of the default route. In a simple Internet router scenario, the default route will point to the ISP's next-hop router, and this is where the default gateway (the consumer Internet router) will send all the packets with destination IPs that do not belong the networks connected locally to the consumer Internet router.

2 Likes
10

Unfortunately not all unmanaged switches will do that. We had cases in this forum where the unmanaged switch was not propagating tagged frames.

4 Likes
11

thank you all for the replies, particularly @sirizha for the networking compendium :slight_smile:
the solution with the managed switch in the room sounds good.. indeed, I might have a spare EA4500 somewhere, forgotten in a box

12

If you have a managed switch already, and if you know how to configure it for VLANs, then by all means, you should use the managed switch.

13

^^^ This ^^^

I didn't have time to get back to this post, but this is what I wanted to say.
@sirizha - The behavior of VLANs through unmanaged switches is undefined. Some will work where all ports act as trunks. But we have seen situations were VLANs do not get passed at all (which is actually not a terrible 'failure mode') and even some cases where the tags get stripped or some other issue occurs where the network can completely fail to function properly. This is why I always discourage the use of unmanaged switches -- not just because you shouldn't use them in any proper VLAN based network infrastructure, but because it can truly cause major problems.

@sirizha - you also asserted that:

... this is simply not true. VLAN tagging exists in some OS's so that a single physical interface can indeed connected directly to multiple different networks and/or to be able to connect to a network that is tagged as part of intentional network design (usually most end-devices connect to "access ports" -- a single untagged network, but sometimes there is a reason to have only a single tagged network on a port).
Further, not all consumer OS's support VLANs. Mac OS does, by default. I'm not sure about Windows. Linux, of course, does, but it is not part of a standard Ubuntu desktop installation -- you actually have to install additional packages to get proper VLAN capabilities. And other consumer devices like video game consoles, streaming STBs, IoT devices, etc. often have no means of configuring VLANs (at least not to the end user).

1 Like
14

Windows support for VLAN tagging

Linux Mint support for VLAN tagging

macOS support for VLAN tagging

I will go out on a limb here and say that Windows and macOS together cover 99% of all consumer OS installations. I will go out on another limb and say that 99% of consumers don't have managed switches on their networks.

1 Like
15

True. But 99% of consumers don’t have VLANs.

VLAN support in consumer devices and OS's is not a given, but again, managed switches allow you to work around that potential limitation. Beyond that, VLANs were not designed for consumer devices -- it was really for enterprise environments first, and then trickled down to consumer grade devices and OS's over time.

The important points are:

  • unmanaged switches are not designed to carry VLANs.
    -- some unmanaged switches may work, others may not, and some may cause major issues.
  • the status of the end devices and their ability to support VLANs has nothing to do with the fact that an unmanaged switch should not be used with VLANs.
2 Likes
16

The fact that some switches may not pass tagged frames is possible in poorly engineered switches that drop Ethernet frames larger than 1518 bytes. The 802.1q header requires additional 4 bytes for the total size of the frame to be 1522 bytes, so a 802.1q tagged frame would be dropped by such a switch.

However, the “stripping” of the VLAN tag is impossible by an unmanaged L2 switch. You know why? You should look at the structure of an Ethernet frame and see where the 802.1q tag is located in an Ethernet Frame. It would have to be a deliberate and “smart” programming of the firmware running in a “dumb” unmanaged switch to intentionally remove the VLAN tag from a frame and then re-assemble the frame into a functional Ethernet frame, as you can’t chop the 802.1q tag off from the beginning or from the end of the frame.

Most of these assertions of unmanaged switches “stripping” VLAN tags are urban legends.

17

This is an incorrect statement. Why? Because unmanaged switches are not designed to carry VLANs. Period. The behavior with VLANs is not defined and is not likely part of the design or test plan. It's like if a full grown adult sits in a toddler's chair and breaks it... bad engineering? No.. the user exceeded the design limits.

1 Like