Several months ago I started working with an SMC6752AL2 managed Ethernet switch. Our hospitality team has an upcoming installation with Ethernet in each of the rooms of a very large hotel. One of the requirements we have for any installation is that a host on one port cannot be allowed to see traffic from a host on another port.
SMC includes a "private VLAN" feature in their managed switches which provdes the host-to-host security we want. However, I discovered when I first tried implementing it that the private VLAN feature also cuts off any remote IP connectivity to the switch. With the private VLAN enabled on VLAN2, I couldn't connect via telnet, ssh, or http to VLAN1 for management.
After going back and forth with SMC's engineers for a couple of months, trying umpteen different configs, we determined that having the management and host VLANs separate just flat out won't work. Since the management IP is on a different logical subnet than the IPs that will be handed out to client hosts via DHCP, we decided to ignore VLAN1, make VLAN2 a private VLAN, and assign the management IP to VLAN2 with an ACL allowing IP connections from only the LAN's default gateway.
That's where we ran into another snag. Something was causing the connections to the switch that went through the gateway to time out. If I had my laptop configured with the gateway's IP and connected directly to the uplink port of the switch I could get in, although the time to setup a telnet or http session was s l o w.
Today, SMC sent me some new opcode for the switch. I tftped to the box, rebooted, and FINALLY, I was able to remotely manage the switch. Now I can move on to other things.
What a relief!
Thursday, November 03, 2005
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment