Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

IPv6 / IPSec / VRF

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.

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


dst             src             state          conn-id status


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


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.


IPv6 / IPSec / VRF

Hi Jess,

Why are you using (deprecated) site local addresses for the tunnel endpoints?



New Member

IPv6 / IPSec / VRF

Thanks for the reply, Leo.  I changed the site local addresses to fc00 addresses, but the results are the same.

IPv6 / IPSec / VRF

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.



New Member

IPv6 / IPSec / VRF

Yes, I agree.

I've opened a TAC case for this, so we'll see what happens.

New Member

IPv6 / IPSec / VRF

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.