What are the implications of having two subnets on the same switch?

Question

Can anyone tell me what some of the implications of having two different subnets on the same switch would be if VLANs are not being used?

Answer 1

Things will work pretty much as you'd expect. At the heart of it, they're just sharing a broadcast domain. The computers in the different subnets won't ARP across-subnet so they will still need a router (or embedded layer-3 entity in the switch) in order to "talk" to each other.

Because they share a broadcast domain there's much less (arguably, none) isolation than if you were using VLANs. It would be easy to ARP and MAC spoof hosts in either subnet from either subnet.

If you're just doing this in a lab scenario it's probably fine. If you truly need isolation, though, in production deployment, you should use VLANs or separate physical switches.

Answer 2

If you don't use VLANs a person could easily just add 2 IPs to their interface say 192.182.0.1/24 and 172.16.0.1/24 so that he or she could access both networks.

By using VLANs you can tag the switchports so that any computer configured to only receive traffic from the VLAN will not be able to get any traffic (except the one directed to it and having the correct VLAN) regardless of how the local interface is configured (how many IPs there are on the interface).

In essence:

• if you trust your users there's no reason at all to use VLANs (from a security point of view).
• if you don't trust your users VLANs will keep certain groups of users seperated from each other

Answer 3

1. if you have untrusted users - some of them might spoof ip addresses of those from other subnet. if there are some address rules - they might bypass them. some users from subnet1 might spoof address of router in network b - and eavesdrop into [at least part of ] the communication.
2. you'll have more broadcast 'garbage' [ arp packets ] - but that should not be your concern if you have few dozens of users and 100 or 1000 Mbit/s link.

Answer 4

First, I'm not sure why you would do this for users. The one scenario I can think of is that you are out of IPs in your current user subnet and can't easily extend you current subnet. In this case I think it would be fine to add another subnet. The spoofing thing becomes a non-issue when you are using the IPs this way because both subnets are equal, so you have the same spoofing risk whether using a single subnet or multiple. One question I have here is how DHCP would work. If your DHCP scopes aren't contiguous, and the DHCP server serves IPs based on the "helper" address of the router, wouldn't all the requests go to one scope or the other? I suppose this might become a non-issue if your DHCP server is sitting directly in the broadcast domain, but it's still something to explore.

All that said, I actually do this in production for one of my apps. I have an app that has geographically diverse silos, each silo has its own /27. Those IPs are what I consider to be infrastructure IPs. They belong to those servers. Then I route an additional /29 to the same broadcast domain. This subnet belongs to the application. When I next upgrade hardware, I will build out an entirely new silo with a new /27, then change the route for the application /29 onto it. Since this /29 handles communication with network elements, this allows me to not have to reprogram all the NEs if we get new hardware or new software, and using the same broadcast domain allows me to do it without a dedicated NIC.