Remote Teleworker Solutions – Branch Office Routing Solutions

In the final section of this chapter, we are going to be looking at branch office routing solutions, specifically across Generic Routing Encapsulation (GRE) tunnels and floating static routes.

Floating Static Routes

Floating static routes are commonly used for backup connections in medium-sized branch office implementations, although they can also be used in full-sized branch office implementations. Floating static routes are simply static routes that are configured with a higher administrative distance than the primary route, which can either be statically configured or learned dynamically using a routing protocol. To demonstrate the use of floating static routes, consider the topology illustrated in Figure 10-17:

Fig. 10-17. Implementing Floating Static Routes

Referencing Figure 10-17, a remote site router, R1 is connected to the MPLS network as well as to the Internet. The primary connection should be the MPLS connection. The Internet connection should only be used in the event that the MPLS connection is unavailable. It should be assumed that the Ethernet interface is connected to a cable modem and the provider has assigned the customer a globally routable subnet as they are a business class customer. For the sake of simplicity, only static default routes are used. Taking into consideration all we have learned in this chapter, the site router, R1, would be configured as follows:

NOTE: For clarity, the floating static route is highlighted in the following configuration.

Based on the configuration implemented on R1, the MPLS connection will be used to forward all packets to the corporate and unknown networks. In the event that the MPLS connection is unavailable, the site-to-site VPN tunnel between R1 and the VPN headend device VE1 is used to securely allow access to the enterprise network across the Internet. When the primary path is restored, the static route pointing out of the Serial0/0 interface is reinstalled into the RIB and is used for forward all packets via the MPLS VPN.

Generic Routing Encapsulation (GRE) Tunnels

Generic Routing Encapsulation tunnels, which were described in detail in Chapter 9 – IPv4 and IPv6 Integration and Coexistence, support multiple protocols in addition to Unicast, Multicast and Broadcast traffic, which allows dynamic routing protocols to be configured across them. The configuration of GRE tunnels is straightforward and is performed as follows:

The configuration of static tunnels in Cisco IOS software is a straightforward process. The following section goes through the configuration steps required to create static or manually configured tunnels for encapsulating IPv6 packets within IPv4 packets:

• Configure a static tunnel interface using the interface tunnel [number] global configuration command. The number range will vary depending on the version of Cisco IOS software that the router on which the tunnel is being configured is running

• Assign the static tunnel interface an IP address using the ip address interface configuration command

• Configure a tunnel source for the static tunnel using the tunnel source [address | interface] interface configuration command. This is used as the tunnel source address. All packets sent across this tunnel will have this IPv4 address as the source address included in the IPv4 packet header. This is typically a Loopback interface but can be any interface with a globally routable IP address

• Configure a tunnel destination for the static tunnel using the tunnel destination [IPv4 address] interface configuration command. This is the IPv4 address of the tunnel endpoint, i.e. the far-end side of the tunnel. This address should be the same as the tunnel source address for the tunnel endpoint

• Because GRE is the default encapsulation protocol for tunnel interfaces, you do not need to issue thetunnel mode gre ip command; however, issuing does not affect the implementation

Referencing the topology in Figure 10-17, which was used to demonstrate the configuration of floating static routes, the following example illustrates how to configure a GRE tunnel to be used as a backup in the event that the primary tunnel via the MPLS WAN is unavailable or the routing protocol adjacency is down. The VPN headend router is configured as follows:

Following the same logic, the remote site router, R1, is configured in a similar way as follows:

Following this configuration, the show ip eigrp neighbors command is used to verify that the EIGRP neighbor relationship across the tunnel has been established as follows:

NOTE: Due to default tunnel bandwidth and delay values, in most cases the path via a Tunnel interface will always be less preferred than one via other interface types, e.g. Serial or Ethernet, keep in mind that if you use a routing protocol such as EIGRP, you can use the variance command to load share traffic between the primary and backup connections which allows for better utilization of resources. Consideration, however, should be given to the actual topology that this implementation is being deployed on. For example, this may not work in an environment that uses stateful firewalls. It is therefore important to consider the whole picture.

While GRE tunnels do allow routing protocols to be implemented across them, it is important to know that GRE tunnels by themselves do not provide any additional security. Therefore, the packets sent across the GRE tunnel over the Internet are still legible, i.e. are not in cryptographic form, and therefore can be intercepted and read. If security is a requirement, IPsec can be used in conjunction with GRE tunnels, similar to DMVPN operation, to ensure and provide data confidentiality, integrity and authenticity.