o1bigtenor via Dng <dng@???> wrote:

> I'm trying to educated myself on networking and am finding, so far at
> least, that this is considered specialist only country. So when I
> start asking questions I get ignored because my questions are too
> basic (so they're considered boring) yet I can't find answers.

I would imagine you are suffering from the “don’t know enough to be able to ask the right questions” problem.


> There is a change in ISP coming and I'm working on setting up a
> opnsense router/firewall - - - at present I'm on fixed wireless (quite
> pathetic internet service actually and far far too expensive for what
> I get!!) but that change is still some time away - - - at least a few
> weeks and maybe even a few months.
>
> Should I switch my present router from 192.168.1.1 to my chosen
> 172.16.x.x (I'm running on dd-wrt)?

What your ISP offers is (almost) completely irrelevant to how you run your own internal network.

The exception is, as someone mentioned in the thread, if your ISP uses RFC1918 addresses (meaning you have a NAT between your “internet” connection and the actual internet. That’s evil and shouldn’t happen, but it’s actually more common than it should be - not least because more and more ISPs are implementing “carrier grade NAT” (CGN) because they don’t have enough IPv4 address to give a single address to every subscriber. If you are so afflicted, then you’ll need to avoid a clash between your internal network and the ISP addressing - otherwise your router will suffer from not being able to know which way to send packets.
But running DD-WRT gives you a good start as at least we know it won’t suffer from some of the issues mentioned below :)

> (Any suggestions for how to learn more about networking without buying
> hugely pricey Cisco courses?)

I wouldn’t learn networking from Cisco courses - they will teach you "networking according to Cisco” which isn’t necessarily the same as what everyone else does. I recall having done Cisco courses in the past, and for example they still taught things like classful subnetting/supernetting and not being able to use subnet zero - something the rest of the world had abandoned perhaps a decade earlier !



Antony Stone <Antony.Stone@???> wrote:

> Now, the interesting bit for you is that the entire range of addresses
> 192.168.0.0 up to 192.168.255.255 have been reserved (in document RFC 1918)
> for "private use", and there is nothing to stop you deciding "right, I'll use
> all of them, then" and setting your netmask to 255.255.0.0
>
> That means you can have up to 65534 machines on your network using addresses
> which all start with 192.168, just so long as every machine on the network has
> a netmask of 255.255.0.0 (at present you'll be using 255.255.255.0).

Unfortunately I found some kit that for unfathomable reasons can’t cope with that. It was a long time ago, and there’s no excuse for it, but “supernetting” Class C 192.168 addresses can cause issues. Better to just use the 172.16/12 block in the first place (or the 10.0.0.0/8 block).
My current (ISP supplied) router doesn’t work (DHCP doesn’t work) if I change from the default 192.168.1.0/24 ! I do this as a matter of course because the use of 192.168.0.0/24 and 192.168.1.0/24 is so ubiquitous and it can cause problems when using VPNs to other networks. I used to work in an environment where we did this a lot.



o1bigtenor via Dng <dng@???> wrote:

> I seem to remember that 0.0, 1.1 and 255.255 were reserved from any group.
> not allowed to use the 0.0 and the 255.255 as you mention and that 1.1 is the
> router's address.

No, only the very first and very last addresses are unusable - the first is the subnet address (not actually used for anything), and the last is the broadcast address.
However, over the years I’ve come across plenty of kit that (as mentioned above) has been built by people who really should know better - for example I’ve come across routers that refused to allow .0 or .255 to be used in the config despite them being perfectly valid in many situations. Special callout for Netgear for this bit or brain dead design.

> I'm thinking that I'll land up using a whole pile of something like 16 port
> unmanaged switches - - - cheap and sorta inflexible but still useable.
> Then the idea is to chain them together.

Should work. Try to cascade them rather than daisy chaining them. I.e. have a root switch, with a number of branches off it, and then branches off those - rather than going a to b, then b to c, then c to d, then d to e, and ... In principle it makes no difference, but the more hops between nodes, the higher the latency. In the “good old days” of hubs (not switches) and/or coax there used to be a 5-4-3 rule which I won’t go into here - suffice to say it’s not relevant once you use switches and network design is now much simpler for large networks.

However, on such a size of network, unmanaged switches could be something of a nightmare WHEN there is a problem. Suppose there’s a broadcast storm* - with an unmanaged network you would have to manually unplug cables to localise the problem. With managed switches, you should be able to identify where they are coming from without unplugging anything, and even shut down an offending port. OK, this is getting into advanced networking territory, but if you are going to run this size of network, and it going down is going to be more than an irritation, then you need to learn it.
* One classic source of a broadcast storm is when someone plugs a network cable into two switch ports instead of a switch port and an end device. In once case it was someone just being helpful - they’d found a network cable lying on the floor and assumed it should have been plugged into a spare port on the small unmanaged switch on the desk (they didn’t have enough ports in the room). Actually, it was for someone to plug into their laptop. So the first broadcast packet that comes along is queued by the switch to be sent out of both the ports - and when it is, it’s received on the opposite ports. There are now two copies of the broadcast packet, which get queued for both ports so now there are four of them, then 8, then 16, then 32, until the packet rate is limited only be the capacity of the switch to buffer them and the network cable to carry them. You now have the single packet replicated to the limit of the network and being fed to every other port in the network. It’s interesting to diagnose the first time you come across it.

Basic switches will just do the above, when you get into “not bottom end" end switches, they often have protections (e.g. rate limits) for such traffic so at least the network carried on “sort of” working. Also, once you get into managed switches, then you have options such as rapid spanning tree (RSTP) which will shut down one of the ports and completely prevent it.


> The big question is - - - if I'm using this 192.168.1.1/19 setup - - -
> can I do this from 1 (!!) router?

In principle yes, but if the router has been nobbled to not support larger networks then no.

> (If this was all high speed data I wouldn't be asking - - - most of this
> stuff is say a chunk of data every 0.5 second which to networking
> is sorta slow and as there might be only 4 bytes of actual information
> that isn't a lot of bandwidth.)

It’s not a lot of data, but each ethernet packet is (from memory) a minimum of 56 bytes.



Ralph Ronnquist <rrq@???> wrote:

>> This is where ipv6 would be useful but its going to be a while before
>> my isps are getting there - - - my guess is at least a couple years if
>> not longer!
>
> It's easy enough to tunnel ipv6 through an ipv4 virtual cable onto an
> ipv6 internet host (eg $5/month VPS) and in that way become ipv6
> connected well before your ISP :)

Or use someone like https://tunnelbroker.net/
Their training (certification) is quite a useful tool too.
However, IPv6 significantly increases the overheads, and some of these devices may be quite resource constrained. Easier to stick to IPv4 & RFC1918 addresses.

> The principles are the same as ipv4
> although the ipv6 folks seem to have reinvented the wheels with
> different names, maybe just to make life interesting or maybe to make
> grounds for new consulting $$…

There are good grounds for using different names.
In some cases the IPv4 names aren’t actually very good, in some cases the thing being described is different (sometimes subtly) to IPv4, and it helps shift the mentality away from “just the same as IPv4 but with more address bits”. If you think “just the same but more bits” then you miss out on a lot of capability, and you’ll struggle to grasp some of the things you do need to know.




o1bigtenor via Dng <dng@???> wrote:

>> The networks themselves (172.17 != 192.168 afterall ;), and total
>> available subnets (for example, there are only 256 /24s in
>> 192.168.0.0/16 vs 4240 in 172.16.0.0.12).
>
> If only I knew or could find out what '!=' meant.?

“Not equal to”. “=“ has the same meaning as most places, i.e. equal to. “!” means “not" in many maths and computer contexts.


> Hmmmmm - - - - so if I were monitoring some 3k sensors/points and the
> actual volume of information isn't that high (high for me is say 10 bytes every
> 0.5 seconds per sensor with most being much lower - - - say 6 to 8 bytes
> every 2 to 5 minutes) this still can be controlled through 'one' point?

That doesn’t sound like a lot of traffic, it will most likely be limited by the ability of that one point to process the data - and that depends on what it is, how you process it, and the overall specification of the system.




Antony Stone <Antony.Stone@???> wrote:

> You have to take into account the ARP table inside switches (and wireless
> access points, if you're even thinking about doing any of this without
> cables).
>
> The ARP table matches up MAC addresses (which are the hardware-unique thing
> about any networkable device) and the IP address the device has been assigned
> at the time.
>
> You *might* find enterprise (ie: expensive) switches which can handle this many
> ARP table entries, but there's no way a wireless access point is going to be
> able to do that.

Good point, but these days I’d be surprised if even low end switches couldn’t handle (say) 4k entries. Enterprise switches would do it would think. But definitely something to bear in mind.
Picking one switch at random (well almost), I picked a 48 port unmanaged switch from Netgear https://www.netgear.com/uk/business/wired/switches/unmanaged/gs348/
The spec sheet says that the 5 port version (GS305) has a 2k table - so your point is valid. The 8, 24, and 48 port versions all have 8k tables so would be OK.




Steve Litt <slitt@???> wrote:

>> Note that it is advisable to keep networks down to ABOUT 1000 hosts or
>> so (a /22), as network overhead can cause problems after that
>> (although, it also depends on how much actual traffic you need to
>> move).
>
> I didn't know this. If I had, let's say, 20,000 hosts, could I get
> around the problem you mention by using routers between networks of
> 1000 hosts per network?

Yes, that is indeed one way of doing it. It had crossed my mind before I got to your email, but hesitated mentioning it as it’s somewhat more networking to configure. The capability of the individual systems/sensor devices also needs to be considered - they might well have tighter limits than the MAC address tables in switches mentioned above. If that’s the case, then splitting them up might be required.

Thinking about it, there’s a good argument for putting a router between the “house” network and the “industrial” network - and apply some filtering. You don’t want every random device being able to probe your industrial network, potentially causing problems’ and introducing a vector for attacks or malware.



Dan Purgert via Dng <dng@???> wrote:

>>
>> I didn't know this. If I had, let's say, 20,000 hosts, could I get
>> around the problem you mention by using routers between networks of
>> 1000 hosts per network?
>
> Bear in mind I'm focusing somewhat on general "business grade" type
> stuff that costs in the range of a few hundred to a few thousand dollars
> (say 4 figures max), but ... Yep, that's pretty much how the general
> internet works today.
>
> Taking 192.168.0.0/16 as an example; we could have one central router
> talking to say 8 routers that each control a /19.
>
> In turn, these 8 intermediate routers each talk to 8 more routers with
> the /22s for "client access".

I wouldn’t use two levels like that, it’s an unnecessary complication. Bear in mind that many L2 switches also do L3 routing, so a (say) 24 port L2/L3 switch could handle up to 23 downstream networks.
To a certain extent, a lot of this depends on how the devices logically group.
If, for example, each “cell” had a few hundred devices - then it might make sense to put each cell on it’s own network and have a lot of networks.
On the other hand, if there are only (say) 2 or 3 devices in a cell, then you’d put a lot of cells in each network.
There isn’t a “right” answer - it’s a case of looking at what you are looking to connect, and trade off the various options to arrive at what you consider the optimum solution (given your idea of how the different factors should be weighted).




o1bigtenor via Dng <dng@???> wrote:

> So - - - - these individual points are NOT complete computer systems -
> - - there may only be a signal - - - ie start and then the
> microcontroller is giving information back - - - often that will be
> just 'done' sometimes a function happens on some kind of basis (this
> sensor is read every xx period of time).

Ah, a bit more detail.
I’d probably be looking to implement a controller for each cell that will handle all the sensors and actuators for that cell - and on the upstream side talk to your central system. You’ve simplified the system, and simplified (at least reduced in size) the network. it also means you aren’t implementing an IP stack in each tiny device.

As others have mentioned, putting IP on each device probably isn’t the best way to go. For example, you can probably feed analogue signals into a lot of small computing systems quite cheaply - I’m sure that (for example) at least some ARM system will have that. I know that the small controllers Arduino runs on can do it - but then it’s a relatively expensive option to add ethernet to it. I don’t know if something like a Raspberry Pi handles analogue signals in ?

Another thing to consider is whether you need anything approaching deterministic control response. Ethernet doesn’t offer deterministic packet delivery, though there are some (expensive) options that approach it. So a localised controller, using more appropriate signals, may well be the right thing to do within each cell.



Didier Kryn <kryn@???> wrote:

> Didn't you forget that all these sensors don't speak to each other, but they instead only speak with one single host. Given that, I'm not sure breaking down the traffic into many local loops would bring much improvement.

But don’t forget that even though each device may only be talking to one other, there will almost certainly be broadcast traffic which will go to all devices. Individual devices may suffer from overload just handling the packets, or they may suffer from resource overload (e.g. too many entries in the ARP table), and so on.
There’s also a reliability issue since in one big network, a broadcast storm may kill everything (the results of those can be “quite interesting”, I’ve seen and had to diagnose/locate them). Split the network up and you stand a better chance of most of it keeping going. But as per the bit above, it now looks like the size of the network may be significantly smaller.




Dan Purgert via Dng <dng@???> wrote:

> Yeah, I "sort of" remember efficiency being a thing, but always took it
> on the numbering side ("you get a /64!").

Take the “/64” with a pinch of salt.
Yes, at a network/prefix level, /64 is more or less ingrained - particularly if you use SLAAC (nodes picking addresses for themselves. AFAIK that is the only case where /64 is “hard coded”. If you don’t use SLAAC then you can use longer or shorter prefixes. For example, in a server farm you might use a different address allocation system (DHCP, or config via an automation system) and a much longer prefix to allow a few addresses/host and lots of hosts.
At the other end of the network, you should be getting at least a /56 from your ISP, possibly even a /48 - allowing you to have 256 or 65536 /64 prefixes in your network.
For a general network where you don’t control all the devices, you effectively have to support SLAAC because a major OS vendor has a religious zeal that the device should have free reign to pick addresses via SLAAC and the idea of a network administrator having any control is just evil - never mind all the security, accountability, and legal reasons why people might actually need that level of control. So unless you want Android devices to not be able to use your IPv6 network, you have to support SLAAC, and hence have to use /64 regardless of whether that is the most appropriate for your situation.

I think that apart from SLAAC, there is nothing (protocol spec wise) that hardcodes /64 anywhere. But for practical reasons, it’s the de-facto standard. And of course, there are bound to be implementations where someone assumed that everything is /64 so won’t work properly with anything else - much like the “can’t use .0 or .255” mentioned above.


Simon