08-04-2008 03:18 AM - edited 03-03-2019 11:00 PM
Hi all,
I can't traceroute across a SVTI tunnel. I can ping across the SVTI using local subnet router interface as ping source and this works fine. Normal WAN traffic seems to be unaffected.
Do SVTIs support traceroute? I have setup a SVTI tunnel between R1 and R2 with static routes pointing to the remote subnets via the tunnel interface. The SVTI is configured with encryption.
R1
--
interface Tunnel10
description CORE ADSL SVTI to R2
ip address 192.168.24.1 255.255.255.252
no ip redirects
no ip unreachables
no ip proxy-arp
ip route-cache flow
no ip mroute-cache
tunnel source BVI1
tunnel destination 10.32.255.6
tunnel mode ipsec ipv4
tunnel protection ipsec profile ENCRYPT_IT
ip route 155.24.0.0 255.255.252.0 Tunnel10
R2
--
interface Tunnel10
description CORE ADSL SVTI to R1
ip address 192.168.24.2 255.255.255.252
no ip redirects
no ip unreachables
no ip proxy-arp
ip route-cache flow
no ip mroute-cache
tunnel source BVI1
tunnel destination 10.32.255.62
tunnel mode ipsec ipv4
tunnel protection ipsec profile ENCRYPT_IT
ip route 155.24.5.0 255.255.255.0 Tunnel10
08-04-2008 04:29 AM
Douglas
I believe that we do not have enough information to be sure what the problem is. In particular I think that we need to see how IPSec and encryption are set up. I would be particularly interested in the profile ENCRYPT_IT and in the access list that it uses.
I will also make a guess at what is causing this problem. The title of the post seems to associate traceroute with ICMP. This is true if the traceroute is done from a Windows machine (using the tracert command) which sends ICMP packets as the probe and receives ICMP responses. But it sounds like you are doing the traceroute from the router. And in IOS traceroute sends UDP packets as the probe and receives ICMP responses. My guess is that the configuration of IPSec is not defining the UDP packets as packets which should be encrypted.
HTH
Rick
08-04-2008 05:48 AM
Rick, Thanks for your reply.
The crypto profile is as follows:
R1#
-------
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
lifetime 3600
!
crypto isakmp key *********************** address 10.32.255.6
!
!
crypto ipsec transform-set TRANS-SET esp-3des esp-sha-hmac
!
crypto ipsec profile ENCRYPT_IT
set transform-set TRANS-SET
R2#
-------
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
lifetime 3600
!
crypto isakmp key *********************** address 10.32.255.62
!
!
crypto ipsec transform-set TRANS-SET esp-3des esp-sha-hmac
!
crypto ipsec profile ENCRYPT_IT
set transform-set TRANS-SET
08-04-2008 07:45 AM
Douglas
Thanks for the additional information. However it does not include the part that I especially want to see. Can you also post the part of the config that identifies traffic to be included in encryption by IPSec.
HTH
Rick
08-04-2008 07:56 AM
Rick, There are no ACL's specified in the config, I didn't think this was required for a SVTI unlike as is required for a crypto-map?
I assumed pointing a static to the tunnel10 interface would work.
08-04-2008 08:38 AM
Douglas
Perhaps you are correct. I have not done an SVTI and assumed that it identified traffic similar to the way that a crypto map does, but perhaps I am mistaken. I will need to think about this some more to identify what to look at next. Perhaps some other participant in the forum will also have a suggestion.
HTH
Rick
08-05-2008 01:05 AM
Rick, thanks for your help. I learnt something about traceroute from routers :)
For info. a traceroute from R1 to R2 gives the following:
R1#traceroute 155.24.1.254 source 155.24.5.254
Type escape sequence to abort.
Tracing the route to 155.24.1.254
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 *
R1#
Regards,
Douglas
08-05-2008 03:37 AM
Douglas
I see that the traceroute here fails and you are specifying the source address. Does it work if you just traceroute 155.24.1.254 (without specifying the source address)?
Also it would be helpful to know if you can do a standard ping to that destination (ping 155.24.1.254) and if you do an extended ping to that destination and in the extended ping specify the source address as 155.24.5.254.
HTH
Rick
08-05-2008 05:33 AM
R1#traceroute 155.24.1.254
Type escape sequence to abort.
Tracing the route to 155.24.1.254
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 *
R1#
R1#
R1#
R1#
R1#ping 155.24.1.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.24.1.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/104/208 ms
R1#ping 155.24.1.254 source 155.24.5.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.24.1.254, timeout is 2 seconds:
Packet sent with a source address of 155.24.5.254
!!!!!
R1#ping
Protocol [ip]:
Target IP address: 155.24.1.254
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 155.24.5.254
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.24.1.254, timeout is 2 seconds:
Packet sent with a source address of 155.24.5.254
!!!!!
08-05-2008 05:35 AM
I've also logged a case with Cisco TAC.
Douglas
08-13-2008 01:19 AM
TAC advised removing the "no ip unreachables" command this has fixed the problem.
Apparently the "no ip unreachables" command on a tunnel/interface allows ICMP ping echo and echo-reply but blocks UDP traceroutes.
I'm now able to traceroute around all SVTI tunnels in our network.
Regards,
Dougie
08-13-2008 04:12 AM
Douglas
Thanks for posting back indicating that you have a solution and what the solution is. It makes the forum more useful when people can read about a problem and can read the successful solution to the problem.
Good catch by the TAC. It makes sense. Echo request and Echo reply would work fine but the UDP based traceroute depends on the ICMP port unreachable (which is one of the ip unreachables) to indicate that it has gotten to the destination. So UDP based traceroute would break when no ip unreachables is configured.
HTH
Rick
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: