Single-Homed EBGP 

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 design 

sounds 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  63.1.1.1  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  63.1.1.1  

Corp(config-if)# tunnel  destination  63.1.1.2  

Corp# sho  run  interface  tunnel  0  

Building  configuration...  

Current  configuration  :  117  bytes  

!  

interface  Tunnel0  

  ip  address  192.168.10.1  255.255.255.0  

  tunnel  source  63.1.1.1  

  tunnel  destination  63.1.1.2  

end  

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  63.1.1.2  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  63.1.1.2  

SF(config-if)# tun  destination  63.1.1.1  

*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 63.1.1.2 was the  source and 63.1.1.1 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. 

Site Search:

Close

Close
Download Free Demo of VCE
Exam Simulator

Experience Avanset VCE Exam Simulator for yourself.


Simply submit your e-mail address below to get started with our interactive software demo of your free trial.


Enter Your Email Address

Free Demo Limits: In the demo version you will be able to access only first 5 questions from exam.