Generic Routing Encapsulation or GRE for short provide a mechanism to transport packets of one protocol within another protocol usually TCP. The protocol that is carried across or encapsulated is referred to as the passenger protocol, and the protocol that is used for carrying the passenger protocol is called as the transport protocol.
Generic Routing Encapsulation tunnels are useful for a verity of tasks. From a network standpoint the tunnel traffic is considered just that a GRE nothing more. It’s not unicast, multicast or IPSEC, however you can encrypt the traffic if needed. You can utilize GRE tunnels for traffic that might not otherwise be able to traverse the Network. For that matter the traffic traveling through the tunnel is completely unaware of the underlying Network Topology and or routing protocols.
With the ever increasing demand for more and more Guest access, and BYOD I was tasked with coming up with a solution for isolating Guest related access, and then back hauling the isolated traffic across our MPLS network. If it wasn’t so cost prohibitive at the time it would have been much simpler just burden each remote location with the expense of a Broadband or DSL connection. The other challenge was the ability to monitor and control usage along with appropriate content. With this in mind it became even more of a challenge with each location having their own Internet connection.
Keepalive
The GRE Tunnel Keepalive feature provides the capability of configuring keepalive packets to be sent over IP-encapsulated GRE tunnels. You can specify the rate at which keepalives will be sent and the number of times that a device will continue to send keepalive packets without a response before the interface becomes inactive.
Dynamic Routing Considerations
GRE tunnels are sometimes combined with IPSEC, however IPSEC alone does not support multicast packets. This prevents dynamic routing protocols such as EIGRP, and OSPF from forming neighbor relationships. Since IPSEC alone does not support multicast, a dynamic routing protocol can be run over a GRE tunnels. This way, you can encrypt unicast, and multicast packets when tunneled. In this particular scenario dynamic routing is not a factor.
Default MTU Size: 1500 – 24 = 1476
Configure the first Tunnel interface on Router Seattle with Netflow
Seattle#configure terminal
Seattle(config)#interface Tunnel1
Seattle(config-if)#ip address 10.0.3.1 255.255.255.252
Seattle(config-if)#ip flow ingress
Seattle(config-if)#ip flow egress
Seattle(config-if)#ip tcp adjust-mss 1436
Seattle(config-if)#tunnel source 172.16.0.1
Seattle(config-if)#tunnel destination 172.16.3.1
Seattle(config-if)#exit
Seattle(config)#exit
Seattle#
Configure the second Tunnel interface on Router R1 with Netflow
Seattle#configure terminal
Seattle(config)#interface Tunnel2
Seattle(config-if)#ip address 10.0.4.1 255.255.255.252
Seattle(config-if)#ip flow ingress
Seattle(config-if)#ip flow egress
Seattle(config-if)#ip tcp adjust-mss 1436
Seattle(config-if)#tunnel source 172.16.0.1
Seattle(config-if)#tunnel destination 172.16.4.1
Seattle(config-if)#exit
Seattle(config)#exit
Seattle#
Be sure to add the static Guest network routes for the Tunnels to Dallas and New York. We need to make sure that the static routes are in place so that R1 will be able route back to remote Guest networks, and Router Seattle is not simply sending back out ICMP destination unreachable messages to Router Dallas, and New York.
Seattle#configure terminal
Seattle(config)#ip route 172.16.3.0 255.255.255.0 Tunnel1
Seattle(config)#ip route 172.16.4.0 255.255.255.0 Tunnel2
Seattle(config)#exit
Seattle#
We need to configure the subinterface for dot1Q trunk for VLAN 2
Dallas#configure terminal
Dallas(config)#interface GigabitEthernet0/0.1
Dallas(config-if)#description Data
Dallas(config-if)#encapsulation dot1Q 2
Dallas(config-if)#ip address 172.16.3.1 255.255.255.0
Dallas(config-if)#exit
Dallas(config)#exit
Dallas#
We need to configure the subinterface dot1Q for Guest VLAN 3
Dallas#configure termianl
Dallas(config)#interface GigabitEthernet0/0.2
Dallas(config-if)#description Guest
Dallas(config-if)#encapsulation dot1Q 3
Dallas(config-if)#ip address 192.168.3.1 255.255.255.0
Dallas(config-if)#ip access-group Guest in
Dallas(config-if)#exit
Dallas(config-if)#exit
Dallas#
Configure the Tunnel interface on Router Dallas with Netflow exports
Dallas#configure terminal
Dallas(config)#interface Tunnel1
Dallas(config-if)#ip address 10.0.3.1 255.255.255.252
Dallas(config-if)#ip flow ingress
Dallas(config-if)#ip flow egress
Dallas(config-if)#ip tcp adjust-mss 1436
Dallas(config-if)#tunnel source 172.16.3.1
Dallas(config-if)#tunnel destination 172.16.0.1
Dallas(config-if)#exit
Dallas(config)#exit
Dallas#
Add the route for the Guest traffic through the Tunnel interface on Seattle
Dallas#configure terminal
Dallas(config)#ip route 172.16.3.0 255.255.255.0 Tunnel1
Dallas(config)#exit
Dallas#
Create the extended ACL on R3 for the Guest traffic
Dallas#configure terminal
Dallas(config)#ip access-list extended Guest
Dallas(config-ext-ncal)#permit ip 172.16.3.0 0.0.0.255 any
Dallas(config-ext-ncal)#deny ip any 172.0.0.0 0.31.255.255
Dallas(config-ext-ncal)#permit ip 192.168.3.0 0.0.0.255 any
Dallas(config-ext-ncal)#exit
Dallas(config)#exit
Dallas#
Force the Guest traffic over the Tunnel on Router R3 with a Route Map
Dallas#configure terminal
Dallas(config)#route-map Guest
Dallas(config-route-map)#route-map Guest permit 10
Dallas(config-route-map)#match ip address Guest
Dallas(config-route-map)#set ip next-hop 10.0.3.1
Dallas(config-route-map)#set interface Tunnel1
Dallas(config-route-map)#exit
Dallas(config)#exit
Dallas#
Configure Router New York for Layer 2 trunking from the Data VLAN
NY#configure terminal
NY(config)#interface GigabitEthernet0/0.1
NY(config-if)#description Data
NY(config-if)#encapsulation dot1Q 2
NY(config-if)#ip address 172.16.4.1 255.255.255.0
NY(config-if)#exit
NY#config)#exit
NY#
Configure Router New York for Layer 2 trunking from the Guest VLAN
NY#configure terminal
NY(config)#interface GigabitEthernet0/0.2
NY(config-if)#description Guest
NY(config-if)#encapsulation dot1Q 3
NY(config-if)#ip address 192.168.4.1 255.255.255.0
NY(config-if)#ip access-group Guest in
NY(config-if)#ip policy route-map Guest
NY(config-if)#exit
NY(config)#exit
NY#
Configure the Tunnel interface on Router New York with Netflow exports
NY#configure terminal
NY(config)#interface Tunnel1
NY(config-if)#ip address 10.0.4.1 255.255.255.252
NY(config-if)#ip flow ingress
NY(config-if)#ip flow egress
NY(config-if)#ip tcp adjust-mss 1436
NY(config-if)#tunnel source 172.16.4.1
NY(config-if)#tunnel destination 172.16.0.1
NY(config-if)#exit
NY(config)#exit
NY#
Add the route on Router New York for the 172.16.4.0 network
NY#configure terminal
NY(config)#ip route 172.16.4.0 255.255.255.0 Tunnel1
NY(config)#exit
NY#
Create the extended ACL on New York for the Guest traffic
NY#configure terminal
NY(config)#ip access-list extended Guest
NY(config-ext-ncal)#permit ip 172.16.4.0 0.0.0.255 any
NY(config-ext-ncal)#deny ip any 172.0.0.0 0.31.255.255
NY(config-ext-ncal)#permit ip 192.168.4.0 0.0.0.255 any
NY(config-ext-ncal)#exit
NY(config)#exit
NY#
Configure the Route Map on New York for the Guest traffic
NY#configure terminal
NY(config)#route-map Guest
NY(config-route-map)#route-map Guest permit 10
NY(config-route-map)#match ip address Guest
NY(config-route-map)#set ip next-hop 10.0.4.1
NY(config-route-map)#set interface Tunnel1
NY(config-route-map)#exit
NY(confg)#exit
NY#
I included the Netflow configuration on the Tunnel Interfaces just so we can keep track of the Guest bandwidth usage. As far as Netflow is concerned the Tunnel Interface is just another Interface on the Router so we can export the flows just as we would on any other Physical Interface. The utilization of a Route Map or Policy Based Routing is a major component of the configuration and does a lot of the work. You may want also want to include a bandwidth statement on the Tunnel interfaces relative to the WAN bandwidth.
I hope you found this post on GRE helpful and informative. Be sure to let me know what you think by leaving your suggestions, and feedback in the comments section below. You can find out more about these and other articles be checking out recent posts and archives. To learn more about myself be sure to check out the About page. And as always thanks again for visiting The Packet.
