GRE tunnel, why and what for ?

[AdamBudzinski]

Hi all,

I was wondering, what was the reason behind creating GRE? I mean, it's not secure, does not provide encryption, of course we can have it configure with IPsec but why would one want to configure an plain GRE tunnel ? In the end with GRE we configure a virtual tunnel between two endpoints e.g. CISCO routers but isn't the communication between this two networks already in place?   

I appreciate all of your help in advance!

Best Regards

Adam 

[Rahul Govindan]

I guess the answer is sort of in the name itself. Generic Routing encapsulation (GRE) was primarily used to send multicast (initially for routing, now much more) over a non-multicast enabled cloud. Normally without having GRE, it is not easy to send routing information between 2 segments separated by the internet. So with GRE, 2 branches can be merged into one routing domain using GRE tunnels between the branch gateways. With the encapsulation, you are converting any multicast packet into a unicast with the GRE endpoints as headers. For a private cloud, just plain GRE can be used without IPsec. Adding encryption allows you to securely send it across a public cloud.

Hope this helps.

[AdamBudzinski]

[@rahul.govindan]  Thank you. What do you exactly mean when referring to cloud ? 

[Rahul Govindan]

I was referring to any public network not in your control - like Internet or carrier provided MPLS or WAN circuit.

[Richard Burts]

Sending multicast/routing protocols is one use for GRE but there are a number of other functions that it enables and that are reasons why GRE was created. Here are a few of them:

- in the early days of routing protocols when we were using classful principles summarization at network boundaries was the default and this created problems if you had discontiguous networks. For example site A uses subnet 172.16.20.0/24 and site B uses subnet 172.16.30.0/24 and the sites are connected by network 192.168.1.0 it would not have worked to run a routing protocol over the connecting link, but configuring a GRE tunnel between sites would allow you to specify a subnet that made the network contiguous and allow the routing protocol to advertise specific subnets between sites.

- I have been doing networking long enough to remember when networks had protocols other than IP that needed to be supported. I had a customer who had multiple remote sites. They ran decnet at each remote site but the backbone connecting the sites was IP only. So GRE tunnels provided a way for decnet at site A to communicate with decnet at site B even though the connection between sites was IP only.

- GRE would be an effective solution in a situation in which you had multiple remote sites connected by an ISP network. Perhaps site A uses networks 192.168.10.0, 192.168.11.0, and 192.168.12.0, and site B uses networks 192.168.20.0, 192.168.21.0, and 192.168.22.0. You want the sites to communicate and want to run a routing protocol so you have accurate knowledge of what networks are actually available. But this was before the days of MPLS and the ISP would not run a routing protocol with you. So configuring a GRE tunnel between sites provided a way to run a routing protocol between sites over the ISP network.

HTH

Rick

[tomasz.ciepiaszuk]

I actually use plain GRE in number of scenarios in production environment.

- to deliver application's bespoke multicasts over 3rd party networks where they either are not able to deliver multicasts or the network is already using RP for multicast distribution (our specific multicasts delivery with RP would be complex beyond being practical solution) so GRE can provide level of separation while traversing 3rd party networks.

- to provide easy single point for QoS marking. No need to mark traffic on multiple NIC/network devices. We only mark GRE traffic and deliver whatever we want to be delivered with AF inside the GRE encapsulation.

- to avoid joining routing domains with 3rd party network - we can deliver our traffic and seperate routing safely isolated inside GRE. This also allows for networks addressing to overlap with no issues nor requirment for NAT.

All the above circles pretty much around delivering traffic/interfacing across legacy networks with minimal/no changes required on those. This is common enough scenario in public sector where there is no money for upgrades, everything takes forever, there are issues finding skilled or any resources to deliver changes to existing infrastructure. Using GRE allowes to bypass a lot of those constrains.

Kind Regards

Tom