Where Would You Need GRE?
After I made the “duct tape of networking” joke, I quickly became a GRE lover (according to @Neelixx – another Twitter account lost in the mists of time). Jokes aside, let’s see where it makes sense to use GRE.
Whenever you want to transport your data over a third-party IP infrastructure without exposing your addressing and routing structure (example: building a VPN across a public IP infrastructure), you need a mechanism that allows you to encapsulate your IP packets (which are not routable by the third-party IP infrastructure) into routable IP envelopes.
There are at least five mechanisms that can do that (please add the ones I’ve missed in the comments):
- IPsec tunneling mode, which encrypts private IP packet and transports it in a public IP datagram with Encapsulated Security Payload header;
- GRE, which puts private IP packet in a GRE envelope (IP+GRE header);
- LISP, which uses LISP-over-UDP-over-IP headers;
- Various SSL VPNs, which put private IP packets into SSL (encrypted HTTP);
- IP-over-IP tunnels.
In redundant scenarios, it usually makes sense to run a routing protocol between VPN sites – failure detection is more consistent and it’s easier to reroute around failed links. Most routing protocols expect the routing protocol neighbors to be adjacent and Cisco IOS implementation of routing protocols requires the protocols to be associated with interfaces. To run routing protocols across an IP-over-IP technology with Cisco IOS you therefore need tunnel interfaces. We’ve managed to get RIP and BGP running across IPsec implementations using crypto maps, but trust me: you don’t want to do that.
If you need encryption, IPsec Virtual Tunnel Interface (VTI) will give you encryption and a point-to-point tunnel interface. If you just need IP-over-IP transport, GRE is probably the best option; more so as it’s multi-protocol: you can run IPv4, IPv6 and MPLS across the same GRE tunnel concurrently. Last but definitely not least, you can use multipoint GRE tunnels, where the same tunnel interface connects you to a number of remote sites. You can’t do anything remotely similar with IP-over-IP tunnels or IPsec.
Now that you know why you’d need GRE, let’s see where you would use it:
- DMVPN – multipoint GRE technology allows you to build scalable networks where a single tunnel interface can be used to reach numerous remote sites.
- MPLS/VPN WAN – once you get sick-and-tired of service provider incompetence (you want to hear a good rant – listen to Greg Ferro every time someone mentions VPLS in Packet Pusher podcasts), you can build GRE tunnels across their MPLS/VPN infrastructure and have a smoothly running network even when they manage to create yet another byzantine failure.
- Enterprise MPLS/VPN – if you decide to build your own MPLS/VPN network across a public IP infrastructure (including building your own MPLS/VPN service across a SP MPLS/VPN WAN), you need GRE tunnels.
More Information
- If you’re interested in basics of various VPN technologies and their benefits/drawbacks, Choose the Optimal VPN Service webinar is just what you need.
- You’ll learn everything you ever wanted to know about DMVPN in the DMVPN: from Basics to Scalable Networks webinar.
- Building your own enterprise MPLS/VPN service? Get started with the Enterprise MPLS VPN Deployment webinar.
You missed PWE3 ;)
P.S. Have a look at the presentation I gave a couple weeks back at CEW APAC in HK: http://db.tt/0td2WXO , you'll probably find it somewhat-related ;)
I was working for a smaller company, which has hub and spoke topology and runs IPsec over GRE from hub to each spoke via MPLS of a ISP. EIGRP is running accross GRE tunnels. Now I am working for a bigger company, which has two MPLS ISPs and runs OSPF mutual re-distributions to inject the routes learned from each ISP to LAN and route-map filter based on the tagging to prevent un-necessary routes learned from one ISP from being injected to the other ISP. I heard the main reason not to use GRE is because of MTU. GRE overheard requires routers configured to use lower MTU size, otherwise, too many TCP re-transmission would cause network delay and kill some applications. I think it might be true. But the solution we had in my previous smaller company is on the user end. All the PC images come with MTU size 1400. It's not complicated and it's working fine. I have to admit that the OSPF mutual re-distribution design is very interesting but it adds difficulties to troubleshooting.
Appreciate it if you could make some comment here.
SSL VPN is not necessarily encrypted HTTP. E.g. OpenVPN is a stand-alone protocol.
Guest: GRE does have some overhead, but usually it's not a trouble. Path MTU discovery usually works well in private networks, so TCP works fine too. Even if for some reason it doesn't, it's possible to manually adjust MSS for the interface. My favorite setup for VPN over a public network is GRE over IPsec with OSPF routing.
HTTP and HTTPS are just two protocols that happen to be used by web browsers most of the time, but can be used by a number of other things (including curl and wget).
I need to decide on a type of VPN to use for a Mobile Number Portability project. Basically, the Mobile operators will need to connect to a Primary and DR sites to be able to do portings, can you advise on a vpn desgn please.
#1 - buy the recordings of "Choose the Optimal VPN Service" and "DMVPN" webinars. You'll probably get lots of useful information there.
#2 - I can get you in touch with our Professional Services.
Use the "Contact me" link (top of page) if you're interested in #2.
HTTP and HTTPS are just two protocols that happen to be used by web browsers most of the time, but can be used by a number of other things (including curl and wget).
Actually, that isn't quite correct. OpenVPN runs on whatever port is configured, with the default being 1194. Many people use OpenVPN in TCP mode on port 443 out of convenience with firewall rules; however, when you do that, using the port assigned for HTTPS is the only thing it shares with HTTPS.
Sending encrypted data over TCP Port 443 does not make something HTTPS. You still have to utilize the HTTP protocol over the SSL/TLS encryption layer in order for it to be HTTPS.
The OpenVPN protocol itself does use SSL/TLS for encryption, but shares nothing at all with HTTP. The protocol used for an encrypted OpenVPN packet has more in common with an IPSec ESP packet than it does with an HTTP request.
I know this is an old thread. Can you please tell what the disadvantages of doing this are?
Thanks
Peter