GET VPN with a VRF twist.

I couldn't find this properly documented with an example so here goes.
 
Since GET was designed to secure large private networks, like MPLS clouds,  it is understandable that some VRF features would soon make it to this world.

Cisco documents it here:
http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_encrypt_trns_vpn_ps10591_TSD_Products_Configuration_Guide_Chapter.html#wp1235754

You can have crypto map applied on a particular interface in VRF and still reach your KS via global VRF.

KS is completely oblivious to VRF configuration, so it will not be shown here.

GM configuration (relevant parts)
----------------------------
crypto isakmp policy 10
 authentication pre-share
crypto isakmp key cisco address 0.0.0.0 0.0.0.0 no-xauth
!
!
crypto gdoi group GET
 identity number 1111
 server address ipv4 172.16.1.1
 client registration interface Loopback0
!
!
crypto map MAP 10 gdoi
 set group GET
-------------

interfaces' config:


---------
interface Loopback0
 ip address 172.16.1.2 255.255.255.255
!
interface Loopback1
 ip vrf forwarding RED
 ip address 172.16.1.2 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.0.0.2 255.255.255.0
!
interface FastEthernet0/0.10
 encapsulation dot1Q 10
 ip vrf forwarding RED
 ip address 10.0.0.2 255.255.255.0
 crypto map MAP
-----------------

OSPF:
------------
GM1-VRF#sh run | s router
router ospf 100 vrf RED
 network 10.0.0.0 0.0.0.255 area 0
 network 172.16.1.0 0.0.0.255 area 0
router ospf 1001
 network 10.0.0.0 0.0.0.255 area 0
 network 172.16.1.0 0.0.0.255 area 0
------------

Result:
----------------
GM1-VRF#sh crypto gdoi
GROUP INFORMATION

    Group Name               : GET
    Group Identity           : 1111
    Rekeys received          : 0
    IPSec SA Direction       : Both

     Group Server list       : 172.16.1.1

    Group member             : 172.16.1.2       vrf: None
       Registration status   : Registered
       Registered with       : 172.16.1.1
       Re-registers in       : 2568 sec
       Succeeded registration: 1
       Attempted registration: 2
       Last rekey from       : 0.0.0.0
       Last rekey seq num    : 0
       Unicast rekey received: 0
       Rekey ACKs sent       : 0
       Rekey Received        : never
       allowable rekey cipher: any
       allowable rekey hash  : any
       allowable transformtag: any ESP

    Rekeys cumulative
       Total received        : 0
       After latest register : 0
       Rekey Acks sents      : 0

 ACL Downloaded From KS 172.16.1.1:
   access-list  deny ospf any any
   access-list  permit ip any any

KEK POLICY:
    Rekey Transport Type     : Unicast
    Lifetime (secs)          : 86400
    Encrypt Algorithm        : 3DES
    Key Size                 : 192
    Sig Hash Algorithm       : HMAC_AUTH_SHA
    Sig Key Length (bits)    : 1024

TEK POLICY for the current KS-Policy ACEs Downloaded:
  FastEthernet0/0.10:
    IPsec SA:
        spi: 0x730377E0(1929607136)
        transform: esp-3des esp-sha-hmac
        sa timing:remaining key lifetime (sec): (2687)
        Anti-Replay :  Disabled

GM1-VRF#ping vrf RED 172.16.1.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/12 ms
---------------

IOS - Lan-to-Lan with two dynamic peers. (Both can initiate)

Original credit goes to Zsolt Horvath from Cisco TAC.

Goal:
Establish L2L tunnel between two hosts with dynamic IP. In this case both are registered to a dynamic DNS service (dyndns, no-ip or others). 

Problem.
IOS does not do name resolution when it's IKE responder. Documented here:
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsc92917

Usual resolution:
Use "dynamic" keyword on one peer side and dynamic crypto map on other.
Resulting in only one peer being able to initiate.

A solution when both peers are able to initiate:
This will require having both static and dynamic crypto maps, but with dynamic being first (to account for responding) and static crypto map later (to account for initiating).

Configuration in a nutshell:
R1:

crypto dynamic-map DynamicMAP 10
  set transform TRANSFORM

crypto map StaticMAP 100 ipsec-isakmp dynamic DynamicMAP

crypto map StaticMAP 110 ipsec-isakmp

 set peer R2.provider.tld dynamic
 set transform-set TRANSFORM

 match address 150 

R2: 

crypto dynamic-map DynamicMAP 10
  set transform TRANSFORM
crypto map StaticMAP 100 ipsec-isakmp dynamic DynamicMAP

crypto map StaticMAP 110 ipsec-isakmp

 set peer R1.provider.tld dynamic
 set transform-set TRANSFORM
match address 150

Please note:
Note1: You need to have DNS resolution enabled on routers.
Note2: Remote access IPsec VPN should also work.
Note3: While in theory, isakmp key and identity with hostname should work. This has only been tested with identity address and a wildcard isakmp key.