GRE over IPsec
As I just mentioned, GRE by itself provides no security—no form of payload confidentiality or encryption. If the packets are sniffed over the public networks, their contents are in plain-text, and although IPsec provides a secure method for tunneling data across an IP network, it has limitations.
IPsec does not support IP broadcast or IP multicast, preventing the use of protocols that need them, like routing protocols. IPsec also does not support the use of the multiprotocol traffic. GRE is a protocol that can be used to “carry” other passenger protocols like IP broadcast or
IP multicast, as well as non-IP protocols. So using GRE tunnels with IPsec allows you to run a routing protocol, IP multicast, as well as multiprotocol traffic across your network.
With a generic hub-and-spoke topology (corp to branch, for example), you can implement static tunnels, typically GRE over IPsec, between the corporate office and branch offices. When you want to add a new spoke to the network, all you need to do is configure it on the hub router. The traffic between spokes has to traverse the hub, where it must exit one tunnel and enter another. Static tunnels can be an appropriate solution for small networks, but this solution actually becomes an unacceptable problem as the number of spokes grows larger and larger!
Cisco DMVPN (Cisco Proprietary)
The Cisco Dynamic Multipoint Virtual Private Network (DMVPN) feature enables you to easily scale large and small IPsec VPNs. The Cisco DMVPN is Cisco’s answer to allow a corporate office to connect to branch offices with low cost, easy configuration, and flexibility. DMVPN has one central router, such as a corporate router, which is referred to as the hub, and the branches are called spokes. So the corporate to branch connection is referred to as the hub-and-spoke
interconnection. Also supported is the spoke-to-spoke design used for branch-to-branch interconnections. If you’re thinking this designsounds eerily similar to your old Frame Relay network, you’re right! The DMPVN features enables you to configure a single GRE tunnel interface and a single IPsec profile on the hub router to manage all spoke routers, which keeps the size of the configuration on the hub router basically the same even if you add more spoke routers to the network. DMVPN also allows spoke router to dynamically create VPN tunnels between them as network data travels from one spoke to another.
Cisco IPsec VTI (Cisco Proprietary)
The IPsec Virtual Tunnel Interface (VTI) mode of an IPsec configuration can greatly simplify a VPN configuration when
protection is needed for remote access. And it’s a simpler option to GRE or L2TP for encapsulation and crypto maps used with IPsec. Like GRE, it sends routing protocol and multicast traffic, but you don’t need the GRE protocol and all the overhead that brings. A nice simple configuration and routing adjacency directly over the VTI offers many benefits. Understand that all traffic is encrypted and that it supports only one protocol—either IPv4 or IPv6, just like standard IPsec.
Now let’s take a look at how to configure a GRE tunnel. It’s actually pretty simple.
Configuring GRE Tunnels
Before you attempt to configure a GRE tunnel, you need to create an implementation plan. Here’s a checklist for what you need to con figure and implement a GRE:
1. Use IP addressing.
2. Create the logical tunnel interfaces.
3. Specify that you’re using GRE tunnel mode under the tunnel interface (this is optional since this is the default tunnel mode).
4. Specify the tunnel source and destination IP addresses.
5. Configure an IP address for the tunnel interface.
Let’s take a look at how to bring up a simple GRE tunnel.shows the network with two routers.
Example of GRE configuration
First, we need to make the logical tunnel with the interface tunnel number command. We can use any number up to 2.14 billion.
Corp(config)# int s0/0/0
Corp(config-if)# ip address 220.127.116.11 255.255.255.252
Corp(config)# int tunnel ?
<0-2147483647> Tunnel interface number
Corp(config)# int tunnel 0
*Jan 5 16:58:22.719:%LINEPROTO-5-UPDOWN: Line protocol on
Interface Tunnel0, changed state to down
Once we have configured our interface and created the logical tunnel, we need to configure the mode and then the transport protocol.
Corp(config-if)# tunnel mode ?
aurp AURP TunnelTalk AppleTalk encapsulation
cayman Cayman TunnelTalk AppleTalk encapsulation
dvmrp DVMRP multicast tunnel
eon EON compatible CLNS tunnel
gre generic route encapsulation protocol
ipip IP over IP encapsulation
ipsec IPSec tunnel encapsulation
iptalk Apple IPTalk encapsulation
ipv6 Generic packet tunneling in IPv6
ipv6ip IPv6 over IP encapsulation
nos IP over IP encapsulation (KA9Q/NOS compatible)
rbscp RBSCP in IP tunnel
Corp(config-if)# tunnel mode gre ?
ip over IP
ipv6 over IPv6
multipoint over IP (multipoint)
Corp(config-if)# tunnel mode gre ip
Now that we’ve created the tunnel interface, the type, and the transport protocol, we must configure our IP addresses for use inside of the tunnel. Of course, you need to use your actual physical interface IP for the tunnel to send traffic across the Internet, but you also need to configure the tunnel source and tunnel destination addresses.
Corp(config-if)# ip address 192.168.10.1 255.255.255.0
Corp(config-if)# tunnel source 18.104.22.168
Corp(config-if)# tunnel destination 22.214.171.124
Corp# sho run interface tunnel 0
Current configuration : 117 bytes
ip address 192.168.10.1 255.255.255.0
tunnel source 126.96.36.199
tunnel destination 188.8.131.52
Now let’s configure the other end of the serial link and watch the tunnel pop up!
SF(config)# int s0/0/0
SF(config-if)# ip address 184.108.40.206 255.255.255.252
SF(config-if)# int t0
SF(config-if)# ip address 192.168.10.2 255.255.255.0
SF(config-if)# tunnel source 220.127.116.11
SF(config-if)# tun destination 18.104.22.168
*May 19 22:46:37.099: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Tunnel0, changed state to up
Oops—did I forget to set my tunnel mode and transport to GRE and IP on the SF router? No, I didn’t need to because it’s the default tunnel mode on Cisco IOS. Nice! So, first I set the physical interface IP address (which used a global address even though I didn’t have to), then I created the tunnel interface and set the IP address of the tunnel interface. It’s really important that you remember to configure the tunnel interface with the actual source and destination IP address es to use or the tunnel won’t come up. In my example, the 22.214.171.124 was the source and 126.96.36.199 was the destination.
BGP version 4 has a long and storied history. Although the most recent definition was published in 1995 as RFC 1771 by Rekhter and Li, BGP’s
roots can be traced back to RFCs 827 and 904, which specified a protocol called the exterior gateway protocol (EGP). These earlier specifications date from 1982 and 1984, respectively—ages ago! Although BGP obsoletes EGP, it uses many of the techniques first defined by EGP and draws upon the many lessons learned from its use.
Way back in 1982, many organizations were connected to the ARPAnet, the noncommercial predecessor of the Internet. When a new network was added to ARPAnet, it would typically be added in a relatively unstructured way and would begin participating in a
common routing protocol, the Gateway to Gateway Protocol (GGP). As you might expect, this solution did not scale well. GGP suffered from excessive overhead in managing large routing tables and from the difficulty of troubleshooting in an environment in which there was no central administrative control.
To address these deficiencies, EGP was developed, and with it the concept of autonomous systems (ASs) . RFC 827 was very clear in laying out the problems with GGP and in pointing out that a new type of routing protocol was required, an exterior gateway protocol (EGP) . The purpose of this new protocol was to facilitate the flow of traffic among a series of autonomous systems by exchanging information about routes contained in each system. The complexities of this network of networks, the Internet, would be hidden from the end user contains a Comparison of BGP and OSPF who simply views the Internet as a single address space through which
they travel, unaware of the exact path they take.
The BGP that we know today flows directly from this work on EGP and builds upon it. So that you can get a better understanding of BGP, I
will provide an overview of its features next.
Protocol Comparison and Overview
Because BGP is the first exterior gateway protocol we’ve encountered, I’ll briefly compare it to a more familiar interior gateway protocol, like OSPF, so that we can put its features into context. After that comes a brief overview of BGP so that you can quickly become aware of its main capabilities.
Just to clarify things, with this comparison, I’m not implying that OSPF could be a substitute for BGP. In fact, there are a number of reasons that BGP is far better suited as an exterior gateway protocol than OSPF. For example, the requirement that all OSPF areas be connected to area 0 simply doesn’t allow OSPF to scale to the size required by the Internet. Thousands of areas would have to connect to area 0, overwhelming it with route updates. In addition, OSPF uses a metric based on bandwidth, but in the context of the Internet, routing decisions are also based on political and business issues. OSPF does not have any mechanism to modify path selection based upon factors such as interconnection agreements between Internet service providers.
Although BGP can be thought of as just another routing protocol, the differences between it and protocols like OSPF are significant enough to catapult it into an entirely different category.