Re: EIGRP - where is this route coming from??

ryan.chapman · ‎11-10-2004

We have a Dymanic Multiuser VPN (DMVPN) setup, but I can't figure out why the route 10.0.0.0/8 is coming from a spoke router (via 10.64.0.96). Also, if I shut down the 10.64.0.96 router, then another spoke (such as 10.64.0.20) will then put the route for 10.0.0.0/8 into the VPN1 route table. Could someone look at the partial configs and tell me whats up??

VPN1#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 66.xx.xx.189 to network 0.0.0.0

66.xx.xx.0/29 is subnetted, 1 subnets

C 66.xx.xx.184 is directly connected, FastEthernet0/0

172.16.0.0/24 is subnetted, 2 subnets

S 172.16.1.0 [1/0] via 66.xx.xx.190

S 172.16.2.0 [1/0] via 66.xx.xx.190

208.xx.xx.xx/32 is subnetted, 1 subnets

S 208.xx.xx.xx [1/0] via 66.xx.xx.189

10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks

S 10.10.0.0/16 is directly connected, Tunnel14

D 10.0.0.0/8 [90/15616000] via 10.64.0.96, 00:00:00, Tunnel0

D 10.0.20.0/24 [90/2841600] via 10.64.0.20, 01:21:40, Tunnel0

C 10.64.0.0/24 is directly connected, Tunnel0

D 10.0.96.0/24 [90/2841600] via 10.64.0.96, 01:21:41, Tunnel0

S* 0.0.0.0/0 [1/0] via 66.xx.xx.189

VPN1#

VPN1 (hub router):

!

version 12.3

!

hostname VPN1

!

memory-size iomem 10

ip subnet-zero

ip cef

!

crypto isakmp policy 122

authentication pre-share

crypto isakmp key xxxxxx address xxxx

crypto isakmp invalid-spi-recovery

!

crypto ipsec transform-set dmvpn esp-3des esp-md5-hmac

!

crypto ipsec profile dmvpnProfile

set transform-set dmvpn

!

crypto map rXXX 10 ipsec-isakmp

set peer 208.xx.xx.xx

set transform-set csv1

match address 170

!

interface Tunnel0

bandwidth 1000

ip address 10.64.0.1 255.255.255.0

no ip redirects

ip mtu 1416

ip nhrp authentication XXXXXXX

ip nhrp map multicast dynamic

ip nhrp network-id 99

ip nhrp holdtime 300

no ip split-horizon eigrp 1

no ip mroute-cache

delay 1000

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel key 10000

tunnel protection ipsec profile dmvpnProfile

!

interface Tunnel14

ip unnumbered FastEthernet0/0

tunnel source FastEthernet0/0

tunnel destination 208.xx.xx.xx

crypto map rXXX

!

interface FastEthernet0/0

ip address 66.xx.xx.186 255.255.255.248

duplex auto

speed auto

no cdp enable

crypto map rXXX

!

router eigrp 1

redistribute static

passive-interface FastEthernet0/0

passive-interface FastEthernet0/1

passive-interface Tunnel14

network 10.0.0.0 0.0.0.255

network 10.64.0.0 0.0.0.255

distribute-list 90 out

no auto-summary

!

ip classless

ip route 0.0.0.0 0.0.0.0 66.xx.xx.189

ip route 10.0.0.0 255.0.0.0 Null0 254

ip route 10.10.0.0 255.255.0.0 Tunnel14

ip route 172.16.1.0 255.255.255.0 66.xx.xx.190

ip route 172.16.2.0 255.255.255.0 66.xx.xx.190

ip route 208.xx.xx.xx 255.255.255.255 66.xx.xx.189

!

access-list 90 deny 208.xx.xx.xx

access-list 90 deny 10.10.0.0 0.0.255.255

access-list 90 permit any

access-list 170 permit ip host 66.xx.xx.186 host 208.xx.xx.xx

access-list 170 permit gre 66.xx.xx.160 0.0.0.31 10.10.0.0 0.0.255.255

!

end

(SPOKE ROUTER CONFIG TO FOLLOW IN SEPARATE POST)

ryan.chapman · ‎11-10-2004

All spoke routers have similar configs.

SPOKE ROUTER:

!

version 12.3

service tcp-keepalives-in

service tcp-keepalives-out

!

hostname GW1.0096

!

ip subnet-zero

no ip source-route

ip tcp selective-ack

ip dhcp excluded-address 10.0.96.1 10.0.96.128

!

ip dhcp pool CLIENT

import all

network 10.0.96.0 255.255.255.0

default-router 10.0.96.1

dns-server 172.16.1.22 172.16.1.1

lease 0 2

!

no ip bootp server

ip cef

ip inspect name myfw cuseeme timeout 3600

ip inspect name myfw ftp timeout 3600

ip inspect name myfw realaudio timeout 3600

ip inspect name myfw smtp timeout 3600

ip inspect name myfw udp timeout 15

ip inspect name myfw http java-list 50 urlfilter timeout 3600

ip inspect name myfw tcp timeout 3600

ip urlfilter cache 8000

ip urlfilter audit-trail

ip urlfilter server vendor n2h2 172.16.1.4

ip audit notify log

ip audit po max-events 100

vpdn enable

!

vpdn-group 1

!

crypto isakmp policy 1

authentication pre-share

crypto isakmp key 0 xxxx address 66.xx.xx.186

crypto isakmp invalid-spi-recovery

!

crypto ipsec transform-set ts1 esp-3des esp-md5-hmac

!

crypto ipsec profile vpnprof

set transform-set ts1

!

interface Null0

no ip unreachables

!

interface Tunnel0

bandwidth 1000

ip address 10.64.0.96 255.255.255.0

no ip redirects

no ip unreachables

no ip proxy-arp

ip mtu 1416

ip nhrp authentication XXXXX

ip nhrp map 10.64.0.1 66.xx.xx.186

ip nhrp map multicast 66.xx.xx.186

ip nhrp network-id 99

ip nhrp holdtime 300

ip nhrp nhs 10.64.0.1

no ip route-cache

no ip split-horizon eigrp 1

no ip mroute-cache

tunnel source Dialer1

tunnel destination 66.xx.xx.186

tunnel key 10000

tunnel protection ipsec profile vpnprof

!

interface Ethernet0

ip address 10.0.96.1 255.255.255.0

no ip redirects

no ip proxy-arp

ip nat inside

no ip mroute-cache

no cdp enable

hold-queue 100 out

!

interface ATM0

no ip address

atm vc-per-vp 64

no atm ilmi-keepalive

pvc 0/35

pppoe-client dial-pool-number 1

!

dsl operating-mode auto

!

interface Dialer1

ip address negotiated

ip access-group 120 in

ip access-group 130 out

ip verify unicast reverse-path

no ip redirects

no ip proxy-arp

ip accounting access-violations

ip mtu 1492

ip nat outside

ip inspect myfw out

encapsulation ppp

ip tcp adjust-mss 1452

no ip mroute-cache

dialer pool 1

dialer remote-name redback

dialer-group 1

no cdp enable

ppp authentication pap chap callin

ppp chap hostname XXXX

ppp chap password 7 XXXXXX

ppp pap sent-username XXXXX password 7 XXXX

!

router eigrp 1

passive-interface Dialer1

passive-interface Ethernet0

network 10.0.96.0 0.0.0.255

network 10.64.0.0 0.0.0.255

no auto-summary

!

ip nat inside source list 101 interface Dialer1 overload

ip classless

ip route 0.0.0.0 0.0.0.0 Dialer1

ip route 66.xx.xx.186 255.255.255.255 Dialer1

!

access-list 50 permit any

dialer-list 1 protocol ip permit

no cdp run

scheduler max-task-time 5000

scheduler interval 500

!

end

Kevin Dorrell · ‎11-11-2004

It would be interesting to see the show ip route from the spoke router, whether the 10.0.0.0/8 route turns up there, and if so how does the metric compare.

I noticed that the metric of the 10.0.0.0/8 route is considerably less than, for example, the 10.0.96.0/24 route. I wondered whether that might give us a clue. It seems to be closer than the Ethernet of the spoke router, so it looks like it come from inside the spoke router.

I thought it might be something to do with the default route 0.0.0.0/0 to Dialer1, but why that should be propagated as 10.0.0.0/8 is a mystery to me. I looked up the rules for redistribution of the default route into EIGRP, and the document says that if you want the 0.0.0.0/0 route distributed by EIGRP, then you have to specifically redistribute the static. So that looks like another dead-end, but here is the doc anyway:

http://www.cisco.com/warp/public/105/default.html

Both your central site and your spokes are ip classless, so no joy there.

I looked for no auto-summary, and you have that OK. I looked for some ip summary-address lines, but I did not see any of those either.

Sorry, I've checked everything I know about, and I still cannot see it. What does the routing table look like on a spoke router?

Kevin Dorrell

Luxembourg

Kevin Dorrell · ‎11-11-2004

Shouldn't the default route on the spoke router be to Tunnel0 rather than to Dialer1. Is the route coming from your access server? I'm no expert in these configurations, so tell me if I'm wrong.

Alternatively, could you use an EIGRP stub configuration?

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcprt2/1cfeigrp.htm#wp1003890

Kevin Dorrell

Luxembourg

ryan.chapman · ‎11-11-2004

Kevin,

Thanks for the reply.

Here is the routing table from the spoke:

GW1.0096>sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

70.0.0.0/32 is subnetted, 1 subnets

C 70.xx.xx.169 is directly connected, Dialer1

66.0.0.0/32 is subnetted, 1 subnets

S 66.xx.xx.186 is directly connected, Dialer1

172.16.0.0/24 is subnetted, 2 subnets

D EX 172.16.1.0 [170/15362560] via 10.64.0.1, 13:28:18, Tunnel0

D EX 172.16.2.0 [170/15362560] via 10.64.0.1, 13:28:18, Tunnel0

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

C 10.6.8.1/32 is directly connected, Dialer1

D 10.0.20.0/24 [90/15641600] via 10.64.0.1, 13:28:18, Tunnel0

C 10.64.0.0/24 is directly connected, Tunnel0

C 10.0.96.0/24 is directly connected, Ethernet0

S* 0.0.0.0/0 is directly connected, Dialer1

GW1.0096>

To answer your question on the default route being Dialer1 rather than Tunnel0, we actually have a split tunnel situation here where URL Filtering is in place.. all HTTP, POP3, HTTPS, and a few other protocol traffic are NAT'd to the IP of the Dialer1 interface, then sent directly to the internet. We could have just set the default route to Tunnel0, but we didn't want to tunnel everything through headquarters. We expect to eventually have 200 spokes connected, so tunneling all spokes would generate (and waste) ALOT of traffic on the hq WAN pipe.

I think EIGRP stub is intended for sending all traffic through a central router, similar to setting the default route to tunnel0... or am I wrong? I only briefly looked over the stub feature.

Thanks for the help.

Ryan

olorunloba · ‎11-11-2004

Why not do a show ip eigrp topology for the route on the spoke?

Why do you have the route 10.0.0.0/8 pointing to the null interface on the hub?.

My guess is that this static route is being redistributed into eigrp, advertised to the spokes and advertised back again. Consider that you have an administrative distance of 254, higher than all routing protocols.

The EIGRP topology would give you an idea of what is actually happening?.

Kevin Dorrell · ‎11-12-2004

Olorunloba,

I understand what you are suggesting, but there are three things I cannot reconcile about it:

1. If that were the mechanism, wouldn't there be a D entry in the spoke routing table for 10.0.0.0/8? Perhaps it would be useful to see the EIGRP database on the spoke.

2. Wouldn't split horizon stop the route being re-advertised out the port it came from?

3. For the static default route to be re-distributed into EIGRP, doesn't it have to be done explicitly in the configuration? I don't see it anywhere.

It is strange that we don't see a D entry for 10.0.0.0/8 on the spoke, yet it turns up in the hub, apparently coming from the spoke. There is something going on that I haven't seen yet.

Is there a route to 10.0.0.0/8 in the access server, and is it distributed by EIGRP? We haven't seen the config of the access server yet.

Kevin Dorrell

Luxembourg

marikakis · ‎11-12-2004

I agree with Olorunloba.

The hub sends the 10.0.0.0/8 to the spokes

and the spokes send it back to the hub, which installs it as a D route.

There exists the static route "ip route 10.0.0.0 255.0.0.0 Null0 254" in the hub,

in conjunction with "redistribute static" under the eigrp 1.

The "distribute-list 90 out" allows 10.0.0.0/8.

The "no ip split-horizon eigrp 1" is in the tunnels.

Is the 254 distance necessary ?

I think it should be less than the eigrp AD.

If you have more specific routes they will be used.

Why the route is not in the spoke table needs investigation.

If you do not want the spokes to have it,

you can filter it in the hub.

M.

Kevin Dorrell · ‎11-12-2004

You are right. How did I miss the redistribute static and the no ip split-horizon? I think I need a new pair of eye glasses 9-)

Kevin Dorrell

Luxembourg

ryan.chapman · ‎11-13-2004

Thanks olorunloba, you're correct. The 10.0.0.0/8 static route on the hub is being distributed to the spokes, then distributed back to the hub.

I guess I should explain what I'm trying to accomplish because I have no clue how to do it.

All traffic destined for 10.0.0.0/8 gets forwarded to the VPN1 router (the DMVPN hub).

As is, a ping to a host on a unavailable network (say 10.65.0.1) looks like so

(note that I removed the route to 10.0.0.0/8 -> Null0, dist 254 before executing this ping)

ryan@euclid(172.16.1.1):~$ traceroute -n 10.65.0.1

traceroute to 10.65.0.1 (10.65.0.1), 30 hops max, 40 byte packets

1 172.16.1.200 0.8 ms 0.855 ms 0.792 ms

2 66.xx.xx.186 2.073 ms 1.806 ms 1.737 ms

3 66.xx.xx.189 2.309 ms 2.057 ms 2.097 ms

4 66.xx.xx.189 3.539 ms * 4.276 ms

^C

(with the route to 10.0.0.0/8 -> Null0, dist 254 in the route table on VPN1, the ping looks like so...)

ryan@euclid(172.16.1.1):~$ traceroute -n 10.65.0.1

traceroute to 10.65.0.1 (10.65.0.1), 30 hops max, 40 byte packets

1 172.16.1.200 0.816 ms 0.821 ms 0.8 ms

2 66.xx.xx.186 2.807 ms 1.71 ms 1.74 ms

3 * 10.64.0.96 58.861 ms 57.732 ms

4 * * *

^C

Now, back to the 10.0.0.0/8 ->Null0 route not being in the table.... Because VPN1 (66.xx.xx.186) has 66.xx.xx.189 as its default route, when VPN1 doesn't have

a routing entry for 10.65.0.1, then the packet gets forwarded to 66.xx.xx.189.

I would like for the VPN1 router to just send an unreachable response, this is why I placed

the "ip route 10.0.0.0 255.0.0.0 Null0 254" thinking it would take care of this, but it obviously didn't.

I realize this is a simple question, but I have no idea how to do it. Please help. :-)

If it helps, here is the topology table on the HUB:

VPN1#sh ip eigrp top

IP-EIGRP Topology Table for AS(1)/ID(192.168.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 0.0.0.0/0, 1 successors, FD is 28160

via Rstatic (28160/0)

A 10.0.0.0/8, 1 Successors, FD is 15616000, Q

3 replies, active never, query-origin: Clear

via 10.64.0.96 (15616000/15360000), r, Tunnel0

Remaining replies:

via 10.64.0.200, r, Tunnel0

via 10.64.0.20, r, Tunnel0

P 10.0.20.0/24, 1 successors, FD is 2841600

via 10.64.0.20 (2841600/281600), Tunnel0

P 10.64.0.0/24, 1 successors, FD is 2816000

via Connected, Tunnel0

P 10.0.96.0/24, 1 successors, FD is 2841600

via 10.64.0.96 (2841600/281600), Tunnel0

P 172.16.1.0/24, 1 successors, FD is 28160

via Rstatic (28160/0)

P 172.16.2.0/24, 1 successors, FD is 28160

via Rstatic (28160/0)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 10.0.200.0/24, 1 successors, FD is 2841600

via 10.64.0.200 (2841600/281600), Tunnel0

VPN1#

olorunloba · ‎11-14-2004

Simplest means will be to remove the config

no ip split-horizon eigrp 1

from the tunnel interfaces. This will ensure that the 10.0.0.0/8 route is not advertised back to the hub.

If you change the administrative distance on the route, say to anything less than 90 (can ommit it for the default of 1), I guess it should also work.