Private VLAN isolation stops guest-to-guest attacks, yet DHCP still works and casting to the room screen fails — why?
answer
- isolation is about ports, not protocols
- who does the client actually need to reach?
- the gateway sits on a promiscuous port
- client-to-server lives, client-to-client dies
- the shared display becomes the meeting point
basics
~20 sAn isolated port may exchange frames only with promiscuous ports, where the gateway and the address relay sit — so assignment still completes. Two guest devices are both isolated, so the host-to-host discovery casting depends on is dropped.
solid answer
~50 sPrivate VLAN isolation does not silence a port; it restricts who it may talk to. An isolated port can reach promiscuous ports and nothing else — not other isolated ports, and not community ports outside its own community. Address assignment survives because the request broadcast still reaches the promiscuous uplink, where the gateway relays it to the server and the reply comes back the same way. Casting dies because it needs two guest devices to hear each other: the device advertises itself with link-local broadcast or multicast, and the phone answers it directly. Both are isolated ports, so those frames are dropped. The fix is to put the shared display or printer on a promiscuous or community port, or to proxy discovery through a device — and each of those re-creates exactly the reachable neighbour you isolated the floor to remove.
go deeper
Know the three port roles by what they may reach: promiscuous talks to everything, community talks to its own community and promiscuous, isolated talks only to promiscuous. That table answers most questions on this topic.
Explain the mechanics: the assignment broadcast still reaches the promiscuous gateway where the relay lives, while peer discovery between two isolated ports is dropped. Be able to predict which services break before enabling it.
Demonstrate that you price the exception. Placing a shared display or a discovery proxy back on a reachable port re-creates the adjacency you removed, and you should name who owns that device and what an adversary inherits with it.
Own the trade between a cheap control that needs no readdressing and a guest experience the business sells. Be ready to argue for per-room communities with an owner and a reset discipline rather than a permanent site-wide hole.
## What isolation actually restricts A private VLAN splits one primary VLAN, which keeps its subnet and its gateway, into secondary port roles: | Port role | May exchange frames with | |---|---| | Promiscuous | every port in the primary VLAN | | Community | promiscuous ports, plus other ports in the *same* community | | Isolated | promiscuous ports only | Notice what this is and is not. It is not a filter on protocols or addresses; it is a statement about which ports may reach which. Every host keeps the same subnet, the same mask and the same default gateway, so nothing in the host's configuration reveals that it has been isolated. ## Why address assignment survives The assignment exchange begins as a broadcast from the client. On an isolated port that broadcast is still forwarded to promiscuous ports — and the gateway interface, which is where a relay agent runs, is a promiscuous port. The relay forwards the request as a unicast to the server, tags it with the interface it arrived on so the server picks the right pool for that segment (this is the job Option 82 does when it is used), and the offer returns down the same promiscuous path. Nothing in the exchange requires client-to-client reachability, so it is unaffected. This is exactly why isolation is a tempting first move on a flat guest floor: no readdressing, no new subnets, no relay to build, and the change is invisible to a correctly behaving client. ## Why casting and printing die Those services are built on the opposite assumption. A display or printer advertises itself with link-local broadcast or multicast; the phone or laptop hears the advertisement, then opens a session directly to the device's address in the same subnet. Both ends are isolated ports, so the advertisement is dropped and the direct session would be dropped even if the address were typed in by hand. The guest sees "no devices found" and the venue sees a support call from a room somebody paid for. The same applies to peer file sharing, device pairing, and anything else that resolves a neighbour rather than a server. **The rule of thumb: isolation preserves everything that is client-to-server through the gateway and breaks everything that is client-to-client.** ## The price of putting the service back There are three usual moves, and each has an honest cost: 1. **Put the shared device on a promiscuous port.** Now every isolated guest can reach it — which is the point — but so can a compromised guest, and that device is now a permanently reachable, usually unpatched neighbour sitting in the guest domain. It becomes a stepping stone, and if it is dual-homed to a back-of-house network it becomes a bridge. 2. **Put the room's devices in a per-room community.** Guests in that room can hear each other and nobody else. This is the closest thing to the right answer for meeting rooms, and it costs you a secondary community per room, a mapping from floor box to community that somebody must maintain, and a reset discipline between bookings. 3. **Proxy discovery through a device that repeats advertisements.** Convenient and widely done, but that proxy is by construction permitted to talk to every isolated host, so compromising it hands an adversary the adjacency you removed — with the added property that its traffic looks legitimate. ## What an interviewer is listening for The wrong answer offered confidently is that broadcast traffic is somehow exempt from isolation, which is why address assignment survives. It is not exempt: it survives because the party it needs to reach happens to be on a promiscuous port. Get that right and the rest follows — you can predict which services break before you turn it on, rather than discovering them from the helpdesk queue. The second thing they listen for is whether you price the exception. Isolation that has been reopened for a shared display is not isolation with a small hole in it; it is isolation with a designated meeting point, and the meeting point should be the least trustworthy device on the floor, chosen deliberately and stated in the design.
- A guest types the display's IP address in by hand. Does the session work?No. Isolation drops frames between two isolated ports regardless of how the address was learned, so bypassing discovery changes nothing. That is the useful distinction: this is not a discovery problem you can work around, it is a reachability rule at the port.
- Where would you place a shared floor printer, and what have you accepted by doing it?On a promiscuous or community port, so isolated guests can reach it. You have accepted that it is now a permanently reachable neighbour for every device on the floor, usually one that is rarely patched, and that anyone who takes it inherits sessions from every isolated host. It gets logged as an exception with an owner.
- Does isolation change anything about the host's own configuration or the subnet?Nothing. Same subnet, same mask, same gateway, same address assignment path. The restriction lives entirely in the switch's port roles, which is what makes it cheap to deploy and also what makes it invisible when troubleshooting from the host.
saying these in an interview costs you the question
- Says broadcast traffic is exempt from private VLAN isolation
- Believes isolated ports can reach other isolated ports in the same secondary VLAN
- Thinks isolation requires a new subnet or a readdressing plan
- Suggests hardcoding the display's IP address as a workaround
- Adds a discovery proxy without noting it can reach every isolated host