Hmm, looks like the tunnel isn't working. From 192.168.16.1 I cannot ping 192.168.16.2 even though the tunnel shows up/up. It was working earlier. The ping just worked because of the default route... I'm confused. I followed the Cisco document and it worked at first. Weird.

Jake

The thing that stands out is that you have a problem in your crypto map. Notice the second line that says "incomplete". This is because the crypto map says to use access list 120. But from what you posted it looks like there is no access list 120 and there is access list 130.

crypto map vpn 10 ipsec-isakmp

! Incomplete

set peer 10.64.32.77

set transform-set strong

match address 120

It is not as serious, but depending on the version of code that you are running you probably should have the crypto map only on the physical interface and not on the tunnel interface. In older code (which was the basis for the example that you followed) the crypto map needed to be on both the tunnel and the physical interface. In more recent code it should be only on the physical interface.

Fix those things and let us know if it works better.

HTH

Rick

Thanks Rick. That worked to get the tunnel up and running, but now I'm trying to get EIGRP running across the tunnel and I get the following errors:

1w0d: %DUAL-5-NBRCHANGE: IP-EIGRP 64: Neighbor 192.168.16.1 (Tunnel0) is up: new adjacency

fake_wan_core#

1w0d: %DUAL-5-NBRCHANGE: IP-EIGRP 64: Neighbor 192.168.16.1 (Tunnel0) is down: holding time expired

fake_wan_core#

1w0d: %DUAL-5-NBRCHANGE: IP-EIGRP 64: Neighbor 192.168.16.1 (Tunnel0) is up: new adjacency

fake_wan_core#

1w0d: %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing

1w0d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down

1w0d: %DUAL-5-NBRCHANGE: IP-EIGRP 64: Neighbor 192.168.16.1 (Tunnel0) is down: interface down

Here is the current config:

Router 1:

ip subnet-zero

!

!

!

!

crypto isakmp policy 1

authentication pre-share

crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0

!

!

crypto ipsec transform-set strong esp-des esp-md5-hmac

mode transport

!

crypto map vpn 10 ipsec-isakmp

set peer 192.168.10.55

set transform-set strong

match address 130

!

call rsvp-sync

!

!

!

!

!

!

!

!

interface Tunnel0

ip address 192.168.16.2 255.255.255.0

tunnel source FastEthernet0/0

tunnel destination 192.168.10.55

!

interface FastEthernet0/0

description to_WAN

ip address 10.64.32.77 255.255.254.0

speed 100

full-duplex

crypto map vpn

!

interface Serial0/0

no ip address

shutdown

no fair-queue

!

interface BRI0/0

no ip address

encapsulation hdlc

shutdown

!

interface FastEthernet0/1

description private_lan

ip address 10.1.1.2 255.255.255.0

speed 100

full-duplex

!

router eigrp 64

network 10.0.0.0

network 192.168.16.0

no auto-summary

!

ip default-gateway 10.64.32.33

ip classless

ip route 0.0.0.0 0.0.0.0 10.64.32.33 name default_to_fw

ip route 10.1.1.0 255.255.255.0 FastEthernet0/1

ip http server

!

access-list 130 permit gre host 10.64.32.77 host 192.168.10.55

Router 2:

ip subnet-zero

no ip source-route

!

!

no ip domain-lookup

ip domain-name penson.cisco.com

!

!

crypto isakmp policy 1

authentication pre-share

crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0

!

!

crypto ipsec transform-set strong esp-des esp-md5-hmac

mode transport

!

crypto map vpn 10 ipsec-isakmp

set peer 10.64.32.77

set transform-set strong

match address 130

!

call rsvp-sync

!

!

!

!

!

!

!

!

interface Tunnel0

ip address 192.168.16.1 255.255.255.0

tunnel source FastEthernet0/0

tunnel destination 10.64.32.77

!

interface FastEthernet0/0

description to_firewall

ip address 192.168.10.55 255.255.255.0

no ip redirects

no ip unreachables

no ip proxy-arp

duplex auto

speed auto

crypto map vpn

!

interface FastEthernet0/1

no ip address

no ip redirects

no ip unreachables

no ip proxy-arp

shutdown

speed 100

full-duplex

!

router eigrp 64

network 192.168.10.0

network 192.168.16.0

no auto-summary

!

ip default-gateway 192.168.10.4

ip classless

ip route 0.0.0.0 0.0.0.0 192.168.10.4 name default_to_fw

no ip http server

!

access-list 130 permit gre host 192.168.10.55 host 10.64.32.77

Jake

The problem of recursive routing in fairly common when working with GRE tunnels. It happens frequently when the tunnel destination is advertised by the dynamic routing protocol running through the tunnel. The issue is that it makes it look like the best way to get to the tunnel destination is to go THROUGH the tunnel. When that happens the IOS does a temporary shutdown of the tunnel.

There are a couple of ways that you can fix this. You could configure a distribute list that denies the address of the tunnel destination (and permits other addresses) and put the distribute list in EIGRP inbound on the tunnel. Or you could configure a static route for the tunnel destination. The administrative distance of the static route will be better than the distance of EIGRP and so even though EIGRP may advertise the address of the destination through the tunnel, the static route will be used.

HTH

Rick

Thanks, Rick. I added the following and it seems to have cleared up the recursive routing, but now the 10.1.1.0 network is not propgating:

access-list 80 deny 192.168.16.0 0.0.0.255

router eigrp 64

no auto-summary

distribute-list 80 in

network 192.168.10.0

network 192.168.16.0

and on the other route:

access-list 80 deny 192.168.16.0 0.0.0.255

router eigrp 64

no auto-summary

distribute-list 80 in

network 10.0.0.0

network 192.168.16.0

Jake

I believe that you need to filter the updates received on the tunnel but not on the physical interface. I suggest that you change the config to this:

distribute-list 80 in tunnel0

Also in the access list 80 after you deny what you do not want, then you need to permit other routes so you should add:

access-list 80 permit any

HTH

Rick

That caused the recursive routing to come back. here are the configs:

Router 1:

p subnet-zero

!

!

!

!

crypto isakmp policy 1

authentication pre-share

crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0

!

!

crypto ipsec transform-set strong esp-des esp-md5-hmac

mode transport

!

crypto map vpn 10 ipsec-isakmp

set peer 192.168.10.55

set transform-set strong

match address 130

!

call rsvp-sync

!

!

!

!

!

!

!

!

interface Tunnel0

ip address 192.168.16.2 255.255.255.0

tunnel source FastEthernet0/0

tunnel destination 192.168.10.55

!

interface FastEthernet0/0

description to_WAN

ip address 10.64.32.77 255.255.254.0

speed 100

full-duplex

crypto map vpn

!

interface Serial0/0

no ip address

shutdown

no fair-queue

!

interface BRI0/0

no ip address

encapsulation hdlc

shutdown

!

interface FastEthernet0/1

description private_lan

ip address 10.1.1.2 255.255.255.0

speed 100

full-duplex

!

router eigrp 64

network 10.0.0.0

network 192.168.16.0

distribute-list 80 in Tunnel0

no auto-summary

!

ip default-gateway 10.64.32.33

ip classless

ip route 0.0.0.0 0.0.0.0 10.64.32.33 name default_to_fw

ip route 10.1.1.0 255.255.255.0 FastEthernet0/1

ip http server

!

access-list 80 deny 192.168.16.0 0.0.0.255

access-list 80 permit any

access-list 130 permit gre host 10.64.32.77 host 192.168.10.55

Router 2:

ip subnet-zero

no ip source-route

!

!

no ip domain-lookup

ip domain-name penson.cisco.com

!

!

crypto isakmp policy 1

authentication pre-share

crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0

!

!

crypto ipsec transform-set strong esp-des esp-md5-hmac

mode transport

!

crypto map vpn 10 ipsec-isakmp

set peer 10.64.32.77

set transform-set strong

match address 130

!

call rsvp-sync

!

!

!

!

!

!

!

!

interface Tunnel0

ip address 192.168.16.1 255.255.255.0

tunnel source FastEthernet0/0

tunnel destination 10.64.32.77

!

interface FastEthernet0/0

description to_firewall

ip address 192.168.10.55 255.255.255.0

no ip redirects

no ip unreachables

no ip proxy-arp

duplex auto

speed auto

crypto map vpn

!

interface FastEthernet0/1

no ip address

no ip redirects

no ip unreachables

no ip proxy-arp

shutdown

speed 100

full-duplex

!

router eigrp 64

network 192.168.10.0

network 192.168.16.0

distribute-list 80 in Tunnel0

no auto-summary

!

ip default-gateway 192.168.10.4

ip classless

ip route 0.0.0.0 0.0.0.0 192.168.10.4 name default_to_fw

no ip http server

!

no logging trap

logging source-interface FastEthernet0/0

access-list 80 deny 192.168.16.0 0.0.0.255

access-list 80 permit any

access-list 130 permit gre host 192.168.10.55 host 10.64.32.77

You're the man, Rick. That worked. This is a test environment, but for production I'll actually build a tunnel with a /30 from the WAN core to the LAN core across a firewall. That should work just as well as this /24, right? just change up the subnet masks?

Also, not sure if you're familiar, but I'll be building these tunnels from our WAN core across a firewall to two LAN cores running in HSRP. 2 Questions. First, is the encryption part of this tunnel necessary for EIGRP? and Second, would I just build seperate tunnels from the WAN core to each of the LAN cores and how will that work w/ HSRP?

Thanks a ton. You rock.

Jake

Thanks for marking this discussion as solved. (and for the rating) It makes the forum more useful when people can read about a problem and know that they will be able to read the thing that solved the problem.

Yes changing the masks should not be a problem.

The encryption part is not necessary for EIGRP. The important part for EIGRP is the point to point tunnel. Whether the traffic is encrypted or not does not matter to EIGRP. I dont know that it makes much difference to the firewall. As long as the firewall permits the traffic through it should work (whether the firewall is permitting ESP or permitting GRE - check with the firewall administrators and see if it matters to them).

I would advise building separate tunnels to each LAN core. I am not sure that HSRP affects things very much. If you just build the tunnels and let everything take default values then you should get mostly equal cost routes to all the destinations. If you have set the LAN cores so that one is generally preferred as the active router in HSRP you might want to increase the delay of the tunnel to the standby so that the EIGRP metrics through the tunnel to the active router look better than routes to the standby router.

HTH

Rick

I know we use our LAN cores in HSRP for both fault tolerance and load sharing. Half our VLANs are on one and the other half on the other. Also, since its EIGRP from WAN to LAN I'll go ahead and keep the encryption :).

Thanks again for the help.