brwainer

Network chuck is a good channel to learn basics of networking. 
 
https://youtube.com/@NetworkChuck?feature=shared
 

The irony in that statement in which Cisco is considered vendor locked where as Ubiquiti isn't.
 
Learning IOS-* paves the way for ease of transition to a large majority of other vendors.
 
Even the most regarded GUIs are meh at best and it becomes clear whenever you get familiar with any NOS' CLI. You will never get responsiveness, verbose/condensed output, more fluid configuration or a multitude of methods to interface with a GUI the way you do with CLI. CLI is still king and will be the go to for the foreseeable future.
 
Don't fall in the trap that GUIs are easier as in most instances they are not (there are exceptions of course for specific configs). Some GUIs can make things more convoluted or tedious requiring a dozen or more steps across various unrelated directories where the same config would be a few lines at worse. Unifi is notorious for this and one reason why I consider it among one of the worse GUIs on the market. Pretty != good/easy.
 
GUIs have their use cases but each one is easily replaced by almost any NMS if possible.
 
 
show | compare commit check commit confirmed commit and-quit FTFY
 
RFCs are not standards, they are strongly recommended guidelines to abide by.

I’m working at a Fortune 500 company as a Lead Network Engineer. A few weeks ago, myself and three of my colleagues flew out to a new datacenter to rack and set up $2 million worth of Cisco and F5 equipment. Nexus 9K switches in spine and leaf topology, with Catalyst 9300L switches for the out of band management, and Catalyst 8500 routers. Each one we performed initial setup on purely from serial console. All programming of them done via CLI after they got online too. The VXLAN config will be done via Nexus Fabric Manager, but that’s it and we’d be comfortable doing it by hand if we hadn’t been given it for free. We’re connecting console servers to provide OOB serial access as well. If we had gone with Arista or Juniper for this deployment, the overall methods would have been the same - I haven’t seen a GUI yet that is good enough to completely replace the speed at which you can get precise information out of a CLI. GUIs are good when you are taking a larger overall view at something, or to enable templates and standardized workflows.
 
Except for when they try to teach their automation tools, anything you learn about Cisco will be transferable to general networking principals and other vendors. I had a networking class in college that was just using a CCNA Study Guide as the course material, and at my first job after that I mainly touched Aruba/HP and then later Ruckus/Brocade switches, and the knowledge I gained follow the Cisco methods was still useful to me.
 
At my second job, we used hardly any Cisco equipment. And even so, when talking to my manager about what I should study and certifications to try to get to further my career both with that company and in general, I was told to continue on the Cisco certification path.
 
At my current employer, when I applied for my first position here, the role was for removing Cisco routers from over 1000 branch locations and replacing them with a non-Cisco SDWAN appliance. And yet the fact that I was CCNA certified was a deciding factor between me and another candidate.
 
Try to recognize in your studies what is an industry standard, such as protocols and RFCs that everyone has to abide by, and what is Cisco’s way of implementing things. Sometimes the way Cisco does things becomes the standard that everyone follows, and sometimes they go off on their own, and its only the requirement of interoperability that keeps things minimally compatible.

Also consider that a Chassis like that typically includes the drive backplane and often the PSU(s) as well, which are low-volume specialized parts as far as these things go. If you look at the cost breakdown of a Backblaze pod you’ll see the backplanes cost as much or more than the bent metal, and they designed fairly simple ones that just need to do SATA, not full SAS.

I’m working at a Fortune 500 company as a Lead Network Engineer. A few weeks ago, myself and three of my colleagues flew out to a new datacenter to rack and set up $2 million worth of Cisco and F5 equipment. Nexus 9K switches in spine and leaf topology, with Catalyst 9300L switches for the out of band management, and Catalyst 8500 routers. Each one we performed initial setup on purely from serial console. All programming of them done via CLI after they got online too. The VXLAN config will be done via Nexus Fabric Manager, but that’s it and we’d be comfortable doing it by hand if we hadn’t been given it for free. We’re connecting console servers to provide OOB serial access as well. If we had gone with Arista or Juniper for this deployment, the overall methods would have been the same - I haven’t seen a GUI yet that is good enough to completely replace the speed at which you can get precise information out of a CLI. GUIs are good when you are taking a larger overall view at something, or to enable templates and standardized workflows.
 
Except for when they try to teach their automation tools, anything you learn about Cisco will be transferable to general networking principals and other vendors. I had a networking class in college that was just using a CCNA Study Guide as the course material, and at my first job after that I mainly touched Aruba/HP and then later Ruckus/Brocade switches, and the knowledge I gained follow the Cisco methods was still useful to me.
 
At my second job, we used hardly any Cisco equipment. And even so, when talking to my manager about what I should study and certifications to try to get to further my career both with that company and in general, I was told to continue on the Cisco certification path.
 
At my current employer, when I applied for my first position here, the role was for removing Cisco routers from over 1000 branch locations and replacing them with a non-Cisco SDWAN appliance. And yet the fact that I was CCNA certified was a deciding factor between me and another candidate.
 
Try to recognize in your studies what is an industry standard, such as protocols and RFCs that everyone has to abide by, and what is Cisco’s way of implementing things. Sometimes the way Cisco does things becomes the standard that everyone follows, and sometimes they go off on their own, and its only the requirement of interoperability that keeps things minimally compatible.

Also consider that a Chassis like that typically includes the drive backplane and often the PSU(s) as well, which are low-volume specialized parts as far as these things go. If you look at the cost breakdown of a Backblaze pod you’ll see the backplanes cost as much or more than the bent metal, and they designed fairly simple ones that just need to do SATA, not full SAS.

I’m working at a Fortune 500 company as a Lead Network Engineer. A few weeks ago, myself and three of my colleagues flew out to a new datacenter to rack and set up $2 million worth of Cisco and F5 equipment. Nexus 9K switches in spine and leaf topology, with Catalyst 9300L switches for the out of band management, and Catalyst 8500 routers. Each one we performed initial setup on purely from serial console. All programming of them done via CLI after they got online too. The VXLAN config will be done via Nexus Fabric Manager, but that’s it and we’d be comfortable doing it by hand if we hadn’t been given it for free. We’re connecting console servers to provide OOB serial access as well. If we had gone with Arista or Juniper for this deployment, the overall methods would have been the same - I haven’t seen a GUI yet that is good enough to completely replace the speed at which you can get precise information out of a CLI. GUIs are good when you are taking a larger overall view at something, or to enable templates and standardized workflows.
 
Except for when they try to teach their automation tools, anything you learn about Cisco will be transferable to general networking principals and other vendors. I had a networking class in college that was just using a CCNA Study Guide as the course material, and at my first job after that I mainly touched Aruba/HP and then later Ruckus/Brocade switches, and the knowledge I gained follow the Cisco methods was still useful to me.
 
At my second job, we used hardly any Cisco equipment. And even so, when talking to my manager about what I should study and certifications to try to get to further my career both with that company and in general, I was told to continue on the Cisco certification path.
 
At my current employer, when I applied for my first position here, the role was for removing Cisco routers from over 1000 branch locations and replacing them with a non-Cisco SDWAN appliance. And yet the fact that I was CCNA certified was a deciding factor between me and another candidate.
 
Try to recognize in your studies what is an industry standard, such as protocols and RFCs that everyone has to abide by, and what is Cisco’s way of implementing things. Sometimes the way Cisco does things becomes the standard that everyone follows, and sometimes they go off on their own, and its only the requirement of interoperability that keeps things minimally compatible.

While the raw materials cost of the chassis isn't going to be much, sure, the cost of machining and assembly for a 60 drive chassis is not insignificant. All of the drive bays and the chassis itself are going to be built to spec with smaller tolerances than what you would get in a consumer case. This is because, once 60 drives are involved, the amount of vibration from them is pretty extreme. The chassis cannot be allowed to rattle about as a result of the drives spinning, so it needs to be built more precisely. It's also highly likely that it needs to ultimately be assembled by hand, which is going to require someone with experience - not a minimum wage employee - and there would be a lot of QC checks.
 
A business isn't going to blink at spending $2000 AUD, or even $2000 USD, for a chassis for their server, but they will be beyond furious if the chassis causes drive failures and loss of data.
 
Basically, while it might seem excessive for a case, the company likely isn't making that extreme of margins on it at the end of the day once you take the complexities of such a case into account.

Cisco is the de facto standard in enterprise deployments.
 
Once you get up to speed with the CLI, it's so much faster than re-learning the web UI on new gear. Even other brands tend to imitate the way IOS handles when they make their own interfaces. (Brocade is almost identical.) It's also extremely convenient to dump a config out to a text file, and the commands you learn on an old 2600 series still generally apply to current hardware. It's like learning how to use Bash.
 
Ubiquiti is prosumer at best. Propose rolling that out at a large company and you'll get laughed out of the room.
 
Always remember: copy run start

I'm also learning networking, but in high school, and CLI really is faster when you get used to it, especially when you can copy paste most of the configuration, and just change things like ip addresses

CLI is easier than GUI once you get use-to autocomplete, it's also safer as scripts can be checked by work colleagues before implementing.

Yes.

Harhar tin foil hat.
but seriously if you actually want to “turn on and off” the wireless often and quickly, a shielded box that you can place over it is going to be effective. Faster to walk over and remove the box than to log into a page and change a setting. (Depending on the size of the house).
 
Or as @Heats with Nvidia says, get your own router. You won’t get anywhere with most ISPs with the argument that other ISPs let customers do this because your ISP probably has no competition. Or else move to the competition.

Harhar tin foil hat.
but seriously if you actually want to “turn on and off” the wireless often and quickly, a shielded box that you can place over it is going to be effective. Faster to walk over and remove the box than to log into a page and change a setting. (Depending on the size of the house).
 
Or as @Heats with Nvidia says, get your own router. You won’t get anywhere with most ISPs with the argument that other ISPs let customers do this because your ISP probably has no competition. Or else move to the competition.

This “smells” like a SATA cable/backplane issue to me.

CRC Error count > 0 makes me think this is the issue. I've seen it a few times, actually.

Wow I read that wrong. 
 
IN that case, I'd just do raidz2 instead of a hot spare then.

looks like LAN, you can probably lift up the little flap you see now and underneath should be RJ45

Should be rougly the same code for ZFS
 
Truenas has a much better gui for working with ZFS, and unraid doesn't handle a lot of ZFS changes that well, so I'd probably skip ZFS on unraid for most uses.

Having different subnets means that devices won’t expect an IP outside of their subnet to be local, and therefore will use the default gateway instead. If there is a shared router between the subnets, and it doesn’t have firewall policies prevent the two from talking to each other, then it will happily route traffic between the subnets - that is in fact the main job of a true router, the way they were used originally.
 
You mention “Guest Network” - some routers or APs will have this function, and it normally includes automatic firewall policies to let the devices on it talk to the internet but not anything local. Maybe something happened to the settings on your guest network? Did you need to allow it to reach a printer or something like that at some point?
 
Finally, you mention subnets, but you didn’t mention VLANs. If you have two subnets, but don’t have VLANs, then those subnets are in the same “broadcast domain” - meaning that they will hear broadcast and multicast packets from each other. That may be a contributing factor to the behavior you are seeing.
 
Hopefully this will help you determine what has changed. But I can promise you that the fundamentals of the subnet mask have not.

Alternatively, have you been doing automatic snapshots? What’s the timeframe on those? In ZFS this is the difference between “Used” and “Referred” - Referred being the current data, and Used including snapshots.

Alternatively, have you been doing automatic snapshots? What’s the timeframe on those? In ZFS this is the difference between “Used” and “Referred” - Referred being the current data, and Used including snapshots.

6430’s only do 1Gb SFP
 
https://webresources.ruckuswireless.com/pdf/datasheets/ds-icx-6430-6450.pdf

I don’t have insight into their system. But I do have insight into a system that is probably similar complexity, age, and annoying-ness.
 
$dayjob has a custom-built application that was originally developed in the early 1980’s. It exclusively runs on Unix mainframes, currently HP-UX mainframes with Intel Itanium processors since the early 2000’s. We were one of the companies that bought into the hype of Itanium, but it was already a Unix Mainframe application so the porting from whatever it ran before to Itanium wasn’t hard, and HP themselves helped with the porting because we were an early customer. Two decades later and we are trying to port it to Linux/x64 but day to day production still relies on 8 HP-UX systems that take up 1/2 of a rack each. An entire datacenter is built around supporting them.
 
Anyway, relevant to this story, for us the issue isn’t “disk space”. The HP-UX OS is capable of mounting iSCSI shares of any arbitrary size (I believe its been patched with ext4 support). The issue is that the system uses files with specially laid out metadata structures as databases. Technically all databases are files at the end of the day - have to structure the data on disk somehow. The difference is that this is some special type of database written in the early 2000’s that is tuned for fast processing by the Itanium CPUs and to be read directly between disk and RAM, and the data structure has to be written out in advance. Its like formatting a drive before you can use it, or if you’re old enough to know these things its like writing the sectors onto a HDD or FDD directly. Every time the system is down for maintenance, in addition to their other tasks, the Unix Admins run scripts to expand the database files as fast as the system can handle it - literally just writing out empty areas at the end of the existing database files for it to fill in with data later. If the system ever caught up with the prepared database area, it would crash and require emergency expansion. I suspect it is something like this when they say they ran out of disk space - and it sounds like their application didn’t just halt immediately but instead tried to keep running and they lost a bunch of data either that was trying to be added, or already stored on disk. The two days was probably the time it took to restore the most recent backup, and replay/rebuild as much data as they could.
 
The decisions around making the system this way made sense at the time - there’s no use in complaining about decisions made two decades ago. But its hard to swap a diesel engine for the steam locomotive while the train is in motion.
 
Edit: Went and read the actual article. This sounds like a more mundane issue than I thought - it literally ran out of disk space when they tried to update it, but when it did so it deleted some data. And they resolved it by recovering to a new server with more space. That’s just bad administration.

I don’t have insight into their system. But I do have insight into a system that is probably similar complexity, age, and annoying-ness.
 
$dayjob has a custom-built application that was originally developed in the early 1980’s. It exclusively runs on Unix mainframes, currently HP-UX mainframes with Intel Itanium processors since the early 2000’s. We were one of the companies that bought into the hype of Itanium, but it was already a Unix Mainframe application so the porting from whatever it ran before to Itanium wasn’t hard, and HP themselves helped with the porting because we were an early customer. Two decades later and we are trying to port it to Linux/x64 but day to day production still relies on 8 HP-UX systems that take up 1/2 of a rack each. An entire datacenter is built around supporting them.
 
Anyway, relevant to this story, for us the issue isn’t “disk space”. The HP-UX OS is capable of mounting iSCSI shares of any arbitrary size (I believe its been patched with ext4 support). The issue is that the system uses files with specially laid out metadata structures as databases. Technically all databases are files at the end of the day - have to structure the data on disk somehow. The difference is that this is some special type of database written in the early 2000’s that is tuned for fast processing by the Itanium CPUs and to be read directly between disk and RAM, and the data structure has to be written out in advance. Its like formatting a drive before you can use it, or if you’re old enough to know these things its like writing the sectors onto a HDD or FDD directly. Every time the system is down for maintenance, in addition to their other tasks, the Unix Admins run scripts to expand the database files as fast as the system can handle it - literally just writing out empty areas at the end of the existing database files for it to fill in with data later. If the system ever caught up with the prepared database area, it would crash and require emergency expansion. I suspect it is something like this when they say they ran out of disk space - and it sounds like their application didn’t just halt immediately but instead tried to keep running and they lost a bunch of data either that was trying to be added, or already stored on disk. The two days was probably the time it took to restore the most recent backup, and replay/rebuild as much data as they could.
 
The decisions around making the system this way made sense at the time - there’s no use in complaining about decisions made two decades ago. But its hard to swap a diesel engine for the steam locomotive while the train is in motion.
 
Edit: Went and read the actual article. This sounds like a more mundane issue than I thought - it literally ran out of disk space when they tried to update it, but when it did so it deleted some data. And they resolved it by recovering to a new server with more space. That’s just bad administration.