Differences

This shows you the differences between two versions of the page.

--- network:internet_multiwan [2024/12/05 17:09] – [Gentle reminders] system
+++ network:internet_multiwan [2024/12/06 03:40] (current) – [Anatomy of a multi-WAN profile] system
@@ Line 28: / Line 28: @@
 ===== Anatomy of a multi-WAN profile =====
   *  A functional multi-WAN profile consists of the following:
-    * A name, which can be thought of as a find of folder, under which the interfaces are grouped. There is also a site-wide option that makes the multi-WAN profile available for all clouds in RADIUSdesk.
+    * A name, which can be thought of as a kind of folder, under which the interfaces are grouped. There is also a site-wide option that makes the multi-WAN profile available for all clouds in RADIUSdesk.
     * One or more interfaces that are used for WAN access.
@@ Line 50: / Line 50: @@
 ===== When to switch sides =====
-  * Each interface that you define has a dedicated section which allows you to fine tune the conditions when the specific interface will be considered unavailable / offline.
+  * For each interface you define, there is a separate area where you can specify the conditions under which the respective interface is considered unavailable / offline.
-  * Here are a few things to consider when tweaking some of the values.
+  *  Here are some things to keep in mind when customising some values.
-    * Active monitoring where hosts are pinged is not compulsory.
+    *  Active monitoring, where the hosts are pinged, is not mandatory
-    * If it is not enabled, the multi-WAN configuration will still monitor if the interface itself is up or down and act accordingly.
+    *  If it is not enabled, the multi-WAN configuration will still monitor whether the interface itself is available or unavailable and act accordingly.
-    * Some of the more popular hosts that people use for ping tests might limit the replies or might not even reply at all.
+    * Some of the more popular hosts used for ping testing may limit the number of responses or not respond at all.
-    * This can result in a false trigger and can also make the device not being reachable on the specific interface (e.g. to access the device through ssh or Luci).
+    * This can lead to a false trigger and also to the device being unreachable on the specific interface (e.g. for accessing the device via ssh or Luci).
 <panel type="primary">
@@ Line 62: / Line 62: @@
 ------
-====== Using a Multi-WAN Profile ======
+====== Application of a multi-WAN profile ======
 ===== Applying a multi-WAN profile =====
-  * When you attach a device to a mesh or access point profile there is the option to select the type of Internet connection.
+  * When you connect a device to a Mesh or Access Point profile, you have the option of selecting the type of Internet connection.
-  * If you select the Multi-WAN option, another select control will show where you can select which multi-wan profile to apply.
+  * If you select the Multi-WAN option, a further selection field is displayed in which you can select which Multi-WAN profile you want to apply.
-  * Remember that the multi-wan profile and hardware has to be compatible. For instance you cant use a multi-WAN profile that has a LTE interface defined on hardware that does not have LTE capability.
+  * Remember that the Multi-WAN profile and the hardware must be compatible. For example, you cannot use a Multi-WAN profile with an LTE interface on hardware that is not LTE-capable.
 <panel type="primary">
@@ Line 74: / Line 75: @@
 ===== Multi-WAN reporting =====
-  * Multi-WAN Internet connections are visually distinctive on the overviews of mesh nodes and APs.
+  * Multi-WAN Internet connections are visually recognisable in the overviews of the mesh nodes and APs.
  <panel type="primary">
 {{:network:multiwan:ap_multi_wan_internet.png?nolink|}}
 </panel>
-  * In the following screenshot we have an Access Point with a multi-WAN profile in failover mode.
+  * In the following screenshot we have an access point with a multi-WAN profile in failover mode.
     * The WAN interface is active.
-    * Traffic allocation is 100%
+    * The traffic allocation is 100%
     * Two LTE interfaces are in the standby role.
-    * They are actively monitored and thus marked in blue as on standby.
+    * They are actively monitored and are therefore marked in blue as being in standby mode.
-    * The WiFi interface are not actively monitored but the interface itself is up.
+    * The WiFi interface is not actively monitored but the interface itself is up.
  <panel type="primary">
 {{:network:multiwan:active_standby.png?nolink|}}
 </panel>
-  * Next we introduce a scenario which triggers a failover.
+  * Next, we introduce a scenario that triggers a failover.
 <code bash>
-#We block ping packets on the host to which the access point is configured to send.
+#We block ping packets from being sent on the host to which the access point is configured.
 #This will trigger  a failover
 sudo iptables -A INPUT -s 197.64.14.100 -p icmp --icmp-type echo-request -j DROP
 #We remove the block
-#This result in a fall back.
+#This leads to a fallback.
 sudo iptables -D INPUT -s 197.64.14.100 -p icmp --icmp-type echo-request -j DROP
@@ Line 101: / Line 102: @@
 {{:network:multiwan:standby.png?nolink|}}
 </panel>
-  * Ping block removed and active role link is restored.
+  * Ping block is removed and the active role connection is restored.
  <panel type="primary">
 {{:network:multiwan:recover.png?nolink|}}
 </panel>