06-07-2012 01:27 PM - edited 03-01-2019 05:35 PM
All, I am trying to configure IPv6 IPSec (with tunnel protection mode) on a tunnel interface within a VRF, not the global routing table. I have searched google and found the following post in which a user is discussing a very similar situation. Near the end of the thread, he posts a response from a TAC engineer listing some bug IDs, but I cannot find any info on those in the bug toolkit.
https://supportforums.cisco.com/thread/2119892
Has anyone heard or seen anything relating to this issue? I will continue to search as well. Thanks.
P.S. I can make the configuration work in the global context, but when I change the crypto keyring, isakmp profile, tunnel interface (using both 'vrf forwarding' and 'tunnel vrf' commands), it does not work. Show commands display the following:
R1#show crypto isa sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
IPv6 Crypto ISAKMP SA
dst: FEC0:0:0:1::1
src: FEC0:0:0:1::2
state: MM_SA_SETUP conn-id: 0 status: ACTIVE
R1#show crypto session
Crypto session current status
Interface: FastEthernet0/0
Session status: DOWN-NEGOTIATING
Peer: FEC0:0:0:1::2 port 500
IKE SA: local FEC0:0:0:1::1/500
remote FEC0:0:0:1::2/500 Inactive
R1#show crypto ipsec sa
R1#
So it looks like the IKE SA comes up, but for some reason, the IPSec SA does not come up (debugging shows phase 1 timing out "death by retransmission", which makes me think routing within the crypto/ipv6/vrf setup is not working properly). Any thoughts or comments are appreciated. Thanks.
06-08-2012 10:25 AM
Hi Jess,
Why are you using (deprecated) site local addresses for the tunnel endpoints?
regards,
Leo
06-08-2012 01:10 PM
Thanks for the reply, Leo. I changed the site local addresses to fc00 addresses, but the results are the same.
06-08-2012 03:17 PM
No, I did not assume it would help.
Just a matter of using best practices where you can.
This tends to keep one out of trouble.
regards,
Leo
06-12-2012 07:38 AM
Yes, I agree.
I've opened a TAC case for this, so we'll see what happens.
06-13-2012 06:54 AM
So, in playing around with this setup, i changed the tunnel mode to ipv6 with no encryption, just to see if I could get the tunnel to get to up/up state. I was not able to initially, but just for fun I added a static route to the global routing table for the tunnel destination ipv6 address and used the nexthop-vrf keyword and boom, the tunnel went to UP/UP!
So it looks like for some reason the "tunnel vrf" command is not taking effect and the tunnel is trying to use the global table rather than the vrf specific table to reach the tunnel endpoint. It looks like this is a problem with the "tunnel vrf" command referencing an IPv6-enabled vrf.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide