Catalyst 3850 ARP “Feature”

The new catalyst 3850s are great! They have a ton of features that come in handy. I recently ran into a bit of a conundrum though. The 3850 was bouncing back my ARP requests from the nexus management interface with the 3850’s MAC address. The nexus management interfaces were on the same subnet in the same vlan, that didn’t even span multiple switches.

Packet capture

I’ve changed the IP addresses to protect the innocent. The packets are out of order, just because it was near impossible to collect amount of packets necessary to make it look nice. This is plenty though. The originator is the owner of the eb:81 MAC. So why is the ARP packet coming back to me with the MAC of the 3850(52:99). Turns out it’s a little feature that Cisco has implemented and is very poorly documented as of 09/2013. Here is the response from TAC –

“Please add the following configuration on the interfaces connected to the Nexus switches: ‘nmsp attach suppress’.

IP Device Tracking (IPDT) is globally enabled by default on the 3850. It can only be disabled on a per-interface level. The 3850 uses a feature called Network Mobility Service Protocol (NMSP) which in turn uses IPDT. The cause of the ARP errors is caused by IP Device Tracking.  We’ll want to disable NMSP to prevent the 3850 from sending these packets.

Once the configuration is added, please let me know if the Nexus switch still sees these ARP packets.”

Documentation –

Source 1

Source 2

DTP and VTP

Problem: Trunk links using DTP aren’t transitioning into a trunk state.

SW02 –


SW02#sh int trunk
SW02#

SW02#sh vtp status
VTP Version                     : running VTP2
Configuration Revision          : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 20
VTP Operating Mode              : Client
VTP Domain Name                 : TEST2
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Enabled
VTP Traps Generation            : Disabled
MD5 digest                      : 0xEA 0xAD 0xAA 0x55 0xAF 0xF7 0x75 0xE7
Configuration last modified by 0.0.0.0 at 3-1-93 01:27:27

SW02#sh run int fa0/3
Building configuration...
Current configuration : 106 bytes
!
interface FastEthernet0/3
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
end

SW01 –


SW01#sh vtp status
VTP Version                     : running VTP2
Configuration Revision          : 23
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 20
VTP Operating Mode              : Client
VTP Domain Name                 : TEST
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Enabled
VTP Traps Generation            : Disabled
MD5 digest                      : 0xAE 0xD8 0xC3 0x52 0x44 0xD4 0x77 0xCE
Configuration last modified by 0.0.0.0 at 3-1-93 01:27:27

SW01#sh run int fa0/3
Building configuration...
Current configuration : 106 bytes
!
interface FastEthernet0/3
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
end

In the above commands, the only item that is mismatching is the VTP domain. Is this why the trunk links aren’t forming?

Verificaton:

SW01 –


SW01#sh dtp
Global DTP information
Sending DTP Hello packets every 30 seconds
            Dynamic Trunk timeout is 300 seconds
6 interfaces using DTP

SW01#sh dtp int fa0/3
DTP information for FastEthernet0/3:
TOS/TAS/TNS:                              ACCESS/DESIRABLE/ACCESS
TOT/TAT/TNT:                              802.1Q/802.1Q/802.1Q
Neighbor address 1:                       001794BCE683
Neighbor address 2:                       000000000000
  Hello timer expiration (sec/state):       3/RUNNING 

 Access timer expiration (sec/state):      never/STOPPED
Negotiation timer expiration (sec/state): never/STOPPED
Multidrop timer expiration (sec/state):   never/STOPPED
FSM state:                                S2:ACCESS
# times multi & trunk                     0
Enabled:                                  yes
In STP:                                   no

Statistics
----------
128 packets received (99 good)
29 packets dropped
      0 nonegotiate, 0 bad version, 29 domain mismatches,
0 bad TLVs, 0 bad TAS, 0 bad TAT, 0 bad TOT, 0 other
131 packets output (131 good)
128 native, 3 software encap isl, 0 isl hardware native
0 output errors
1 trunk timeouts, last timeout on Mon Mar 01 1993, 00:54:43
4 link ups, last link up on Mon Mar 01 1993, 00:01:10
3 link downs, last link down on Mon Mar 01 1993, 00:01:08

Conclusion:

If one were to perform a packet capture, one would see that DTP actually transmits the VTP domain between the switches. If the switches cannot agree on the VTP domain, the switch transitions to an access port.  If the trunks are already negotiated, the switch takes 300 seconds to timeout to an access port. Which means the trunks will continue to forward traffic properly for the next 5 minutes.

VTP Version 2 and Updates

Problem:

Some of the older documentation and study guides state that VTP domains don’t need to match when set to version 2 transparent.

VTP Source 1:

“Version-dependent transparent mode; transparent mode no longer checks domain name. This enables support of more than one domain across a transparent domain.”

Some of the newer documentation states to the contrary.

VTP Source 2:

“Version-Dependent Transparent Mode—In VTP version 1, a VTP transparent switch inspects VTP messages for the domain name and version and forwards a message only if the version and domain name match. Although VTP version 2 supports only one domain, a VTP version 2 transparent switch forwards a message only when the domain name matches.”

Verification:

 

#########

CORE01#sh vtp status
VTP Version                                          : running VTP2
Configuration Revision               : 14
Maximum VLANs supported locally : 1005
Number of existing VLANs               : 17
VTP Operating Mode                          : Server
VTP Domain Name                             : TEST
VTP Pruning Mode                              : Enabled
VTP V2 Mode                                        : Enabled
VTP Traps Generation                       : Disabled
MD5 digest                      : 0x49 0x30 0x4E 0x43 0x02 0xB2 0x36 0x7A

#########

Make a change to the VTP database and then verify that the Revision number has incremented and has updated across the transparent switch. The transparent switch will not install the update into its vlan database, only pass it along.

#########

CORE01#sh vtp status
VTP Version                                         : running VTP2
Configuration Revision              : 15
Maximum VLANs supported locally : 1005
Number of existing VLANs              : 17
VTP Operating Mode                         : Server
VTP Domain Name                            : TEST
VTP Pruning Mode                             : Disabled
VTP V2 Mode                                       : Enabled
VTP Traps Generation                      : Disabled
MD5 digest                      : 0x02 0x24 0xF4 0xD7 0x11 0x28 0x33 0xFC

 

SW02#sh vtp status
VTP Version                                         : running VTP2
Configuration Revision              : 15
Maximum VLANs supported locally : 1005
Number of existing VLANs              : 17
VTP Operating Mode                         : Client
VTP Domain Name                            : TEST
VTP Pruning Mode                             : Disabled
VTP V2 Mode                                     : Enabled
VTP Traps Generation                      : Disabled
MD5 digest                      : 0x02 0x24 0xF4 0xD7 0x11 0x28 0x33 0xFC

#########

Now if the transparent switch’s domain doesn’t match that of the rest of the network, updates will fail to be forwarded.

#########

CORE02#sh vtp status
VTP Version                                          : running VTP2
Configuration Revision                      : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs               : 17
VTP Operating Mode                    : Transparent
VTP Domain Name                        : BROKEN
VTP Pruning Mode                              : Disabled
VTP V2 Mode                                        : Enabled
VTP Traps Generation                        : Disabled
MD5 digest                      :0xB3 0x30 0x72 0x9D 0x83 0x74 0xCD 0xAD

#########

 When a change is made it the vlan database, it will not update across the broken domain.

#########

CORE01(config)#do sh vtp status
VTP Version                                          : running VTP2
Configuration Revision               : 18
Maximum VLANs supported locally : 1005
Number of existing VLANs               : 18
VTP Operating Mode                          : Server
VTP Domain Name                             : TEST
VTP Pruning Mode                              : Disabled
VTP V2 Mode                                        : Enabled
VTP Traps Generation                        : Disabled
MD5 digest                   : 0xA2 0x09 0xB2 0x86 0xD8 0xC8 0xBE 0x48

 

SW02#sh vtp status
VTP Version                                          : running VTP2
Configuration Revision               : 15
Maximum VLANs supported locally : 1005
Number of existing VLANs               : 17
VTP Operating Mode                          : Client
VTP Domain Name                             : TEST
VTP Pruning Mode                              : Disabled
VTP V2 Mode                                        : Enabled
VTP Traps Generation                       : Disabled
MD5 digest                      : 0x02 0x24 0xF4 0xD7 0x11 0x28 0x33 0xFC

#########

Conclusion:

Even though the documentation has been corrected in newer version, this doesn’t mean that myth won’t continue to live on. It’s always a good idea to verify what the documentation is saying by setting up a practice lab. Or you may find that certain assumptions are incorrect.

Zone Based Firewalls – Failing to Drop/Inspect

Problem: Connectivity with zone based firewalls enabled.

#########

class-map type inspect match-any CLASS_WAN_TRAFFIC
match protocol icmp
match protocol isakmp
match protocol echo
!
!
policy-map type inspect POLICY_WAN_TRAFFIC
class type inspect CLASS_WAN_TRAFFIC
inspect
class class-default
drop log
!
zone security inside
zone security outside
zone-pair security PAIR_WAN_TRAFFIC source inside destination outside
service-policy type inspect POLICY_WAN_TRAFFIC
!
!
!
!
interface FastEthernet0/1
ip address 172.16.0.1 255.255.255.0
zone-member security inside
!
interface Serial0/0/0
ip address 10.0.0.1 255.255.255.0
zone-member security outside
#########

As you can see I am trying to inspect pings. So based on what I have read about zone based firewalls, someone pinging from the 10.0.0.0/24 subnet shouldn’t be able to reach the 172.16.0.0/24 subnet.

But when I ping the 172.16.0.0/24, I am able to reach it.

#########
PERTR01#ping 172.16.0.1 source 10.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
#########

Check the zone-pair statistics.

#########
CERTR01#sh policy-map type inspect zone-pair
 Zone-pair: PAIR_WAN_TRAFFIC

Service-policy inspect : POLICY_WAN_TRAFFIC

Class-map: CLASS_WAN_TRAFFIC (match-any)
Match: protocol icmp
        0 packets, 0 bytes
        30 second rate 0 bps
Match: protocol isakmp
0 packets, 0 bytes
30 second rate 0 bps
Match: protocol echo
0 packets, 0 bytes
30 second rate 0 bps
Inspect
Session creations since subsystem startup or last reset 0
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [0:0:0]
Last session created never
Last statistic reset never
Last session creation rate 0
Maxever session creation rate 0
Last half-open session total 0

Class-map: class-default (match-any)
Match: any
Drop
0 packets, 0 bytes

#########

Solution: So what’s the problem? Traffic destined or sourced from the router is in the special zone “self”. Traffic is set to automatically permit.

Here is my new code –

#########
class-map type inspect match-any CLASS_SELF_TRAFFIC
match protocol icmp
!
!
policy-map type inspect POLICY_OUTSIDE_SELF_TRAFFIC
class type inspect CLASS_SELF_TRAFFIC
drop
class class-default
!
policy-map type inspect POLICY_SELF_OUTSIDE_TRAFFIC
class type inspect CLASS_SELF_TRAFFIC
inspect
class class-default
!
!
zone-pair security PAIR_SELF_TRAFFIC source outside destination self
service-policy type inspect POLICY_OUTSIDE_SELF_TRAFFIC
!
zone-pair security PAIR_SELF_OUTSIDE_TRAFFIC source self destination outside
service-policy type inspect POLICY_SELF_OUTSIDE_TRAFFIC

#########

The ping is now unsuccessful.

#########

PERTR01#ping 172.16.0.1 source 10.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.2
…..
Success rate is 0 percent (0/5) 

#########

Verification: You can now see the zone-pair statistics registering the traffic.

#########

CERTR01#sh policy-map type inspect zone-pair PAIR_SELF_TRAFFIC
Zone-pair: PAIR_SELF_TRAFFIC
Service-policy inspect : POLICY_OUTSIDE_SELF_TRAFFIC

Class-map: CLASS_SELF_TRAFFIC (match-any)
     Match: protocol icmp
        10 packets, 800 bytes
        30 second rate 0 bps
      Drop
        10 packets, 800 bytes

Class-map: class-default (match-any)
Match: any
Drop (default action)
0 packets, 0 bytes

#########

WAAS Failed to Fetch Encryption Key from Central Manager

Problem: Devices are unable to access the secure store.

#########

2012 Jan 24 10:39:23 WAV01 java: %WAAS-CMS-4-700001: CESecureStoreFacade(main): Failed to retrieve key from key manager.Can’t retrieve key from CM
2012 Jan 24 10:39:23 WAV01 ss_init: %WAAS-CMS-2-700001 Failed to fetch encryption key from Central Manager to open secure store, try 163
2012 Jan 24 10:39:43 WAV01 java: %WAAS-CMS-4-700001: ce(DataFeedPoll): Error processing configuration updates: SecureStoreNotReadyException@com.cisco.unicorn.director.DataFeedAgent.encryptData (DataFeedAge
nt.java:3616) UserConfig_14729:Secure store is initialized but not open. Please open secure store. Failed to encrypt data . Rejecting updates from CM.
2012 Jan 24 10:39:54 WAV01 java: %WAAS-CMS-4-700001: CESecureStoreFacade(main): Failed to retrieve key from key manager.Can’t retrieve key from CM
2012 Jan 24 10:39:54 WAV01 ss_init: %WAAS-CMS-2-700001 Failed to fetch encryption key from Central Manager to open secure store, try 164

#########

This error will show up in the GUI of your central manager as well.

Solution: There are two ways to fix this.

1.(Preferred) Reset the crypto keys and re-initialize the secure store on the device with the error message. The warnings you will get will differ than what I have listed below. You will want to type ‘yes’ to all responses. If the secure store doesn’t initialize, try again. I had a few warnings that I had entered the commands to quickly (seriously.)

#########

WAV01#crypto pki managed-store initialize
Managed store key is set successfully, no need to re-init. Are you sure you want to continue(yes/no)? [no]:yes
All certificate/private keys in SSL managed store will be deleted and optimized SSL traffic will be interrupted. Are you sure you want to continue(yes/no)? [no]:yes

WAV01#cms secure-store init

#########

2. This solution should be tried at your own risk. This is the nuke option. You will need to de-register and then re-register the device with the central manger. This should only be done as a last resort.

####WARNING!#####

WAV01#cms deregister

WAV01#config t
WAV01(config)#cms enable

####WARNING!#####

This is like registering the device as brand new. Any location information will be lost, etc.

 

Verification: Verify the accelerator and the secure store.

#########

WAV01#sh accelerator
Accelerator     Licensed        Config State    Operational State
———–     ——–        ————    —————–
cifs            Yes             Enabled         Running
epm             Yes             Enabled         Running
http            Yes             Enabled         Running
mapi            Yes             Enabled         Running
nfs             Yes             Enabled         Running
ssl             Yes             Enabled         Running
video           No              Enabled         Shutdown

WAV01#sh cms secure-store
Secure-store is initialized and open.

 

Wireless Integrated Routing and Bridging(IRB) with ARP Caching

Problem: Unable to connect to a host connected to the wireless network on the same subnet but different segments (e.g. switchport or access point.)

 Network Hosts Visio Diagram

If the host on the wireless segment originates the ping, the ping will be successful.

Network Hosts Visio Diagram

But if another host on the different segment originates the ping, the ping will most likely fail. In my environment, sometimes it worked and sometimes it didn’t.

Network Hosts Visio Diagram

 

#########

Windows Ping results –

C:\Users\network-haven>ping 10.0.0.1

Pinging wireless-user [10.0.0.1] with 32 bytes of data:

Reply from 10.0.0.2: Destination host unreachable.
Reply from 10.0.0.2: Destination host unreachable.
Reply from 10.0.0.2: Destination host unreachable.
Reply from 10.0.0.2: Destination host unreachable.

Ping statistics for 10.0.0.1:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

#########

Depending on the order of operations, you will not see the ARP entry for the respective IP addresses on the respective hosts. If you try to ping from the wireless host first, the entries will most likely show up.

This is partly due to bridging being enabled. Essentially, bridge groups will restrict broadcasts and multicasts. ARP works off of broadcasts. It appears that the access point shouldn’t allow broadcasts through at all.
Sources: Bridge Group Configuration

How ARP Works

 

Yet, everything points to the contrary on the network. It looks like you should be able to reach the host on the wireless segment. The switches show the proper layer 2 addresses. The access point doesn’t show the hosts dropping off. You can ping and connect to the host from a different subnet (e.g. 10.0.1.1 /24).

Solution: Enable ARP caching. The access point will reply to ARP requests on behalf of the host.

#########

Command: AP(config)#dot11 arp-cache optional

#########
Source: Configure ARP Caching

NOTE: I am running Version 12.4(25d)JA

CAUTION: DO NOT ENABLE THIS ON BRIDGED ACCESS POINTS; ARP REQUESTS WILL FAIL.

WAAS BVI Configuration

How to implement BVI on a WAAS device to support the virtual machine features. This is what I came up with for a remote device that is in production. This limits the impact to operations.

WARNING: This is not an inline configuration – I am using WCCP. Do not use this config on an inline configuration.

  • Log into the device using telnet –
  • Run the following command (Put the device name in place of Nameofdevice) –

copy startup-config ftp SERVER-IP Nameofdevice

  • Browse to the directory of the FTP server
  • Open the file and replace the following code –

primary-interface GigabitEthernet 1/0
!
interface GigabitEthernet 1/0
ip address ##IP Address of copied device## ##Subnet Address##
exit
!

  • Put in place (Make Sure to copy the IP Address over!!!)–
  • NOTE: If you are using radius, make sure to copy the radius password into the config. Otherwise you will notice that when you upload the new change, it will not be applied.

primary-interface BVI 1
!
bridge 1 protocol ieee
!
interface BVI 1
ip address ##IP address of copied device## ##Subnet Address##
exit
!
interface GigabitEthernet 1/0
bridge-group 1
exit
!

  • Go back to the telnet session –

copy ftp disk SERVER-IP / Nameofdevice Nameofdevice

Some notes on this command – The “/” stands for the root directory
The first name stands for the remote file name
The second name is what you want it called on the upload

copy disk startup-config Nameofdevice

  • Reboot the device –

reload
Proceed with reload?[confirm]
Proceed with clean WCCP shutdown?[confirm]
Existing connections =    72 Press ^C to skip waiting for clean WCCP shutdown

Note – Let the system reboot on its own, if it asks you to save configuration changes, don’t.

System configuration has been modified. Save?[yes]:no

I rebooted one of my WAE-274 devices; clean reboot of course. It took approximately 6 Minutes 52 Seconds for a full reload – mileage will vary.

VTP Transparent Mode – Persistent VLANs

Why do my VLANs persist even though I run “delete flash:vlan.dat”?

If you are running VTP in transparent mode the VLAN data will show up in the running config.

#########

Switch1#sh run | in vlan
vlan internal allocation policy ascending
Switch1#sh vlan
VLAN Name Status    Ports
—- ——————————– ——— ——————————-
1    default                          active    Fa0/1, Fa0/2, Fa0/3, Fa0/4, Fa0/5, Fa0/6, Gi0/1
180 TESTTHIS           active
190 go                            active
201 WAAS                     active
255 GUEST-WIRELESS active

Switch1#sh vtp status
VTP Version                     : running VTP1 (VTP2 capable)
Configuration Revision          : 0
Maximum VLANs supported locally : 255
Number of existing VLANs        : 9
VTP Operating Mode              : Client
VTP Domain Name                 : test
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Disabled
VTP Traps Generation            : Disabled

Switch1#config t
Enter configuration commands, one per line. End with CNTL/Z.

Switch1(config)#vtp mode transparent
Setting device to VTP TRANSPARENT mode.
Switch1(config)#end
Switch1#sh vtp status
VTP Version                     : running VTP1 (VTP2 capable)
Configuration Revision          : 0
Maximum VLANs supported locally : 255
Number of existing VLANs        : 9
VTP Operating Mode              : Transparent
VTP Domain Name                 : test
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Disabled
VTP Traps Generation            : Disabled
Switch1#sh run | in vlan
vlan internal allocation policy ascending
vlan 180
vlan 190
vlan 201
vlan 255

#########

What this means is if you are trying to delete the vlan.dat file and it keeps showing up in your flash: it isn’t because the switch is saving it. The VLANs now exist in the configuration file. Simply do a “no vlan #” in global config and it will be deleted.

#########
Switch1#config t
Enter configuration commands, one per line. End with CNTL/Z.

Switch1(config)#no vlan 180
Switch1(config)#end
Switch1#sh vlan
VLAN Name Status    Ports
—- ——————————– ——— ——————————-
1    default                          active    Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Gi0/1
190 go                              active
201  WAAS                         active
255  GUEST-WIRELESS   active

#########

The one thing about this change is that the command line does not tell you this is happening. You have to be aware that the change occurs in the background.

IP Mobility Quick and Dirty

LAM: Local Area Mobility

Advantages: Allows mobility of a single or multiple addresses onto a different subnet. Essentially, this allows you to take an IP address (10.0.0.1) and put it on a different subnet (172.16.0.1/24) and still maintain the 10.0.0.1 address.

Pros: Easy to setup. Mobility of IP addresses.

Cons: Does not work on the 4500 L3 switches running (cat4500e-ENTSERVICES-M), Version 12.2(54)SG. 6500 switches have not been tested. Potential to allow any IP address on the configured mobility subnet. Essentially, if I plug a device with any IP address I want it will be advertised out from the mobility subnet. You can create acl’s to limit this.

Limitations:Do not move the IP address more than once per second.  Potential additional load on the routers.  The router that advertises the mobile client out will advertise a host route.

 

Configuration:

Router(config)# router mobile

Router(config)# interface GiabitEthernet(0/0)

Router(config-if)# ip mobile arp access-group 10

Router(config)# access-list 10 permit 10.10.10.0 0.0.0.255

What this does:

  1. Enables Mobility on the router
  2. Enables Mobility on the inside interface of the router with an ACL
  3. Limits the Mobility Address Range to 10.10.10.0/24

Configuration
Redistribute Mobile Routes:

Router(config)#router bgp 1

Router(config-router)#redistribute mobile

Router(config)#router eigrp 1

Router(config-router)#redistribute mobile metric 10 2000 255 1 1500

Verification:

Router#sh ip route mobile

Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP

D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2

E1 – OSPF external type 1, E2 – OSPF external type 2

i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2

ia – IS-IS inter area, * – candidate default, U – per-user static route

o – ODR, P – periodic downloaded static route, + – replicated route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 73 subnets, 7 masks

M        10.10.10.213/32[3/1] via 10.10.10.213, 19:46:26, GigabitEthernet0/0

Router#sh ip int bri

Interface IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0    172.16.0.250   YES NVRAM up                    up

Router#sh ip mobile int

IP Mobility interface information:
Interface GigabitEthernet0/0:
IRDP (includes agent advertisement) disabled
Prefix Length not advertised
Lifetime is 36000 seconds

 

Real World
Application-

Ability to easily move Virtual Machines to another site or subnet without the need to Re-IP them.

VPN Quick Mode Failed

Error Message-

%CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer at X.X.X.X

Common Debug Commands-

debug crypto isakmp

debug crypto engine

debug crypto ipsec

Results from Debug Crypto Isakmp-

Jul 20 17:08:50: map_db_find_best did not find matching map
Jul 20 17:08:50: IPSEC(validate_transform_proposal): no IPSEC cryptomap exists for local address 10.0.0.1
Jul 20 17:08:50: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 10.0.0.1, remote= 192.168.0.1,
local_proxy= 10.0.1.0/255.255.255.0/0/0 (type=4),
remote_proxy= 192.168.0.0/255.255.0.0/0/0 (type=4),

protocol= ESP, transform= esp-3des esp-md5-hmac  (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x2

What this means-

Access list applied to crypto map is misconfigured.

For Instance-

RTR1

access-list encrypt permit ip 10.0.0.0 0.0.0.255 192.168.0.0 0.0.0.255

RTR2

access-list encrypt permit ip 192.168.0.0 0.0.0.255 10.0.1.0 0.0.0.255

These two access lists conflict which in turn produce the error message above.

Real World Application-

When working with a disparate team at another company, miscommunication will occur. With something as both simple and complex as a VPN connection, mistakes will occur. By producing the above debug code, you can inform the other team of the necessary corrections. Or even maybe make the corrections on your side.

Source 1: Website / PDF

Scroll to Top