[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 6130
  • Last Modified:

EIGRP over IPSEC Tunnel

I'm having trouble getting EIGRP to propogate the proper routes over the IPSEC tunnel.  Any help would be appreciated.

I have three routers. Hub, Spoke-A and Spoke-B.  Spoke-A and Spoke-B each have a ipsec tunnel to Hub.  Spoke-A and Spoke-B do not have a direct connection to each other.  I can ping Hub from Spoke-A and Spoke-B and I can ping each spoke from the hub.  I can apply static routes to each spoke which allows them to ping the other spoke via the Hub. When I remove the spoke-to-spoke static routes from the spokes and enable eigrp I get some eigrp related routes in the routing tables on my spokes but not the correct ones. For example, to route from Spoke 1 to spoke 2 I use static route 'ip route 192.168.49.0 255.255.255.0 10.168.13.1.  The route I see when eigrp is enabled is a route to the ipsec tunnel to the other spoke but not the spoke itself:
 D       10.168.49.0 via 10.168.13.1, 00:00:31, Tunnel1  
That is the correct gateway but not the routed subnet.  

Any hints would be appreciated.  

-----------------------------------
Here is my configuration for the Hub.  

version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname HUB

ip subnet-zero

ip inspect tcp max-incomplete host 250 block-time 3
ip inspect name fwout tcp
ip inspect name fwout udp
ip inspect name fwout ftp
ip inspect name fwout vdolive
ip inspect name fwout http
ip inspect name fwout netshow
ip inspect name fwout realaudio
ip audit attack action alarm drop
ip audit notify log
ip audit po max-events 100
ip audit smtp spam 25
ip audit name audit_fbnc attack action alarm
ip dhcp-client network-discovery informs 2 discovers 2
no ftp-server write-enable
!
crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2

crypto isakmp key MYKEY address 1.1.1.1 no-xauth
crypto isakmp key MYKEY address 2.2.2.2 no-xauth
crypto isakmp keepalive 300 5
crypto isakmp nat keepalive 20
!
!
crypto ipsec transform-set MYSTATIC esp-3des esp-sha-hmac
 mode transport
crypto ipsec transform-set MYTUNNEL esp-3des esp-sha-hmac
!
crypto map MYNETWORK 113 ipsec-isakmp
 set peer 2.2.2.2
 set transform-set MYTUNNEL
 match address 113
crypto map MYNETWORK 149 ipsec-isakmp
 set peer 1.1.1.1
 set transform-set MYTUNNEL
 match address 149
!
!
interface Tunnel0
 ip address 10.168.49.1 255.255.255.0
 tunnel source Ethernet1/0
 tunnel destination 1.1.1.1
 crypto map MYNETWORK
!
interface Tunnel1
 ip address 10.168.13.1 255.255.255.0
 tunnel source Ethernet1/0
 tunnel destination 2.2.2.2
 crypto map MYNETWORK
!
interface FastEthernet0/0
 description connects to internal lan
 ip address 192.168.4.254 255.255.255.0
 ip nat inside
 ip inspect fwout in
 service-policy input mark-inbound-hacks
 ip tcp adjust-mss 1300
 ip policy route-map NoNatVpnClient
 no ip mroute-cache
 speed auto
 no cdp enable
!
interface Ethernet1/0
 ip address 4.4.4.4 255.255.255.248
 ip access-group 193 in
 ip nat outside
 ip inspect fwout out
 ip audit audit_fbnc in
 service-policy input mark-inbound-hacks
 no ip mroute-cache
 full-duplex
 no cdp enable
 crypto map MYNETWORK
!
router eigrp 60
 auto-summary
 network 192.168.0.0
 network 10.168.0.0 0.0.255.255
 no auto-summary
 no eigrp log-neighbor-changes
!
ip nat inside source route-map NoNatLAN interface Ethernet1/0 overload
ip classless
ip route 0.0.0.0 0.0.0.0 4.4.4.3
ip route 192.168.13.0 255.255.255.0 10.168.13.2
ip route 192.168.49.0 255.255.255.0 10.168.49.2
no ip http server
no ip http secure-server
!
!
access-list 113 permit gre host 4.4.4.4 host 2.2.2.2
access-list 149 permit gre host 4.4.4.4 host 1.1.1.1

access-list 193 permit gre any any
access-list 193 permit esp any any
access-list 193 permit udp any any eq isakmp
access-list 193 permit icmp any any
access-list 193 permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
access-list 193 permit udp any any eq non500-isakmp

access-list 199 remark (INTERESTING TRAFFIC FOR LAN IPSEC VPN - not NATed)
access-list 199 permit ip 192.168.4.0 0.0.0.255 any
!
route-map NoNatLAN permit 10
 match ip address 199
!
end


-----------------------------------------------------------
Spoke 1

version 12.4
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service password-encryption
service sequence-numbers
!
hostname spoke1
!
!
no aaa new-model
!
resource policy
!
ip subnet-zero
no ip source-route
no ip cef
!
!
ip tcp synwait-time 10
no ip bootp server
ip ssh time-out 60
ip ssh authentication-retries 2
ip inspect name DEFAULT100 cuseeme
ip inspect name DEFAULT100 ftp
ip inspect name DEFAULT100 h323
ip inspect name DEFAULT100 icmp
ip inspect name DEFAULT100 netshow
ip inspect name DEFAULT100 rcmd
ip inspect name DEFAULT100 realaudio
ip inspect name DEFAULT100 rtsp
ip inspect name DEFAULT100 esmtp
ip inspect name DEFAULT100 sqlnet
ip inspect name DEFAULT100 streamworks
ip inspect name DEFAULT100 tftp
ip inspect name DEFAULT100 tcp
ip inspect name DEFAULT100 udp
ip inspect name DEFAULT100 vdolive
ip inspect name DEFAULT100 telnet
!
!
crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key MYKEY address 4.4.4.4
crypto isakmp keepalive 300 5
crypto isakmp nat keepalive 20
!
!
crypto ipsec transform-set MYSTATIC esp-3des esp-sha-hmac
 mode transport
crypto ipsec transform-set MYTUNNEL esp-3des esp-sha-hmac
!
crypto map MYNETWORK 104 ipsec-isakmp
 set peer 4.4.4.4
 set transform-set MYTUNNEL
 match address 104
!
!
!
!
interface Tunnel1
 ip address 10.168.13.2 255.255.255.0
 tunnel source FastEthernet4
 tunnel destination 4.4.4.4
 crypto map MYNETWORK
!
interface FastEthernet0
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
!
interface FastEthernet4
 ip address 2.2.2.2 255.255.255.252
 ip access-group Outside_In in
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat outside
 ip virtual-reassembly
 no ip route-cache
 ip tcp adjust-mss 1450
 duplex auto
 speed auto
 crypto map MYNETWORK
!
interface Vlan1
 ip address 192.168.13.254 255.255.255.0
 ip nat inside
 ip inspect DEFAULT100 in
 no ip virtual-reassembly
 no ip route-cache
 ip tcp adjust-mss 1300
!!
router eigrp 60
 auto-summary
 network 192.168.0.0
 network 10.168.0.0 0.0.255.255
 no auto-summary
 no eigrp log-neighbor-changes
!
ip classless
ip route 0.0.0.0 0.0.0.0 2.2.2.1
ip route 192.168.4.0 255.255.255.0 10.168.13.1
!
!
ip http server
ip http authentication local
ip http secure-server
ip http timeout-policy idle 600 life 86400 requests 10000
ip nat pool lfs_nat_pool 2.2.2.2 2.2.2.2 netmask 255.255.255.252
ip nat inside source route-map NoNatLAN pool lfs_nat_pool overload
!
ip access-list extended Outside_In
 permit gre any any
 permit esp any any
 permit udp any any eq isakmp
 permit udp any any eq non500-isakmp
 permit icmp any any echo-reply
 permit icmp any any echo
 permit icmp any any time-exceeded
 permit icmp any any traceroute
 permit ip 192.168.0.0 0.0.255.255 192.168.13.0 0.0.0.255
!
logging trap debugging
access-list 104 permit gre host 2.2.2.2 host 4.4.4.4
access-list 197 permit ip 192.168.13.0 0.0.0.255 any
no cdp run
!
route-map NoNatLAN permit 10
 match ip address 197
!
end


---------------------------------------------------------------------
spoke 2

version 12.4
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service password-encryption
service sequence-numbers
!
hostname spoke2
!
boot-start-marker
boot-end-marker
!
no aaa new-model
!
resource policy
!
ip subnet-zero
no ip source-route
ip cef
!
!
ip tcp synwait-time 10
no ip bootp server
ip ssh time-out 60
ip ssh authentication-retries 2
ip inspect name DEFAULT100 cuseeme
ip inspect name DEFAULT100 ftp
ip inspect name DEFAULT100 h323
ip inspect name DEFAULT100 icmp
ip inspect name DEFAULT100 rcmd
ip inspect name DEFAULT100 realaudio
ip inspect name DEFAULT100 rtsp
ip inspect name DEFAULT100 esmtp
ip inspect name DEFAULT100 sqlnet
ip inspect name DEFAULT100 streamworks
ip inspect name DEFAULT100 tftp
ip inspect name DEFAULT100 tcp
ip inspect name DEFAULT100 udp
ip inspect name DEFAULT100 vdolive
ip inspect name DEFAULT100 telnet
!!
crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key MYKEY address 4.4.4.4 no-xauth
crypto isakmp keepalive 300 5
crypto isakmp nat keepalive 20
!
!
crypto ipsec transform-set MYSTATIC esp-3des esp-sha-hmac
 mode transport
crypto ipsec transform-set MYTUNNEL esp-3des esp-sha-hmac
!
crypto map MYNETWORK 104 ipsec-isakmp
 set peer 4.4.4.4
 set transform-set MYTUNNEL
 match address 104
!
bridge irb
!
interface Tunnel0
 ip address 10.168.49.2 255.255.255.0
 tunnel source FastEthernet4
 tunnel destination 4.4.4.4
 crypto map MYNETWORK
!
interface FastEthernet0
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
!
interface FastEthernet4
 ip address 1.1.1.1 255.255.255.252
 ip access-group Outside_In in
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat outside
 ip virtual-reassembly
 ip tcp adjust-mss 1450
 duplex auto
 speed auto
 crypto map MYNETWORK
!
!
interface BVI1
 ip address 192.168.49.254 255.255.255.0
 ip nat inside
 ip inspect DEFAULT100 in
 no ip virtual-reassembly
 ip tcp adjust-mss 1300
!
router eigrp 60
 auto-summary
 network 192.168.0.0
 network 10.168.0.0 0.0.255.255
 no auto-summary
 no eigrp log-neighbor-changes
!
ip classless
ip route 0.0.0.0 0.0.0.0 1.1.1.2
ip route 192.168.4.0 255.255.255.0 10.168.49.1
!
!
ip http server
ip http authentication local
ip http secure-server
ip http timeout-policy idle 5 life 86400 requests 10000
ip nat pool lfs_nat_pool 1.1.1.1 1.1.1.1 netmask 255.255.255.252
ip nat inside source route-map NoNatLAN pool lfs_nat_pool overload
!

ip access-list extended Outside_In
 permit gre any any
 permit esp any any
 permit udp any any eq isakmp
 permit udp any any eq non500-isakmp
 permit icmp any any echo-reply
 permit icmp any any echo
 permit icmp any any time-exceeded
 permit icmp any any traceroute
 permit ip 192.168.0.0 0.0.255.255 192.168.49.0 0.0.0.255
!
access-list 104 permit gre host 1.1.1.1 host 4.4.4.4
access-list 197 permit ip 192.168.49.0 0.0.0.255 any
no cdp run
!
route-map NoNatLAN permit 10
 match ip address 197
!
bridge 1 protocol ieee
bridge 1 route ip
banner login ^CCC
!
end

0
lfscarolinas
Asked:
lfscarolinas
  • 13
  • 12
  • 4
  • +1
1 Solution
 
stressedout2004Commented:
Do the following changes:

1) On the hub and each spoke, delete all static routes.

Hub:

no ip route 192.168.13.0 255.255.255.0 10.168.13.2
no ip route 192.168.49.0 255.255.255.0 10.168.49.2

Spoke1:

no ip route 192.168.4.0 255.255.255.0 10.168.13.1

Spoke2:

no ip route 192.168.4.0 255.255.255.0 10.168.49.1

2) Modify the EIGRP process on all three routers:

On Hub:

no router eigrp 60
router eigrp 60
 auto-summary
 network 192.168.0.0 0.0.255.255
 no eigrp log-neighbor-changes

Spoke1:

no router eigrp 60
router eigrp 60
 auto-summary
 network 192.168.0.0 0.0.255.255
 no eigrp log-neighbor-changes

Spoke2:

no router eigrp 60
router eigrp 60
 auto-summary
 network 192.168.0.0
 no eigrp log-neighbor-changes
0
 
mikebernhardtCommented:
The main trick here is that you need to use non-eigrp routes to connect your tunnel endpoints. Otherwise the tunnel will flap. So use static routes to get the tunnel up, then configure eigrp to advertise the routes. The main problem with your current eigrp config, as stressed out illustrates, is that you are only advertising 192.168.0.0/24 because you don't have the wildcard bits in the config.
0
 
logic0004Commented:
Well, I think u know how to configure the stuff , so i wont include the commands but u might need to take out EIGRP and use OSPF and no troubles then...
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
logic0004Commented:
0
 
mikebernhardtCommented:
EIGRP will work fine- I did this myself a few years back, and we actually changed from OSPf to EIGRP because we needed to put a distribute-list into EIGRP so it wouldn't send the routes to the tunnel endpoints. OSPF was harder to control (although I know how to do it now...).
0
 
lfscarolinasAuthor Commented:
I tried stressedout's suggestion and no eigrp neighbors were seen and no routes were being propogated. I could also no longer ping the hub from the spokes and vice-versa.  

I followed mikebernhardts suggestion and put the non-eigrp routes back in for my endpoints
192.168.0.0 0.0.255.255 in for my network.  I can now ping the hub a from the spokes.  When I sho ip route:
10.168.49.0  via 10.168.13.1, 00:06:50, Tunnel1

so my hub router has propogated the route to the tunnel in the opposite spoke but the the spoke itself.  

Now my router configs are the same as I posted originally with this exception:
router eigrp 60
 auto-summary
 network 192.168.0.0 0.0.255.255
 network 10.168.0.0 0.0.255.255
 no auto-summary
 no eigrp log-neighbor-changes

i tried it without the 10.168.0.0 network but then no neighbors were shown or routes propogated.  
0
 
mikebernhardtCommented:
So is the problem that the spokes can't ping each other?
1. did you add the wildcard bits to 192.168.0.0 on all 3 routers?
2. Try turning off auto-summary in eigrp:
     router eigrp 60
      no auto-summary

0
 
stressedout2004Commented:
lfscarolinas, Im very sorry, that code wasn't for you. It was for another customer. Thats what happens when you have so many windows open = (. On a GRE, GRE/IPSEC or DMVPN network, you always need to include the IP subnet of the tunnel interface for routes to propagate which is why no routes where propagated when you apply the codes I gave you.

You should have something like these minus the static routes that you have. As mike suggested, make sure auto-summary is off on each process and clear the eigrp to make sure the changes takes effect using the command
clear ip eigrp neighbors :

Hub:

router eigrp 60
 network 10.168.0.0 0.0.255.255
 network 192.168.4.0
 no auto-summary
 no eigrp log-neighbor-changes


Spoke1:

router eigrp 60
 network 10.168.0.0 0.0.255.255
 network 192.168.13.0
 no auto-summary
 no eigrp log-neighbor-changes

Spoke2:

router eigrp 60
 network 10.168.0.0 0.0.255.255
 network 192.168.49.0
 no auto-summary
 no eigrp log-neighbor-changes

When you do "sh ip route", you should see something like these:

On hub:

D    192.168.13.0/24 [x/y] via 10.168.13.2, Tunnel1
D    192.168.49.0/24 [x/y] via 10.168.49.2, Tunnel0

On spoke1:

D    192.168.4.0/24 [x/y] via 10.168.13.1, Tunnel1
D    192.168.49.0/24 [x/y] via 10.168.13.1, Tunnel1

On spoke2:

D    192.168.4.0/24 [x/y] via 10.168.49.1, Tunnel0
D    192.168.13.0/24 [x/y] via 10.168.49.1, Tunnel0
0
 
lfscarolinasAuthor Commented:
mike,
Correct.  The spokes are unable to ping each other when I'm using eigrp, the routes aren't in the routing table.  I can apply a static route to each spoke and they can ping each other just fine.  
The second eigrp config I put in my previous was incorrect.  I already had 'no auto-summary'  I'm not sure how 'auto-summary' got in there.  Anyway, I verified 'no auto-summary' on all three routers.  The wildcard bits were  on all there routers as well.  This is the  eigrp config on all three routers.  So take my initial config and replace the 'router' sections with this and it is exacly what I am running now.

router eigrp 60
 network 192.168.0.0 0.0.255.255
 network 10.168.0.0 0.0.255.255
 no auto-summary
 no eigrp log-neighbor-changes


Could there be a IOS version problem on my hub? I'm running 12.3.  I'm getting some EIGRP routes on my spokes but they are the ip tunnels.  So I know that eigrp is communication across my GRE tunnel.  

stressed,
I had tried that config before but thought I'd give it another whirl.  No luck.  The only EIGRP routes I see are for the spokes.

spoke 1
D       10.168.49.0 [90/310044416] via 10.168.13.1, 00:00:06, Tunnel1

spoke 2
D       10.168.13.0 [] via 10.168.49.1, 00:00:43, Tunnel0

These are the same D routes I see when I put network 192.168.0.0 0.0.255.255 in the eigrp config.  So far this is the most I have been able to get.
0
 
stressedout2004Commented:
It could be an IOS problem. The config looks good. Is there anyway you can upgrade the hub to 12.4? I am thinking that maybe since both spokes have higher version than the hub, eigrp is not properly propagating. Normally, the IOS version shouldn't matter but then it could be a bug on the IOS.
0
 
mikebernhardtCommented:
Try this on the hub:
interface ethernet1/0
no ip split-horizon eigrp 60

Since both tunnels terminate on the same ethernet interface, split horizon may be stopping the hub from sending eigrp updates from one spoke back out to the other...
0
 
lfscarolinasAuthor Commented:
Mike,
That didn't do it either.  
0
 
lfscarolinasAuthor Commented:
How about debuging?  Are there any specific debug methods I can use to see what is happening?  
0
 
mikebernhardtCommented:
I just realized it couldn't be split horizon because if I am correct, you don't get the hub LAN at either of the spokes? This says that LAN routes aren't getting through the tunnel

Did you verify that your 192.168 network statements are now classful (in other words, drop the wildcard bits) as suggested by stressesout2004 in his last config post? Maybe using a supernet mask doesn't work.
0
 
stressedout2004Commented:
You can try turning on the following debugs and check if you see something unusual. If not, I will go for an upgrade, because as far as the configuration is concern, everything should be fine if you said you tried several flavors of subnet mask:

debug ip eigrp
debug ip eigrp notifications
0
 
lfscarolinasAuthor Commented:
Mike,
I tried the config suggested by stressed each without the wildcard bits.  

I'm going to try a different hub router.  I have something with 12.4 on it that I can work the config up on in a jiffy.

Thanks.  
0
 
mikebernhardtCommented:
So on the hub router, do you see all the routes you expect right now, and their not getting to the spokes? Or is it not complete either?
0
 
lfscarolinasAuthor Commented:
Mike,
Yes, on the hub router I see all of the routes I expect.  There is a route to each of the spokes:
S    192.168.13.0/24 [1/0] via 10.168.13.2
C    192.168.4.0/24 is directly connected, FastEthernet0/0
     10.0.0.0/24 is subnetted, 2 subnets
C       10.168.49.0 is directly connected, Tunnel0
C       10.168.13.0 is directly connected, Tunnel1
S    192.168.49.0/24 [1/0] via 10.168.49.2

I can ping each spoke from my hub and I can ping the hub from each spoke.  
0
 
mikebernhardtCommented:
Yes, but those are static routes. What about in EIGRP? We need to see if EIGRP is working properly on the hub.

I just noticed something strange on Spoke 2 though. On Spoke 1, you have the IP address on VLAN1 which is fine. But on Spoke 2, you are using IRB and the LAN IP is on BVI1, but no interfaces are assigned to bridge-group 1. What's up with that? If that is indeed the configuration, I'm surprised that the LAN works there at all. Try miving the IP address to interface Vlan1 as on Spoke 1 and get rid of IRB.
0
 
lfscarolinasAuthor Commented:
Mike,

What EIGRP routes should I be expecting on my hub?  Each of my spokes is directly connected to my hub via a static route.  I didn't think I would see any EIGRP routes on my hub because it is already has all of the routes in my scope 192.168.0.0 definded statically.  

'sho ip eigrp neighbors' on the hub:
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   10.168.13.2             Tu1               10 02:13:00  613  5000  0  62
0   10.168.49.2             Tu0               10 2d01h       1  4500  0  24

 'sho ip eigrp topology' on the hub prints this:
P 192.168.49.0/24, 0 successors, FD is Inaccessible
         via 10.168.49.2 (297372416/175360), Tunnel0
P 192.168.13.0/24, 0 successors, FD is Inaccessible
         via 10.168.13.2 (297246976/28160), Tunnel1
P 192.168.4.0/24, 1 successors, FD is 28160
         via Connected, FastEthernet0/0
P 10.168.49.0/24, 1 successors, FD is 297244416
         via Connected, Tunnel0
P 10.168.13.0/24, 1 successors, FD is 297244416
         via Connected, Tunnel1


sho ip eigrp topology on spoke1
P 192.168.13.0/24, 1 successors, FD is 28160
        via Connected, Vlan1
P 192.168.4.0/24, 0 successors, FD is Inaccessible
        via 10.168.13.1 (297246976/28160), Tunnel1
P 10.168.49.0/24, 1 successors, FD is 310044416
        via 10.168.13.1 (310044416/297244416), Tunnel1
P 10.168.13.0/24, 1 successors, FD is 297244416
        via Connected, Tunnel1

sho ip eigrp neighbors on spoke 1:
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   10.168.13.1             Tu1               10 00:05:01   72  5000  0  35


sho ip eigrp topology on spoke 2
P 192.168.49.0/24, 1 successors, FD is 175360
        via Connected, BVI1
P 192.168.4.0/24, 0 successors, FD is Inaccessible
        via 10.168.49.1 (297246976/28160), Tunnel0
P 10.168.49.0/24, 1 successors, FD is 297244416
        via Connected, Tunnel0
P 10.168.13.0/24, 1 successors, FD is 310044416
        via 10.168.49.1 (310044416/297244416), Tunnel0

sho ip eigrp neighbors on spoke 2
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   10.168.49.1             Tu0               12 2d02h     142  5000  0  19


Those interfaces are there on spoke 2.  I accidently pulled them out when sanitizing my configuration for public posting.  

interface Dot11Radio0
 no ip address
 !
 encryption key 1 size 128bit 7 *** transmit-key
 encryption mode wep mandatory
 !
 ssid ***
    authentication open
 !
 speed basic-1.0 2.0 5.5 6.0 9.0 11.0 12.0 18.0 24.0 36.0 48.0 54.0
 station-role root
 no cdp enable
 bridge-group 1
 bridge-group 1 subscriber-loop-control
 bridge-group 1 spanning-disabled
 bridge-group 1 block-unknown-source
 no bridge-group 1 source-learning
 no bridge-group 1 unicast-flooding
!
interface Vlan1
 no ip address
 ip tcp adjust-mss 1452
 bridge-group 1
0
 
mikebernhardtCommented:
OK, that makes more sense on the IRB!

If you look at your EIGRP topology output, you can see that the routes you need are "Inaccessible" on the hub and spokes. You are correct, you wouldn't see them on the hub with the static route defined with "show ip route" but your topology indicates that they wouldn't work anyway.

I keep thinking that is has something to do with what's being allowed in the gre or crypto tunnels.

Try (just on the hub for now)
debug ip eigrp
debug ip eigrp neighbor'
debug ip eigrp notifications
Then type clear ip route *

We need to see why those routes are inaccessible. If you're not on the console, type term mon so you can see the output in your telnet session.
0
 
lfscarolinasAuthor Commented:
Mike,
I applied the debug statements and did a 'clear ip route *'

the output:  I removed most of the date and replace "Default-IP-Routing-Table:60" with DIPRT:60 in an attempt to save line space and keep the output from wrapping:
08.226: IP-EIGRP(DIPRT:60): Callback: route_adjust FastEthernet0/0
08.226: IP-EIGRP(DIPRT:60): Callback: route_adjust Tunnel0
08.226: IP-EIGRP(DIPRT:60): Callback: route_adjust Tunnel1
08.226: IP-EIGRP(DIPRT:60): Callback: reload_iptable
08.254: IP-EIGRP(DIPRT:60): 192.168.49.0/24 - doadvertise out Tunnel1
08.254: IP-EIGRP(DIPRT:60): Int 192.168.49.0/24metric 297372416 - 284444416 12928000
08.254: IP-EIGRP(DIPRT:60): Int 192.168.13.0/24 metric 297246976 - 284444416 12802560
08.254: IP-EIGRP(DIPRT:60): Int 192.168.49.0/24 metric 297372416 - 284444416 12928000
08.254: IP-EIGRP(DIPRT:60): 192.168.13.0/24 - do advertise out Tunnel0
08.254: IP-EIGRP(DIPRT:60): Int 192.168.13.0/24 metric 297246976 - 284444416 12802560
09.235: IP-EIGRP(DIPRT:60): iptable_redistribute into eigrp
11.255: IP-EIGRP(DIPRT:60): 192.168.49.0/24 - do advertise out Tunnel1
11.255: IP-EIGRP(DIPRT:60): Int 192.168.49.0/24 metric 297372416 - 284444416 12928000
11.255: IP-EIGRP(DIPRT:60): Int 192.168.13.0/24 metric 297246976 - 284444416 12802560
11.259: IP-EIGRP(DIPRT:60): Int 192.168.49.0/24 metric 297372416 - 284444416 12928000
11.259: IP-EIGRP(DIPRT:60): 192.168.13.0/24 - do advertise out Tunnel0
11.259: IP-EIGRP(DIPRT:60): Int 192.168.13.0/24 metric 297246976 - 284444416 12802560
13.226: IP-EIGRP(DIPRT:60): Callback: lostroute 192.168.49.0/24
13.226: IP-EIGRP(DIPRT:60): Callback: lostroute 192.168.13.0/24
15.762: IP-EIGRP(DIPRT:60): 192.168.49.0/24 - do advertise out Tunnel1
15.762: IP-EIGRP(DIPRT:60): Int 192.168.49.0/24 metric 4294967295 - 284444416 4294967295
15.762: IP-EIGRP(DIPRT:60): 192.168.13.0/24 - do advertise out Tunnel1
15.762: IP-EIGRP(DIPRT:60): Int 192.168.13.0/24 metric 4294967295 - 284444416 4294967295
15.766: IP-EIGRP(DIPRT:60): 192.168.49.0/24 - do advertise out Tunnel0
15.770: IP-EIGRP(DIPRT:60): Int 192.168.49.0/24 metric 4294967295 - 284444416 4294967295
15.770: IP-EIGRP(DIPRT:60): 192.168.13.0/24 - do advertise out Tunnel0
15.774: IP-EIGRP(DIPRT:60): Int 192.168.13.0/24 metric 4294967295 - 284444416 4294967295
15.902: IP-EIGRP(DIPRT:60): Processing incoming REPLY packet
15.906: IP-EIGRP(DIPRT:60): Int 192.168.49.0/24 M 4294967295 - 0 4294967295 SM 4294967295 - 0 4294967295
15.906: IP-EIGRP(DIPRT:60): Int 192.168.13.0/24 M 297246976 - 284444416 12802560 SM 28160 - 25600 2560
15.922: IP-EIGRP(DIPRT:60): Processing incoming REPLY packet

I then tried "clear ip eigrp neighbors"
The output:
26.904: EIGRP: Holdtime expired
26.904: EIGRP: Neighbor 10.168.49.2 went down on Tunnel0
26.904: EIGRP: Holdtime expired
26.904: EIGRP: Neighbor 10.168.13.2 went down on Tunnel1
27.645: EIGRP: New peer 10.168.49.2
27.653: IP-EIGRP(DIPRT:60): 10.168.49.0/24 - do advertise out Tunnel0
27.653: IP-EIGRP(DIPRT:60): 10.168.13.0/24 - do advertise out Tunnel0
27.653: IP-EIGRP(DIPRT:60): Int 10.168.13.0/24 metric 297244416 - 284444416 12800000
27.653: IP-EIGRP(DIPRT:60): 192.168.4.0/24 - do advertise out Tunnel0
27.653: IP-EIGRP(DIPRT:60): Int 192.168.4.0/24 metric 28160 - 25600 2560
28.234: IP-EIGRP(DIPRT:60): Processing incoming UPDATE packet
29.183: EIGRP: New peer 10.168.13.2
29.191: IP-EIGRP(DIPRT:60): 10.168.49.0/24 - do advertise out Tunnel1
29.191: IP-EIGRP(DIPRT:60): Int 10.168.49.0/24 metric 297244416 - 284444416 12800000
29.191: IP-EIGRP(DIPRT:60): 10.168.13.0/24 - do advertise out Tunnel1
29.191: IP-EIGRP(DIPRT:60): 192.168.4.0/24 - do advertise out Tunnel1
29.191: IP-EIGRP(DIPRT:60): Int 192.168.4.0/24 metric 28160 - 25600 2560
29.656: IP-EIGRP(DIPRT:60): 10.168.49.0/24 - do advertise out Tunnel0
29.656: IP-EIGRP(DIPRT:60): 10.168.13.0/24 - do advertise out Tunnel0
29.656: IP-EIGRP(DIPRT:60): Int 10.168.13.0/24 metric 297244416 - 284444416 12800000
29.656: IP-EIGRP(DIPRT:60): 192.168.4.0/24 - do advertise out Tunnel0
29.656: IP-EIGRP(DIPRT:60): Int 192.168.4.0/24 metric 28160 - 25600 2560
29.740: IP-EIGRP(DIPRT:60): Processing incoming UPDATE packet
29.740: IP-EIGRP(DIPRT:60): Int 192.168.49.0/24 M 297372416 - 284444416 12928000 SM 175360 - 47360 128000
29.740: IP-EIGRP(DIPRT:60): 192.168.49.0/24 routing table not updated
29.897: IP-EIGRP(DIPRT:60): Processing incoming UPDATE packet
29.897: IP-EIGRP(DIPRT:60): Int 10.168.13.0/24 M 4294967295 - 284444416 4294967295 SM 4294967295 - 284444416 4294967295
30.257: IP-EIGRP(DIPRT:60): Processing incoming UPDATE packet
31.195: IP-EIGRP(DIPRT:60): 10.168.49.0/24 - do advertise out Tunnel1
31.195: IP-EIGRP(DIPRT:60): Int 10.168.49.0/24 metric 297244416 - 284444416 12800000
31.195: IP-EIGRP(DIPRT:60): 10.168.13.0/24 - do advertise out Tunnel1
31.195: IP-EIGRP(DIPRT:60): 192.168.4.0/24 - do advertise out Tunnel1
31.195: IP-EIGRP(DIPRT:60): Int 192.168.4.0/24 metric 28160 - 25600 2560
31.271: IP-EIGRP(DIPRT:60): Processing incoming UPDATE packet
31.275: IP-EIGRP(DIPRT:60): Int 192.168.13.0/24 M 297246976 - 284444416 12802560 SM 28160 - 25600 2560
31.275: IP-EIGRP(DIPRT:60): 192.168.13.0/24 routing table not updated
31.427: IP-EIGRP(DIPRT:60): Processing incoming UPDATE packet
31.427: IP-EIGRP(DIPRT:60): Int 10.168.49.0/24 M 4294967295 - 284444416 4294967295 SM 4294967295 - 284444416 4294967295

It says my route table was not updated but I don't know why.
0
 
mikebernhardtCommented:
I'll have to look into what the above means exactly. I do know from the topology output and the above that the routes are being advertised, so that isn't the problem. But for some reason the metrics are so high that the routers are rejecting them:

P 192.168.13.0/24, 0 successors, FD is Inaccessible
         via 10.168.13.2 (297246976/28160), Tunnel1

31.271: IP-EIGRP(DIPRT:60): Processing incoming UPDATE packet
31.275: IP-EIGRP(DIPRT:60): Int 192.168.13.0/24 M 297246976 - 284444416 12802560 SM 28160 - 25600 2560
31.275: IP-EIGRP(DIPRT:60): 192.168.13.0/24 routing table not updated

One thing I was just thinking- you should do this anyway- is to set the bandwidth on the tunnel interfaces to the actual bandwidth. If it's fast ethernet, then make it 100000. EIGRP sets it's metrics accordingly. At the very least it will make the numbers smaller :-)

You might also set the mtu on the tunnel interfaces down a bit-- to like 1440 or so-- since you have so much encapsulation going on. this would help reduce possible retransmissions.
0
 
lfscarolinasAuthor Commented:
Do you mean set the bandwidth on the physical interface the tunnel is on, such as FE1 or Eth0  or do you mean set the bandwith within tunnel0 or tunnel1?  
0
 
mikebernhardtCommented:
I mean on the tunnel interface itself. I read somewhere that the default bandwidth for calculation purposes on a tunnel interface is like 9kbps. Set it to the actual minimum bandwidth from one end to the other.

Looking at your config one more time, your physical link addressing doesn't line up on the FastE interfaces. Does that mean there are other routers in between?

I was looking over this document:
http://www.cisco.com/en/US/customer/tech/tk583/tk372/technologies_configuration_example09186a008009438e.shtml

It looks like that must have been your reference? You're even using the same EIGRP AS number.
0
 
lfscarolinasAuthor Commented:
Yes, that was one of my references. I used several.

My physical interfaces don't line up because each of these routers is connected publically to the internet, not to each other.  They communicate via the IPSEC tunnels whose ip addresses should line up.   If I am understanding what you are asking, anyway.  

I applied the minimum bandwith to each of the tunnels.  

One the spoke I type: clear ip eigrp neighbors and this set of debug statements is seen:  
IP-EIGRP(Default-IP-Routing-Table:60): Int 192.168.4.0/24 M 16135680 - 3333120 12802560 SM 28160 - 25600 2560
IP-EIGRP(Default-IP-Routing-Table:60): 192.168.4.0/24 routing table not updated thru 10.168.49.1

along with:
 IP-EIGRP(Default-IP-Routing-Table:60): Int 10.168.13.0/24 M 28933120 - 3333120 25600000 SM 16133120 - 3333120 12800000
IP-EIGRP(Default-IP-Routing-Table:60): route installed for 10.168.13.0  ()

So if I am understanding this correctly my neighbors are being established, adjacancy is being set up and my routes are being advertised.  The routes related to the IPSEC tunnels on the other spoke are being installed while the routes for the 192.168.4.0/24 subnet are not.  This sort of makes sense since I have static routes from the spoke to the hub (192.168.4.0/24) defined.  One thing I do not see advertised are routes to the other spoke in the 192.168.13.0.24 range.  These are the routes that I need.  So if I'm understanding this correctly I need to figure out why the 192.168.13.0/24 routes are not being advertised.

I can't find any documentation that tells me what all of these numbers mean:
M 28933120 - 3333120 25600000 SM 16133120 - 3333120 12800000

If you know of any can you point me toward them?  
0
 
lfscarolinasAuthor Commented:
Going through the EIGRP troubleshooting flowchart found here:
http://www.ciscopress.com/articles/article.asp?p=27839&seqNum=3

The first thing it asks me is if my neighbors have been established.  
On my hub and my spokes I see neighbors related to my IPSEC tunnels 10.168.x.x  Should I also have neighbors in my 192.168.0.0 subnet?  

It then asks to check to see if the routes are being advetised:
On my spokes I see the routes to the hub advertised, I see the routes to the IPSEC tunnels advertised and I see the routes to the IPSEC tunnel on the other hub advertised after it has been added to my routing table.

On my hub I see routes to my IPSEC tunnels being advertised and this:
 192.168.4.0/24 - do   advertise out Tunnel0  

What I do not see are routes to my spokes being advertised. I'm assuming I should see
192.168.13.0/24 - do advertise out Tunnel0
192.168.49.0/24 - do advertise out Tunnel1
but I do not.  

I guess I need to figure out why these routes are not being advertised.  The hub knows each of these routes to the spoles and should advertise them to the spokes shouldn't it?  
0
 
mikebernhardtCommented:
>This sort of makes sense since I have static routes from the spoke to the hub (192.168.4.0/24) defined.
Duh, that makes sense. OK, so remove the static routes on the hub and then on the hub. Clear ip routes. Then let's see the output of show ip route and show ip eigrp topology.
0
 
mikebernhardtCommented:
First lets see if the hub is working or if we can get it to work. Then we'll get to the spokes. If the hub isn't accepting the LAN route from a spoke then the other spoke won't see it either.
0
 
lfscarolinasAuthor Commented:
I think that did it.  I removed the static routes on the hub and spokes and can now ping from each spoke to the other.  I'm confused because I know that I tried the configuration without the static routes a couple of times in the past month or so.  I wonder what is different this time.  

Thanks for your help on this.  
Any other general advice about eigrp I should know such as setting the bandwidth, etc...  
0
 
mikebernhardtCommented:
To understand why it's working now, it might be interesting to put the static routes back, then run show ip eigrp topology. Then remove them and run it again. See if there's a difference.

If there isn't any difference, try removing the bandwidth statement and look again, then put it back. I'm not sure why it wasn't working before and it is now, but I'm glad we got it!
0

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

  • 13
  • 12
  • 4
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now