IPv6 / IPSec / VRF

[jess-harris]

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.

[lgijssel]

Hi Jess,

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

regards,

Leo

[jess-harris]

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

[lgijssel]

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

[jess-harris]

Yes, I agree.

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

[jess-harris]

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.