First commit is 2 weeks old because until then the program was internally developed and used, as stated in the README. 2 weeks ago it was put on GitHub and released as GPL.
No, you needn't Ruby on your router if a working packet marking solution is all you need. Just run Fault Tolerant Router in demo mode on... Windows, if you wish! Grab the command output and use the same commands on your router, using Bash or whatever you like.
I would use OpenVPN. One VPN going from each uplink to your data center. Then use channel bonding on the OpenVPN interfaces on both sides: remote location and data center. Of course you would need a modified version of Fault Tolerant Router to detect if an uplink goes down, otherwise your "channel bonded" connection would go down too...
Yes, you could write it in Bash. I extensively used Bash to do shell scripting in the past, but it doesn't give me the same "programming pleasure" as Ruby does. Personal tastes.
It's not aimed at embedded systems, so dependencies are not a problem for me. Then, installing dependencies with bundler it's a joke. It's clear you're not a Ruby fan!;-) I agree it would have been better to write it in C, but I'm a little rusty on C, today I almost develop everything on Ruby, so it was a natural choice for me.
Exactly! I wanted to create a well documented and fully functional system targeted to the average Linux guy, not to a network specialist. It cares about everything: creating iptables configuration, setting ip policy routing rules, monitoring the uplinks, warning the administrator.
Channel bonding is a different thing, but you need upstream support to let it work. It's for example what these guys are doing (letting you connect to their server on the cloud): http://speedify.com/
If I'm not wrong, ja kernel patches detect a dead route by pinging the interface gateway. In my experience, in my environment (Italy), this is not enough to detect a dead gateway: we often get dead DSL links or very disturbed radio links. In both cases the interface gateway is up and running, so the uplink would not be detected as down. And this unfortunately doesn't happen here "less than once or twice a year": we don't have a very nice internet infrastructure here in Italy, in some rural places it can happen once a month.
About the RAID-0 analogy, it was just to let people better understand using a concept they are familiar with: I'm confident many Slashdot readers know what a RAID-0 is. And I still think the RAID-0 analogy is pertinent. If you don't have a mechanism to exclude dead uplinks, it's like losing a disk in a RAID-0 array: all your data is lost! In this case (almost) all of your LAN-to-WAN traffic is down. Actually you had a mechanism to exclude dead uplinks: ja kernel patches, they worked in your environment but, as I said before, not in mine.
Slashdot Mirror
First commit is 2 weeks old because until then the program was internally developed and used, as stated in the README. 2 weeks ago it was put on GitHub and released as GPL.
No, you needn't Ruby on your router if a working packet marking solution is all you need. Just run Fault Tolerant Router in demo mode on... Windows, if you wish! Grab the command output and use the same commands on your router, using Bash or whatever you like.
I would use OpenVPN. One VPN going from each uplink to your data center. Then use channel bonding on the OpenVPN interfaces on both sides: remote location and data center. Of course you would need a modified version of Fault Tolerant Router to detect if an uplink goes down, otherwise your "channel bonded" connection would go down too...
Yes, you could write it in Bash. I extensively used Bash to do shell scripting in the past, but it doesn't give me the same "programming pleasure" as Ruby does. Personal tastes.
It's not aimed at embedded systems, so dependencies are not a problem for me. Then, installing dependencies with bundler it's a joke. It's clear you're not a Ruby fan! ;-) I agree it would have been better to write it in C, but I'm a little rusty on C, today I almost develop everything on Ruby, so it was a natural choice for me.
Exactly! I wanted to create a well documented and fully functional system targeted to the average Linux guy, not to a network specialist. It cares about everything: creating iptables configuration, setting ip policy routing rules, monitoring the uplinks, warning the administrator.
Does OSPF work also with cheap DSL routers Telecom Italia or Vodafone provide us? I doubt it. Unfortunately we're not in Silicon Valley here... ;-)
Channel bonding is a different thing, but you need upstream support to let it work. It's for example what these guys are doing (letting you connect to their server on the cloud): http://speedify.com/
If I'm not wrong, ja kernel patches detect a dead route by pinging the interface gateway. In my experience, in my environment (Italy), this is not enough to detect a dead gateway: we often get dead DSL links or very disturbed radio links. In both cases the interface gateway is up and running, so the uplink would not be detected as down. And this unfortunately doesn't happen here "less than once or twice a year": we don't have a very nice internet infrastructure here in Italy, in some rural places it can happen once a month. About the RAID-0 analogy, it was just to let people better understand using a concept they are familiar with: I'm confident many Slashdot readers know what a RAID-0 is. And I still think the RAID-0 analogy is pertinent. If you don't have a mechanism to exclude dead uplinks, it's like losing a disk in a RAID-0 array: all your data is lost! In this case (almost) all of your LAN-to-WAN traffic is down. Actually you had a mechanism to exclude dead uplinks: ja kernel patches, they worked in your environment but, as I said before, not in mine.