All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
VLAN isolation issues at my colocation
I recently started testing a new colocation and have so far only deployed a single physical machine and a router running as a VM. The environment is not in production yet, but during my initial setup, I discovered something concerning:
- I can configure and use IP addresses that haven’t been assigned to me.
- I see a lot of ARP broadcast traffic for IPs that are not part of my allocation.
This leads me to believe there may be VLAN isolation issues in the network.
I reached out to the data center, and while they acknowledged the issue, they stated that it would be addressed during a network overhaul in the coming months. In the meantime, they advised me not to configure IPs that aren’t assigned to me.
While this isn’t impacting anything yet (since it’s not in production), I’m concerned about potential risks once I start using the colo actively.
Here are my main questions:
- Should I push for a temporary fix before moving to production?
- Is this kind of issue common in colocation setups, or should it be seen as a major red flag?
- How would you mitigate this risk while waiting for the overhaul?
I’d really appreciate any advice or experiences.
Tks

Comments
What’s the subnet netmask you have provided and how many IPs have you ordered ?
I'd try and configure an IP that isn't assigned to you but is otherwise in use.
If it works and you get connectivity to that IP address then pull your hardware out and name & shame.
If you can do it, so can somebody else on that LAN.
Is he in the dedicated VLAN though ?
Sure, the provider could be routing at the TOR and utilizing MAC filtering, in which case, fine (ish) - but it doesn't sound like that's the case.
If a colo customer can assign and use an IP address not allocated to them, then that's a serious problem.
Honestly, sounds like you are in a shared VLAN.
Not that uncommon, especially in smaller DCs and when you only have a few IPs.
If this is a concern to you, they should be able to put you in a dedicated VLAN.
But then you most certainly need to get a full subnet and not just a few single IPs, which has the disadvantage that you lose some IPs for broadcast/gateway etc.
It's been a few years but I'm sure we mitigated this with a mix of IP source guard (IPSG) and ARPwatch notification iirc for Shared VLANs
Not saying this is the greatest of setups or what the provider should or should not do.
Is the OP in a dedicated VLAN or not is going to answer the entire thread. Assumptions just create confusion and delays in troubleshooting.
I did exactly that: I analyzed the network traffic using Wireshark and identified some IPs with active traffic. Out of curiosity, I configured one of those IPs on my device, and, to my surprise, it worked.
My main concern is the possibility of someone else, either intentionally or unintentionally, configuring one of my IPs. This could lead to IP conflicts or, worse, bring down my BGP session, causing a complete loss of connectivity for the /24 block I’m announcing.
Yea, that would be a solution.
Guess various providers haves different approaches.
Just a bit surprised to see this in a colo environment with someone who has rented a partial rack.
At this point, it really makes sense to give the customer a dedicated VLAN.
So what are you saying?
Regardless of shared VLAN or not, it's simply unacceptable in any form of hosting environment to rely on trusting a user to:
"they stated that it would be addressed during a network overhaul in the coming months. In the meantime, they advised me not to configure IPs that aren’t assigned to me."
Yep, time to pull your equipment out and not use that provider again. If you can do it, so can somebody else on the VLAN.
--
If they can't source guard/prevent spoofing logically, then a dedicated VLAN is a simple solution to implement here. Sure, you sacrifice a few IPs for subnet/gw/broadcast but is that really worth the security risk?
I would recommend contacting your hosting provider again, any provider's first response should be to resolve this right away, waiting for a network overhaul is unacceptable.
For the second time, I’m not saying whether the provider has a correct, good, bad, or whatever. The OP is asking for help, as such - one has to establish if it’s a shared or dedicated VLAn first.
Or could just ask for a dedicated VLAN.
OP could also be in breach by assigning IPs not assigned to them, so. I wouldn’t try that until it’s clarified.
It was clear that it's not a dedicated VLAN in the first post.
Shouldn't have to ask for security... Embarrassing.
No, you assumed that. The router the Customer brought may well have created a bridge between OPs private vlan and whatever shared vlan they put their router in.
Many providers don't know broadcast storm and spanning tree
Indeed, OP should just contact their provider, as they would be the only ones able to resolve the issue and clarify how it happened.
I performed a traffic capture and shared it with the data center's support team. In the capture, I noticed a large amount of broadcast traffic, as well as expected traffic, such as SSH sessions..
While I only captured and reported the issue to the data center, my concern is that someone with malicious intent could take advantage of this situation in the same way. This lack of isolation could lead to significant risks, including unauthorized access to resources or disruptions to other clients.
It would be relatively simple for the data center to configure a dedicated VLAN for my setup to prevent these issues. However, their response was merely:
"This is being addressed when we do our network overhaul in ## in the coming months. Do not configure IPs that are not assigned to you."
Sounds like you require a dedicated VLAN, while the quoted message you shared from the operator doesn’t sound promising, you should check if your service included it, otherwise it might be a separate service, potentially chargeable. I would recommend checking your order/terms and escalating with your rep at the provider.
The business with configuring someone else’s IP is super sketchy. Don’t do that, they will be most likely in their right to terminate your account just for that one instance where you “tested”.