I've had to deal with the same sort of buildings before. The key will be to have a good site survey done ahead of time. If you end up needing an AP in every room, it's probably not worth it.
Just an educated guess here, but 2.4GHz will probably get halfway acceptable coverage without acceptable speed for the end users while 5GHz will likely not cover enough area to make it worth moving to entirely.
Moving from that port which was only giving 10FDx to an unused port, gave us 1000FDx.
I'm not sure where this issue stems from..
Got it sorted out, for some reason (and I'm still working on the specifics) our ESXi hosts secondary NIC keeps falling to 10FDx (likely some misconfiguration at setup).
I've moved XO off of this nic, and performance has been fixed.
If you want to improve ESXi performance, install KVM.
Yea, that's a different conversation entirely, I do want a outside of the XCP-ng pool environment, in case something goes sideways. I'm dealing with some sunkcost conversations about it, though I am making progress.
@WrCombs You cannot hide your SSIDs on Eero. You also have a limit of your Main SSID and Guest Network. It is geared for Home and really small environments.
Why Eero over Ubiquiti? Business versus consumer. Does the pro version have APs with wired connections?
Prob because management is much easier. I ditched my APs and edgerouter for a single Amplifi which I can update and control from my phone. My mom has a Deco setup and it works very similarly and is great as well.
Easier if you do it yourself. But if you have a support company, I think the Unifi is easier. The Eeros always made for a lot of extra work when we had to deal with them.
At a former job, we had an Amplifi system that caused ~8 hours of un-needed billable time. If it would have been a UniFi system, we could have fixed it without the site visits.
You can grant remote access to Amplifi. Aftyer I set it up at my mom's, with her credentials, I then added myself as a remote admin.
The short answer is you would get the Router to route between the two VLANS, and fix it so that only the Payment devices have access to the internet.
if this was an on prem system, that would world. but this is a cloud system so both need access to the internet..
Actually that makes it make more sense. It's minimal value, but that doesn't mean zero. It will improve security and simplify audits if they are both SaaS connected devices like that. Not a big deal, but not bad, either.
So how would you make that work? just using firewall rules, to let the 2 talk to pull transaction information?
If they talk only to the hosted apps, the intercommunications should be on the server, not the client. Is that not correct?
If you need devices on two different LANs (vLANs are just LANs without physical separation) then communications between them is always through a router, and routers are firewalls. So first you have to build a route, then block traffic, then allow the traffic that you want.
in a "normal" IT system, that would be the case, as I'm sure you know.
POS however, the Pin pads talk directly to the Register to pull that transaction data to the Pin Pad - otherwise the pin pad wont know how much to charge the credit card -
Then you need to connect the two VLANs, effectively defeating the purpose. It's not entirely defeated, it is still a secondary firewall but only replicating the vastly more important local firewall.
ROFMAO - like the terminals have firewalls - HAHAHAHAHAHA
on this particular system (which I am the Admin for) Windows firewalls are required to stay on - for all 3 options no matter what.
That's pretty easy to do when you're self hosted, but if you're doing something like Vultr instances, I'm guessing it's a bit harder - unless Vultr allows for the creation of VMs that only exist on a private network.
True and that why I specifically mentioned a self-hosting scenario. I think I have a thread from the past asking about whether or not people bother with reverse-proxy for things hosted in Vulture or the like.
The Dream Machine looks interesting, but I'm not inpressed with it also being an 8-port switch.
I have not looked at it yet, but are they fixed switch ports, or assignable? The ER-X is an example of this.
The documentation I've seen doesn't tell me much. It seems like the switch ports create just a plain layer 2 switch. They aren't assignable interfaces like the old EdgeRouter Lite's eth0, 1 and 2.
I believe that to be true.
The old ER Lite were software bridged only and not something you ever wanted to do. Horrible performance killer.
The ER-X and ER-4 have an actual switch chip. You don't have to make each port use it, but it is there.
So you could make eth0 be WAN and eth1 through eth3 be members of switch0
I ran a LAN Test speed using from a client to a server, which are both in the same LAN as it's a small dental office network. The results are showing 67.88Mbps (Writing/Upload) and 405.51Mbps (Reading/download). I don't know what their physical infrastructure is as I work remote, but I'm sure it's 1Gbps Ethernet. If that's the case, does this test result indicate there's an issue, with the huge difference between upload and download, all in the local LAN?
That the test is labeled writing / reading.... then yes, you're expected to be testing a lot more than the network and a big difference would be expected.
The new, unreleased Unifi UXG Pro just arrived here at the NTG Dallas offices. Woot! It's dual power supply, dual WAN, dual LAN, touch screen LCD and up and running!
One option I didn't see in the redhat doc was openvswitch. Don't they support it?
The link I posted was for RHEL 6. I just now saw that RHEL 8's documentation is online. I glanced through it and didn't see that mentioned. I'll read it more closely tomorrow.
There's no mention of openvswitch anywhere in that document. I am aware of XenServer and XCP-ng uses it by default. So its possible RHEL just prefers using macvlan/macvtap instead of openvswitch.
Ran into this about 12 years ago. A guy on the dev team decided to setup his own DHCP server. Screwed up all sorts of stuff. Can't remember for sure what we did, but I think after we realized that it wasn't actually an issue with our known DHCP servers, we decided to talk to the dev team and found out that is what he had done.
It amazes me how many people just don't think about it - they have a problem, they think they know how to solve it, and just slap something onto the network.
