Software Defined WAN
-
Yeah. It's really slick the way they do it, and it does work relatively well. I was out for 2 weeks when I got my cochlear implant a few months ago. I spent one of those weeks working from home using ZeroTier to connect to my office machine.
-
@dafyre said:
Yeah. It's really slick the way they do it, and it does work relatively well. I was out for 2 weeks when I got my cochlear implant a few months ago. I spent one of those weeks working from home using ZeroTier to connect to my office machine.
We currently have everyone connecting through an RDP client to a Terminal Server. I inherited this network and they do not embrace any kind of change here
-
@wirestyle22 said:
@dafyre said:
Yeah. It's really slick the way they do it, and it does work relatively well. I was out for 2 weeks when I got my cochlear implant a few months ago. I spent one of those weeks working from home using ZeroTier to connect to my office machine.
We currently have everyone connecting through an RDP client to a Terminal Server. I inherited this network and they do not embrace any kind of change here
I definintely know how that is!
-
Well this chain went on quite a ways and I read Scott's posts. I will agree that originally it was for larger companies.. Facebook uses SD WAN instead of MPLS. However, SD WAN is a good alternative for MPLS actually.
I agree it does make more sense with bigger companies, however this is how it works and why it is advantageous.
SD Wan like Aryaka allows you to choose the best Edge provider in your geographic regions. Then the SD Wan provider has NTN interfaces with all the carriers and with the shortest amount of hops brings the traffic back onto their backbone.
However, you could very easily build your own solution. Simply build out strategic data center locations nation wide and geographically have your end user sites VPN to the data center and connect your data center over their backbone or set up Gig Wave circuits between sites.
This is becomming the standard for multi-site scenarios. Anyone who has 4 or 5 sites and wants to use a single carrier for MPLS can attest that certain sites when they price out are more expensive because they are offnet. SD WAN is providing a realistic alternative for this while keeping latency low and being able to tag packets for priority for voice and Video.
-
@TeleFox Well said. Thanks for the feedback
-
@TeleFox said:
However, you could very easily build your own solution. Simply build out strategic data center locations nation wide and geographically have your end user sites VPN to the data center and connect your data center over their backbone or set up Gig Wave circuits between sites.
.This is what Pertino has always done before the SD-WAN term was around. Central connection points in datacenters all over the world and dynamically changing the paths as needed. It was just called SDN and was just a dynamic balancing on a VPN backend before the new marketing term came around.
-
@dafyre You can bridge ZeroTier to standard Ethernet, though at the moment it requires some manual configuration work and some expertise with Linux and bridging and such.
Edit: pretty easy to do with a Raspberry Pi although the USB-wired 100mbit Ethernet on those won't work for really really high bandwidth stuff. Fine for ordinary use though, since the WAN is usually slower than that.
-
@adam.ierymenko said:
@dafyre You can bridge ZeroTier to standard Ethernet, though at the moment it requires some manual configuration work and some expertise with Linux and bridging and such.
Edit: pretty easy to do with a Raspberry Pi although the USB-wired 100mbit Ethernet on those won't work for really really high bandwidth stuff. Fine for ordinary use though, since the WAN is usually slower than that.
I actually had a ZT gateway set up to actually route traffic between my home network and my ZT network. It worked rather well. I accidentally whoopsied the VM and didn't bother with restoring, because by that time I had more devices on ZT than not, lol.
-
@dafyre Bridging works much better than I thought it would when I developed that feature. At first I was like "well, technically this is possible but I'm going to call it experimental until we see how it works in practice." I've heard of people using it with whole big LANs behind it, so I'm a bit stunned.
-
Quite sTUNned? Is that a TUN pun?
network device humour is the best.
-
@adam.ierymenko said:
@dafyre Bridging works much better than I thought it would when I developed that feature. At first I was like "well, technically this is possible but I'm going to call it experimental until we see how it works in practice." I've heard of people using it with whole big LANs behind it, so I'm a bit stunned.
Curious. I'd have to figure out how to do that. Got any docs handy
I'll definitely give that a go as my network is expanding. 
(I have a XenServer in France now, lol). -
@dafyre Big gotchas are (1) designating the node as a bridge on your network at the ZT level, and (2) getting the IP routing issues correct so that hosts on either side of the bridge can actually see each other. Remember that Ethernet is not IP so if a host doesn't know another host's IP range is on the same net it won't route to it that way. Instead it will try to go via default gateway.
There's also a few weird Linux options such as one that selects whether or not Ethernet bridge packets also traverse iptables. Usually you want this off (forget the actual setting but it's sysctl) but sometimes it can be useful... though it's a bit perverse. There's also Linux ebtables (Ethernet bridge tables) which are also useful for advanced stuff.
One more tidbit: If you allow all Ethernet frame types on a ZT network, spanning tree protocol will work and your bridges and switches will handle routing loops. It will treat ZT like another switch or LAN segment and work normally. (ZT itself knows nothing about STP but Linux bridging does.)
-
@dafyre We've considered making a little appliance for this, or a ready-to-run Raspberry Pi image.
-
@adam.ierymenko said:
@dafyre We've considered making a little appliance for this, or a ready-to-run Raspberry Pi image.
Appliance isn't a bad idea.
In regards to your other posts, yeah. I ran into the same issues, kinda. I was able to get it to work by adding routes on the devices that needed to talk across networks. A curious thought, though... Why not install a few ZT "routers" on each end of my network... Then I can let the local DHCP server hand out static routes to the ZeroTier subnets?
I think you and I are thinking at different levels of the stack, in some regards, aren't we? You're thinking down at the ethernet level, and I am thinking one notch up at the IP level?
Also when thinking about a bridge set up... what I envision when you say that is something like this:
192.168.100.1-128/24 --> ZT BRIDGE --> (other site) --> 192.168.100.129 - 254 / 24 ?
-
@adam.ierymenko said:
@dafyre We've considered making a little appliance for this, or a ready-to-run Raspberry Pi image.
Hrm, I might just pull my pi out of storage to make one weather you do an "official" one or not.
-
@dafyre said:
@adam.ierymenko said:
@dafyre We've considered making a little appliance for this, or a ready-to-run Raspberry Pi image.
Appliance isn't a bad idea.
In regards to your other posts, yeah. I ran into the same issues, kinda. I was able to get it to work by adding routes on the devices that needed to talk across networks. A curious thought, though... Why not install a few ZT "routers" on each end of my network... Then I can let the local DHCP server hand out static routes to the ZeroTier subnets?
I think you and I are thinking at different levels of the stack, in some regards, aren't we? You're thinking down at the ethernet level, and I am thinking one notch up at the IP level?
Also when thinking about a bridge set up... what I envision when you say that is something like this:
192.168.100.1-128/24 --> ZT BRIDGE --> (other site) --> 192.168.100.129 - 254 / 24 ?
That description is a nightmare waiting to happen. You described a pair of /25 networks setup as a single /25 and want it all to be magic across a VPN.
It is an extremely bad idea.
-
@JaredBusch said:
@dafyre said:
@adam.ierymenko said:
@dafyre We've considered making a little appliance for this, or a ready-to-run Raspberry Pi image.
Appliance isn't a bad idea.
In regards to your other posts, yeah. I ran into the same issues, kinda. I was able to get it to work by adding routes on the devices that needed to talk across networks. A curious thought, though... Why not install a few ZT "routers" on each end of my network... Then I can let the local DHCP server hand out static routes to the ZeroTier subnets?
I think you and I are thinking at different levels of the stack, in some regards, aren't we? You're thinking down at the ethernet level, and I am thinking one notch up at the IP level?
Also when thinking about a bridge set up... what I envision when you say that is something like this:
192.168.100.1-128/24 --> ZT BRIDGE --> (other site) --> 192.168.100.129 - 254 / 24 ?
That description is a nightmare waiting to happen. You described a pair of /25 networks setup as a single /25 and want it all to be magic across a VPN.
It is an extremely bad idea.
Considering ZT - why is this any worse? Sure, if you are going to be that separate, then just make the separate networks, but there is no requirement to, just like there is no requirement to make separate networks in ZT.
-
@adam.ierymenko said:
@dafyre We've considered making a little appliance for this, or a ready-to-run Raspberry Pi image.
You need to get it into some vendor devices like Ubiquiti.
-
@JaredBusch said:
192.168.100.1-128/24 --> ZT BRIDGE --> (other site) --> 192.168.100.129 - 254 / 24 ?
That description is a nightmare waiting to happen. You described a pair of /25 networks setup as a single /25 and want it all to be magic across a VPN.
I keep rereading this trying to figure out the goal. But I think he just wants a /24 with roughly half the IPs used on one side and half on the other with bridging in between rather than ZT installed to each device.
-
@scottalanmiller said:
@adam.ierymenko said:
@dafyre We've considered making a little appliance for this, or a ready-to-run Raspberry Pi image.
You need to get it into some vendor devices like Ubiquiti.
Oh grief no. Ubiquiti take ages to do anything, feature requests people have been begging for take ages.
Let us white box our own hardware
Or setup a VM to do it.
