Project - Using Routers

A single Annex device can provide amazing functionality, but there are many reasons why we might want to network several together.
But how many of us know how to create a network best suited to our Annex needs ?
I certainly didn't, and it was quite a big learning curve to achieve everything I wanted... but it isn't actually that difficult once you know how.

Here was my wish list...
I wished to leave the original incoming router alone and achieve everything using extra add-on routers.
I wanted a 'private' subnet with internet access to at least 2 other locations, all with access to a shared NAS drive (Network Attached Storage).
I also wanted a separate 'public' subnet with internet access for guests without them having access to any other of my network areas.
Last but not least, I wanted a separate 'normally-isolated' Annex subnet to cover at least 4 different wifi zones spread over a couple of hundred meters.
Ideally the normally-isolated Annex subnet could optionally be able to connect to the internet whenever needed.

This article should allow anyone to achieve their own network project tailored to their own specific needs - and importantly, without needing to mess with their existing wifi.
Just be aware that this article has been sat on the shelf for nearly a year waiting for time to polish and publish, but I can't waste any more time on it now, so it was a choice of publish 'as-is' or not at all.  It may contain some typo's and cockups, but that shouldn't detract from the wealth of useful info it contains, and I don't think there is anything else similar available (there wasn't a year ago anyway), so hopefully some people will find something useful.
It caters to both newbies and experts, so it covers a broad range of info... but people only need sufficient for their purposes, therefore just skip over whatever isn't needed.
I've also added a "UTP Cabling" supplement to show how to create your own network cables if needed.

IP Address
Networks use 'routers' to literally route network messages between networked devices, which must each have a unique IP address.
The 4 byte (IPv4)  IP address actually consists of 2 parts, the network SUBNET address, and the NODE address, as differentiated by the Subnet Mask  (always for our purposes - logical AND the IP address with the subnet mask to obtain the actual subnet address)
For our use, each subnet can address 1 bytes worth (8 bits) of nodes (256) - but 0 is reserved to denote network, and 255 is reserved as the 'all-nodes' broadcast address, leaving only 1 to 254 actually available for usable node addresses, of which one is needed for the router (usually .1) leaving  253  available for client devices.  By 'client device' we mean anything connecting with a node address in 'station' mode to a routers subnet.

If Annex does not 'join' a routers network at startup it defaults to as an Access Point (AP) to offer an SSID for a browser connection to allow editing or config changes etc.
In this mode it is not part of a network, so cannot send network messages to other nodes.

For Annex to send network messages to other network nodes, it must connect to a wifi router in Station mode and join that routers subnet. It must first connect to the routers wifi SSID using the appropriate name and password. Then it needs a valid unique IP address in order to actually be accepted on to that routers subnet.
IP addresses can be assigned to network clients in 2 ways, static (embedded in the device configuration), or dynamic (temporary DHCP lease).

Dynamic (DHCP) Address
If a connecting device has not been configured to use a reserved 'static' IP address, it can lease a temporary 'dynamic' IP address from a routers DHCP Server 'pool' of available addresses. Different routers use different DHCP server defaults, perhaps a Start address' of 100 might be used with maybe a 'Pool Size' of 100 addresses or perhaps an 'End address' of 200 for example.
But importantly, there will only be a limited subset of the available 253  (router needs one)  IP addresses for DHCP clients.
The 'Lease' duration allows a device to retain use of that IP address for the specified lease period, but if not in use and renewed when the lease expires, then that IP address is returned to the pool again for use by another DHCP client.
So be aware that the next time a DHCP client connects, it may be allocated a different IP address from the pool.

This is the same principle that ISP's use to allocate temporary DHCP  IP addresses to their internet subscribers, whose allocated IP addresses can often change overnight. Those allocated internet addresses are actually Public addresses which must be unique on the world-wide internet, whereas a local LAN has Private addresses which only need to be unique on that particular subnet.

Requesting a DHCP IP address for an Annex device is just a matter of supplying the router 
SSID name and password in the Config 'Station Mode' fields and leave all the IP fields blank.

Although DHCP has the advantage of simplicity, it has the disadvantage that the device can attach to a network without indication of the assigned IP address... but you will probably need to know its IP address in order to connect to and manage it.

There are ways to deal with that... many devices will have a user button (typically gpio0) and LED which could be used to blink out the IP address on the LED when the button is pressed.
Or a new node could send its newly assigned DHCP address to a known existing networked device which can be connected to for retrieving that info.
I use an Annex text-to-speech 'Voice Announcer" server which can speak the IP addresses of any connecting node at startup if I wish.
All my networked devices respond to an EasyNet "All Reply" instruction, causing them to udp.reply back with their node names and IP addresses.

You could use a utility to scan your subnet for existing devices before powering up a new node, then scan again after to see what is new.
Or simply scan and try connecting to any devices which you don't recognise.

Static IP Address
Alternatively you could manually assign 'static' IP addresses to your devices so that you would always know what address to connect to for each device (what I usually do).

To assign a static IP address to an Annex device is just a matter of entering the appropriate details in the IP fields... but those details obviously need to be correct and relevant.

To find out that info: assuming you are on a Windows computer connected to the same wifi router that you wish the Annex device to connect to (I'm using Win7 in a vm),... open a 'cmd' command line window  then run IPCONFIG  and take note of the displayed Wireless LAN adapterdetails... and especially the all-important 'Default Gateway' IP address.
On linux, type ip a  into a terminal window to show the IP addresses of your interfaces, then ip r to show the 'default' gateways.

The Default Gateway is normally the address of the controlling master router.
Technically the subnet address is obtained when you AND the Default Gateway IP address with the subnet mask.
But for our purposes we know (from the subnet mask) that the last byte gives the routers node address, so the subnet address consists of the first 3 bytes of the Default Gateway address... therefore the subnet is 192.168.2 in the example.

You need to choose a valid static address on that subnet, but one that falls outside of the DHCP pool, and which also doesn't conflict with any other static address assigned on the subnet.  That's why only one controlling master router should have its DHCP Serrver enabled if there is more than 1 router on a subnet.
To avoid IP conflicts it's worth pinging the proposed address from the command line just to be sure nothing else responds.

All 3 Annex IP fields must be populated for a Static address, including the subnet mask..

Summary: the Default Gateway is usually the IP address of the router, whose first 3 bytes are its subnet, which must be the same as the first 3 bytes of the proposed static IP address wishing to join that subnet, and whose last 'node' address byte must be unique on that subnet.

Dynamic IP addresses will be assigned automatically from the routers DHCP Server poolto connecting devices unless the connecting device is already configured to use a static IP address.

Default Gateway
The Default Gateway points to the controlling primary subnet router which is responsible for routing all LAN traffic to all nodes on the local subnet.
If the default gateway is NOT configured for a WAN connection it will ignore any IP addresses it does not recognise as being local to the subnet it is controlling.
If the router DOES have a remote WAN connection it will be configured with an appropriate remote client IP address on the remote subnet  eg: ISP internet connection) along with the WAN default gateway address of remote subnets controlling router, so anything not recognised as a local subnet address gets dumped out for the WAN default gateway router to handle.
The internet is basically a network of networks, so unrecognised subnet traffic will keep being dumped out the WAN garbage chute for other WAN Default Gateways to deal with, until eventually one of them recognises it as for their own local subnet and delivers it.

Public IP addresses are like phone numbers - they can identify the country, the region, the ISP, the subscriber group, and ultimately the specific unique subscriber... so it's not like shooting in the dark at a needle in a haystack, and doesn't require as many different Gateway 'hops' as one might think, because each hop homes in ever closer to the required destination.

Summary:  the LAN Default Gateway is the controlling routers address where all local traffic is sent for directing as appropriate.
Local traffic (addressed to other nodes on the local subnet) is directed to the relevant local subnet node destination.
NON-local traffic (denoted by a different subnet address) gets ejected out through the WAN port (if one is connected) and sent to the WAN Default Gateway for it to deal with... and so on until it reaches its final destination.

Computers and electronic devices process numbers, but our human brains are much more comfortable with words.
Therefore IP address numbers are not easily digested or remembered by us, especially when there are lots of them to remember.
DNS (Domain Name System) makes them easier for us to use, by assigning registered Domain Names of words to the IP numbers. 
DNS servers act like an internet version of a telephone directory, allowing us to use Domain Names, which are automatically resolved back to IP numbers from DNS lookup tables, which routers can then use to 'route' on to their destination.

If you open a CMD prompt then enter "ping" by itself, it will return the Ping Help syntax, and listed under Options you can see...
 "-a  Resolve addresses to hostnames".
To see that in action, clear the screen with "cls", then enter "ping -a"  and notice that it returns the IP address which has been 'resolved' from the domain name (even though the destination ping reply response has been deliberately turned off).
Now carry on reading, but later (if you don't forget), see which you remember... the domain name or its IP number.

Annex devices address other devices using IP numbers because there is unlikely to be a DNS server available to resolve names to addresses on a home LAN.
(EasyNet does offer facility to address Annex UDP nodes by name, but this is not about EasyNet, so will be covered elsewhere)
If the router has its WAN connected (usually to the internet but possibly to a parent subnet)  any messages that the local router does not recognise as local will be dumped out through the WAN port for the parent WAN Default Gateway router to deal with.
If the message is addressed using a Domain Name then the WAN Default Gateway must use the specified DNS Server to first translate the domain name into the appropriate IP address number before it can send the message on towards its destination.
That's why the WAN configuration also includes DNS server addresses (Primary DNS, and Secondary DNS as a backup).

A DNS lookup takes a finite amount of time to reach the specified DNS server, then return with the response - so DNS lookups cause a delay (which will be dependent on the DNS servers connection speed) even before the original message can be sent.

Most ISPs are likely to 'scrape' all their subscribers web activities for their own financial purposes, as well as for local legal reasons.
So although the closest DNS server will probably be those of your ISP, that doesn't necessarily make them the fastest or best.
Other DNS servers can be used if preferred, eg:  a fast and ethical global DNS service is provided (free) by Cloudflare

Summary:  Local home LAN's must use IP numbers to address messages to other local nodes because there is no local DNS server available to locally resolve Domain Names back to their corresponding IP address numbers.
If the LAN connects elsewhere using its WAN port (typically to the internet) the WAN parameters include facility for entering DNS servers to translate global domain names into their appropriate IP address numbers when necessary.

IP Protocols
There are 2 main methods (protocols) for sending networked messages using IP addressing.
TCP is like a person-to-person phone call with 2-way conversation to only 1 target, with feedback to resolve misunderstandings.
UDP is like a DJ at a night club broadcasting to anyone listening, but the noisier the environment, the harder to reliably hear.

Annex uses UDP for networking, which is easy to use, but being a 'one-to-many' broadcast means there is no feedback mechanism and therefore no error-correction, so broadcasters take no further interest in their sent messages... not caring whether it was received or not.

IP Traffic
Most people will probably already have a wifi network for their internet access, which should initially be ok for developing Annex projects.
But piggy-backing Annex devices onto a live internet environment is far from ideal for reliable Annex UDP interaction.
The more network traffic, the less reliable the UDP broadcasts, because UDP has no inbuilt handshaking or error feedback,
Therefore ANY other traffic could prevent a critical Annex UDP broadcast from being received by the intended Annex target.

Even if nobody else is using thenetwork, software such as Google browsers and Microsoft operating systems regularly send back network messages reporting'telemetry' (legalised spyware) information about usage. Various other 'agents' are regularly checking online for availability of software updates, and vulnerable Microsoft products need to be regularly downloading anti-virus signature updates to avert malware disasters.
And then of course there are the relentless Windows 10 updates.
And this is assuming there are no malwares already exploiting your internet resources.
So just being connected to the internet can generate a surprising amount of network traffic... and that's even without the usual heavy usage of downloading files or streaming media.
And much of the traffic will use TCP, whose 2-way handshaking can more than double the amount of traffic.
You get the idea - if you value your children and want them to be safe, don't let them play on a busy main road.

But it's not really a huge problem, because routers are cheap enough to add another (you may even already have old ones laying around).
This project aims to show anyone how they can add one or more routers to create a network that is better suited to their needs.

Wifi Standards
HiFi syndrome was when those who could afford it kept upgrading to the "latest" hifi music system when something 'better' came out.

In this day and age it has been superceded by WiFi syndrome, upgrading to the latest router with the biggest range (or most aerial 'legs').
While it is sometimes overlooked that both the router and the wifi receivers need to support the newer specs to obtain that latest performance, what it does mean is that there are a lot of cheap lower spec 'yesterdays news' routers floating around, any of which is more than adequate to use for an Annex network of 2.4GHz ESP devices... as seen from the wifi comparison chart.

The home wifi router is basically a LAN (Local Area Network) controller with a wifi transceiver and some RJ45 LAN cable ports.
Most include a DHCP Server used for giving out dynamic IP pool addresses to client devices which don't have a static IP address.
The router keeps an IP table of all local client devices that connect to its LAN subnet address via its wifi and/or LAN ports.
The routers IP address serves 3 crucial purposes:
  Subnet Address - the first 3 IP bytes are the subnet address, to which all devices using that same subnet must connect to.
  Default Gateway - is the IP address that points all connected client devices to itself because it is the primary controlling router.
  Management Web Server - the IP address for connecting from browser to access router configuration and management pages.

Most routers will have some way of connecting to an external router using a WAN or ADSL or Modem port, for internet access.
An ethernet WAN port is not necessarily just for internet connection, it can connect to a parent router to provide anothersubnet.
Similarly, other routers WAN ports could be plugged into the local routers LAN ports to provide additional secondary client subnets.
Note that the WAN IP address, if configured, is the local routers remote client connection address on a remote WAN subnet.
In which case the WAN Default Gateway will be the IP address of the remote router, to which all non-local traffic will be directed.

Some routers have a USB port for connecting an external USB HDD to be shared on the LAN as NAS (Network Attached Storage).
Configuring Routers
To manage a router and change its configuration requires browser connection to its IP address then login with appropriate credentials.
It is advisable for the router to be unplugged from everything except the configuring computer, to avoid possible IP address conflicts.
It is also advisable to reset the router back to the known state of its factory defaults.
Connect to the routers factory default IP address, then login with the default credentials... often admin and admin, or on a label underneath, else will need an online search for the specific make and model. Remember that those default credentials are readily available to everyone, so best to change the router password and put it on a label stuck to the router (you'll be glad of it one day).

Enter the routers new IP address in the appropriate LAN or Network field, then Save and Reboot, then connect to the new address after the router has rebooted.

You are connecting internally from the LAN port to manage the router, so if you won't need to connect externally (from the internet) from the WAN, then disable Remote Admin access.

Only enable DHCP server on the primary controlling router of each subnet, and make sure it is disabled on all slave routers.

Isolated Network
If you just want an isolated wifi network to be reserved only for Annex devices to optimise reliability, then any old wifi router will do.
An isolated router does not need a WAN port for connecting to the outside world, so simply leave the 'Internet' or 'WAN' configuration page details at their unused defaults (and of course no DHCP address can be obtained from an ISP without any WAN connection).

Go to the 'Network' or 'LAN' configuration page and assign the router an IP address that has a different subnet to your internet router to be sure that they can co-exist in harmony together.  If your internet router is using for instance, then you might assign  or  for your 'Annex' router (or even  if you wish).
Both routers will be the primary router on their respective different subnets, so they can both have a node address of  .1 to befit their primary status in their own subnet kingdoms.

You may as well enable the DHCP server, taking note of the address pool start and end (or size) so that you can decide on a different range of addresses to use for manually allocating 'static' addresses if you so choose.
If giving your Annex devices a 'static' IP address, use the router address as the Default Gateway, and don't forget the subnet mask.
Obviously you will need to ensure Wifi is enabled, and assign a unique SSID and password for the Annex devices to connect to.
You would also be advised to pay attention to wifi channel numbers.

Wifi Channels
2.4GHz routers allow selecting a wifi channel number from 1 to 13, each operating on slightly different adjacent frequencies. Usually a routers channel number defaults to 'auto', which might be ok ... or it might cause it to be affected by your neighbours wifi channels.
To avoid adjacent channel interference you can manually set a routers wifi channel number to one of your choice. You will not have control over neighbouring wifi routers channels of course, but wifi range is usually poor, so hopefully your router will may not be affected by the neighbours channels anyway... and even if it is, then you simply set yours to something else.

Channel Overlap
When having 2 or more routers yourself though, channel selection needs some thought, because it's not quite so straightforward.
Channels 1, 6 and 11 do not overlap or interfere with adjacent channels.
So theoretically you could have 3 wifi routers in the same room which were using channels 1, 6 and 11 without suffering adjacent channel interference.
But if any of those routers was using a channel other than 1, 6 or 11 then you could have interference problems.

The more routers used, whether for providing adequate signal strength in areas between buildings or floors etc, or for having different subnets in the same areas (eg: internet and Annex), or perhaps both (I am using 7 routers), the more important channel separation becomes.

Be aware that there is a big difference between Channel overlap and Zone or Range overlap.
The red and blue zones shown here have ranges which overlap with all other zones, but none of them have channel overlap.
The yellow and green zones both use the same channel number, but their zones are out of range of each other, so there is no channel overlap.

Network Range
Wifi range is normally limited to just a few tens of meters (if you are lucky).
The range can be made longer but narrower by using a directional antenna, but like the difference between using a sniper rifle or a grenade ... the greater the distance, the better the aim must be.

Newer routers may offer some form of wifi extender facility, but they obviously still need to be within wifi range of the main router anyway, therefore need range overlap, which means they can only effectively increase overall range by about 50% or so.
So in the diagram above it could be used to extend the red range to the blue, but could not extend the yellow to the green.
And because their ranges must overlap, they need to use separated channels to avoid adjacent channel interference.
Plus there will be an inevitable transmission delay due to the extender having to receive signals before it can re-transmit them.
So for one reason or another, a wifi range extender may not be the best way to extend wifi range.
That's why many have an RJ45 Ethernet Cable port, allowing them to act as a cabled Remote Access Point for extending wifi range.

Remote Access Points
It is possible to connect one or more 'slave' routers in parallel by ethernet cable between their LAN ports to use as remote wifi Access Points.
Being connected LAN to LAN means they are all on the primary routers subnet, so they don't need a WAN port, therefore any old routers will do.
Ethernet cables can be up to 100m long, and several routers (or Ethernet HUBS/Switches) can be chained together for greater distances.

Any of the routers could be the primary subnet router, which is decided by configuration, not position or cabling.

The slave AP router(s) need to be assigned a client IP address on the primary routers subnet.
They also need their default gateway pointing to the primary routers address (not their own), and their DHCP server facility must be disabled, so that devices connecting to their AP SSID will be pointed to the primary router to receive a DHCP address if needed, so that the primary router can manage all the routing.

Each router with wifi enabled will offer an SSID for connecting to - each can be different - OR - they can all have the same SSID if preferred.
It is significant for Annex devices, because the SSID and password are typically pre-configured on each device - ie: embedded... so if you are creating an Annex wifi network which uses different SSID's, then you will need to ensure that each device is configured for where it will be installed.
That can be problematic, because the final destination router may be different from the one where it was being developed - so if you forget to change the SSID when siting, it might still manage to connect to the original developement router.. but with a much weaker signal, giving poor performance and reliability.

Alternatively, all Annex routers could use the same SSID and password, then any and all the Annex devices can connect anywhere.

Using the same SSID's is perhaps not such a good idea for mobile devices..
Connecting in the overlap area (shown on the right) will connect to the SSID with the strongest signal.
But moving in any direction may move deeper into the connected zone and result in an even stronger signal, or it may move further away into the other zone causing a weaker signal, resulting in poorer performance and reliability... a phone will connect to the strongest signal and keep that connection while it can.
So for example:  connecting during the day to a downstairs router and staying connected while moving upstairs into the range of an upstairs router would not connect to the stronger upstairs signal unless the original weaker connection is lost... you would need to break the original connection and reconnect upstairs.
So for phones etc, having different SSIDs offers choice of specific connection depending on preferred destination.

A wifi router lets local devices connect to its own LAN (Local Area Network) subnet, and routes all local messages between LAN nodes - connection to the LAN might be by wired RJ45 ethernet port and/or wifi.

The routers IP address is used as the default gateway for that subnet because it is the controlling primary router for the subnet, to which all local traffic is sent.

Additional LAN Ports
If your router does not have enough LAN ports, you don't need to buy an ethernet HUB or Switch if you have another router available... simply connect one (or more) 'slave' routers in parallel from LAN to LAN with their wifi disabled so that they just offer additional subnet LAN ports.

A routers WAN connection is like a remote waste disposal chute where it can dump all un-recognised traffic.

The WAN connection is basically a client address on a remote routers subnet (often an ISP internet connection), and if the WAN connection is being used it also needs to include the remote routers address to use as the remote WAN Default Gateway.

If the WAN is an internet connection, the ISP will also provide Primary and Secondary DNS Server addresses.
Each routers job is to route local subnet traffic to other devices on the local subnet (LAN) while keeping it separated from the external WAN, while at the same time also acting as a bridge to route offsite traffic between LAN and WAN whenever necessary.

Most modern routers will have a different coloured RJ45 ethernet WAN port which is similar to the RJ45 ethernet LAN ports. 
Some older routers may look like they have a different coloured RJ45 ethernet WAN port, but closer inspection may show it to be a slightly smaller RJ11 ADSL telephone port (with fewer electrical contacts) - if an ethernet cable fits, then it's probably a WAN port.

The WAN port is only relevant if you intend daisy-chaining routers in series to create nested multiple subnets  (which will be explained shortly), but suffice to say for now that if an ethernet cable can be plugged in, then it probably will be a WAN port.

Multiple Subnets
Let's take the existing internet wifi router as the starting point to add another 'child' router with internet access.
Take note of the original routers LAN IP address, because it will be used for the new child routers WAN Default Gateway address.
But there is no need to change any of the original routers configuration, so it is best left alone to avoid any unnecessary problems.

You will of course need to configure the new child router with an appropriate IP address which is different to the parent router address.

Note: I prefer to use an addressing system which makes things easier for myself...
  • For node addresses I assign .1 to the primary controlling router of each subnet, and reserve the other single digit numbers for any secondary routers... cos even if the details get forgotten, it makes them easy to figure out again - so 1 to 9 is reserved for routers.

  • Addresses 10 to 19 are reserved for important Annex static IP devices, such as my Sentry Alarm, Voice Announcer, Log Server etc. 

  • I use from 20 up to the start of the DHCP pool for well-separated 'temporary' static addresses during development, making it easy to avoid duplicate conflicts even when forgetting some of the devices that may still be on and connected.

  • I tend not to use DHCP addresses much, simply because they can change, which has tricked me into editing the wrong device.

  • Above the pool can be used for any other networked devices such as wifi printers and NAS drives etc - it keeps them away from the Annex stuff, and there won't be many, so they can be assigned memorable addresses such as 210, 220, 230, 240.

  • My system for subnet addressing is to use for the original internet parent router, and adjacent numbers for child subnets. So my Annex subnet router is  and my private subnet router is,  a guest subnet router could be
This system is only mypersonal preference cos it makes sense to me - so let's demonstrate it with the following address choices:
In the example shown below, the original parent internet router has LAN address (subnet 1, node 1), so we have given our new child router the adjacent subnet 2 address.
And because the child router is still the primary controlling router of its subnet 2 we have given it node address 1 as befits its primary status on its own subnet.
So the resulting child router LAN address is

To configure the new child router with the chosen IP address you will initially need to connect to its current IP address to access the LAN or Network fields where you can enter the new router IP address, then Save, Reboot the router, and reconnect to the new IP.
Enable the DHCP Server and take note of its pool start and end (or size), or change the settings to something else if you prefer.
Enable the wifi and assign a suitable SSID and password.
Eventually you may wish to change wifi channels, but that can be done later.
Save any configuration changes, else they will be ignored and lost - and changes usually require a router reboot.

At this point, having now configured the LAN side of the child router, you could connect an Annex node to test the LAN.
After booting the device in Recovery Mode, assign it a static address on the child subnet, eg:
Use the routers address of for the Default Gateway field, and of course for the subnet mask.
Then after rebooting the device, try connecting to it in the browser.

If all is will with the child LAN, you can move confidently on to the WAN configuration.
Connect the WAN port of the child router to any unused LAN port of the parent router.
This will make the new child routers WAN connection become a client on the parent router subnet, so it will need to be assigned a valid vacant IP address from the existing primary subnet.

The parent router is,  and I have plans for,  so we'll use  for the child WAN address.
The WAN Default Gateway address must be configured to the subnets primary controlling router, which is
The subnet mask will be as usual.

Because this is a WAN connection with potential for internet access we must provide primary and secondary DNS Server addresses so that domain names can be resolved to IP addresses.
The parent router will already be supplied with the ISP's DNS server addresses, so we just need to point the child DNS to the parent.
But I prefer using the independent Cloudflare DNS server rather than the ISP's DNS servers, so I use the Cloudflare address for the primary, and the parent IP (ISP) as secondary.
The diagram will hopefully make sense of what we've done (click it for a bigger image)...
After completing the WAN configuration changes, the new child internet connection can be tested by browsing to any web site from any logged on device.

Controlled Isolation
If I left home leaving doors and gates wide open then there would be nobody to blame for the consequences of my lazy stupidity other than myself.
The same applies to 'cloud' services which offer free lazy convenience... but it cannot be considered as 'out of sight, out of mind', because the 'cloud' is not white fluffy innocence, it is the lawless global internet - which is the hunting grounds of merciless ravenous hordes who ruin peoples lives daily for countless different reasons.
So it's reassuring to have the confidence of certainty that you have no internet connection... because if you cannot reach the internet, then you know the internet cannot reach you.
After testing that the internet access works, you can unplug the WAN cable from between the child and parent routers and then prove to yourself that you no longer have an internet connection.

I strive for isolated Annex system autonomy, but whenever internet access is unavoidable for any reason, then it is reassuring to be able keep internet connection to a controlled minimum.
Obviously it's not practical to be unplugging a cable... but its a perfect job for Annex and something like a Sonoff S20. 
I use an old ethernet hub/switch connected between the child WAN and parent LAN ports, with it's mains plugged into a Sonoff S20 which can be remotely turned On or Off whenever needed.
The Internet device also has an EasyNet interactive connection allowing it to be monitored and controlled by my Sentry Alarm, which turns it Off automatically if it has been left On for too long.

If the 'isolating' Sonoff device is logged on to the child subnet then it can only be controlled internally from that subnet.
But if the device is logged on to the parent subnet then it can potentially be controlled 'by those in the know' from anywhere in the world (eg: by using txt msg or email to initiate an outgoing call).

The internet connection could also be controlled automatically - so if an event trigger needs to send an Alert email for instance, it could switch on internet access, send the email, then switch off internet access again after.
If an email alert is received  (when out shopping for instance), internet access could be enabled remotely for whatever reasons, then disabled again afterwards.
This might be handy for eg: connecting to a CCTV DVR server, which could be accessed remotely for viewing if needed, but not normally be available online.

You could use a spare router simply as an ethernet hub/switch if you disable the wifi... or you can buy a new 2.4GHz router for about 12 quid or a 5-port ethernet hub for about 6 quid - whatever you use, simply plug a cable from the Parent into one LAN port, and a cable from the Child into another LAN port, and they will only be connected to each other when that unit is powered On.

Adding More
Now that you know what to do, it's just as easy to add a second (or more) child subnet alongside the first.
You might want a 'guest' router subnet with internet access but which can't access anything on your 'private' subnet.
Or you might want to add an 'Annex' subnet that would remain completely separate from your 'private' subnet.

My network (shown) still has the untouched original internet router which is still on its default configuration settings.
Our 'private' subnet is extended to two different properties, and includes a NAS HDD on its primary routers USB port.
The 'Annex' subnet is extended to the three different properties, plus a sensor zone, covering in total a couple of hundred meters, all on the same SSID so that any Annex devices can contact any others and be physically moved around when needed but without needing to be reconfigured for different locations.
The Annex subnet is normally kept isolated from the internet, but can be connected to the internet whenever necessary.

Your needs will probably be different to mine, but whatever they are, it shouldn't be too difficult to 'mix n match' things to suit your own purposes.