Rural

That makes sense...even to me. I'll be playing with the v1910's routing capability eventually. I'll make a point to test this then. It kind of makes sense if you assume that the switch is going to be doing the routing.

Correct. But without the default gateway set to whatever it happens to be on 10.0.20.0/24, you'll be unable to get to the interface unless you are directly connected to that VLAN. So you have to use ipsetup on the CLI or work through the web GUI's wizard to set the default gateway on the management VLAN. That totally threw me when I first messed with it. But now, my faith in the v1910's web interface has been (somewhat) improved as a result.

Just to be clear: Our aim is to avoid using the VLAN 1 for any kind of user traffic, including management. Admittedly, I've went back and forth on whether to use the default VLAN as the management VLAN, but it basically comes down to two things: 1) The default VLAN gets used by the switches and routers for a bunch of stuff. I noticed this when doing captures. Mostly, I don't like this traffic messing up my captures, but I also don't want to interfere with it in any way. An example would be STP converging to a solution. I'd like that to happen as quickly as possible. 2) I've read in several places that it is generally considered best practise to avoid the default VLAN as much as possible, mostly for security reasons. Don't get me wrong, I don't know enough to really argue whether it is a good idea or not. I'd certainly be interested in any discussion.

I mentioned that we were looking a v1910 as a "core" switch in another thread. (No. I'm not kidding. Money is tight.) I also mentioned that I was having problems with it. The issue was very simple: The first thing we do when we get a switch is set it up with a trunk port that connects to another switch and carries our management VLAN. The management VLAN is what we use to configure all of our networking devices. We then move the switch's managment interface (telnet, SSH, web, whatever) to that VLAN. With that done, we do all further configuration on the management VLAN. And that's where my problem occurred. When I moved the management VLAN from the default VLAN, I would lose access to the management interface (on either VLAN) and it seemed like all VLANs would stop working (ie. a port configured as untagged on the management VLAN couldn't access devices on the rest of the network). I'm still not sure if the problem was just me, but I'm leaning towards that fact. In any case, I dumped the web GUI and started learning the CLI. Didn't take long before I had VLANs up and running. Some help from a forum member (@Ashm) got me the reference manual for equipment with a similar CLI (HP A5500 EI & A5500 SI). It began to come together. I was able to get the management interface working on the VLAN I wanted except that there was no way of changing the default gateway to whatever was appropriate for that VLAN. I ended up searching the v1910 manual and found that one could do it through the web GUI. It seems to be working now. I'll be sticking with the CLI for further configuration and hope that someone will point out that I just missed where this setting could be altered via the CLI. I'm thinking that it could be done with the ipsetup command. This makes some sense, although the documentation does point out that it only applies to the interface on VLAN1.

Thanks for the tip @CyberNerd and @glennda. I'll give the (warm and comforting) CLI a try on the v1910 Monday. @glennda: I really can't put my finger on any raw numbers that would make the 2800 series more attractive than the V1910. The 2900 series brings 10G to the table. I imagine the 2800 versus V1910 difference comes down to L3 static routing performance. Heck, if the price of the 2800 line is comparable to the V1900 line, I'd go with them based on their being home-grown in HP. But I know almost nothing at this point. To date, we've only used switches for switching. I consider routers as security devices and therefore like their source to be open. As long as I have this view, the L3 routing capabilities of a 2910al-48G would be wasted. But I'm on the fence about this view. So you can see why the v1910 is interesting to me. It might actually be capable of decent link-aggregation performance. That would open up the bottle-neck we have between switches, to the router, and to servers. And it can do L3 static routing. I want to explore the security implications of doing static routing in a switch. It may be something I can live with. But cost is by far the biggest factor here. I would love nothing more than to put 10G between our switches, router, and servers. At our larger schools, this is justified, the money just isn't there (and I'm working on that). Anyways, I imagine my situation is quite entertaining. I certainly find it so. If I ever seem cross, it's just my envy showing.

@SYNACK: Thanks for the warning on the DGS-1248T switches. So far, I've never been able to implicate them in an issue. I'll trust them less as a result of your comments. We have definitely had issues with some very old and high-end (for their time) D-Link switches, but they were quite ancient. I'll admit that it was a struggle finding good sources for Linux networking material. Ended up just buying a few books from O'Reilly, Packt, and an excellent one from NoStarch. But this was more for networking security background. Honestly, I've found the Linux command-line network configuration tools to be less esoteric than the Cisco equivalents... Although I have to admit that I like how the history of Cisco's product line is often embedded right there in the CLI. In any case, I've been on both sides of either being easier. For example, getting our Cisco routers sending NetFlow stats to the right place (a Linux box, of course) was a piece of cake. I've yet to get the Linux routers doing the same. pfSense is completely different. If you are doing something that everybody else uses it for, it is dead-simple and will work well. If not, you better be buying support from the developers (which is a really good idea anyway). When I started here, we had a mix of Linux and Cisco networking equipment (still do). In both cases, nothing made sense. The problem: No documentation of why anything was configured the way it was. And the fellow who knew why was so angry (he'd been fired) that he wouldn't talk to any of us. And then he passed away! Now we try hard to document what we do and why. Don't get me wrong. If we had the money, I'd go Cisco. But we bought and deployed 400 computers this summer. Our only cost was shipping. $5 each. That's how we roll. (And I'm very mixed on whether it's a good idea.) King of straying off topic a bit here: One can build really low power Linux boxes, actually just PCs. (We're building an off-grid home. My average power-budget for computing is 200W. Guess how much I've delved into this.) I've got PC Engines Alix boxes that we use as firewalls and to coordinate shutting-down/bringing-up servers due to power events. They draw about 10W under load (but can only push about 70Mb/s). Our pfSense routers are probably more like 40W and will do 600Mb/s with a fair bit of packet inspection. The networking numbers are assuming pfSense, which has a pretty inefficient firewall. I'd expect Linux to perform better.

@snoerre: I'd read about opening up the CLI on the v1910, but haven't tried it yet. My opinion is is that the web-interface should work as advertised. It would also be nice if a web-interface could be used for most configuration. My staff tends to get scared of the command-line (but my personal preference is command-line all the way). Since my initial post, HP has responded to me and we're working on the issue. Thanks for the bit about your experience regarding the HP switches, especially about unfixed security issues. Those are the kinds of experiences that have pushed me towards open source solutions whenever security is a requirement. I would very much like to trust a vendor's word regarding security, but with the possible exception of Cisco, my experiences won't allow me to do so. I'll share what we go with and our experiences going forward. But progress is going to be slow. The bottleneck being my time.

@glennda: The issue with the v1910 is that it doesn't seem to want to talk to our existing switching infrastructure if VLANs are involved. Actually, it is more complicated than that. It worked fine until I made the v1910's web interface available on another VLAN. It became intermittent at that point. Upgrading the firmware on the v1910 introduced a weird certificate problem. (Firefox won't trust it and refuses to allow an exception.) I'm curious if the v1910 came along with the 3COM acquisition. And more generally, just so I don't unduly bias someone against D-Link gear, I should say that we have generally been happy with their switches. We have about 24 DGS-1248T and 10 DGS-1210-48 switches in service. These are fairly low-end "web-smart" switches. Just basic features (VLANs, link-aggregation, 802.1x, etc.) accessible through a web interface. Other than the crappy link aggregation performance, the occasional lock up while messing with stuff over the web interface, and the fans needing to be replaced right around the end of the warranty period, we've had little to complain about. I'm hoping to keep most of them in service on the edge. (Of course, our networks are almost all edge. Not much of a core to speak of yet.) We've probably had to reboot switches three or four times since we started using them. Knock on wood, we've had no failed ports. To put this in perspective: We do absolutely the opposite of over-building. It has mostly worked. Where it doesn't, we either suffer or find work-arounds. As an example, I've been replacing old Cisco routers with commodity rack-mount PCs running pfSense. It has worked very well for us. I'm also experimenting with building Linux routers/firewalls and have generally been very happy with the flexibility this brings at very small cost. When it comes to security (ie. firewalls), I actually feel strongly that one needs the source. Other than that, I'm not advocating what we do. Not at all. Our budget imposes this approach upon us.

@dgsmith and @bossman: I hear you. We have a bunch of small schools (40 to 800 students, 50-500 ports) and much of the kit discussed in this thread is well beyond our means. We upgraded our network from a bunch of D-Link FastEthernet switches to D-Link GigE switches two years ago. Getting the money for that was a real challenge. The new switches were capable of link aggregation so we used it, thinking it would help avoid bottle-necks. This summer we had a summer student test the throughput and we realized the switches were topping out at 1.6Gbps per bonded link. Didn't matter if you had four ports in the bond, 1.6Gbps was what you got. Since almost all of our servers have 2 or 4 GigE ports, we've been shopping for GigE switches that can do VLANs, link aggregation (802.3ad), and not much else. Tested an HP V1910 last week (and had troubles with it). So now we're looking again but spending anywhere close to $3k on a switch is going to be a tough sell.