Using EIGRP with IPSEC encrypted GRE tunnels

In one of my last posts, GRE tunneling with IPSec encryption, i explained the setup of a simple ipsec-protected GRE connection.

When your network is a little bit larger than my test scenario, you would prefer to use an dynamic routing protocol between your routers (hilde and maria in my case).

Nothing easier than that….
Here’s an example using EIGRP:

gre_ipsec_eigrp

First, we will configure routing process “EIGRP 4711″ on both routers with this template:

router eigrp 4711
 eigrp log-neighbor-changes
 eigrp log-neighbor-warnings
 passive-interface default
 no passive-interface Tunnel1
 network 10.99.88.0 0.0.0.3
 no auto-summary

When both sides are configured, the following syslog message will appear on router maria indicating that the neighborship to hilde has been established

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 4711: Neighbor 10.99.88.2 (Tunnel1) is up: new adjacency

Verify, that only required interfaces take part at eigrp process 4711

maria#sh ip eigrp interfaces
IP-EIGRP interfaces for process 4711
                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Tu1                1        0/0       150      71/2572      2572           0
maria#
maria#
hilde#sh ip eigrp interfaces
IP-EIGRP interfaces for process 4711
                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Tu1                1        0/0       140      71/2572      2572           0
hilde#

Okay, that was the basic EIGRP configuration. But at that point, we don’t see any routes coming in.
To announce some routes, in EIGRP, we have to redistribute some routes in it (from connected, static or else…)
To keep it simple, we will start only with connected routes and a simple network statement.
When you used the example in GRE tunneling with IPSec encryption, please don’t forget to delete your static routes for network 172.16.1.0/24 (hilde) and 192.168.222.0/24  (maria), because they have a lower administrative distance than the incoming EIGRP route.

maria(config)#router eigrp 4711
maria(config-router)#no network 192.168.222.0 0.0.0.255
maria(config-router)#network 192.168.222.0 0.0.0.255
maria(config-router)#

Add the network statement for 172.16.1.0/24 in hildes EIGRP process 4711 in the same manner.

You can debug, if the route for 192.168.222.0/24 is installed in the global routing table of  hilde, or if the route 172.16.1.0/24 is announced out, you can do a little bit debugging…

hilde#debug ip eigrp
IP-EIGRP Route Events debugging is on
hilde#
*Mar  1 07:12:44.002: IP-EIGRP(Default-IP-Routing-Table:4711): Processing incoming UPDATE packet
*Mar  1 07:12:44.006: IP-EIGRP(Default-IP-Routing-Table:4711): Int 192.168.222.0/24 M 297270016 - 284444416 12825600 SM
281600 - 256000 25600
*Mar  1 07:12:44.010: IP-EIGRP(Default-IP-Routing-Table:4711): route installed for 192.168.222.0  ()
*Mar  1 07:20:38.402: IP-EIGRP(Default-IP-Routing-Table:4711): 172.16.1.0/24 - do advertise out Tunnel1
*Mar  1 07:20:38.406: IP-EIGRP(Default-IP-Routing-Table:4711): Int 172.16.1.0/24 metric 281600 - 256000 25600

After that, you will see the routes on both sides. The leading “D” indicates, that the route has been learned via EIGRP

maria#sh ip route eigrp
D       172.16.1.0/24 [90/297270016] via 10.99.88.2, 00:00:43, Tunnel1
maria#
hilde#sh ip route eigrp
D    192.168.222.0/24 [90/297270016] via 10.99.88.1, 00:03:40, Tunnel1
hilde#

You should also be able to ping/traceroute from 192.168.222.140 to hildes fa0/0 172.16.1.1 (sorry, i have still no host 172.16.1.x in my test setup).

debian:# ping -f 172.16.1.1
PING 172.16.1.1 (172.16.1.1) 56(84) bytes of data.
...            
--- 172.16.1.1 ping statistics ---
358 packets transmitted, 355 received, 0% packet loss, time 5123ms
rtt min/avg/max/mdev = 12.483/67.624/227.990/52.556 ms, pipe 16, ipg/ewma 14.350/24.426 ms
debian#

Adding EIGRP MD5 authentication (optional)

If you like to protect your routers from establishing EIGRP relationships to unwanted routers or  against attacks, you could add MD5 authentication on a per interface base.
Simply follow the next steps.

Creating a key chain

key chain KC_EIGRP_MD5_AUTH
 key 1
   key-string 0 Md5aUtH

Activate MD5 authentication for each Interface participating in EIGRP process 4711 (in my case, it’s just interface Tunnel1)

interface Tunnel1
 ip authentication mode eigrp 4711 md5
 ip authentication key-chain eigrp 4711 KC_EIGRP_MD5_AUTH

You could verify, if Tunnel1 is using MD5 authentication method by examining EIGRP interfaces

maria#sh ip eigrp 4711 interfaces detail
IP-EIGRP interfaces for process 4711
                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Tu1                1        0/0      1282      71/2727      2727           0
  Hello interval is 5 sec
  Next xmit serial <none>
  Un/reliable mcasts: 0/0  Un/reliable ucasts: 2/9
  Mcast exceptions: 0  CR packets: 0  ACKs suppressed: 5
  Retransmissions sent: 0  Out-of-sequence rcvd: 0
  Authentication mode is md5,  key-chain is "KC_EIGRP_MD5_AUTH"
  Use unicast
maria#

When hildes interface Tunnel1 isn’t configured for MD5 auth yet, you should see it with “debug eigrp packets”…

hilde#debug eigrp packets
EIGRP Packets debugging is on
    (UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
hilde#
*Mar  1 02:02:37.823: EIGRP: Sending HELLO on Tunnel1
*Mar  1 02:02:37.827:   AS 4711, Flags 0x0, Seq 0/0 idbQ 1/0 iidbQ un/rely 0/0
*Mar  1 02:02:40.587: EIGRP: Tunnel1: ignored packet from 10.99.88.1, opcode = 5 (authentication off or key-chain missing)

… and here’s the output for the case, that authentication key differs from the other side.

*Mar  1 02:13:40.911: EIGRP: Sending HELLO on Tunnel1
*Mar  1 02:13:40.911:   AS 4711, Flags 0x0, Seq 0/0 idbQ 1/0 iidbQ un/rely 0/0
*Mar  1 02:13:41.863: EIGRP: pkt key id = 1, authentication mismatch
*Mar  1 02:13:41.867: EIGRP: Tunnel1: ignored packet from 10.99.88.1, opcode = 5 (invalid authentication)

After adapting hildes configuration in an appropriate way, EIGRP relationship between Hilde and Maria will be established again

*Mar  1 02:29:59.479: EIGRP: Sending HELLO on Tunnel1
*Mar  1 02:29:59.479:   AS 4711, Flags 0x0, Seq 0/0 idbQ 1/0 iidbQ un/rely 0/0
*Mar  1 02:30:03.607: EIGRP: received packet with MD5 authentication, key id = 1
*Mar  1 02:30:03.611: EIGRP: Received HELLO on Tunnel1 nbr 10.99.88.1
*Mar  1 02:30:03.615:   AS 4711, Flags 0x0, Seq 0/0 idbQ 0/0
*Mar  1 02:30:03.619: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 4711: Neighbor 10.99.88.1 (Tunnel1) is up: new adjacency
*Mar  1 02:30:03.619: EIGRP: Enqueueing UPDATE on Tunnel1 nbr 10.99.88.1 iidbQ un/rely 0/1 peerQ un/rely 0/0
*Mar  1 02:30:03.627: EIGRP: Requeued unicast on Tunnel1
*Mar  1 02:30:03.627: EIGRP: Enqueueing UPDATE on Tunnel1 iidbQ un/rely 0/1 serno 1-1
*Mar  1 02:30:03.635: EIGRP: Sending UPDATE on Tunnel1 nbr 10.99.88.1
*Mar  1 02:30:03.639:   AS 4711, Flags 0x1, Seq 11/0 idbQ 1/0 iidbQ un/rely 0/1 peerQ un/rely 0/1
*Mar  1 02:30:03.655: EIGRP: Sending HELLO on Tunnel1
*Mar  1 02:30:03.659:   AS 4711, Flags 0x0, Seq 0/0 idbQ 1/0 iidbQ un/rely 0/1
*Mar  1 02:30:03.787: EIGRP: Enqueueing UPDATE on Tunnel1 nbr 10.99.88.1 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-1

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>