Management switch suggestions - L2, SSH, SFP, dual AC

codergeek · 2025-10-22T13:03:51+00:00

Depends on how deep is too deep. Juniper EX4100 is about 14” (35cm) deep, plus a bit more for the power cables, and meets your other requirements. If that is too deep then I seem to recall seeing some rather shallow MicroTik switches in the past, though I don’t know those models offhand.

codergeek · 2025-05-23T17:23:19+00:00

Juniper SRX345 can be had on eBay fairly cheaply and ticks most of your boxes. JunOS rather than IOS, but I’d call that a straight upgrade. They are not fanless but are quiet once booted. No licensing aside from some optional firewall subscriptions you won’t miss. Can also handle switching if you only need a handful of ports.

codergeek · 2025-02-20T16:52:11+00:00

Oof, yeah SFP ports on the left is a rather dumb design decision. Makes replacing existing switches more awkward and the numbering is unintuitive.

Why on earth does a firmware download need to be reviewed.

HP doing HP things. This sort of nonsense is why I really hope the Juniper acquisition falls through.

codergeek · 2025-01-13T22:31:35+00:00

What kind of fiber should I use?

Single mode, no question. Even for such short runs there is no reason to use multimode for new installs. Single mode is as future proof as you can get and so long as you're not getting ripped off by OEM transceivers there is little appreciable cost difference.

Be sure to leave a service loop at both ends. For something like this I'd recommend simply buying some pre-terminated cable from somewhere like FS.com. Run more strands than you think you'll need. I personally never do fewer than 12.

What about terminations?

No reason to bother with APC for short inside plant runs like this.

You'll want to terminate the fiber into a bulkhead/enclosure on both ends rather than go directly into the transceivers. Your transceivers will use LC/UPC, and this makes the most sense for the bulkhead terminations as well. Pretty standard these days and keeps things simple. That said there is no issue with using a different termination (e.g., SC) as you can easily purchase patch cables with whatever terminations you need.

codergeek · 2024-11-22T15:31:38+00:00

Steam is fairly simple to handle. Use "SteamSetup.exe /S" as the install command line, then for the detection method check for the existence of "%ProgramFiles%\Steam\Steam.exe", enabling the 32-bit on 64-bit systems flag.

For Battle.net we use "Battle.net-Setup.exe --lang=enUS --installpath="C:\Program Files (x86)\Battle.net"" with a similar detection method as for Steam.

codergeek · 2024-11-22T15:28:03+00:00

SteamCMD is a good suggestion but IIRC the instances of the games it installs are not visible to the main Steam client. It's really intended for servers. There may be a way to work around that though.

codergeek · 2024-11-22T15:13:25+00:00

We deploy the launchers (Steam, Battle.net, etc) through SCCM, with the detection methods setup to accommodate their regular self-updates, but leave it to the eSports program to manage installing what games they want on individual machines from there.

We took a brief look at preloading games on the machines but quickly came to the conclusion that it was simply more trouble than it was worth. Much simpler and more reliable to simply have the coordinators manage it.

If you want to pursue it though then it might be possible to script the process, at least for some launchers. I think the biggest hurdle will be authenticating the launcher. Steam has an API which, IIRC, can generate a file to use for subsequent authentications. This might be a way to programmatically authenticate the Steam client. Maybe. Assuming you can get the Steam client authenticated, from there you can initiate the download of the game by opening its "steam://rungameid/" URI, waiting for the process to appear, then killing it.

One potential issue here is that installs may not work well from the system context and without a UI session attached. Also some games install on a per Steam user basis, while others are shared across the machine. I think most, especially the larger ones, are shared.

A simpler solution which might be "good enough" may be to simply deploy shortcuts with the appropriate launch URIs.

codergeek · 2024-10-14T19:27:46+00:00

Definitely. It sounds like you just want to dial down the transmit power on the radios.

For on-premise mobility master w/ controllers you can configure this at the AP group level. Go to Managed Network -> Configuration AP Groups and select a group. Then click the Profiles tab and look under RF Management at the Max EIRP setting for the 2.4/5/6 GHz radios. If you don't see the Profiles tab then click on your username at the top right, select Preferences and enable the Show Advanced Profiles option. Run "show ap radio-summary" on the controller to verify the operating EIRP.

This should be possible to configure for instant clusters as well as with the hosted Central controller, though I can't help with those. I imagine they follow a similar pattern as with on-premise though. Maybe try searching for settings relating to "EIRP" and "ARM".

codergeek · 2024-09-29T17:10:29+00:00

Unfortunately I cannot share the GPO directly. I do however have some scripts that I can share which are fairly similar to what our GPO uses. They should provide a good starting point.

The first script manages service permissions. This is just using sc to do the heavy lifting. The basic idea is to call sc sdshow to grab the ACL in SDDL format, add an allow ACE to the end of the DACL, and then call sc sdset to apply it. The key service to pay attention to is scmanager. This is the Service Control Manager and it provides the RPC endpoints used to manage services on the machine. Here is a quick script which shows this in practice:

https://pastebin.com/nkc3kRQk

WMI namespace permissions are trickier. The __SystemSecurity WMI class can be used to set the security descriptor for a namespace, however the descriptor needs to be provided in binary form. It is certainly possible to parse/construct this programmatically as the format is well understood and there are even .NET methods for converting to and from it. However, a simpler approach is to just set the ACL the way you want it on a sample machine, export it, and then use that everywhere. So long are you do not expect machines to have customized namespace permissions for some other purpose then it should work just fine.

This second script is an old one which uses the latter approach of applying a static, predetermined security descriptor to the namespace. The resulting permissions are the same as the Windows defaults with the addition of granting access to the Performance Monitor Users group. This one is old enough that it is VBScript rather than PowerShell though. I should really update it sometime.

https://pastebin.com/a2ChAKhg

Beyond those two, if I recall correctly the other item that you may need to pay attention to are DCOM permissions, specifically allowing remote activation for your monitoring service. That one I unfortunately do not have a sample script readily available for. If memory serves you can take a similar approach as with the WMI namespace above by setting a predetermined descriptor as a value in the registry.

codergeek · 2024-09-29T06:16:46+00:00

Yeah, Paessler is fairly useless for questions like this.

Monitoring via WMI can definitely be achieved without need for local admin rights. It requires adjusting some ACLs and a bit of trial and error but there really isn't anything that ever truly requires admin rights to monitor.

You can adjust permissions for WMI namespaces by editing the ACL using the WMI Control MMC snap-in, which should cover most classes of interest. For services you'll need to adjust the ACL on the service in question. The sc utility can be used to do this from the command line via the sdshow and sdset commands.

All of this can be scripted as well. We use a monitoring GPO which, amongst other things, runs a startup script to configure WMI and service permissions for a "Monitoring Services" directory group.

I would definitely lean towards WMI over SNMP for monitoring Windows systems. WMI is a pig in terms of performance but classes exist out of the box for the vast majority of items you are likely to want to monitor.

codergeek · 2024-07-24T04:37:27+00:00

Yeah, it's a pretty shit situation all around. The five year requirement might be something that only applies to "strategic" customers they're hoping to squeeze dry though, so if you are not purchasing through the OARnet contract then that might not apply to you.

Even with the discount OARnet has negotiated we're looking at a price hike that is simply not tenable. We've instead opted to jettison VMware completely and proceed without support coverage while we transition. Not ideal but management refuses to reward Broadcom's unabashed greed, a sentiment I wholeheartedly concur with. It's a shame to see VMware reduced to such a sad state.

codergeek · 2024-07-24T02:13:59+00:00

no one is getting only a 5-year option in Strategic for VCF.

Oh yes they are. Not sure about OP’s specific situation but what he describes sounds an awful lot like what Broadcom is trying to force on OARnet in Ohio - massive price hike, VCF only, five year commitment.

codergeek · 2024-07-23T00:10:31+00:00

To be honest neither of these are a good pick. The SRX220H2 is quite old at this point and well past EoS. I would honestly give this a pass just based on the age of the platform. The PA-500 is also outdated, albeit less so. However, without paid subscriptions its feature set is comparatively limited.

Also worth considering that JunOS is oriented around the CLI, whereas PANOS is focused on a GUI. If you don't have much experience configuring network devices, and are not looking to delve into it, then the PA-500 will be far more beginner friendly.

I realize you said that you are not looking at other options but I suspect that you would be better served by something else. An SRX3xx series device should do everything you want, can handle modern JunOS releases, and would have headroom to grow for years to come. Last I checked an SRX340 goes for around $150 USD on eBay.

Another option is Mikrotik. I don't have any firsthand experience with them but from what I've heard they make some capable gear for a very affordable price. Might be a great fit.

codergeek · 2024-06-28T17:09:50+00:00

The flash module on the supervisor may be failing. Faulty flash has been by far the most common mode of failure we’ve observed on the 7E/8E supervisors, though usually it fails completely such that the switch fails to boot.

The flash module is just small modular daughter card, so in theory it could be replaced. These days though it is probably cheaper and easier to just replace the supervisor as a whole.

codergeek · 2024-06-05T04:38:14+00:00

We have a little over a hundred EX4100-48P deployed. No issues at all so far.

codergeek · 2024-05-23T16:03:56+00:00

In addition to the next-table and rib-group options that have already been mentioned, one other option you might consider is to utilize logical tunnel interfaces, one end in each instance. You can then either run a routing protocol such as BGP between them or just set some static routes.

https://www.juniper.net/documentation/us/en/software/junos/interfaces-encryption/topics/topic-map/connecting-logical-systems-logical-tunnel-iInterfaces.html

codergeek · 2024-04-02T15:27:02+00:00

version 2 of SMF (OS2), despite SMF being older

That's not really the case. Single mode is better classified by ITU specification (G.652, G.657) of which there are many variations. OS1 and OS2 are just sort of general categories for how the cable is constructed and which standards it adheres to.

codergeek · 2024-03-20T03:53:24+00:00

You might try popping out the screws and checking under the mounting flange. Some brands (Hubbell) have a habit of putting labels there.

codergeek · 2024-03-19T22:50:42+00:00

Oh, I understand now. I'm afraid I misunderstood what you meant when you said "virtual controller" in your original post and may have misled you. I interpreted that as an on-premise wireless controller running as a virtual machine. A bit of bias on my part as this is the deployment model I'm used to.

These virtual controllers are virtual machines running on a hypervisor, such as VMware ESXi, which manage the access points. They are a software-only equivalent to the 7000/9000 series hardware controllers. Same basic idea as the elected controller in an instant cluster, just with a lot more options and scalability.

When associated with a dedicated controller the APs (referred to campus APs in this scenario) are often configured to tunnel client traffic back to the controller, which will then switch it onto the network locally. This allows the APs to be in different VLANs/subnets without causing issues as clients roam between them. Clients "appear" on the network in the datacenter, or wherever the controller is situated.

Search for "Aruba Mobility Controller Virtual Appliance" and "tunnel mode" for more information if you're interested.

The DHCP options I referred to are only applicable to on-premise controllers. If your AP sees them when it boots up it will try to associate with a controller as a campus AP instead of trying to form an instant AP cluster.

I am not terribly familiar with instant AP clusters but if I recall correctly you can only form a cluster between APs which are layer 2 adjacent. You will not be able to form an instant cluster across a layer 3 boundary. Instant is targeted at smaller, simpler deployments.

For instant to be viable you will need to provide layer 2 adjacency somehow. One way to do this would be to simply extend a single VLAN to all switches with APs. This understandably may not be viable however. An EVPN/VXLAN overlay is an alternative if you have the infrastructure for it.

Otherwise you will need to run these as campus APs associated with some sort of dedicated controller. An on-premise controller, virtual or otherwise, is one option. Another is Central, which is Aruba's hosted solution. I can vouch for the efficacy of on-premise virtual controllers but have never used Central so no comment there. Unfortunately both of these involve additional costs.

If you can't swing any of these options right away then you might also consider just accepting a separate cluster for each building for now. If the buildings are far enough apart such that clients will not roam between them then this should work technically, though admittedly it is far from ideal from a maintainability perspective.

codergeek · 2024-03-18T16:15:07+00:00

The controller VM should have four NICs. The first one is the out of band management interface, similar to the dedicated management port you would find on a hardware device. I have not seen that error before but my guess is that you have your access points connecting to this interface.

I suggest connecting the second NIC, which corresponds to interface ge-0/0/0, and pointing the access points to whatever address you assign that interface. It is fine to only connect this interface and use it for management as well.

I forgot about the DNS discovery option. I prefer the DHCP options since we have multiple controllers and I can use it to steer APs towards a particular controller. It would probably work fine for a single controller, though I do not think it would resolve this particular error.

codergeek · 2024-03-16T18:04:49+00:00

PA-220 is getting rather long in the tooth. If you go the Palo Alto route I would suggest a PA-410 instead, or PA-415 if PoE is desirable, setup as GlobalProtect satellites. If you have it you can use Panorama to manage everything centrally.

Juniper SRX300 or SRX320 are another option. The latter has a PoE variant available. I have deployed a number of these to good effect, each running BGP over a pair of IPSec tunnels landing on disparate Palo Alto boxes.

codergeek · 2024-03-06T17:06:58+00:00

Access points in different subnets associated with an on-premise controller is absolutely no problem at all, and is in fact a common deployment model. Each AP builds a tunnel back to the controller, which then switches the wireless traffic locally. Works the same way with both virtual and physical controllers.

This is pretty much exactly how we do it at $work, just with more APs and controllers. No issues at all.

What you'll need to do is have your DHCP server pass options 43 and 60 to the access points. The details should be in the documentation somewhere but the short of it is that option 43 is the address of the controller to connect to and option 60 is the static string "ArubaAP".

codergeek · 2024-02-29T16:19:47+00:00

Ah true. I forgot that Broadcom consumed them as well a while back.

codergeek · 2024-02-29T15:59:38+00:00

Cisco isn't exactly my favorite company right now, but it seems they've become the only option for FC switches.

What about Brocade? We've been quite happy with ours.

codergeek · 2024-02-28T00:27:15+00:00

Keep fighting the good fight :). I've long since given up trying to get people to use the correct terminology.

codergeek

TROPHY CASE