Hi all,
It worked in a lab but not in the real environment.
I didn't use the reverse-route command because it worked for one site at time in the lab ( and it was decribed in the documentation that it could work only for one crypto map.
As applied in the lab:
crypto dynamic-map DM_profile 10
set transform-set ts1
match address 101
reverse-route
crypto dynamic-map DM_profile 20
set transform-set ts1
match address 102
reverse-route
It worked for each spoke but not for the situation that both spokes where down.
But I've seen yesterday that it's not needed to define interesting traffic at the dynamic side. So the solution could be easier
crypto dynamic-map DM_profile 10
set transform-set ts1
reverse-route
This could work because it's applied under 1 cryptomap (as discussed in the docs). Although Im'not sure if it would work for two sites falling on backup. I'll test this Monday
As we added one site as test I finally added the reverse-route command but although it didn't work.
@Peter
I do a ping from the loopback of the spoke towards a loopback of the hub
interface: FastEthernet0/1
Crypto map tag: static, local addr 3.3.1.1
protected vrf: (none)
local ident (addr/mask/prot/port): (30.0.0.0/255.0.0.0/0/0)
remote ident (addr/mask/prot/port): (172.16.0.0/255.255.0.0/
current_peer 1.1.1.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10 <---------
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0 <---------
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
interface: FastEthernet0/0
Crypto map tag: CM, local addr 1.1.1.1
protected vrf: (none)
local ident (addr/mask/prot/port): (172.16.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (30.0.0.0/255.0.0.0/0/0)
current_peer 3.3.1.1 port 500
PERMIT, flags={}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 <--------
#pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10 <--------
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
Why I think about the other tunnel was that I
interface: Serial1/0.201
...
protected vrf: (none)
local ident (addr/mask/prot/port):
PERMIT, flags={}
#pkts encaps: 13, #pkts encrypt: 13,
#pkts digest: 13
#pkts decaps: 13, #pkts decrypt: 13, #pkts verify: 13
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 2, #recv errors 0
local crypto endpt.: 10.102.0.2, remote crypto endpt.: 10.102.0.1
path mtu 1500, ip mtu 1500, ip mtu idb Tunnelxxx <----
I thought I saw here not the outgoing interface but some tunnel. When I checked this tunnel it hadn't an overlapping route.
current outbound spi: 0x8590D11F(2240860447)
