Best Practices for Deploying GRE Tunnels
Deploying GRE Tunnels
- Zscaler recommends that you configure two GRE tunnels from an internal router behind the firewall to the ZENs (Zscaler Enforcement Nodes). For more information, see GRE Deployment Scenarios.
- Zscaler requires building primary and backup GRE tunnels from every Internet egress location and, if applicable, from each Internet service provider.
- Zscaler requires you to submit a support ticket to receive GRE tunneling configuration. Zscaler will identify the endpoints of the tunnels based on your geolocation information. You can request alternative locations for the tunnels by contacting Zscaler Support.
- Zscaler recommends that you calculate the maximum transmission unit (MTU) and maximum segment size (MSS) values on the GRE tunnel based on the MTU and MSS configuration of the WAN interface. Note that an incorrectly configured MTU results in higher fragmentation, leading to performance degradation.
In this example, the tunnel MTU and MSS values are calculated for a WAN interface that is 1500 bytes.
WAN Interface MTU = 1500
WAN Interface MSS = MTU (1500) – IP (20) – TCP (20) = 1460 (40 bytes TCP+IP Header)
GRE = 24 bytes header
GRE MTU = MTU (1500) – IP (20) – GRE (24) = 1456
GRE MSS = GRE MTU (1456) – IP (20) – TCP (20) = 1416
To learn more, see the following Cisco article: http://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html
Monitoring GRE Tunnels
Zscaler requires you to monitor your GRE tunnels so that failover between the primary and backup tunnel will trigger if a tunnel goes down.
GRE tunneling interfaces do not have a built-in mechanism for detecting when a tunnel is down. Enable GRE keepalives to serve as a basic detection mechanism. GRE keepalives can be configured on the physical or on the logical interface. The GRE keepalives monitor the interface, but not the service beyond the interface.
In order to perform service monitoring, deploy Layer 7 health checks if your vendor supports it. (If your vendor does not support Layer 7 health checks, deploy Layer 4 health checks, such as ICMP and PAC-based failover.)
A majority of Cisco devices support Layer 7 health checks using IPSLA. Some Juniper devices support health checks using RPM (real-time performance monitoring).
NOTE: Do not perform these Layer 7 health checks to commonly visited websites, such as www.google.com. Doing so will result in Google blacklisting Zscaler's IP addresses and enforcing Google Captcha to all users coming from those Zscaler IP addresses.
Perform HTTP Raw Request to the following URL: http://gateway.<zscaler_cloud>.net/vpntest
- Replace <zscaler_cloud> with your cloud name. To learn how to find your cloud name, see What is my cloud name?
See below for a sample Cisco IPSLA configuration.
track 1 ip sla 1 track 2 ip sla 2 ip sla 1 http raw http://172.18.56.162:9480 timeout 5000 threshold 300 http-raw-request GET http://gateway.<zscaler-cloud>.net/vpntest HTTP/1.0\r\n User-Agent: Cisco IP SLA\r\n End\r\n \r\n exit ip sla schedule 1 life forever start-time now ip sla 2 http raw http://172.18.56.166:9480 timeout 5000 threshold 300 http-raw-request GET http://gateway.<zscaler-cloud>.net/vpntest HTTP/1.0\r\n User-Agent: Cisco IP SLA\r\n end\r\n \r\n exit ip sla schedule 2 life forever start-time now ip sla reaction-configuration 1 react rtt threshold-value 300 1 threshold -type consecutive 3 ip sla reaction-configuration 2 react rtt threshold-value 300 1 threshold -type consecutive
GRE Tunnel Failover
Zscaler requires you to connect tunnel monitoring to tunnel failover. When service monitoring is down, the primary tunnel should failover to the backup tunnel, and when monitoring is available, switch back to the primary tunnel.
See below for a sample configuration for a Cisco router.
route-map ZS-NET-PORT permit 10 match ip address ZS-NET-PORT set ip next-hop verify-availability 172.18.56.162 1 track 1 set ip next-hop verify-availability 172.18.56.166 2 track 2