Hi Garett,

THe thing is I don't see any difference in the identities between the 2
debugs, that is why I found strange.
Maybe more verbose debugs would have shown something...


2014-03-16 16:23 GMT+01:00 Garrett Skjelstad <garr...@skjelstad.org>:

> It didn't start accepting them, R5 simply started giving the correct
> identity after the clear.
>
> This is common.
>
> Sent from my (old) iPhone5
>
> On Mar 16, 2014, at 3:54, Bastien Migette <bastien.mige...@gmail.com>
> wrote:
>
> Hi Folks,
>
> I was playing with DMVPN lab from WB1 (Section 7 - DMVPN Phase 1) and got
> this strange behaviour.
>
> Basically after configuring everything fine, R6 Tunnel was up, but R5 kept
> being down.
>
> Debug IPSEC on R8 was giving:
>
> *Mar 16 10:34:18.200: IPSEC(validate_proposal_request): proposal part #1
> *Mar 16 10:34:18.200: IPSEC(validate_proposal_request): proposal part #1,
>   (key eng. msg.) INBOUND local= 192.168.8.8:0, remote= 8.9.50.5:0,
>     local_proxy= 8.9.2.8/255.255.255.255/47/0,
>     remote_proxy= 8.9.50.5/255.255.255.255/47/0,
>     protocol= ESP, transform= NONE  (Transport-UDP),
>     lifedur= 0s and 0kb,
>     spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
> *Mar 16 10:34:18.200: map_db_find_best did not find match
> *Mar 16 10:34:18.200: IPSEC(ipsec_process_proposal): proxy identities not
> supported
>
> R6 was having exact same config except tunnel ip address of course.
>
> Then I did a clear crypto session on R5, and it suddenly started to work:
> *Mar 16 10:34:51.776: IPSEC(key_engine): got a queue event with 1 KMI
> message(s)
> *Mar 16 10:34:51.800: IPSEC(validate_proposal_request): proposal part #1
> *Mar 16 10:34:51.800: IPSEC(validate_proposal_request): proposal part #1,
>   (key eng. msg.) INBOUND local= 192.168.8.8:0, remote= 8.9.50.5:0,
>     local_proxy= 8.9.2.8/255.255.255.255/47/0,
>     remote_proxy= 8.9.50.5/255.255.255.255/47/0,
>     protocol= ESP, transform= NONE  (Transport-UDP),
>     lifedur= 0s and 0kb,
>     spi= 0x0(0), conn_id= 0,
> R8(config)#keysize= 0, flags= 0x0
> *Mar 16 10:34:51.800: insert of map into mapdb AVL failed, map + ace pair
> already exists on the mapdb
> *Mar 16 10:34:51.800: Crypto mapdb : proxy_match
>         src addr     : 192.168.8.8
>         dst addr     : 8.9.50.5
>         protocol     : 47
>         src port     : 0
>         dst port     : 0
>
>
> I am a bit curious though on why clearing crypto session on R5 would have
> made R8 accepting proxy IDs.
>
> This is on
> R8(config)#do sh ver | i IO
> Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version
> 15.2(4)M5, RELEASE SOFTWARE (fc2)
> R8(config)#
>
>
>
> I removed the EZVPN Config from previous task as well, not sure that would
> made a difference.
>
> _______________________________________________
> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos ::
>
> iPexpert on YouTube: www.youtube.com/ipexpertinc
>
>
_______________________________________________
Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos ::

iPexpert on YouTube: www.youtube.com/ipexpertinc

Reply via email to