1

i'm struggeling with some dVTI Issue on a Cisco ASR1000 box.

here is my configuration for the hub site:

crypto keyring FOO-KEYRING  
  pre-shared-key hostname r2-foo key iawg8b32hah
!
crypto isakmp policy 104
 encr aes 256
 authentication pre-share
 group 5
 lifetime 7200
crypto isakmp keepalive 10
crypto isakmp profile FOO-IKEPROFILE
   keyring FOO-KEYRING
   match identity user-fqdn r2-foo
   virtual-template 104
!
!
crypto ipsec transform-set AES_256-SHA esp-aes 256 esp-sha-hmac 
 mode tunnel
!
crypto ipsec profile FOO-IPSECPROFILE
 set security-association lifetime seconds 7200
 set transform-set AES_256-SHA 
 set pfs group5
 responder-only

crypto ipsec transform-set AES_256-SHA esp-aes 256 esp-sha-hmac 
 mode tunnel
!
crypto ipsec profile FOO-IPSECPROFILE
 set security-association lifetime seconds 7200
 set transform-set AES_256-SHA 
 set pfs group5
 responder-only

interface Virtual-Template104 type tunnel
 ip address 10.241.1.13 255.255.255.252
 tunnel source Loopback0
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile FOO-IPSECPROFILE

When the router at the Spoke site is establishing connection virtual template will be cloned as expected, but is has no ip address:

Virtual-Access3 is up, line protocol is up 
  Hardware is Virtual Access interface
  MTU 9922 bytes, BW 100 Kbit/sec, DLY 50000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL
  Tunnel vaccess, cloned from Virtual-Template104
  Vaccess status 0x4, loopback not set
  Keepalive not set
  Tunnel linestate evaluation up
  Tunnel source 212.X.Y.Z (Loopback0), destination 85.X.Y.Z
   Tunnel Subblocks:
      src-track:
         Virtual-Access3 source tracking subblock associated with Loopback0
          Set of tunnels with source Loopback0, 2 members (includes iterators), on interface <OK>
  Tunnel protocol/transport IPSEC/IP
  Tunnel TTL 255
  Tunnel transport MTU 1422 bytes
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Tunnel protection via IPSec (profile "FOO-IPSECPROFILE")
  Last input never, output never, output hang never
  Last clearing of "show interface" counters 00:00:58
  Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 packets output, 0 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

#sh ip int Virtual-Access3
Virtual-Access3 is up, line protocol is up
  Internet protocol processing disabled

Phase 1 and 2 are established correctly, there are no noticeable errors visible in the output. I Have 2 Similar configured dVTI Endpoints that work fine. I diffed the outputs of "deb cry isakmp" and "deb cry ipsec" between a successful working dVTI Endpoint and the non working one.... everything looks equal.

I also moved the configuration to a different Router with the same effect.

Any idea how to debug the Virtual-Template cloning process here? Any other suggestions are welcome too!

EDIT: added a sample of "show cry ipsec sa"

interface: Virtual-Access3
    Crypto map tag: Virtual-Access3-head-0, local addr 212.X.Y.Z

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 85.X.Y.Z port 4500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #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

     local crypto endpt.: 212.X.Y.Z, remote crypto endpt.: 85.X.Y.Z
     plaintext mtu 1422, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0/0
     current outbound spi: 0xF213DE06(4061388294)
     PFS (Y/N): Y, DH group: group5

     inbound esp sas:
      spi: 0x21480EF2(558370546)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel UDP-Encaps, }
        conn id: 2029, flow_id: HW:29, sibling_flags 80000048, crypto map: Virtual-Access3-head-0
        sa timing: remaining key lifetime (k/sec): (4608000/6130)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xF213DE06(4061388294)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel UDP-Encaps, }
        conn id: 2030, flow_id: HW:30, sibling_flags 80000048, crypto map: Virtual-Access3-head-0
        sa timing: remaining key lifetime (k/sec): (4608000/6130)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:

MORE EDIT: i figured out that configuring "ip unnumbered Loopback0" results that cloned VirtualAccess will have an Ip address assigned. Unfortunately i only deal with static Routing here and need a static next-hop address. I can't use a multicast based routingprotocol. I assigned a /30 Network to the Virtual-Template in several cases without any issues.

I also checked out the Cisco Bugtracker without any success. Also several more debugs like "deb vaccess" didn't provide me any clues.

EDIT 3: After fiddling around a bit the only difference between the already working dVTI configs and the newly created one is that the working ones were configured before a router reboot about 14 Month ago. So the Virtual Template interface config is loaded from NVRAM and is not manually configured.

So i deconfigured a working dVTI interface and reconfigured it back again. The result is: after removing the Virtual-Template interface config and pasting the same config-lines back to the box leads to the same problem. Virtual-template is cloned, but the IP address is not.

So i think that i'm struggeling with some sort of software bug. I will see if i can reload the two ASRs in an upcoming maintenance window.

Unfortunately we decided to suspend our Cisco Support contract this year because the old 1002F Boxes will be replaced by two 1001X next year.

2
  • Statically assigning IP to virtual-template results in duplicates so will not work. If you need static routes/redistribution, don't point them at the IP next hop, point them out the interface. Or something like PPPoE where you can set the IP address to negotiated.
    – cpt_fink
    Oct 1, 2019 at 6:27
  • Hi, Thanks for your comment, unfortunately i can't point the static route to a interface at the dVTI site because interface virtual-template104 is cloned to a random Virtual-Access interface (e.G. Virtual-Access 5) On the SVTI site this is no issue because the Tunnel interface is staticly configured and i can point the routes to interface Tunnel0 for example. What exactly do you mean with: "Statically assigning IP to virtual-template results in duplicates"? where is the Duplicate here? Oct 1, 2019 at 13:14

1 Answer 1

0

OK, this is a really annoying problem.

We created a solution by configuring sVTI and dVTI Sides with "ip unnumbered" and use RIP to "discover" the Tunnel IPs on both sides dynamically.

This works for the moment, but is not satisfying me.

In future i will to migrate the static Routing configuration to aaa-attributes (Locally or on our RADIUS), but for the moment i'm fine with this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.