On Wed, Jun 7, 2023 at 4:24 PM Simon <linux@???> wrote:
>
> 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.

Exactly!!!!

IOT sounds useful until one realizes that its mostly about wireless signaling.
Don't think that that's a good idea in my design.
>
>
> > 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 :)

Well its the contemporary router that's running DD-WRT - - - - version the next
is OPNsense23.1 (IIRC) - - - the system its running on has lots of hp too.

snip
> 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.
>
My present thinking is to use 172.16/19 - - - that gives lots of
address space without
throwing the door wide open either.
>
>
snip
> > 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.

In checking pricing found that 24+2 switches seem to be available for
about 20 to 25%
of the 48+4 models. Yes there will be more boxes but the price point
is significantly
lower.
>
>
> > 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.

Last idea I ran into was a dual-protocol network (both ipv4 and ipv6.

I do want to be ready for a reasonably painless switch to ipv6 - - -
the impending isp is working on it but likely dragging their feet so
I will have time to get things started in ipv4 - - - I think.
>
> > 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.

I commented because using a search engine I was not able to find a definition.
Understand it may be common practice but I'd never seen such symboling
in mathematics - - - - likely its mostly a 'programming' thing.
>
>
> > 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.

That may be a result but - - - not yet - - - its called cost.
>
>
>
> 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).
>

I'm starting with 4 to 6 working points per 'node'.
Looking down the road that might escalate - - - - if it gets to 10 to 16 then
I think it would make sense to have a switch (thinking a 24 at this point) per
'node'. (By that time there would also be some more interspersion of
'servers' (for lack of a better term).
>
>
>
> 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 ?

Arduino is far too pricey - - - I've been considering something like
the RP2040 - - -
its not really wimpy nor is it very pricey either.
>
> 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.

Initially that makes sense.
Loathe to have a controller on top of a group of 6 or 8 other 'controllers'.
Haven't started to worry about the system for that level - - - that's
going to be
version 2.5 to 3.0 and that's a little down the road - - -grin! (I've
got lots to
work on as it is!)
>
>
>
> 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.
>
>

Interesting ideas - - - thanks for the time sir!!!