Ethernet Failover Help

[delid4ve]

Due to me not being on premises all the time and no other staff having any I.T/Networking Knowledge (mine is only self taught and there is a lot i do not know) i'm having to implement some fail over.

This may seem a dumb question but i dont know the best way to achieve.
My network layout is as follows:


Local Clients --> Patch Panel --> Managed 24 Port Switch --> Mikrotik RB1100AHX2 --> FTTP Gateway (ISP supplied)

The mikrotik router also feeds off to other premises as we are providing internet due to the slow ADSL speed of 2mb/s. (routed public IP's)
There is also a wireless AP.
I've bought an RB1100AHX4 and have been reading up on VRRP for fail over should the existing router fail.

My question is..
How am i going to split the patch panel off to two routers?
I know i can use the switch to assign VLANS before the routers but then what if the switch fails?
I can obviously have a spare switch present and configured ready should it happen, but no one would even know how to troubleshoot the switch or even know if it had failed, so there goes my failover.

Enlighten me please, as short of patching one cable into multiple patch ports im scratching my head..
I cant see that its possible other than buying splitters but then losing gigabit speed.

Apologies if I'm being dumb here

 

[sfx2000]

I would consider VLAN as close to the dmarc as possible - more options there if you have multiple public addresses there.

Otherwise - you can do the VLAN's on the the Microtik or the managed switch (depends though if it is layer 2, layer 3 lite, or full layer 3).

 

[degrub]

can the local folks follow "plug cable 1 into port 1" with a diagram illustrating ?
If so, just preconfigure a spare router and switch if you are concerned about hardware failure.

 

[MichaelCG]

You need to define what your risk tolerance is for failure and what failure scenarios you are trying to build for.
- Router
- Switch
- ISP
- What is an acceptable recovery time?
- Who is expected/required to be available to recover?

VRRP is one method for redundancy for sure, but you will generally need a switch on both sides of the FW sandwich to work properly. You also will now have to also make sure you are keeping your two routers/FWs configurations somewhat in sync.

Once you better define what scenarios and overall tolerances are, we may be able to better narrow down guidance.

 

[coxhaus]

You definitely need to define how far and what you need redundancy for. It can be a black hole you sink into. As stated above you need to define what you are trying to accomplish. The extra equipment, cabling, internet connections and electrical circuits can get expensive fast.

 

[delid4ve]

It’s only the router failure that I’m concerned about. The routers are directly below each other so I would like to think they could swap the cabling out and this seems like the simple option.
They can live without WiFi
They can live without a client pc going down
I’ve already put together a flow of what to look for regarding the isp’s fibre gateway.
I also have a spare switch so I can also stack that and again get them to swap out cabling.
Would have like it to be automated but hey ho. Thanks

 

[MichaelCG]

Automated....I don't know enough about Mikrotik to know if they have an automated method to sync configs or if they offer state sync between FWs.

Automated Fail-over
- switch sandwich required to use VRRP
- FW-A fails, FW-B should take over
- minor hiccup in traffic for a few seconds as sessions reset and VRRP moves traffic to FW-B
- need to find a way to keep FW configs in sync

Manual Fail-over
- manual cable swap required
- FW-A fails, local user will have to manually move cables
- disruptive to users, but lower recovery times
- proper documentation lowers requirement for IT skill set on-site
- need to find a way to keep FW configs in sync or at least how to quickly backup/restore the configs

 

[sfx2000]

Interesting post over on servethehome.com recently....

https://www.servethehome.com/intel-atom-c2000-avr54-bug-strikes-sth/

read thru it - as a result of a power outage at their data center, they lost the front-end router for their site... and a few other items at the same time...