GRE configuration question

[bberry]

I am in the process of learing how to configure my first GRE tunnel and have a few questions. I know that I need to have a unique IP address for the tunnel on each end but am wondering if there are any standards or best practices for selecting this address. For example the VLANs of the remote are going to be something in the 192.168.0.0 space and I use say 10.2.4.0 network for my primary WAN connections and 10.2.6.0 network for the 3G backup connections so figure to use the corresponding IP address in say the 10.2.8.0 network for the GRE interfaces.

Secondly, I am going to have several GRE tunnels connecting on one end to the same router. (spoke & hub) Do I need unique tunnels for each connection or can they share the same endpoint? At most I am expecting to only have 6 to 8 GRE tunnels configured.

Lastly, Are their any limitations on the way I can redistribute routing tables into or out of the GRE tunnels. I gather that I simply need to consider the basic GRE tunnel simply as a connection and be able to run whatever routing protocol I need just as I do of this were a Frame Relay or MPLS connection.

Brent                     

[Kyle McKay]

1. For the IP addressing scheme, I would just select a brand new set of networks that have not been previously used. If you're using 10.x.x.x and 192.168.x.x - maybe go for 172.16.x.x

2. You could do this either way. You could create a GRE multipoint tunnel at your hub connecting to all of your remote sites - or you could create a seperate tunnel to each and every remote site. I would personally prefer the method of using a seperate tunnel for each connection if you have a small number of spokes.

3. You're right - you can run and extend your routing protocol through the GRE tunnels. In this way, you should establish a routing adjacency between the sites. Other than that there is no real specific configuration related to routing protocols.

You will however have to keep in mind a common issue related to routing via tunnel interfaces, called recursive routing. If configured improperly, the routing table could end up using the virtual tunnel interface as the next hop for the tunnel destination, thus breaking the connectivity (because, without the physical interfaces the tunnel doesn't really "go" anywhere on its own). To remedy this, you need to create static routes with a better AD than your routing protocol pointing to the tunnel destination, forcing the router to send packets to the tunnel destination through the physical interface and not the virtual tunnel interface.

Here is a great write up that will explain this concept a bit further:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094690.shtml

Hope this helps !

[bberry]

Do I need to do anything special to have EIGRP peer across the link? I have the tunnel up and I configured the same EIGRP group on both sides but as of yesterday afternoon I could not get them to peer with each other. Now that today is a fresh day, I am going to go back and verify that I did not miss anything when creating the groups.

Brent

[Kyle McKay]

Are you configuring all of the required EIGRP parameters such as "network" commands ?

Are both ends of the tunnel in the same subnet?

[bberry]

OK I configured EIGRP for both sides and am redistributing on the core side. I now have a flappng peer. I receive the Line protocol on Interface Tunnel1, changed state to up. I get the EIGRP-IPv4 20:Neighbor 10.2.8.2 (Tunnel1) ip up: new adjacency. Then I get %ADJ-5-Parent: Midchain parent maintenance for IP midchain out of tunnel1 - looped chain attempting to stack. and then Tunnel1 temporarily disabled due to recursive routing.

core side:

         router eigrp 20

          default-metric 10000 100 255 1 1500

          network 10.0.0.0

          network 172.16.0.0

          redistribute bgp 65000

remote side:

           router eigrp 20

          network 10.0.0.0

          network 192.168.124.0

          redistribute eigrp 10

EIGRP 10 is the routing protocol between the remote router and the remote core switch.

[Giuseppe Larosa]

Hello Brent,

>>  Tunnel1 temporarily disabled due to recursive routing.

This happens when you advertise the external IP addresses of the GRE tunnel ( tunnel source and tunnel destination) over EIGRP over the tunnel itself.

You need to avoid this to have a stable connection.

You need to use route-maps so that you can deny the IP subnets of GRE tunnel source and destination in order to avoid to advertise.

Or you can simply use distribute-list XX out interface tunnel YY to filter out the tunnel source -address you need to do this on both ends

Hope to help

Giuseppe

[Joseph W. Doherty]

Disclaimer

The     Author of this posting offers the information contained within this     posting without consideration and with the reader's understanding  that    there's no implied or expressed suitability or fitness for any   purpose.   Information provided is for informational purposes only and   should not   be construed as rendering professional advice of any kind.   Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In     no event shall Author be liable for any damages whatsoever   (including,   without limitation, damages for loss of use, data or   profit) arising  out  of the use or inability to use the posting's   information even if  Author  has been advised of the possibility of  such  damage.

Posting

Can you ping from one side of GRE tunnel to the other?

GRE tunnels will generally show up/up even when they don't have a valid connection between the GRE tunnel end-points.  (NB: tunnel keepalive can also be used to verify GRE tunnel is good, and take it down when it's not.)