GRE tunnels vs static routes
Moderator: Queue Moderator
GRE tunnels vs static routes
Our Trbo team is building out a new multi-site repeater system for a customer with a lot of locations they want to unify. As large as the customer is, there is internal inertia and resistance to building out the necessary static ip links between the sites to tie it all together. In fact, it's taken months, and they still can't seem to agree among themselves what to do. So, our team is moving forward with the project using Cradlepoint LTE routers on Verizon service to form the backbone of a limited three site roll out as proof of concept.
I was asked to make the link work, and ran into a little weirdness. I could make port forwarding work which satisfies the system requirements, but doesn't pass any other traffic between sites. I could not get static routes working at all. I couldn't get any of the supported routing protocols to do what was needed. But! I could get GRE to work. Passes traffic perfectly between the three subnets without port forwarding, you can ping every device, and RDAC works. It does not support VPN remote client sessions. So, for now, you have to be on site to touch the network.
Very strange. GRE is a fancy version of static routing. Verizon and Cradlepoint tech support is lean. Since the product isn't broken, it's a customer configuration issue which is a value added service.
I am not a layer 3 expert. I muddle. I get by. Any thoughts on why GRE would work, and why static routing did not?
I was asked to make the link work, and ran into a little weirdness. I could make port forwarding work which satisfies the system requirements, but doesn't pass any other traffic between sites. I could not get static routes working at all. I couldn't get any of the supported routing protocols to do what was needed. But! I could get GRE to work. Passes traffic perfectly between the three subnets without port forwarding, you can ping every device, and RDAC works. It does not support VPN remote client sessions. So, for now, you have to be on site to touch the network.
Very strange. GRE is a fancy version of static routing. Verizon and Cradlepoint tech support is lean. Since the product isn't broken, it's a customer configuration issue which is a value added service.
I am not a layer 3 expert. I muddle. I get by. Any thoughts on why GRE would work, and why static routing did not?
-
- Posts: 47
- Joined: Wed Sep 28, 2005 1:55 pm
Re: GRE tunnels vs static routes
Bill,
Use VPN Tunnels not GRE. They are on page 139 Section 7.6
http://www.cradlepoint.com/sites/defaul ... al_4.2.pdf
Most probably you will also need to use a service link DYNDNS unless you are purchasing Static IPs from Verizon.
An finally be careful of your subnets so your routing works correctly when the VPN links are up.
-----------
By the way I did something similar for a customer recently, but I used the CBR400 and then pfSense Firewall boxes behind them instead of this CradlePoint only because I thought it gave me a little more flexibility in the long run.
Use VPN Tunnels not GRE. They are on page 139 Section 7.6
http://www.cradlepoint.com/sites/defaul ... al_4.2.pdf
Most probably you will also need to use a service link DYNDNS unless you are purchasing Static IPs from Verizon.
An finally be careful of your subnets so your routing works correctly when the VPN links are up.
-----------
By the way I did something similar for a customer recently, but I used the CBR400 and then pfSense Firewall boxes behind them instead of this CradlePoint only because I thought it gave me a little more flexibility in the long run.
J. Silberberg
CompuDesigns, Inc.
Atlanta, GA.
CompuDesigns, Inc.
Atlanta, GA.
Re: GRE tunnels vs static routes
Thanks. I can make that recommendation. If I were to implement something like that, I'd set the IBR600s to passthrough, and use Juniper Netscreens (personal preference). But, not my project.jsilberberg wrote:Bill,
Use VPN Tunnels not GRE. They are on page 139 Section 7.6
http://www.cradlepoint.com/sites/defaul ... al_4.2.pdf
Most probably you will also need to use a service link DYNDNS unless you are purchasing Static IPs from Verizon.
An finally be careful of your subnets so your routing works correctly when the VPN links are up.
-----------
By the way I did something similar for a customer recently, but I used the CBR400 and then pfSense Firewall boxes behind them instead of this CradlePoint only because I thought it gave me a little more flexibility in the long run.
OTOH, the GRE tunnels made it easy to pass the udp packets because they pass all services. Is there a specific reason you chose to use VPN tunnels instead?
Re: GRE tunnels vs static routes
We use a tunnel device made by DCB Inc. to connect our sites when a public internet link is used. Like jsilberberg mentioned you would need to use a service like DYNDNS or have a static public IP address at one location which would act as a master. The other units connect as clients to the master and can use dynamic ips. What's nice about them is you don't have to worry about routing and you can keep all your IP equipment in the same subnet. They pass all ethernet protocols and multicast between all the units.
http://www.dcbnet.com/datasheet/ut3302ds.html
http://www.dcbnet.com/datasheet/ut3302ds.html
Re: GRE tunnels vs static routes
That's a thought. I've used DCB equipment in conjunction with Telex consoles quite a bit. It's a pretty straight forward appliance. It's another good recommendation. Thanks.
-
- Posts: 47
- Joined: Wed Sep 28, 2005 1:55 pm
Re: GRE tunnels vs static routes
I have done some GRE tunnels in the past, mostly with Telex solutions. Although I also prefer the DCBNet hardware for that. I just find that the VPN tunnels tend to work better, and if needed you can run GRE over the IPSEC/VPN Tunnel as well but now the data is encrypted / protected..Bill_G wrote:jsilberberg wrote:Bill,
OTOH, the GRE tunnels made it easy to pass the udp packets because they pass all services. Is there a specific reason you chose to use VPN tunnels instead?
J. Silberberg
CompuDesigns, Inc.
Atlanta, GA.
CompuDesigns, Inc.
Atlanta, GA.
Re: GRE tunnels vs static routes
Okay. Thanks. I'm not too worried about data security since it is just voice traffic on a voice network that is physically independent from the customer's data network. But, if using a VPN makes it more robust, we can switch them over.jsilberberg wrote:I have done some GRE tunnels in the past, mostly with Telex solutions. Although I also prefer the DCBNet hardware for that. I just find that the VPN tunnels tend to work better, and if needed you can run GRE over the IPSEC/VPN Tunnel as well but now the data is encrypted / protected..Bill_G wrote:jsilberberg wrote:Bill,
OTOH, the GRE tunnels made it easy to pass the udp packets because they pass all services. Is there a specific reason you chose to use VPN tunnels instead?
Re: GRE tunnels vs static routes
(snort) CradlePoint tech support finally responded - they want me to upgrade the units with the latest firmware and factory reset them before they will proceed with assistance. Shades of Canopy support ...
Re: GRE tunnels vs static routes
Bill, I have to ask, why go through all those gyrations. Does the customer have a specific reason not using the public network? I am under the assumption that in a IPSC system only the master site needs the static IP.
Re: GRE tunnels vs static routes
Part of the problem was the customer's IT dept. Big company with lots of internal inertia and territorialism. The road for the request to tie the three locations together through their existing enterprise network has been bumpy. Lots of meetings, lots of conference calls, and no action. So, our Trbo group decided to use these M2M (machine to machine) cellular routers to get it done. Static routes is how I decided to do it through Verizon, and because it was going through the Internet, I had to employ GRE or IPSec tunnels to join the subnets behind the NAT at each end. I was also able to do it with port forwarding which also requires static addresses to work correctly. But, then you cannot manage any of the other devices. There are probably other ways to do it. This seemed the simplest and easiest method that left a migration path for the next phases in the project.FMROB wrote:Bill, I have to ask, why go through all those gyrations. Does the customer have a specific reason not using the public network? I am under the assumption that in a IPSC system only the master site needs the static IP.
Re: GRE tunnels vs static routes
I know the world of hurt with corporate IT depts. We have the same issues here as well. That cradlepoint device you linked to, is that is a gsm cellular device that provides an IP connection to the internet? That looks to be a nifty device. What's the monthly charge on that?
Re: GRE tunnels vs static routes
It's v.kitchensink. 2G to LTE. There are other devices out there. This is the one the Verizon rep suggested. I dunno the cost. It's not totally intuitive, but it's pretty close to being an appliance. Uses setup wizards for configurations, but they will let you set it up wrong. The reason our Trbo guys ran into trouble started with Verizon. Verizon knew there were three nodes, and they assigned three static addresses. But, they set the subnet mask to .252 which guaranteed they wouldn't work right out of the gate. Once I got that straightened out, it was just a matter of building the tunnels to join the NAT subnets.
ETA - let me explain this a little better. Verizon assigned static addys of .184, .185, and .186 with a netmask of 255.255.255.252. Because of the addresses they chose, .184 is outside the subnet. It doesn't come into the subnet until you use a netmask of .240.
ETA - let me explain this a little better. Verizon assigned static addys of .184, .185, and .186 with a netmask of 255.255.255.252. Because of the addresses they chose, .184 is outside the subnet. It doesn't come into the subnet until you use a netmask of .240.
Re: GRE tunnels vs static routes
Bill, did this experiment work for you?
I am looking at setting up a couple of IPSC repeaters via cellular as a proof of concept and showcasing later on.
I have two Sixnet SN-6721 HSPA/LTE routers (nice units) provisioned with static IP addresses. I have good cell signal & good internet surfing speeds. However, round trip pings from one to the other average 500ms. Since TRBO specifies 60-90ms, I'm wondering how IPSC would even work, without using C-Bridge units at each end?
I am looking at setting up a couple of IPSC repeaters via cellular as a proof of concept and showcasing later on.
I have two Sixnet SN-6721 HSPA/LTE routers (nice units) provisioned with static IP addresses. I have good cell signal & good internet surfing speeds. However, round trip pings from one to the other average 500ms. Since TRBO specifies 60-90ms, I'm wondering how IPSC would even work, without using C-Bridge units at each end?
No trees were harmed in the posting of this message...however an extraordinarily large number of electrons were horribly inconvenienced.
Welcome to the /\/\achine.
Welcome to the /\/\achine.
Re: GRE tunnels vs static routes
Overall, it's a success. Zero problems with the Cradlepoint modems. But, we have had issues with Verizon in the late afternoon when their network gets busy. Maybe once a week or so. Lots of dr pped w rds and som tim s get bub le v ice from fr me loss. Dif icu t t un erst nd. And then it all clears up later. The customer understands the limitation, and is copeing with it. They are exploring other wireless carriers, but none can cover all their locations.
Re: GRE tunnels vs static routes
So high latency doesn't seem to be causing you issues, for the most part. I'll report back once I have my setup running.
FWIW, I can surf the internet through the modems and get ping times to servers in the 60ms range when using a website such as speedtest.net. But pinging from one unit to another results in the first ping taking 1500-1800ms, the subsequent pings in the 600ms range. Immediate pings afterwards stay at the 600ms range, but if given even say 10 seconds rest, the first ping again takes the near two seconds.
FWIW, I can surf the internet through the modems and get ping times to servers in the 60ms range when using a website such as speedtest.net. But pinging from one unit to another results in the first ping taking 1500-1800ms, the subsequent pings in the 600ms range. Immediate pings afterwards stay at the 600ms range, but if given even say 10 seconds rest, the first ping again takes the near two seconds.
No trees were harmed in the posting of this message...however an extraordinarily large number of electrons were horribly inconvenienced.
Welcome to the /\/\achine.
Welcome to the /\/\achine.
Re: GRE tunnels vs static routes
Whoa. Sounds like the tunnels shut down after a bit. Is there a keep alive in there somewhere?
Re: GRE tunnels vs static routes
I haven't set the tunnels up yet...doing some reading to get to that point. I know enough to be neighborhood I.T. support, but in reality should be considered very dangerous, lol.Bill_G wrote:Whoa. Sounds like the tunnels shut down after a bit. Is there a keep alive in there somewhere?
No trees were harmed in the posting of this message...however an extraordinarily large number of electrons were horribly inconvenienced.
Welcome to the /\/\achine.
Welcome to the /\/\achine.
Re: GRE tunnels vs static routes
That's me too. I successfully muddle.wavetar wrote:I haven't set the tunnels up yet...doing some reading to get to that point. I know enough to be neighborhood I.T. support, but in reality should be considered very dangerous, lol.Bill_G wrote:Whoa. Sounds like the tunnels shut down after a bit. Is there a keep alive in there somewhere?
Re: GRE tunnels vs static routes
Update - finally found time to devote to this today & now have two XPR8400 repeaters doing IP Site Connect through the LTE modems.
Once I moved things to an area with decent LTE signal, my round trip ping times dropped and stabilized significantly. They now both average approx 200ms during several minutes of continuous pinging from one laptop to another, over varying LTE signal strength from -82dBm to -95dBm (closing our install bay door results in a 13db drop in signal)
I'm surprised in a way, since I left the repeaters on the 'normal' messaging delay setting of 60ms. Even 'high' is only supposed to support 90ms...yet I don't seem to be having any real issues. Voice sounds fine...no dropped syllables or robotic sounding voice...well, no MORE robotic sounding than TRBO normally is, lol.
Once I moved things to an area with decent LTE signal, my round trip ping times dropped and stabilized significantly. They now both average approx 200ms during several minutes of continuous pinging from one laptop to another, over varying LTE signal strength from -82dBm to -95dBm (closing our install bay door results in a 13db drop in signal)
I'm surprised in a way, since I left the repeaters on the 'normal' messaging delay setting of 60ms. Even 'high' is only supposed to support 90ms...yet I don't seem to be having any real issues. Voice sounds fine...no dropped syllables or robotic sounding voice...well, no MORE robotic sounding than TRBO normally is, lol.
No trees were harmed in the posting of this message...however an extraordinarily large number of electrons were horribly inconvenienced.
Welcome to the /\/\achine.
Welcome to the /\/\achine.
Re: GRE tunnels vs static routes
Very long initial ping times usually caused by arp-cache miss at the sender and a wide-area LAN if you ping an IP address. DNS lookup issues if you ping a "name"
Most hosts have about 15 minute timeout on the cache so it is also possible that you have tunnel timer problems. You can exclude arp problems if the pings pass through at least one router (because the local router should be responding to arp resolution requests).
Most hosts have about 15 minute timeout on the cache so it is also possible that you have tunnel timer problems. You can exclude arp problems if the pings pass through at least one router (because the local router should be responding to arp resolution requests).
Re: GRE tunnels vs static routes
I'm surprised your LTE ping times are that high. I usually see <100ms... low latency is one of the cool parts of LTE. In the truck, running a Cradlepoint router, I often see <50ms.wavetar wrote:Update - finally found time to devote to this today & now have two XPR8400 repeaters doing IP Site Connect through the LTE modems.
Once I moved things to an area with decent LTE signal, my round trip ping times dropped and stabilized significantly. They now both average approx 200ms during several minutes of continuous pinging from one laptop to another, over varying LTE signal strength from -82dBm to -95dBm (closing our install bay door results in a 13db drop in signal)
I'm surprised in a way, since I left the repeaters on the 'normal' messaging delay setting of 60ms. Even 'high' is only supposed to support 90ms...yet I don't seem to be having any real issues. Voice sounds fine...no dropped syllables or robotic sounding voice...well, no MORE robotic sounding than TRBO normally is, lol.
Re: GRE tunnels vs static routes
Do you mean between two cradlepoints, or to a website? I also see pings in the 50-80ms range when testing LTE bandwidth speed on websites, but between modems the lowest I've seen is 140ms, with the average being approx 200ms.tvsjr wrote: I'm surprised your LTE ping times are that high. I usually see <100ms... low latency is one of the cool parts of LTE. In the truck, running a Cradlepoint router, I often see <50ms.
No trees were harmed in the posting of this message...however an extraordinarily large number of electrons were horribly inconvenienced.
Welcome to the /\/\achine.
Welcome to the /\/\achine.
Re: GRE tunnels vs static routes
Duh... I missed that part. That's Cradlepoint to data center via IPSec tunnel... not CP to CP. 140-200 is reasonable for LTE to LTE.wavetar wrote:Do you mean between two cradlepoints, or to a website? I also see pings in the 50-80ms range when testing LTE bandwidth speed on websites, but between modems the lowest I've seen is 140ms, with the average being approx 200ms.tvsjr wrote: I'm surprised your LTE ping times are that high. I usually see <100ms... low latency is one of the cool parts of LTE. In the truck, running a Cradlepoint router, I often see <50ms.