From: xiongxiaogang (xiongxg@msn.com)
Date: Sat Jan 12 2008 - 04:10:34 ARST
I know the show ip nhrp should return one entry of nhrp, but from my lab, there is so much which including the loopback address, and I use 12.2-15T, because it is used in lab, of course, I can upgrade to latest IOS to resolve the issue easily, but only 12.2-15T is test in lab, I have to focus on exam. I enalbe/disable cef in hub, get the same result, and of course the cef is disabled in spoke, I am wondering if it is the bug of 12.2-15T, and only spoke-to-spoke traffic is available.
Regards
Steven
________________________________
> Date: Sat, 12 Jan 2008 08:27:30 +0300
> From: farrukhharoon@gmail.com
> To: luan.m.nguyen@gmail.com
> Subject: Re:
> CC: xiongxg@msn.com; jagrinya@microaccess.com; ccielab@groupstudy.com; security@groupstudy.com
>
> Actually when I was labbing DMVPN up, I remember I would get more entries in the NHRP table sometimes.
>
> AFAIR this would depend on the status of 'ip cef' enablement globally. Do you have CEF enabled on the hub? What about the spokes?
>
> Regards
>
> Farrukh
>
>
> On 1/12/08, Luan Nguyen <luan.m.nguyen@gmail.com> wrote:
> Your show ip nhrp output looks funny.
> The spoke should only have one entry. Yours must be the hub side. The two loopbacks in there are bogus...shouldn't be there.
> Check your ios and search for bug on nhrp. Or just upgrade to the latest possible and see what's up.
>
> -lmn
>
> 2008/1/11 xiongxiaogang <xiongxg@msn.com>:
>
>
> Hi All,
>
> Actually I have not set tunnel keepalive when that problem is found, even without setting tunnel keepalive , still have the same issue, so it must be other places to fix it.
>
>
> Regards
> steven
>
> ----------------------------------------
>> Date: Fri, 11 Jan 2008 13:44:06 +0300
>> From: farrukhharoon@gmail.com
>> To: luan.m.nguyen@gmail.com
>> Subject: Re:
>> CC: xiongxg@msn.com; jagrinya@microaccess.com; ccielab@groupstudy.com; security@groupstudy.com
>>
>> Yup Luan, Thanks for that information :)
>>
>> It is mentioned on the following doc:
>>
>> http://www-search.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftgreips.html#wp1039493
>>
>> "GRE tunnel keepalives (that is, the *keepalive* command under a GRE
>> interface) are not supported on point-to-point or multipoint GRE tunnels in
>> a DMVPN Network."
>>
>> Regards
>>
>> Farrukh
>>
>>
>>
>
>> On Jan 11, 2008 7:06 AM, Luan Nguyen wrote:
>>
>>> I would remove the keepalive 100 3 on your spoke.
>>> DMVPN doesn't support keep alive.
>>> Incidentally, 100 3 is also about 5 minutes :)
>>>
>>> -lmn
>>>
>
>>> On Jan 10, 2008 8:22 PM, xiongxiaogang wrote:
>>>
>>>>
>>>> Hi Julius and luan,
>>>> please refer to the below config and my test result.
>>>> *******SPOKE CONFIG***************
>>>> crypto isakmp policy 10
>>>> encr 3des
>>>> authentication pre-share
>>>> crypto isakmp key dmvpnkey address 0.0.0.0 0.0.0.0
>>>> crypto isakmp keepalive 10 3
>>>> !
>>>> !
>>>> crypto ipsec transform-set myset esp-3des esp-md5-hmac
>>>> mode transport
>>>> !
>>>> crypto ipsec profile dmvpnprof
>>>> set transform-set myset
>>>>
>>>> interface Loopback10
>>>> ip address 192.168.5.5 255.255.255.0
>>>> !
>>>> interface Tunnel0
>>>> bandwidth 1000
>>>> ip address 172.16.1.5 255.255.255.0
>>>> no ip redirects
>>>> ip mtu 1400
>>>> ip nhrp authentication dmvpn
>>>> ip nhrp map 172.16.1.4 201.1.0.4
>>>> ip nhrp map multicast 201.1.0.4
>>>> ip nhrp network-id 1000
>>>> ip nhrp holdtime 300
>>>> ip nhrp nhs 172.16.1.4
>>>> no ip route-cache
>>>> ip tcp adjust-mss 1360
>>>> no ip mroute-cache
>>>> delay 1000
>>>> keepalive 100 3
>>>> tunnel source Serial1/1
>>>> tunnel mode gre multipoint
>>>> tunnel key 12345
>>>> tunnel protection ipsec profile dmvpnprof
>>>>
>>>> router eigrp 200
>>>> network 172.16.1.0 0.0.0.255
>>>> network 192.168.5.0
>>>> no auto-summary
>>>>
>>>> ********HUB CONFIG*****************
>>>>
>>>> crypto isakmp policy 10
>>>> encr 3des
>>>> authentication pre-share
>>>> crypto isakmp key dmvpnkey address 0.0.0.0 0.0.0.0
>>>> !
>>>> !
>>>> crypto ipsec transform-set myset esp-3des esp-md5-hmac
>>>> mode transport
>>>> !
>>>> crypto ipsec profile dmvpnprof
>>>> set transform-set myset
>>>>
>>>> interface Loopback10
>>>> ip address 192.168.4.4 255.255.255.0
>>>> !
>>>> interface Tunnel0
>>>> bandwidth 1000
>>>> ip address 172.16.1.4 255.255.255.0
>>>> ip mtu 1400
>>>> ip nhrp authentication dmvpn
>>>> ip nhrp map multicast dynamic
>>>> ip nhrp network-id 1000
>>>> ip nhrp holdtime 300
>>>> no ip route-cache
>>>> no ip split-horizon eigrp 200
>>>> ip tcp adjust-mss 1360
>>>> no ip mroute-cache
>>>> delay 1000
>>>> tunnel source Serial1/1
>>>> tunnel mode gre multipoint
>>>> tunnel key 12345
>>>> tunnel protection ipsec profile dmvpnprof
>>>>
>>>> router eigrp 200
>>>> network 172.16.1.0 0.0.0.255
>>>> network 192.168.4.0
>>>> no auto-summary
>>>>
>>>> ***********RESULT CAPTURED FROM HUB***********
>>>> after tunnel is up, ping from spoke1 to hub, get the following result,
>>>> r4#sh ip nhrp
>>>> 172.16.1.2/32 via 172.16.1.2, Tunnel0 created 1d06h, expire 00:04:02
>>>> Type: dynamic, Flags: authoritative unique registered
>>>> NBMA address: 201.1.20.2
>>>> 172.16.1.5/32 via 172.16.1.5, Tunnel0 created 00:12:16, expire 00:03:44
>>>> Type: dynamic, Flags: authoritative unique registered
>>>> NBMA address: 201.1.0.5
>>>> 192.168.4.0/24 via 192.168.4.4, Tunnel0 created 00:04:50, expire
>>> 00:00:09
>>>> Type: dynamic, Flags: router authoritative unique local
>>>> NBMA address: 201.1.0.4
>>>> 192.168.5.0/24 via 192.168.5.5, Tunnel0 created 00:04:50, expire
>>> 00:00:09
>>>> Type: dynamic, Flags: router unique
>>>> NBMA address: 201.1.0.5
>>>>
>>>> after 5 minutes(equal to the nhrp holdtime settings), tunnel is down,
>>> and
>>>> get the following output, eigrp neighbor disappear.
>>>> r4#sh ip nhrp
>>>> 172.16.1.2/32 via 172.16.1.2, Tunnel0 created 1d06h, expire 00:03:52
>>>> Type: dynamic, Flags: authoritative unique registered
>>>> NBMA address: 201.1.20.2
>>>> 172.16.1.5/32 via 172.16.1.5 , Tunnel0 created 00:12:26, expire 00:03:34
>>>> Type: dynamic, Flags: authoritative unique registered
>>>> NBMA address: 201.1.0.5
>>>> r4#
>>>> r4#
>>>> *Mar 2 16:23:33.261 : %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an
>>>> IPSEC packet.
>>>> (ip) vrf/dest_addr= /201.1.0.4, src_addr= 201.1.0.5, prot= 47
>>>> r4#sh ip nhrp
>>>> 172.16.1.2/32 via 172.16.1.2, Tunnel0 created 1d06h, expire 00:03:45
>>>> Type: dynamic, Flags: authoritative unique registered
>>>> NBMA address: 201.1.20.2
>>>> 172.16.1.5/32 via 172.16.1.5, Tunnel0 created 00:12:33, expire 00:03:27
>>>> Type: dynamic, Flags: authoritative unique registered used
>>>> NBMA address: 201.1.0.5
>>>> r4#
>>>> *Mar 2 16:23:43.721: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor
>>>> 172.16.1.5 (Tunnel0) is down: holding time expired
>>>> *Mar 2 16:23:43.721: destroy peer: 172.16.1.5
>>>> r4#sh ip ei
>>>> r4#sh ip eigrp nei
>>>> r4#sh ip eigrp neighbors
>>>> IP-EIGRP neighbors for process 200
>>>> ----------------------------------------
>>>>> From: jagrinya@fzxmedia.com
>>>>> To: xiongxg@msn.com
>>>>> Subject: Re:
>>>>> Date: Thu, 10 Jan 2008 20:52:54 +0100
>>>>>
>>>>> Hello Xiongxiaogang......,
>>>>>
>>>>> Can you paste your config's for the hub and spokes here for us to
>>>> view...?
>>>>> Could get some clue from the configs.....
>>>>> do u have "no ip split-horizon eigrp ...." on your hub ...?
>>>>>
>>>>> Agrinya Julius Agrinya Jr.
>>>>> Senior Manager Networks
>>>>> Microaccess Limited
>>>>> Abuja-Nigeria.
>>>>> Phone +234-9-4612607-8 ext 113
>>>>> Mobile +2348023854717
>>>>> ----- Original Message -----
>>>>> From: "xiongxiaogang"
>>>>> To: ;
>>>>> Sent: Thursday, January 10, 2008 7:31 PM
>>>>>
>>>>>
>>>>>> Hi,
>>>>>> I configure dmvpn between one hub and two spokes, the tunnels of
>>>>>> spoke-to-spoke and spoke-to-hub both work, but I found there is a
>>>> weired
>>>>>> problem, that is if I only ping from one spoke to the other spoke, it
>>>>>> works normally, but meanwhile if I also ping a spoke to the hub,
>>>> although
>>>>>> tunnel is up normally, but the tunnel cannot keep up always, it
>>>> becoming
>>>>>> down when ip nhrp expires, and the worse is eigrp neighbor between
>>> hub
>>>> and
>>>>>> spoke is affected by the disconnect tunnel, when ip nhrp expires,
>>> eigrp
>>>>>> neighbor between hub and spoke is down with the error message "*Jan 5
>>>>>> 17:32:02.743: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an
>>> IPSEC
>>>>>> packet. (ip) vrf/dest_addr= /105.1.2.5, src_addr= 105.1.50.2, prot=
>>>> 47..."
>>>>>> when the eigrp neigbhor is down, even if you ping from spoke to hub,
>>>>>> cannot enable tunnel up. so I have to go to spoke and shut/no shut
>>>> tunnel
>>>>>> interface to resolve it. but I do not think
>>>>>> it is a good solution, considering in the real world, cannot always
>>> let
>>>>>> the router administrator to login to the spoke router and shut/no
>>> shut
>>>>>> tunnel interface to let the traffic between spokes and hub to go
>>>> through,
>>>>>> and in the lab exam, considering proctor maybe see the error message
>>> if
>>>> he
>>>>>> have ever ping from spoke to hub and provided you set the ip nhrp
>>>> holdtime
>>>>>> to 300 seconds, it is expected that the proctor will see the error
>>>> message
>>>>>> after 5 minutes and he know the eigrp neighbor is down.
>>>>>>
>>>>>> so I doubt the solution could be improved in some place, but I read a
>>>> lot
>>>>>> of dmvpn documents, including the long thread discuss about the dmvpn
>>>> in
>>>>>> the forum, but have no idea now, I am wondering who can throw me a
>>>> light
>>>>>> for it, I am very appreciate of it.
>>>>>>
>>>>>> Regards
>>>>>> Steven
>>>>>> _________________________________________________________________
>>>>>> MSNJ%5.@qNo;pHH5G3!#,Cb7Q7"7EVP#,?l@4AlH!0I#!
>>>>>> http://im.live.cn/emoticons/?ID=18
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _________________________________________________________________
>>>> JV;zR2D\IO MSN ADLlAK#,?l@4JTJT0I#!
>>>> http://mobile.msn.com.cn/
>>
>
>
> _________________________________________________________________
> MSNJ%5.@qNo;pHH5G3!#,Cb7Q7"7EVP#,?l@4AlH!0I#!
> http://im.live.cn/emoticons/?ID=18
This archive was generated by hypermail 2.1.4 : Fri Feb 01 2008 - 10:37:59 ARST