Community discussions

MikroTik App
 
Frostbyte
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 85
Joined: Mon Dec 25, 2017 1:42 am

RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Wed Jan 02, 2019 4:53 pm

Greetings and happy new year!

My old scripts and schedulers used to have a lot of hard coded values, were limited to only two gateways, did not utilize functions and were fairly inconsistent.
After nearly two years of putting it off and the acquisition of my new toys, I finally found the time to sit and rewrite the entirety of the scripts that I use on a daily basis.

You can check them out here:
https://github.com/FrostbyteGR/RouterSCRIPTS

Tip: If you plan on using them yourself: make sure you peruse the README section, as it will save you a lot of time and pain, in the long run.
Last edited by Frostbyte on Wed Jan 02, 2019 9:34 pm, edited 1 time in total.
 
Frostbyte
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 85
Joined: Mon Dec 25, 2017 1:42 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Wed Jan 02, 2019 4:54 pm

Frequently Asked Questions:
< To be filled when there are questions >
Last edited by Frostbyte on Mon Aug 17, 2020 7:23 pm, edited 5 times in total.
 
paulavalencia
just joined
Posts: 1
Joined: Tue Jun 25, 2019 5:49 pm

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Tue Jun 25, 2019 6:38 pm

Hey, frostbyte

Don't know if I should be posting here since there are no other replies, but it says to do so in the Github, so here I am.

I keep getting errors saying my variables are empty or contain invalid values in every module. I even tested it with the same values you put in the example, only changing the IP address on WANGateways, but can't make it work. I mainly wanna test your failover script in place of another I have, but also liked the DNS one and would like to set it up as well.

Please, if you can help me on this issue. I'm running the 6.44.3 version, if that's relevant. Thank you in advance.
 
tedd77
newbie
Posts: 39
Joined: Sun Dec 18, 2011 5:05 pm

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Wed Oct 02, 2019 3:01 am

I am facing the same challenge of @paulavalencia
Could anyone assist ?
 
Frostbyte
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 85
Joined: Mon Dec 25, 2017 1:42 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Wed Oct 02, 2019 6:00 pm

Hello,

Apologies for the late reply, due to my fairly busy daily schedule this one managed to slip under my radar.

This behavior occurs when the configuration file is saved with the UNIX (\n) instead of Windows (\r\n) EOL scheme.
I have rolled out an update (to the parser function) where it properly detects and adjusts the EOL sequence, which fixes the issue.

Thank you for reporting this to me and for your patience.
 
Tecleo
just joined
Posts: 1
Joined: Thu Oct 31, 2019 11:55 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Thu Oct 31, 2019 12:05 pm

Hi, please assist.
Irrespective of the values used I am getting the message:
"Provision][Error]: Gateways configuration for XXXXXXXXX does not have a corresponding default route.
[Provision][Error]: Gateways configuration for XXXXXXXX does not have a corresponding default route.
[Provision][Error]: The gateways configuration is invalid, please check the config file and try again.

****** Script output ********
[admin@MikroTik] > /import RouterSCRIPTS_Installer.rsc
[RouterSCRIPTS][Info]: Install finished. Assuming you have read through the supplied readme file, you may now remove any modules that you have no use for, then run:
$provision auto

Script file loaded and executed successfully
[admin@MikroTik] > $provision auto
[Provision][Info]: Provisioning all available modules.
[Provision][Info]: Provisioning gateways.
[Provision][Error]: Gateways configuration for Vodafone does not have a corresponding default route.
[Provision][Error]: Gateways configuration for Verizon does not have a corresponding default route.
[Provision][Error]: The gateways configuration is invalid, please check the config file and try again.
[Provision][Info]: Provisioning failover.
[Provision][Error]: The failover module depends on the gateway selector module, please provision it and try again.
[Provision][Info]: Provisioning dyndns.
[Provision][Info]: Provisioning resolver.
[Provision][Info]: Provisioning livestream.
[Provision][Error]: Completed with errors.
[admin@MikroTik] >
*******
 
Frostbyte
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 85
Joined: Mon Dec 25, 2017 1:42 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Fri Nov 15, 2019 3:32 pm

The provisioning script is complaining because you haven't designated corresponding routes to the connections you have defined in your cfg file.

From the readme file:
WANGatewayPrefix: The comment prefix to use for identifying default gateway routes in the routing table

The value which follows this configuration variable, must be present as a comment (I personally prefer to prefix it but it doesn't matter), on the 0.0.0.0 routes of each gateway defined in the cfg file.
The corresponding routes are being matched/designated via their comment and gateway fields. Without the comment being in place, the script cannot guess which ones to utilize for it's functions.


An example (using values from the readme) cfg file of:
WANGateways=192.168.1.1,192.168.2.1
WANGatewayPrefix=Default route
Would require you to have two routes like these:
/ip route add comment="Default route blah blah" distance=1 gateway=192.168.1.1
/ip route add comment="Default route blah blah" distance=2 gateway=192.168.2.1
Regarding the distance: The allowed range is from 1 to 2. Because you have declared two gateways in the cfg file.
If you had declared three gateways in the cfg file, then it would've been from 1 to 3 and so on..
 
Nic8756
just joined
Posts: 3
Joined: Wed Apr 22, 2020 7:22 pm

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Wed Apr 22, 2020 7:50 pm

Greetings and happy new year!

My old scripts and schedulers used to have a lot of hard coded values, were limited to only two gateways, did not utilize functions and were fairly inconsistent.
After nearly two years of putting it off and the acquisition of my new toys, I finally found the time to sit and rewrite the entirety of the scripts that I use on a daily basis.

You can check them out here:
https://github.com/FrostbyteGR/RouterSCRIPTS

Tip: If you plan on using them yourself: make sure you peruse the README section, as it will save you a lot of time and pain, in the long run.
Hi Frostbyte,
thank you for the script! is very interesting. I'm doing some experiments but I have a problem, I cannot make it work. How can the Failover script check the WAN reachability of the WAN target through the various secondary gateways if the current default route of the Mikrotik router is on the active gateway? I mean, if I try to ping the WAN target (e.g. 8.8.8.8) from the 2nd gateway interface the response is ICMP timeout even if the 2nd gateway has full Internet connectivity. The ICMP request does not go out on the 2nd gatewa interface, so the entire script assumes that the 2nd gw has not WAN connectivity. I have to do something with NAT? Actually I'm only masquerating with src nat to the two gateway interfaces

I have a routerboard with two ISP Internet connections.

Could you help me? thanks a lot,
Best Regards
 
Frostbyte
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 85
Joined: Mon Dec 25, 2017 1:42 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Sat Apr 25, 2020 8:18 pm

How can the Failover script check the WAN reachability of the WAN target through the various secondary gateways if the current default route of the Mikrotik router is on the active gateway?

ping <WAN Target> count=<# of Attempts> interface=<WAN Interface>
The bold part in red is what forces the ping to actually go out from the proper WAN Interface, regardless of what the currently active gateway is.

I mean, if I try to ping the WAN target (e.g. 8.8.8.8) from the 2nd gateway interface the response is ICMP timeout even if the 2nd gateway has full Internet connectivity. The ICMP request does not go out on the 2nd gatewa interface, so the entire script assumes that the 2nd gw has not WAN connectivity. I have to do something with NAT? Actually I'm only masquerating with src nat to the two gateway interfaces

I have a routerboard with two ISP Internet connections.

In order to better understand where the problem lies, some additional information is required:
  • The contents of the *.cfg file you're trying to provision the device with.
  • The output of the following commands (in terminal) from the device:
    1. /ip address print detail
    2. /ip route print detail
    3. $provision auto
    4. $failover check
 
Nic8756
just joined
Posts: 3
Joined: Wed Apr 22, 2020 7:22 pm

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Wed Apr 29, 2020 5:29 pm

How can the Failover script check the WAN reachability of the WAN target through the various secondary gateways if the current default route of the Mikrotik router is on the active gateway?

ping <WAN Target> count=<# of Attempts> interface=<WAN Interface>
The bold part in red is what forces the ping to actually go out from the proper WAN Interface, regardless of what the currently active gateway is.

I mean, if I try to ping the WAN target (e.g. 8.8.8.8) from the 2nd gateway interface the response is ICMP timeout even if the 2nd gateway has full Internet connectivity. The ICMP request does not go out on the 2nd gatewa interface, so the entire script assumes that the 2nd gw has not WAN connectivity. I have to do something with NAT? Actually I'm only masquerating with src nat to the two gateway interfaces

I have a routerboard with two ISP Internet connections.

In order to better understand where the problem lies, some additional information is required:
  • The contents of the *.cfg file you're trying to provision the device with.
  • The output of the following commands (in terminal) from the device:
    1. /ip address print detail
    2. /ip route print detail
    3. $provision auto
    4. $failover check
Dear Frostbyte, thank you for the reply. I'm not completely sure about function of the "interface=" option of the ping command. According to me this command option is used to recursively learn the IP address associated to the specified interface and than create a ping packet with source IP address the IP address of that interface. However this not means that the ping will exit from that interface, because if the destination address of the ping is not in a local network the router still looks at the actual default gateway to decide to which dest address send the packet and accordingly on which interface. But I'm not an expert about Mikrotik world, so I can mistake.

All of this to say that in my small lab your script seems not able to ping the target host from the 2nd path to verify the connectivity, so it can't switch to the 2nd ISP when the first fails. Could you please help me?

Thanks a lot!

I attach the output of your commands, also the ping command.

[admin@MikroTik] > /ip address print detail
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; defconf
address=192.168.80.1/24 network=192.168.80.0 interface=bridge actual-interface=bridge

1 address=192.168.10.71/24 network=192.168.10.0 interface=ether1 actual-interface=ether1

2 address=192.168.88.2/24 network=192.168.88.0 interface=ether5 actual-interface=ether5


[admin@MikroTik] > /ip route print detail
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
0 A S ;;; Default route
dst-address=0.0.0.0/0 gateway=192.168.10.1 gateway-status=192.168.10.1 reachable via ether1 distance=1 scope=30 target-scope=10

1 S ;;; Default route
dst-address=0.0.0.0/0 gateway=192.168.88.1 gateway-status=192.168.88.1 reachable via ether5 check-gateway=ping distance=4 scope=30 target-scope=10

2 ADC dst-address=192.168.10.0/24 pref-src=192.168.10.71 gateway=ether1 gateway-status=ether1 reachable distance=0 scope=10

3 ADC dst-address=192.168.80.0/24 pref-src=192.168.80.1 gateway=bridge gateway-status=bridge reachable distance=0 scope=10

4 ADC dst-address=192.168.88.0/24 pref-src=192.168.88.2 gateway=ether5 gateway-status=ether5 reachable distance=0 scope=10


[admin@MikroTik] > $provision auto
[Provision][Info]: Provisioning all available modules.
[Provision][Info]: Provisioning gateways.
[Provision][Info]: Provisioning failover.


[admin@MikroTik] > $failover check
SEQ HOST SIZE TTL TIME STATUS
0 8.8.8.8 56 57 12ms
sent=1 received=1 packet-loss=0% min-rtt=12ms avg-rtt=12ms max-rtt=12ms

SEQ HOST SIZE TTL TIME STATUS
0 8.8.8.8 timeout
sent=1 received=0 packet-loss=100%


[admin@MikroTik] > ping 8.8.8.8 interface=ether5
SEQ HOST SIZE TTL TIME STATUS
0 8.8.8.8 timeout
2 8.8.8.8 timeout
3 8.8.8.8 timeout
4 8.8.8.8 timeout
5 8.8.8.8 timeout
 
Frostbyte
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 85
Joined: Mon Dec 25, 2017 1:42 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Wed Apr 29, 2020 8:34 pm

Dear Frostbyte, thank you for the reply. I'm not completely sure about function of the "interface=" option of the ping command. According to me this command option is used to recursively learn the IP address associated to the specified interface and than create a ping packet with source IP address the IP address of that interface. However this not means that the ping will exit from that interface, because if the destination address of the ping is not in a local network the router still looks at the actual default gateway to decide to which dest address send the packet and accordingly on which interface. But I'm not an expert about Mikrotik world, so I can mistake.

According to the documentation, the "interface" parameter applies a "Which interface to use" restriction to the command, so the ping is forced to exit from that interface. Since there is a route (0.0.0.0/0) to your target address (8.8.8.8 ) where it's gateway (192.168.88.1) belongs in the same subnet (192.168.88.0/24) that your interface (ether5) participates in, the ping should go through, otherwise it should fail. Once we get your setup working, you will be able to verify this yourself as well (by actually bringing down connections).

All of this to say that in my small lab your script seems not able to ping the target host from the 2nd path to verify the connectivity, so it can't switch to the 2nd ISP when the first fails. Could you please help me?

Thanks a lot!

I attach the output of your commands, also the ping command.

[admin@MikroTik] > /ip address print detail
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; defconf
address=192.168.80.1/24 network=192.168.80.0 interface=bridge actual-interface=bridge

1 address=192.168.10.71/24 network=192.168.10.0 interface=ether1 actual-interface=ether1

2 address=192.168.88.2/24 network=192.168.88.0 interface=ether5 actual-interface=ether5


[admin@MikroTik] > /ip route print detail
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
0 A S ;;; Default route
dst-address=0.0.0.0/0 gateway=192.168.10.1 gateway-status=192.168.10.1 reachable via ether1 distance=1 scope=30 target-scope=10

1 S ;;; Default route
dst-address=0.0.0.0/0 gateway=192.168.88.1 gateway-status=192.168.88.1 reachable via ether5 check-gateway=ping distance=4 scope=30 target-scope=10

2 ADC dst-address=192.168.10.0/24 pref-src=192.168.10.71 gateway=ether1 gateway-status=ether1 reachable distance=0 scope=10

3 ADC dst-address=192.168.80.0/24 pref-src=192.168.80.1 gateway=bridge gateway-status=bridge reachable distance=0 scope=10

4 ADC dst-address=192.168.88.0/24 pref-src=192.168.88.2 gateway=ether5 gateway-status=ether5 reachable distance=0 scope=10


[admin@MikroTik] > $provision auto
[Provision][Info]: Provisioning all available modules.
[Provision][Info]: Provisioning gateways.
[Provision][Info]: Provisioning failover.


[admin@MikroTik] > $failover check
SEQ HOST SIZE TTL TIME STATUS
0 8.8.8.8 56 57 12ms
sent=1 received=1 packet-loss=0% min-rtt=12ms avg-rtt=12ms max-rtt=12ms

SEQ HOST SIZE TTL TIME STATUS
0 8.8.8.8 timeout
sent=1 received=0 packet-loss=100%


[admin@MikroTik] > ping 8.8.8.8 interface=ether5
SEQ HOST SIZE TTL TIME STATUS
0 8.8.8.8 timeout
2 8.8.8.8 timeout
3 8.8.8.8 timeout
4 8.8.8.8 timeout
5 8.8.8.8 timeout

This is a bit weird. On the surface there doesn't seem to be anything wrong with what the scripts are expecting to find. (That means that, concerning the scripts at least, the configuration should be valid).

However, I find two things which are alarming:
1) The provision command did not end with a success/failure message. (If you didn't crop it on purpose, something may have went wrong, which we will need to investigate)
2) Assuming your interface, address, route and firewall (since you mentioned you're NATing) configurations are proper; you should be able to ping with that last command. Something is definitely going on with the configuration of the device in general.

As a small experiment, could you try disabling the route #0 (dst-address=0.0.0.0/0 gateway=192.168.10.1) and try a ping to 8.8.8.8 without the interface parameter? Does it succeed?
 
Nic8756
just joined
Posts: 3
Joined: Wed Apr 22, 2020 7:22 pm

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Sat May 02, 2020 11:16 pm

Dear Frostbyte, thank you for the reply. I'm not completely sure about function of the "interface=" option of the ping command. According to me this command option is used to recursively learn the IP address associated to the specified interface and than create a ping packet with source IP address the IP address of that interface. However this not means that the ping will exit from that interface, because if the destination address of the ping is not in a local network the router still looks at the actual default gateway to decide to which dest address send the packet and accordingly on which interface. But I'm not an expert about Mikrotik world, so I can mistake.

According to the documentation, the "interface" parameter applies a "Which interface to use" restriction to the command, so the ping is forced to exit from that interface. Since there is a route (0.0.0.0/0) to your target address (8.8.8.8 ) where it's gateway (192.168.88.1) belongs in the same subnet (192.168.88.0/24) that your interface (ether5) participates in, the ping should go through, otherwise it should fail. Once we get your setup working, you will be able to verify this yourself as well (by actually bringing down connections).

All of this to say that in my small lab your script seems not able to ping the target host from the 2nd path to verify the connectivity, so it can't switch to the 2nd ISP when the first fails. Could you please help me?

Thanks a lot!

I attach the output of your commands, also the ping command.

[admin@MikroTik] > /ip address print detail
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; defconf
address=192.168.80.1/24 network=192.168.80.0 interface=bridge actual-interface=bridge

1 address=192.168.10.71/24 network=192.168.10.0 interface=ether1 actual-interface=ether1

2 address=192.168.88.2/24 network=192.168.88.0 interface=ether5 actual-interface=ether5


[admin@MikroTik] > /ip route print detail
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
0 A S ;;; Default route
dst-address=0.0.0.0/0 gateway=192.168.10.1 gateway-status=192.168.10.1 reachable via ether1 distance=1 scope=30 target-scope=10

1 S ;;; Default route
dst-address=0.0.0.0/0 gateway=192.168.88.1 gateway-status=192.168.88.1 reachable via ether5 check-gateway=ping distance=4 scope=30 target-scope=10

2 ADC dst-address=192.168.10.0/24 pref-src=192.168.10.71 gateway=ether1 gateway-status=ether1 reachable distance=0 scope=10

3 ADC dst-address=192.168.80.0/24 pref-src=192.168.80.1 gateway=bridge gateway-status=bridge reachable distance=0 scope=10

4 ADC dst-address=192.168.88.0/24 pref-src=192.168.88.2 gateway=ether5 gateway-status=ether5 reachable distance=0 scope=10


[admin@MikroTik] > $provision auto
[Provision][Info]: Provisioning all available modules.
[Provision][Info]: Provisioning gateways.
[Provision][Info]: Provisioning failover.


[admin@MikroTik] > $failover check
SEQ HOST SIZE TTL TIME STATUS
0 8.8.8.8 56 57 12ms
sent=1 received=1 packet-loss=0% min-rtt=12ms avg-rtt=12ms max-rtt=12ms

SEQ HOST SIZE TTL TIME STATUS
0 8.8.8.8 timeout
sent=1 received=0 packet-loss=100%


[admin@MikroTik] > ping 8.8.8.8 interface=ether5
SEQ HOST SIZE TTL TIME STATUS
0 8.8.8.8 timeout
2 8.8.8.8 timeout
3 8.8.8.8 timeout
4 8.8.8.8 timeout
5 8.8.8.8 timeout

This is a bit weird. On the surface there doesn't seem to be anything wrong with what the scripts are expecting to find. (That means that, concerning the scripts at least, the configuration should be valid).

However, I find two things which are alarming:
1) The provision command did not end with a success/failure message. (If you didn't crop it on purpose, something may have went wrong, which we will need to investigate)
2) Assuming your interface, address, route and firewall (since you mentioned you're NATing) configurations are proper; you should be able to ping with that last command. Something is definitely going on with the configuration of the device in general.

As a small experiment, could you try disabling the route #0 (dst-address=0.0.0.0/0 gateway=192.168.10.1) and try a ping to 8.8.8.8 without the interface parameter? Does it succeed?
Hi Frostbyte, thank you again for your help and explanations. As soon as possible I'll do some tests and I let you know.
 
Frostbyte
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 85
Joined: Mon Dec 25, 2017 1:42 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Fri May 15, 2020 10:12 am

Hi Frostbyte, thank you again for your help and explanations. As soon as possible I'll do some tests and I let you know.

It's been nearly two weeks since your last reply, are you still in need of assistance?
 
luddite
just joined
Posts: 21
Joined: Fri Apr 06, 2012 12:09 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Wed Jun 03, 2020 11:59 am

Just want to say thanks for this amazing work, there is a lot in it, and a lot in your replies to people, good effort helping the community.

Hope to use and explore these scripts.
 
norenberg
newbie
Posts: 49
Joined: Mon Nov 23, 2009 2:26 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Mon Aug 17, 2020 1:03 pm

Thanks for putting this together!
I'm trying to make it work, however my problem is that I have just one physical interface where your script seems to rely on two interfaces to work, by using ping with source interface, am I right?

Is there a way I could make this work only with one interface?

Thanks!
 
Frostbyte
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 85
Joined: Mon Dec 25, 2017 1:42 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Mon Aug 17, 2020 7:17 pm

Thanks for putting this together!
I'm trying to make it work, however my problem is that I have just one physical interface where your script seems to rely on two interfaces to work, by using ping with source interface, am I right?

Is there a way I could make this work only with one interface?

Thanks!

Answer #1:

If you have only one internet gateway/connection, then no.
Unless you're planning to perform a "proof of concept" test, which can be achieved by utilizing/configuring multiple MikroTik devices/VMs.

Technically you need at least two different internet gateways/connections so you can have a proper failover. There is no point to it otherwise, I'm sure you can understand why.
Furthermore the provision algorithm explicitly disallows for duplicate values in WANNames and WANGateways, so you can't bypass it by inputting the same information twice in the configuration file.

Answer #2:

In case you have two or more different internet gateways/connections, but accessible through the same interface or on the same subnet, it will still be required of you to split them into different subnets and interfaces (bridges and vlans are allowed too). This limitation exists because there's no other clean way (without confusing the scripts, that is) to differentiate between the available gateways when checking for each one's internet availability.

As per the documentation available on github:
  • You can only have one gateway per subnet. Multiple gateways over the same bridge/master-interface are not supported

Disclaimer: If you're after the Balancing functionality of the gateway module, it is assumed (besides having two different internet gateways/connections) that you know your way around configuring PCC Load Balancing, to achieve a desirable result. Since all that option provides for, is an on/off toggle (sensitive to internet outages) for mangle rules with a matching comment prefix (as defined in the configuration file).
Last edited by Frostbyte on Mon Aug 17, 2020 8:07 pm, edited 1 time in total.
 
norenberg
newbie
Posts: 49
Joined: Mon Nov 23, 2009 2:26 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Tue Aug 18, 2020 2:37 am

Thanks for the reply.
Sorry I forgot to mention, yes I have 2 different gateways in two different subnets on the same interface.
I have tried to fiddle a litte with VLAN's but it's been a while, I couldn't make it work as I'm doing
GW1
--------------untagged,no vlan-------------RouterBoardETH1
GW2

On that scenario I have to get the RB to tag the ingress packets and untag back to a couple of bridges inside that same eth1... or something like that. I'm a bit rusty with VLANs and I'm thinking it might be overkill for my situation so I'm considering just implementing recursive without script instead, although I really like the toggle functionalities of your script.
 
Frostbyte
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 85
Joined: Mon Dec 25, 2017 1:42 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Tue Aug 18, 2020 3:46 am

Thanks for the reply.
Sorry I forgot to mention, yes I have 2 different gateways in two different subnets on the same interface.
I have tried to fiddle a litte with VLAN's but it's been a while, I couldn't make it work as I'm doing
GW1
--------------untagged,no vlan-------------RouterBoardETH1
GW2

On that scenario I have to get the RB to tag the ingress packets and untag back to a couple of bridges inside that same eth1... or something like that. I'm a bit rusty with VLANs and I'm thinking it might be overkill for my situation so I'm considering just implementing recursive without script instead, although I really like the toggle functionalities of your script.

In that situation and if utilizing the scripts is the desirable goal, there are two options to consider:
  1. Connect GW1 and GW2 onto two different physical ports of the RouterBoard device.
  2. Pass GW1 and GW2 as tagged VLANs through a single physical port of the RouterBoard device.
At this point I'm completely unaware of your exact physical setup and as to why you're not just connecting CPE1 to one physical port of the RouterBoard device and CPE2 to another.
That would appear to be the simplest method both physical-wise and configuration-wise (just remember: different subnets, different interfaces).

Now, in case there is some complication or particularity that I am missing (and I probably might be), let's assume the diagram you drew above.
I would not consider option 2 to be an overkill (since you would have one cable reach the RouterBoard device and one of it's physical ports occupied, instead of two). Though you will have to ensure that the combined bandwidth of GW1 and GW2 does not exceed the speed specification of the RouterBoard device port that you're plugging into (to avoid a potential bottleneck).
If you choose to bring in GW1 and GW2 as tagged VLANs over the same physical port of your RouterBoard device, things are really simple from there and onward:
You create two VLANs, each with it's respective VLAN ID (that you tagged it with on the other side) and with the physical port that you're passing them through as the Interface (RouterBoardETH1 in your case). Then you go into IP > Address and you assign a corresponding address and subnet mask to each one of the VLANs you created (remember, different subnets). Lastly, you go into IP > Route and you create your two routes (make sure to peruse the github documentation as the distances and comment contents on this step are important).
 
norenberg
newbie
Posts: 49
Joined: Mon Nov 23, 2009 2:26 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Wed Aug 19, 2020 3:19 pm

Thanks for your reply
At this point I'm completely unaware of your exact physical setup and as to why you're not just connecting CPE1 to one physical port of the RouterBoard device and CPE2 to another.
That would appear to be the simplest method both physical-wise and configuration-wise (just remember: different subnets, different interfaces).
These are two wan gateways that are physically on the other side of the city. The link where both are accessible via Layer3 arrives through P2P on a single cable to eth1. It doesn't make sense to re-split into two cables. This is a bit of a temporary scenario for until I have the ability to have 2 physical links coming to the RB.
You create two VLANs, each with it's respective VLAN ID (that you tagged it with on the other side) and with the physical port that you're passing them through as the Interface (RouterBoardETH1 in your case). Then you go into IP > Address and you assign a corresponding address and subnet mask to each one of the VLANs you created (remember, different subnets). Lastly, you go into IP > Route and you create your two routes (make sure to peruse the github documentation as the distances and comment contents on this step are important).
I don't have means to tag on the other side at the moment but will soon. Since it's a 3011UIAS it should be ok to cope with traffic. I will try that again, for the time being the recursive failover is working.
Thanks!
 
CraigZA
just joined
Posts: 4
Joined: Wed Aug 04, 2010 11:52 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Mon Sep 14, 2020 3:18 pm

I'm having the same issue as a previous poster.

Two WAN interfaces, the $failover check command times out when attempting to ping the external IP:
[admin@xxxxx] > $failover status
[Failover][Info]: Failover status: Active.
[Failover][Info]: ether1: Online        (up for at least 00:01:15)
[Failover][Info]: ether2: Offline       (down for at least 00:01:15)
[admin@xxxxx] > $failover status
[Failover][Info]: Failover status: Active.
[Failover][Info]: ether1: Online        (up for at least 00:01:15)
[Failover][Info]: ether2: Offline       (down for at least 00:01:15)
[admin@xxxxx] > $failover check 
  SEQ HOST                                     SIZE TTL TIME  STATUS             
    0 9.9.9.9                                    56  56 22ms 
    sent=1 received=1 packet-loss=0% min-rtt=22ms avg-rtt=22ms max-rtt=22ms 

  SEQ HOST                                     SIZE TTL TIME  STATUS             
    0 9.9.9.9                                                 timeout            
    sent=1 received=0 packet-loss=100%
I have two default routes, distance of 1 & 2 respectively. NAT both out to the internet. Provision completed fine with no errors (I removed DynDNS, ResolveFQDN & Livestream modules).

Any hints on how to resolve? Thanks!
 
Frostbyte
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 85
Joined: Mon Dec 25, 2017 1:42 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Tue Sep 15, 2020 3:01 pm

I'm having the same issue as a previous poster.

Two WAN interfaces, the $failover check command times out when attempting to ping the external IP:
[admin@xxxxx] > $failover status
[Failover][Info]: Failover status: Active.
[Failover][Info]: ether1: Online        (up for at least 00:01:15)
[Failover][Info]: ether2: Offline       (down for at least 00:01:15)
[admin@xxxxx] > $failover status
[Failover][Info]: Failover status: Active.
[Failover][Info]: ether1: Online        (up for at least 00:01:15)
[Failover][Info]: ether2: Offline       (down for at least 00:01:15)
[admin@xxxxx] > $failover check 
  SEQ HOST                                     SIZE TTL TIME  STATUS             
    0 9.9.9.9                                    56  56 22ms 
    sent=1 received=1 packet-loss=0% min-rtt=22ms avg-rtt=22ms max-rtt=22ms 

  SEQ HOST                                     SIZE TTL TIME  STATUS             
    0 9.9.9.9                                                 timeout            
    sent=1 received=0 packet-loss=100%
I have two default routes, distance of 1 & 2 respectively. NAT both out to the internet. Provision completed fine with no errors (I removed DynDNS, ResolveFQDN & Livestream modules).

Any hints on how to resolve? Thanks!

I had noticed an issue (somewhere between RouterOS 6.46.6 and 6.47.1 I can't remember exactly) where a gateway would refuse to ping the target, after a reboot.
This however is not an issue that can be remedied by or stemming from the scripts.
I haven't been able to reproduce it, so far, on RouterOS 6.47.3

Is your second gateway able to reach 9.9.9.9 without the scripts? If yes:
  1. Try disabling the failover module with "$failover toggle"
  2. Switch to the other gateway with "$gateway switch ether2"
  3. Attempt to "ping 9.9.9.9", does it still timeout?
  4. If it still times out, try enabling the failover module again with "$failover toggle", does it solve the issue?
Additionally, which version and firmware of RouterOS you're using?
 
MikeRoTik
just joined
Posts: 18
Joined: Wed Jul 08, 2020 4:47 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Wed Sep 23, 2020 6:09 am

Would it possible to modify these scripts for use when the WAN IP addresses and gateway addresses are assigned via DHCP?
 
MikeRoTik
just joined
Posts: 18
Joined: Wed Jul 08, 2020 4:47 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Fri Sep 25, 2020 6:39 am

I am trying to make some changes to the scripts. How are you building the RouterSCRIPTS_Installer.rsc file from the source files in the src directory?
 
Frostbyte
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 85
Joined: Mon Dec 25, 2017 1:42 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Fri Sep 25, 2020 7:22 pm

Would it possible to modify these scripts for use when the WAN IP addresses and gateway addresses are assigned via DHCP?

It's been quite a long time since I made them, but if memory serves me correct, you need to do modifications in the following order:
  1. The provision function in the mod-provision script
  2. The gateway function in the mod-gateway script
  3. The failover function in the mod-failover script

While the failover function/provisioning doesn't possess strict verification against the validity of the supplied gateway IP addresses (meaning that you could get away by supplying a gateway IP address within the subnet or range of addresses that the DHCP provides), the gateway function/provisioning does and the failover module is dependent on it for obvious reasons.

The scripts currently support only statically configured gateways (with fixed/static IP addresses and static routes), as it would be difficult to ensure smooth operation for a less deterministric or even completely non-deterministric dynamic counterpart. (would require extra, more complicated code and a lot more checks and validations; and scripts/schedulers have a character limit as well, mind you)
Furthermore, as per by the restrictions section of the README (just to keep it in mind as well):
You can only have one gateway per subnet. Multiple gateways over the same bridge/master-interface are not supported
However, since I'm providing this as a completely open source project, you're free to review the code and modify it to your liking/needs.
Just make sure that if you wish to redistribute it afterwards, to:
  1. Give credit to the original source
  2. Pick a name that will not cause confusion between it and the original material
  3. State any added/altered/removed functionality in it's respective README, so it can be discerned

----------------------------------------------------------------------------------------------------------------------------------------------------------------------

I am trying to make some changes to the scripts. How are you building the RouterSCRIPTS_Installer.rsc file from the source files in the src directory?

Again it's been a long time since I needed to make a significant modification to them, but from what I can remember, that's how I worked on them:
  1. I would create the code in a text editor of choice (Notepad++ for example)
  2. Then I would create the corresponding script/scheduler (with the needed permissions) on the device, copy the code over and test them
  3. When the code was good enough across all modules, I would copy the contents of each script/scheduler to the RouterSCRIPTS_Installer.rsc file

Specifically now for the RouterSCRIPTS_Installer.rsc file, it's only just a wrapper whose purpose is to import said scripts/schedulers/code in an easy fashion.
It's composed by:
  1. A notify function on the top (so it can give you feedback when it's finished executing)
  2. Commands that simply create each script with the necessary/corresponding permissions and code contents
  3. A command that bootstraps the whole thing by executing the provision script/module and another command that removes/cleans-up the installer file from the device

If you're wondering why this file looks way different than the ones residing in the "src" folder, the code following the "source=" parameter on each of the commands has been modified slightly (so it can be human-readable from the device via console/ssh/winbox/etc as well):
  1. With \r and \n sequences instead of newline characters, because they're otherwise ignored when contained within commands
  2. With \t sequences instead of <TAB> characters because, again, they're otherwise ignored when contained within commands
These are purely cosmetic and have no effect on the installation or operation of the scripts/schedulers/etc.

Lastly, have in mind that the scripts make heavy use of local and global functions. The only thing that the scripts do is to actually initialize such functions on the device's memory, and the schedulers simply gain access to them and periodically execute them. All of the code that actually does things, exists within those functions.

I hope that you find this information useful.


----------------------------------------------------------------------------------------------------------------------------------------------------------------------


@CraigZA: It's been about 10 days since your last reply, do you still require assistance?
 
MikeRoTik
just joined
Posts: 18
Joined: Wed Jul 08, 2020 4:47 am

Re: RouterSCRIPTS - A collection of scripts for RouterBOARD devices

Sat Sep 26, 2020 1:49 am

I hope that you find this information useful.
Extremely! Thanks for sharing! Quite a feat given that there is no IDE to correct syntax, debug, step, watch, breakpont, inspect, etc..... You did it old school!

One thing that I'm still trying to figure out is how the variables which are setup in memory from the config files stay persistent over a router reboot.

Who is online

Users browsing this forum: Bing [Bot], vibhupandey and 28 guests