Cisco 7965 IP Phone login fails

Posted on by
Reply

201 Authentication Error

Problem

When the credential policy for a user is set to “User Must Change at Next Login,” the user is prompted to change their PIN with the message [209]-Change PIN. However, when the user enters the new PIN, the [201]-Authenticaiton Error message displays and the user is not able to log in.

Solution 1

Reset the user password/PIN in order to resolve the issue. Go to the user page and click the Edit Credentials button located near the password. Also, make sure the locked by the administrator field is unchecked.

This isssue can also occur if the end users are using the alphanumeric characters to log in to extension mobility since it is configured to use only numeric characters during log in. Go to the Extension Mobility service parameter Alphanumeric User ID and check if it is set to False. If it is, make sure that the end users are using only numeric characters during log in.

Solution 2

When the user tries to log in to Extension Mobility, the userid and PIN are validated through the Identity Management System (IMS). If the IMS returns a Change PIN error, the current implementation of Extension Mobility displays an error message on the phone to change the PIN. Users must change their PIN though the ccmuser pages and then attempt to log in. It is not possible to change the PIN from the phone.

Error: Login is unavailable (205)

Problem

You receive this error message when you try to log in to Extension Mobility:

Login is unavailable (205)

Solution

In order to resolve this issue, associate the phone to the Extension Mobility Controlled Profile.

http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-version-60/109704-cucm6x-em-error.html#autherr

Configuring SNMP

Posted on by
Reply

Overview of Capabilities

Cisco routers and switches contain SNMP agents that can respond to standard SNMP get and set operations. That is, a management station can ask the Cisco device for information via an SNMP get, or it can tell the device to change some setting or take some actions, via a set operation. The device can also spontaneously originate traps or SNMPv2c inform notifications.

The Cisco IOS now (12.0) complies with SNMPv2c. They used to support the draft SNMPv2 Classic but pulled the security features in 11.3 when the version 2 standardization effort fell apart. SNMP version 3 is in 12.0(3) T. See the new features documentation for details (which would be an article in themselves), athttp://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t3/snmp3.htm .

The Cisco IOS also supports the router acting as an SNMP Manager. That means it can send SNMP get requests, receive replies, and receive traps or notifications.
This seems to have been in the documentation since 10.0. But other than enabling the feature, the documentation provides no information as to how to tell the router that it is supposed to send SNMP gets. Or maybe I’m missing something here. If anyone can point me in the right direction, I’d appreciate it (and pass it on in this CiscoWorld column).

For Service Providers, who need substantial information collection at remote sites, there is the system controller SC3640 and associated commands. You can read more about this athttp://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/fun_c/fcprt3/fcsyscon.htm . We won’t go into that since it’s presumably of interest only to a smaller audience.

Those who have been tracking my articles know about the RMON (version 1) capabilities in Cisco routers and switches (“mini-RMON”). This provides an excellent way to spot the devices, links, or ports that are getting into trouble. The 2500 and AS5200 routers provide full RMON version 1 support. (Beware what it may do to the router CPU). Since the prior articles are on my Web page, I won’t go into more detail here. Some reasonably good information may also be found at http://www.cisco.com/warp/public/701/25.html andhttp://www.cisco.com/warp/public/79/17.html . Some slightly stale information is athttp://www.cisco.com/warp/partner/synchronicd/cc/cisco/mkt/enm/cwsiman/tech/rmon2_wp.html .

The Response Time Reporter (RTR) feature in Cisco routers allows the router to track response time information, using IP and SNA probe packets. You can send IP ICMP Echo, SNA SSCP echo, SNA LU type 0 to Cisco NSPECHO program, or SNA LU type 2 to Cisco NSPECHO program. The measurement can either be Echo Round Trip Time, or hop-by-hop analysis. The collected measurements can be used for longer-term trending. The router can report response time threshold violations via traps or SNA Alerts / Resolutions. This is another whole topic in itself. If you’re interested, you might want to look into the Internetwork Performance Monitor software, which is intended to make it easier to access the RTR features in routers. See also http://www.cisco.com/warp/customer/cc/cisco/mkt/enm/cw2000/ipm/index.shtml for the marketing info, and also the Software Center page, http://www.cisco.com/kobayashi/sw-center/netmgmt/cw2000/IPM.html .

In addition to SNMP, Cisco routers can also be managed via syslog reporting. As I’ve mentioned in a prior article, the CiscoWorks 2000 Resource Manager Essentials syslog reporting tool gives very useful access and reporting of this data. As we’ll see below, there’s a tie-in to SNMP.

Configuring SNMP Access in Routers

The first thing you need to do is enable SNMP access. This is done by configuring community strings, which act somewhat like passwords. (The difference is that there can be several community strings, and that each one may grant different forms of access). Here’s what this might look like when configured:

snmp-server community public ro
snmp-server community ourCommStr ro
snmp-server community topsecret rw 60
snmp-server community hideit ro view noRouteTableaccess-list 60 permit 10.1.1.1
access-list 60 permit 10.2.2.2

The first two lines allow read-only (get) SNMP access using either string. We configure our management stations with “ourCommStr” so we can easily cut off access via the well-known community string “public” if we so wish. (Note: non-IOS-based Cisco switches apparently do not allow multiple read-only community strings).

The third line configures the read-write (get/set) SNMP community string. This should not be the well-known string “private” (unless you like having an insecure network). The “60” restricts access to sources permitted via standard access-list 60 (the sample shown lists the individual network management stations permitted to do read-write SNMP operations, you could also use a wildcard mask to allow all stations on selected subnets access).

The fourth line says that those using the community string “hideit” are restricted to information in the view named “noRouteTable”. This might be used to keep management stations (and HPOV Network Node Manager) from pulling huge BGP / Internet routing tables from selected routers, for example:

snmp-server view noRouteTable internet included
snmp-server view noRouteTable ip.21 excluded
snmp-server view noRouteTable ip.22 excluded
snmp-server view noRouteTable ifMIB excluded

Configuring SNMP Traps in Routers

The next thing you’ll probably want to do is get those very useful trouble-indicators, SNMP traps, sent to your management station(s).The way to configure this is as follows:

snmp-server host 10.1.1.1 public

This sends any and all SNMP traps the router sends to host 10.1.1.1 using community string “public”. (There’s no point in exposing your real community strings here — I’d just use “public” unless I ran across some incredibly picky network management software that was silly enough to try to enforce “correct” community strings on inbound traps).

If you wish to be more selective, you can list all the varieties of traps that go to each host:

snmp-server host 10.1.1.1 public snmp bgp
snmp-server host 10.2.2.2 public snmp frame-relay

This says that 10.1.1.1 is to get any SNMP or BGP traps, and 10.2.2.2 gets SNMP and frame relay traps.

This is a good way to nip any undesired messages at the source, rather than wasting network bandwidth on them, only to throw them away using HPOV or your trouble ticket system. On the other hand, life is too short to be diddling what traps go where on more than a few routers.

There is a long list of flavors of traps you can control in this fashion. Check the IOS manual or the router help for the latest items. Note that all the flavors of traps for a particular destination host go on one and the same (long!) line. Omitting any flavors list means they all get sent to that host.

You can also alter whether SNMP version 1 or 2c traps are sent, and what UDP port the traps are sent to.

If the above is all you configure, you may notice some deafening silence. You need to turn on the sending of traps in the first place — the above commands just control who gets which traps. Turn on trap sending by configuring:

snmp-server enable traps

This turns on all the varieties of traps. You can also turn on specific traps, by appending them to the above command, one trap variant at time. Some allow for further specificity. For example

snmp-server enable traps frame-relay
snmp-server enable traps envmon temperature
snmp-server enable traps bgp
snmp-server enable traps snmp

This says the router should send the standard SNMP traps, and also BGP, Frame Relay, and Environmental Monitor traps (but only the temperature type of envmon traps).

One intriguing variety of traps you can enable is the config traps. This records on your management station that someone has configured the router. If you have way too many hands with enable password access, this can be a valuable trouble-shooting tool (“what changed, and who did it”).

Another useful variety of traps is the syslog option to this command. This causes router console messages to be repackaged as SNMP traps and sent to (selected) management stations. I see this as primarily useful in a PC environment, where you don’t wish to run freeware syslog on NT, and are perhaps using HPOV ProSuite or SNMPc as trap receiver. If you wish to use the syslog reporting in CiscoWorks 2000 (CW2000) Resource Manager Essentials (RME), you will need to send console message to management station via syslog. Turning on the syslog trap option would then double the amount of such traffic on your network.

You probably do not want to invoke the “tty” option on  the snmp-server enable traps command. The TTY traps inform you of termination of a telnet session, which can get rather chatty and annoying. They are primarily for “milking machine” situations, where protocol translation maps some bit stream across a TCP connection between paired access servers.

You can control linkUp/linkDown traps on the interface level. To avoid hearing about every call your ISDN backup interface makes, configure:

interface bri 0/0
no snmp trap link-status

Other SNMP Commands in Routers

The above is the most important part of SNMP. To keep this brief, here is a sample of some other things you might wish to configure:

snmp-server contact Orville Wright, Network Operations, (999) 123-4567
snmp-server location Engineering Dept., Floor 6, Building A-20, New York City
snmp-server system-shutdown
snmp-server tftp-server-list 60
no snmp-server trap-authenticationinterface loopback 0
ip address 10.5.5.5 255.255.255.255
snmp-server trap-source loopback 0

The first two lines specify the SNMP-retrievable contact and location. Useful, particularly if you have a lot of devices with different owners.

The system-shutdown command allows a certain SNMP set operation to trigger a router reboot. CiscoWorks and RME use this when upgrading routers.

The TFTP server list allows you to restrict the TFTP servers used by SNMP-triggered TFTP operations. CiscoWorks and RME can use TFTP to move configuration files and IOS images, so you might well want to restrict the sources/destinations for better security. The list of servers might well be the same access list 60 that lists management stations permitted to do SNMP set operations.

You might well want to set the trap source address to be that of the loopback interface. Many sites wish to use this as the official management address of the router.This is a good practice, since when a key interface is down, network management software may be unable to talk to the router. If you ensure that the device name always resolves first to the loopback address (which depends on knowing you DNS server software), then there is less likely to be a problem with connectivity due to downed interface. Setting the trap source to this address then ensures that when reverse name mapping resolves the loopback address to a hostname, the correct name is used. This means the network management software will be able to identify the device in question and, if appropriate, turn the icon red.

Less important SNMP-related router commands:

snmp-server chassis-id 123-45678
snmp-server packetsize 1500
snmp-server queue-length 1
snmp-server trap-timeout 30

The chassis ID defaults to the software chassis id, burned into the CPU card on the router. You may wish to change this to the external serial number, for automated SNMP updating of your records. (Generally this is under-appreciated until you try to RMA a dead router that you don’t know the serial number of, or didn’t purchase support for). I’m not quite sure doing this is best practice, but it might be convenient.

Packetsize specifies how big an SNMP get or set is allowed. The default is now 1500 bytes. Increasing the setting may allow more information to be transferred in one operation. If you have MIB’s with table with many entries in a row, then this is useful to avoid tooBig errors. (SunNet Manager used to do this with the old Cisco MIB). Increasing the number with older IOS releases, from 484 to 1500, seems like a good bet.

Queue-length and trap-timeout refer to retransmission queue for SNMP traps. When an interface fails, the router may be temporarily unable to send the linkDown trap. This might be due to routing protocol convergence, the need to dial up HQ, or other causes. The router will then periodically (every 30 seconds, by default) re-try sending the SNMP trap(s) it couldn’t send. The trap-timeout changes this retry interval, default 30 seconds. The queue-length is how many traps get saved for retransmission in this fashion, default 10.

If you don’t have dial backup, you might wish to set the queue-length to 1. (Is zero allowed?) Otherwise, when a link outage is resolved, you then get a bunch of very stale and old traps telling you about the outage you just fixed.

Free & Public DNS Servers

Posted on by
Reply
Provider Primary DNS Server Secondary DNS Server
Level31 209.244.0.3 209.244.0.4
Google2 8.8.8.8 8.8.4.4
Comodo Secure DNS 8.26.56.26 8.20.247.20
OpenDNS Home3 208.67.222.222 208.67.220.220
DNS Advantage 156.154.70.1 156.154.71.1
Norton ConnectSafe4 199.85.126.10 199.85.127.10
GreenTeamDNS5 81.218.119.11 209.88.198.133
SafeDNS6 195.46.39.39 195.46.39.40
OpenNIC7 216.87.84.211 23.90.4.6
Public-Root8 199.5.157.131 208.71.35.137
SmartViper 208.76.50.50 208.76.51.51
Dyn 216.146.35.35 216.146.36.36
censurfridns.dk9 89.233.43.71 89.104.194.142
Hurricane Electric10 74.82.42.42
puntCAT11 109.69.8.51

[1] The DNS servers listed above as Level3 will automatically route to the nearest DNS server operated by Level3 Communications, the company that provides most of the ISPs in the US their access to the Internet backbone.

[2] Google also offers IPv6 public DNS servers: 2001:4860:4860::8888 and 2001:4860:4860::8844.

[3] OpenDNS also offers DNS servers that block adult content, called OpenDNS FamilyShield. It’s also free but you do have to sign up here. A premium DNS offering is also available, called OpenDNS Home VIP.

[4] The Norton ConnectSafe DNS servers listed above block sites hosting malware, phishing schemes, and scams, and is called Policy 1. Use Policy 2 (199.85.126.20 and 199.85.127.20) to block those sites plus those with pornographic content. Use Policy 3 (199.85.126.30 and 199.85.127.30) to block all previously mentioned site categories plus those Norton deems “non-family friendly.” Be sure to check out the list of things blocked in Policy 3 – there are several controversial topics in there that you may find perfectly acceptable.

[5] GreenTeamDNS “blocks 18 categories which include malware, botnets, dangerous websites, adult related content, aggressive/violent sites as well as advertisements and drug-related websites” according to their FAQ page. Premium accounts have more control.

[6] Register here with SafeDNS for content filtering options in several areas.

[7] The DNS servers listed here for OpenNIC are just two of many in the US and across the globe. Instead of using the OpenNIC DNS servers listed above, see their complete list of public DNS servers here and use two that are close to you or, better yet, let them tell you that automatically here. OpenNIC also offers some IPv6 public DNS servers.

[8] These Public-Root DNS servers are the only two currently operating in the United States but if you’re located ouside the US, see their complete list here and choose the best servers based on your location.

[9] The censurfridns.dk DNS servers are uncensored, operated by a privately funded individual, and are physically located in Denmark. You can read more about them here. IPv6 DNS servers are also available at 2002:d596:2a92:1:71:53:: and 2002:5968:c28e::53

[10] Hurricane Electric also has an IPv6 public DNS server available: 2001:470:20::2.

[11] puntCAT is physically located near Barcelona, Spain. The IPv6 version of their DNS server is 2a00:1508:0:4::9.

Note: Primary DNS servers are sometimes called preferred DNS servers and secondary DNS servers are sometimes called alternate DNS servers. Primary and secondary DNS servers can be “mixed and matched” to provide another layer of redundancy.

Understanding debug isdn q931 Disconnect Cause Codes

Posted on by
Reply

Here is a sample output of the debug isdn q931 command. The output indicates the disconnect cause code for a failed ISDN call:

Calling#ping 10.10.10.2 
   Type escape sequence to abort. 
   Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds: 
   20:52:14: ISDN BR0: TX -> SETUP pd = 8 callref = 0x2E 
   20:52:14: Bearer Capability i = 0x8890 
   20:52:14: Channel ID i = 0x83 20:52:14: Keypad Facility i = '5551111' 
   20:52:15: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0xAE 
   20:52:15: Channel ID i = 0x89

   20:52:16: ISDN BR0: RX <- PROGRESS pd = 8 callref = 0xAE 
   20:52:16: Progress Ind i = 0x8A81 - Call not end-to-end ISDN,
     may have in-band info 
   20:52:16: Signal i = 0x01 - Ring back tone on
   20:52:34: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xAE 
   20:52:34: Cause i =0x829F08 - Normal,unspecified or Special intercept,
     call blocked group restriction     
   20:52:34: ISDN BR0: TX -> RELEASE pd = 8 callref = 0x2E 
   20:52:34: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0xAE

The 0x in the disconnect code indicates that the subsequent bytes are in hexadecimal format and are not part of the actual code. This table provides a breakdown of the code after you strip the 0x from the debug output:

Cause i = 0x829F08
Parsed Hex Bytes 82 9F 08
Description Cause Code Origination Point Disconnect Cause Code Optional Diagnostic field

Cause Code Origination Point

The first byte (most significant) after 0x indicates the point in the circuit path where the disconnect cause code appears. Consider the sample output in the Introduction section. 82 indicates that the call disconnects from the local telco switch. Here is a list of cause code origination points that help you interpret where the call disconnects from:

  • 80—the router
  • 81—the private network near the local user (possibly a local private branch exchange [PBX])
  • 82—the public network near the local user (local telco switch)
  • 83—the transit network (in the ISDN cloud)
  • 84—the public network near the remote user (remote telco switch)
  • 85—the private the network near the remote user (possibly a remote PBX)
  • 87—the international network
  • 8A—a network beyond the internetworking point

Disconnect Cause Code

The next byte (9F in the sample output) that follows the cause code origination point byte is the Disconnect Cause Code. This byte helps you to troubleshoot the disconnection.

Use this table to associate a Disconnect Cause Code (in Hex) and the Cause Description to determine the disconnect reason:

Hex Code Cause Description Additional Information
80 Normal Disconnect The call disconnects normally.
81 Unallocated or unassigned number The switch receives the ISDN number in the correct format. However, the number does not belong to destination equipment.
82 No route to specified network The ISDN exchange receives a request to route the call through an unrecognized intermediate network. This cause indicates that the equipment receives a request to route the call through a particular transit network. However, the equipment does not recognize the network. The equipment that sends this cause does not recognize the transit network due to one of these reasons:

  • The transit network does not exist.
  • The transit network exists, but does not serve the equipment that sends this cause.

This cause is supported on a network-dependent basis.
83 No route to destination The call routes through an intermediate network that does not serve the destination address. This cause indicates that the called user is not reachable. A user is not reachable when the network used to route the call does not serve the required destination. This cause is supported on a network-dependent basis.
84 Send special information tone The remote number you dialed is not reachable. Check the number you dial. Verify if you need any prefixes to access the network. For example, you need to dial 9 for outbound calls through a PBX. Contact your telco/PBX administrator for details.
85 Misdialled trunk prefix. The remote number you dialed is not reachable. Check the number you dial. Verify if you need any prefixes to access the network. For example, you need to dial 9 for outbound calls through a PBX. Contact your telco/PBX administrator for details.
86 Channel unacceptable The service quality of the specified channel is insufficient to accept the connection. The call attempt fails because the channel is unusable. If you use a PBX, check the configuration of the PBX. For a PRI, find out how many channels your telco provides.
87 Call awarded and delivered in established channel The user assigns an incoming call that connects to an already established call channel. This cause indicates that the user receives an incoming call, which connects to a channel already in use for similar calls (for example, packet-mode X.25 virtual calls).
88 Preemption Your call is blocked. Calls are sometimes blocked if another call has a higher priority than your call. This situation is common with voice calls. Wait and call again later. If you use a PBX (or the remote site to which you connect uses a PBX), check the configuration of the PBX. If the condition persists, contact your telco.
89 Preemption, circuit reserved for re-use Your call is blocked. Calls are sometimes blocked if another call has a higher priority than your call. This situation is common with voice calls. Wait and call again later. If either side uses a PBX, check the configuration of the PBX. If the condition persists, contact your telco.
90 Normal call clearing Normal call clearing occurs. You do not need to perform any action. This cause indicates that the call disconnects because one of the users involved in the call has made a request to clear the call. Under normal situations, the network is not the source of this cause. If the call fails with this Disconnect Cause Code, the call most likely fails at a higher layer protocol such as PPP, authentication or idle timeout related issues. Verify the router configuration. Also, if you have requested a callback, the remote device disconnects the call, generates this code, and then calls you back.
91 User busy The called system acknowledges the connection request. However, the system cannot accept the call because all B-channels are in use. The user equipment is compatible with the call in this situation.Note: If you have multiple ISDN circuits, the telco can configure them in a “hunt-group”, in which calls switch to the next available circuit.
92 No user response The connection fails because the destination does not respond to the call. This cause indicates that a user does not respond to a call establishment message within the prescribed period. The user must respond with either an alert or connect indication according to ITU-T Q.931, when either timer T303 or T310 expires.
93 No answer from user The destination responds to the connection request but fails to complete the connection within the prescribed time. This cause indicates that a user has provided an alert indication, but has not provided a connect indication within a prescribed period. Q.931 procedures do not necessarily generate this cause. Internal network timers sometimes generate this cause. The problem is at the remote end of the connection.
94 Subscriber absent The remote device you attempt to reach is unavailable and is disconnected from the ISDN network. Contact the person responsible for that device.
95 Call rejected The destination is able to accept the call but rejects the call for an unknown reason. This cause indicates that the equipment that sends this cause does not want to accept this call.Note: The equipment is able to accept the call because the equipment that sends this cause is neither busy nor incompatible. However, the equipment rejects the call.
96 Number changed The ISDN number used to set up the call does not belong to a system. A caller receives this cause when the called party number is no longer assigned. You can optionally include the new called party number in the diagnostic field. If a network does not support this capability, the caller receives cause No. 81, unassigned (unallocated) number.
97 Redirection to new destination Your call is routed to a different ISDN number. Check the number you call. Also verify the PBX configuration (if you use PBX).
99 Exchange routing error Your call cannot be successfully routed to the remote party. Check the number you call. Also verify the PBX configuration (if you use PBX).
9A Non-selected user clearing The destination is able to accept the call. However, the destination rejects the call because the call is not assigned to a user.
9B Destination out of order The destination is not reachable because of an interface malfunction. In addition, a signaling message cannot be delivered. This condition can be temporary. However, the condition can last for an extended period in some cases. This cause indicates that a signaling message could not be delivered to the remote user. For example, a physical layer or data link layer fails at the remote user end, and the user equipment is off-line (turned off).
9C Invalid number format The connection fails because the destination address is in an unrecognizable format, or is incomplete. Verify whether the format of the number is correct. This includes any appropriate digits for a PBX, and long distance.
9D Facility rejected The network cannot provide the facility that the user requests.
9E Response to STATUS ENQUIRY The status message appears in direct response to the receipt of a status inquiry message.
9F Normal, unspecified This message reports the occurrence of a normal event when no standard cause applies. No action is required.
A1 Circuit out of order The call cannot go through due to some problem in the ISDN network.
A2 No channel available The connection fails because no appropriate channel is available to take the call.
A3 Destination unattainable The destination is not reachable through the Telco network. Contact the Telco.
A4 Out of order Some part of the network necessary to route the call is out of order. The destination is not reachable because of a network malfunction. The condition can last for an extended period. An immediate attempt to reconnect will probably fail. If you use a long distance carrier, try to use a Presubscribed Inter-exchange Carrier (PIC). For example, you can use a 10-10-xyz carrier. A PIC enables you to verify whether the problem lies with the long distance carrier.
A6 Network out of order The destination is not reachable because of a network malfunction. The condition can last for an extended period. An immediate attempt to reconnect will probably fail. If you use a long distance carrier, try to use a Presubscribed Inter-exchange Carrier (PIC). For example, you can use a 10-10-xyz carrier. A PIC enables you to verify whether the problem lies with the long distance carrier.
A7 Permanent frame mode connection out of service This message indicates that equipment failure probably terminates the permanent connection. If the problem persists, contact your telco
A8 Permanent frame mode connection operational This message occurs when the permanent connection is fully operational again after a termination. Equipment failure probably terminated the connection previously.
A9 Temporary failure An error occurs because of a network malfunction. Contact the telco if the problem persists.
AA Switching equipment congestion The destination is not reachable because of a temporary overload on the network switching equipment. Try again later.
AB Access information discarded The network cannot provide the access information that the user requests. This cause indicates that the network is unable to deliver access information to the remote user. For example, user-to-user information, low layer compatibility, high layer compatibility, or a sub-address as the diagnostic indicates.Note: You have the option to include the particular type of discarded access information in the diagnostic.
AC Requested channel not available The remote equipment cannot provide the channel that the user requests, due to an unknown reason. This problem is usually temporary.
AF Resources unavailable, unspecified The channel or service that the user requests is unavailable for an unknown reason. This problem is usually temporary.
B1 Quality of service (QoS) unavailable The network cannot provide the quality of service that the user requests. This issue can occur due to a subscription problem. This cause reports that the network cannot provide the QoS as defined in Recommendation X.213. For example, this cause code appears when the network cannot support throughput or transit delay.
B2 Requested facility not subscribed The remote equipment supports the supplementary service by subscription only. This cause indicates that the network cannot provide the supplementary service that the user requests. The user has probably not completed the necessary administrative arrangements with the supporting networks. The ISDN network can also return this cause code when a user makes a call attempt, but does not enter the SPIDs, or enters the SPIDs incorrectly. Ensure that your SPIDs are correct, or contact your telco to verify your SPIDs. Also verify the speed of the outgoing call that the ISDN network supports (56k or 64k).
B4 Outgoing calls barred There is some restriction on outgoing calls. The ISDN network does not allow you to make outgoing calls.
B5 Outgoing calls barred within CUG1 There is some restriction on outgoing calls. The ISDN network does not allow you to make outgoing calls.
B6 Incoming calls barred The ISDN network does not allow you to receive calls. Contact your telco.
B7 Incoming calls barred within CUG1 The ISDN network does not allow you to receive calls. Contact your telco.
B9 Bearer capability not authorized A subscription problem usually causes this issue. This cause indicates that the user requests a bearer capability that the equipment implements, but the user does not have the authorization to use the capability.
BA Bearer capability not presently available The network normally provides the bearer capability that the user requests. However, if the capability is unavailable currently, this cause appears. A temporary network problem or a subscription problem can cause this issue. If the incoming call is Analog (modem call), verify whether you have an ISDN incoming voice-modem under the PRI or BRI physical interface.
BF Service/option not available, unspecified The network or remote equipment cannot provide the service option that the user requests, due to an unspecified reason. A subscription problem can cause this issue.
C1 Bearer capability not implemented The network cannot provide the bearer capability that the user requests. Contact the telco to troubleshoot further.
C2 Channel type not implemented The network or the destination equipment does not support the channel type that the user requests.
C5 Requested facility not implemented The remote equipment does not support the supplementary service that the user requests.
C6 Only restricted digital info bearer capability available The network cannot provide unrestricted digital information bearer capability. This cause indicates that a device requests an unrestricted bearer service. However, the equipment only supports the restricted version of the bearer capability.
CF Service/option not implemented, unspecified The network or remote equipment cannot provide the service option that the user requests, due to an unspecified reason. A subscription problem can cause this issue.
D1 Invalid call reference value The remote equipment receives a call with a call reference that is not currently in use on the user-network interface.
D2 Identified channel does not exist The user requests the receiving equipment to use a channel that is not activate on the interface for calls. This cause indicates that the equipment receives a request to use an inactive channel on the interface for a call. For example, if a user subscribes to those channels on a primary rate interface numbered from 1 to 12 and the user equipment or the network attempts to assign a call to channels 13 through 23, this cause code appears.
D3 Suspended call exists, but call id does not The network receives a call resume request. The call resume request contains a Call Identify (ID) information element that indicates the call ID that represents a suspended call. This cause indicates that a user attempts to resume a call with a call ID which differs from the ID in use for any currently suspended call(s).
D4 Call id in use The network receives a call resume request. The call resume request contains a Call ID information element that indicates the resume request is for a suspended call. This cause indicates that the network receives a call suspend request. The call suspend request contains a call ID (including the null call ID). This ID is already in use for a suspended call within the domain of interfaces over which the call can be resumed.
D5 No call suspended The network receives a call resume request when there is no suspended call pending. You can resolve this transient error through successive call retries. This cause code indicates that the network receives a call resume request. The call resume request contains a call ID information element that currently does not indicate any suspended call within the domain interfaces over which calls can be resumed.
D6 Call with requested call id has been cleared This cause indicates that the network receives a call resume request. The call resume request contains a call ID information element that originally indicated a suspended call. However, either a network timeout or a remote user clears the suspended call.
D7 User not member of CUG1 Your call does not go through, probably due to one of these reasons:

  • You dial an incorrect ISDN number.
  • You request a service that you are not authorized to use (you have not subscribed to this service).
  • The remote device is not authorized to use a service that you use.

Check the number you call. If the problem persists, contact your telco.
D8 Incompatible destination This cause indicates an attempt to connect to non-ISDN equipment. For example, an analog line. This cause indicates that the equipment receives a request to establish a call that has a low layer compatibility, high layer compatibility, or other compatibility attributes (for example, data rate) that the equipment cannot accommodate. This code often appears when the calling device dials the wrong number, and reaches a non-ISDN device. Therefore, ensure that you dial the correct number. This cause can also occur when a a data call is made to a voice number, or a voice call is made to a number that only supports data. If the number is correct, check whether the telco has configured their switch incorrectly.
DA Non-existent CUG1 Your call does not go through, probably due to one of these reasons:

  • You dial an incorrect ISDN number.
  • You request a service that you are not authorized to use (you have not subscribed to this service).
  • The remote device is not authorized to use a service that you use.

Check the number you dial. If the problem persists, contact your telco.
DB Invalid transit network selection The device requests the ISDN exchange to route the call through an unrecognized intermediate network. This cause indicates that the ISDN exchange receives a transit network identification of an incorrect format. Annex C of ITU-T Q.931 provides this definition.
DF Invalid message, unspecified An invalid message appears with no standard cause. This problem usually occurs due to a D-channel error. If the error occurs systematically, report the error to your ISDN service provider.
E0 Mandatory IE missing The receiving equipment receives a message that does not include one of the mandatory information elements. This cause indicates that the equipment receives a message that does not contain an information element that is necessary for the equipment to process the message. This problem occurs due to a D-channel error. Ensure that you configure the switch type correctly. Upgrade your Cisco IOS® Software on the router to solve this issue. If the error occurs systematically, report the error to your ISDN service provider.
E1 Message type not implemented The receiving equipment receives an unrecognized message, because either the message type is invalid, or the equipment does not support the message type. A problem with the remote configuration or with the local D-channel causes this issue.
E2 Message not compatible with call state or not implemented The remote equipment receives an invalid message with no standard cause. This cause indicates that the equipment receives a message that is not permissible in the call state according to the procedures. This cause can also indicate that the equipment receives a STATUS message to indicate an incompatible call state. The issue occurs due to a D-channel error. If the error recurs, report the error to your ISDN service provider.
E3 IE not implemented The remote equipment receives a message that includes information elements that the equipment cannot recognize. This cause indicates that the equipment receives a message that includes information elements that the device cannot recognize. This problem can occur when the equipment does not define or implement the information element identifier. However, the message does not need to contain the information element in order for the equipment to process the message. This issue occurs due to a D-channel error. If the error recurs, report the error to your ISDN service provider.
E4 The remote equipment receives a message that includes invalid information in the information element. This cause indicates that the equipment receives an information element that is implemented, but one or more of the fields in the information element are coded differently. This issue occurs due to a D-channel error.
E5 Message not compatible with call state The remote equipment receives an expected message that does not correspond to the current state of the connection. This issue occurs due to a D-channel error.
E6 Recovery on time expiry Your call does not go through, probably because an error occurs. For example, a state synchronization error. Wait and try again later. If the problem persists, contact your ISDN service provider.
E7 Parameter not implemented Your call does not go through because the ISDN network does not support a service you need to use. Contact your ISDN service provider.
EF Protocol error, unspecified This cause indicates an unspecified D-channel error with no other standard cause.
FF Interworking, unspecified This cause indicates that an event occurs, but the network does not provide causes for the action. The precise problem is unknown.
?? Unknown Cause value The cause value is unknown.

 

1 CUG: Closed User Group is a facility in X.25 and ISDN networks that allows a called number to be available only to a limited number of other users (in a virtual private network). Contact your telco for more information.

Optional Diagnostic field

The last two hexadecimal digits (08 in the example) are optional. You do not commonly use these digits for diagnostic purposes. However, you can sometimes use this byte to furnish additional information for the Disconnect Cause Code. The debug isdn q931output can sometimes contain these digits.

ISAKMP (IKE Phase 1) Status Messages MM_WAIT_MSG#

Posted on by
Reply

Content here is sourced from tunnelsup.com

http://www.tunnelsup.com/isakmp-ike-phase-1-status-messages/

ISAKMP (IKE Phase 1) Status Messages MM_WAIT_MSG#

ISAKMP (IKE Phase 1) Negotiations States

The MM_WAIT_MSG state can be an excellent clue into why a tunnel is not forming. If your firewall is hanging at a specific state review this graph below to find where along the path the VPN is failing.

ASA ISAKMP STATES

IKE Phase Messages - IMG

Graph source: tunnelsup.com

These are the possible ISAKMP negotiation states on an ASA firewall. ISAKMP stands for: The Internet Security Association and Key Management Protocol

  • MM_WAIT_MSG2 Initiator Initial DH public key sent to responder. Awaiting initial contact reply from other side. Initiator sends encr/hash/dh ike policy details to create initial contact. Initiator will wait at MM_WAIT_MSG2 until it hears back from its peer. If stuck here it usually means the other end is not responding. This could be due to no route to the far end or the far end does not have ISAKMP enabled on the outside or the far end is down.
  • MM_WAIT_MSG3 Receiver Receiver is sending back its IKE policy to the initiator. Initiator sends encr/hash/dh ike policy details to create initial contact. Initiator will wait at MM_WAIT_MSG2 until it hears back from its peer. Hang ups here may also be due to mismatch device vendors, a router with a firewall in the way, or even ASA version mismatches.
  • MM_WAIT_MSG4 Initiator Initiator is sending the Pre-Shared-Key hash to its peer. Initiator sends a hash of its PSK. Initiator will stay at MSG4 until it gets a PSK back from its peer. If the receiver is missing a tunnel group or PSK the initiator will stay at MM_WAIT_MSG4
  • MM_WAIT_MSG5 Receiver Receiver is sending its PSK hash to its peer. Receiver does not yet check if PSK hashes match. If receiver has a tunnel-group and PSK configured for this peer it will send the PSK hash to the peer. If PSKs don’t match, receiver will stay at MM_WAIT_MSG5. I have also seen the tunnel stop here when NAT-T was on when it needed to be turned off.
  • MM_WAIT_MSG6 Initiator Initiator checks if PSK hashes match. If PSK keys match, Initiator becomes MM_ACTIVE and lets receiver know of match. If PSK doesn’t match, initiator stays at MM_WAIT_MSG6. I have also seen the tunnel stop here when NAT-T was on when it needed to be turned off. However, if the state goes to MSG6 then the ISAKMP gets reset that means phase 1 finished but phase 2 failed. Check that IPSEC settings match in phase 2 to get the tunnel to stay at MM_ACTIVE.
  • AM_ACTIVE / MM_ACTIVE The ISAKMP negotiations are complete. Phase 1 has successfully completed.

PIX ISAKMP STATES

    • MM_NO_STATE

ISAKMP SA has been created but nothing else has happened yet.

    • MM_SA_SETUP

The peers have agreed on parameters for the ISAKMP SA.

    • MM_KEY_EXCH

The peers have exchanged Diffie-Hellman public keys and have generated a shared secret. The I SAKMP SA remains unauthenticated.

    • MM_KEY_AUTH

The ISAKMP SA has been authenticated. If the router initiated this exchange, this state trans itions immediately to QM_IDLE and a Quick mode exchange begins.

    • AG_NO_STATE

The ISAKMP SA has been created but nothing else has happened yet.

    • AG_INIT_EXCH

The peers have done the first exchange in Aggressive mode but the SA is not authenticated.

    • AG_AUTH

The ISAKMP SA has been authenticated. If the router initiated this exchange, this state transitions immediately to QM_IDLE and a Quick mode exchange begins.

    • QM_IDLE

The ISAKMP negotiations are complete. Phase 1 successfully completed. It remains authenticated with its peer and may be used for subsequent Quick mode exchanges.

What is the difference between MM and AM?

Main mode vs Aggressive mode. Here is a image taken from Cisco’s website to show the difference.

MM AM - IMG

As you can see the Main mode is the same as the flowchart at the top of the page. Aggressive mode only uses 4 steps to establish the tunnel.

Troubleshooting ISAKMP Or Phase 1 VPN connections

When troubleshooting VPNs, a very common problem is phase 1 not establishing correctly. Here’s a quick checksheet to make sure you have the configuration correct.

  • Verify ISAKMP parameters match exactly.
  • Verify pre-shared-keys match exactly.
  • Check that each side has a route to the peer address that you are trying to form a tunnel with.
  • Verify ISAKMP is enabled on the outside interfaces.
  • Is ESP traffic permitted in through the outside interface?
  • Is UDP port 500 open on the outside ACL?
  • Some situations require that UDP port 4500 is open for the outside.

Cisco vWLC CLI Password change (bold text)

Posted on by
Reply

Configuring Administrator Usernames and Passwords

You can configure administrator usernames and passwords to prevent unauthorized users from reconfiguring the controller and viewing configuration information. This section provides instructions for initial configuration and for password recovery.

Configuring Usernames and Passwords

To configure administrator usernames and passwords using the controller CLI, follow these steps:

Step 1 Configure a username and password by entering one of these commands:

•config mgmtuser add username password read-write—Creates a username-password pair with read-write privileges.

•config mgmtuser add username password read-only—Creates a username-password pair with read-only privileges.

Usernames and passwords are case-sensitive and can contain up to 24 ASCII characters. Usernames and passwords cannot contain spaces.

Note If you ever need to change the password for an existing username, enter the config mgmtuser password username new_password command.

Step 2 List the configured users by entering this command:

show mgmtuser

(Cisco Controller) >show mgmtuser

User Name Permissions Description Password Strength
———————– ———— ——————— —————- —
admin          read-write                          Strong
admin-wpe  read-write                          Strong
peters          read-write                          Strong
(Cisco Controller) >

SQUID ACCESS.LOG MEANING EXPLAINED

Posted on by
Reply

Squid Access.log Meaning Explained

Squid access log is very informative if you know how to dig something out of it. Following is an a line from access.log file.

1201172176.719 1190 127.0.0.1 TCP_MISS/200 529 GET http://www.blogger.com/status.g? – DIRECT/72.14.221.191 application/xml

This line can be written as:

Timestamp, Total time, Source, Action/Code, Size, Method, URL, Ident, Hierarchy/From, Content type

1: Timestamp Time when the request was completed.
2: Total time Total time taken to complete the request
3: Source IP address of the client
4: Action/Code Action taken for the request
5: Size Total size of the request in bytes
6: Method Whether the request was GET or POST
7: URL The actual request
8: Ident Usually –
9: Hierarchy/From How the object is fetched and from where
10: Content type Type of object

Action

“TCP_” refers to requests on the HTTP port (3128)
TCP_HIT A valid copy of the requested object was in the cache.
TCP_MISS The requested object was not in the cache.
TCP_REFRESH_HIT An expired copy of the requested object was in the cache. Squid made an If-Modified-Since request and the response was “Not Modified.”
TCP_REFRESH_FAIL_HIT An expired copy of the requested object was in the cache. Squid attempted to make an If-Modified-Since request, but it failed. The old (stale) object was delivered to the client.
TCP_REFRESH_MISS An expired copy of the requested object was in the cache. Squid made an If-Modified-Since request and received a new, different object.
TCP_CLIENT_REFRESH The client issued a request with the “no-cache” pragma. (“reload” – handled as MISS)
TCP_IMS_HIT An If-Modified-Since GET request was received from the client. A valid copy of the object was in the cache (fresh).
TCP_IMS_MISS An If-Modified-Since GET request was received from the client. The requested object was not in the cache (stale).
TCP_SWAPFAIL The object was believed to be in the cache, but could not be accessed.
TCP_DENIED Access was denied for this request.


“UDP_” refers to requests on the ICP port (3130)
UDP_HIT A valid copy of the requested object was in the cache
UDP_HIT_OBJ Same as UDP_HIT, but the object data was small enough to be sent in the UDP reply packet. Saves the following TCP request.
UDP_MISS The requested object was not in the cache
UDP_DENIED Access was denied for this request
UDP_INVALID An invalid request was received.
UDP_RELOADING The neighbor cache is reloading its disk store metadata and does not want any TCP requests for MISSES until it is finished.


Errors
ERR_READ_TIMEOUT The remote site or network is unreachable – may be down.
ERR_LIFETIME_EXP The remote site or network may be too slow or down.
ERR_NO_CLIENTS_BIG_OBJ All Clients went away before tranmission completed and the object is too big to cache.
ERR_READ_ERROR The remote site or network may be down.
ERR_CLIENT_ABORT Client dropped connection before transmission completed. Squid fetches the Object according to its settings for `quick_abort’.
ERR_CONNECT_FAIL The remote site or server may be down.
ERR_INVALID_REQ Invalid HTTP request
ERR_UNSUP_REQ Unsupported request
ERR_INVALID_URL Invalid URL syntax
ERR_NO_FDS Out of file descriptors
ERR_DNS_FAIL DNS name lookup failure
ERR_NOT_IMPLEMENTED Protocol Not Supported
ERR_CANNOT_FETCH The requested URL can not currently be retrieved.
ERR_NO_RELAY There is no WAIS relay host defined for this cache.
ERR_DISK_IO The system disk is out of space or failing.
ERR_ZERO_SIZE_OBJECT The remote server closed the connection before sending any data.
ERR_FTP_DISABLED This cache is configured to NOT retrieve FTP objects.
ERR_PROXY_DENIED Access Denied. The user must authenticate himself before accessing this cache.


CODE

Code Reason phrase RFC 2616 section
0 No Response Received (Squid-specific) N/A
1xx Informational 10.1
100 Continue 10.1.1
101 Switching Protocols 10.1.2
2xx Successful 10.2
200 OK 10.2.1
201 Created 10.2.2
202 Accepted 10.2.3
203 Non-Authoritative Information 10.2.4
204 No Content 10.2.5
205 Reset Content 10.2.6
206 Partial Content 10.2.7
3xx Redirection 10.3
300 Multiple Choices 10.3.1
301 Moved Permanently 10.3.2
302 Found 10.3.3
303 See Other 10.3.4
304 Not Modified 10.3.5
305 Use Proxy 10.3.6
306 (Unused) 10.3.7
307 Temporary Redirect 10.3.8
4xx Client Error 10.4
400 Bad Request 10.4.1
401 Unauthorized 10.4.2
402 Payment Required 10.4.3
403 Forbidden 10.4.4
404 Not Found 10.4.5
405 Method Not Allowed 10.4.6
406 Not Acceptable 10.4.7
407 Proxy Authentication Required 10.4.8
408 Request Timeout 10.4.9
409 Conflict 10.4.10
410 Gone 10.4.11
411 Length Required 10.4.12
412 Precondition Failed 10.4.13
413 Request Entity Too Large 10.4.14
414 Request-URI Too Long 10.4.15
415 Unsupported Media Type 10.4.16
416 Requested Range Not Satisfiable 10.4.17
417 Expectation Failed 10.4.18
5xx Server Error 10.5
500 Internal Server Error 10.5.1
501 Not Implemented 10.5.2
502 Bad Gateway 10.5.3
503 Service Unavailable 10.5.4
504 Gateway Timeout 10.5.5
505 HTTP Version Not Supported 10.5.6
6xx Proxy Error N/A
600 Unparseable Response Headers (Squid-specific) N/A

Methods

GET Request URL
HEAD Request only HTTP headers of the supplied URL and no document body
POST Transfer data to the supplied URL
PUT Store data under the supplied URL
CONNECT Forward data to SSL-Server:Port
ICP_QUERY Request from a Parent/Neighbor for the supplied URL
NONE Request of an unsupported method

Hierarchy

NONE The object requested by a sibling, was not in my cache.
DIRECT The object has been requested from the origin server.
SIBLING_HIT The object was requested from a neighbor cache which replied with a UDP_HIT (formerly logged as NEIGHBOR_HIT).
PARENT_HIT The object was requested from a parent cache which replied with a UDP_HIT.
DEFAULT_PARENT The object was requested from a default parent cache appropriate for this URL.
SINGLE_PARENT The object was requested from the only parent cache appropriate for this URL.
FIRST_UP_PARENT The object has been requested from the first available parent in your list.
NO_PARENT_DIRECT The object was requested from the origin server because no parent caches exist for the URL.
FIRST_PARENT_MISS The object has been requested from the parent cache with the fastest weighted round trip time.
ROUNDROBIN_PARENT No ICP queries were received from any parent caches. This parent was chosen because it was marked as ‘default’ in the config file and it had the lowest round-robin use count.
CLOSEST_PARENT_MISS This parent was selected because it included the lowest RTT measurement to the origin server. This only appears with ‘query_icmp on’ set in the config file.
CLOSEST_DIRECT The object was fetched directly from the origin server because this cache measured a lower RTT than any of the parent caches.
LOCAL_IP_DIRECT The object has been requested from the origin server because the origin host IP address matched your ‘local_ip’ list.
FIREWALL_IP_DIRECT The object has been requested from the origin server because the origin host IP address is inside your firewall.
NO_DIRECT_FAIL The object could not be requested because of firewall restrictions and no parent caches were available.
SOURCE_FASTEST The object was requested from the origin server because the ‘source_ping’ reply arrived first.
SIBLING_UDP_HIT_OBJ The object was received in a UDP_HIT_OBJ reply from a neighbor cache (formerly logged as UDP_HIT_OBJ).
PARENT_UDP_HIT_OBJ The object was received in a UDP_HIT_OBJ reply from a parent cache (formerly logged as UDP_HIT_OBJ).
PASSTHROUGH_PARENT The neighbor or proxy defined in the config option ‘passthrough_proxy’ was used.
SSL_PARENT_MISS The neighbor or proxy defined in the config option ‘ssl_proxy’ was used.

About Diffie-Hellman Groups

Posted on by
Reply
About Diffie-Hellman Groups

Diffie-Hellman (DH) groups determine the strength of the key used in the key exchange process. Higher group numbers are more secure, but require additional time to compute the key.

Firebox or XTM devices support Diffie-Hellman groups 1, 2, and 5:

  • DH Group 1: 768-bit group
  • DH Group 2: 1024-bit group
  • DH Group 5: 1536-bit group

Both peers in a VPN exchange must use the same DH group, which is negotiated during Phase 1 of the IPSec negotiation process. When you define a manual BOVPN tunnel, you specify the Diffie-Hellman group as part of Phase 1 of creating an IPSec connection. This is where the two peers make a secure, authenticated channel they can use to communicate.

DH groups and Perfect Forward Secrecy (PFS)

In addition to Phase 1, you can also specify the Diffie-Hellman group in Phase 2 of an IPSec connection. Phase 2 configuration includes settings for a security association (SA), or how data packets are secured when they are passed between two endpoints. You specify the Diffie-Hellman group in Phase 2 only when you select Perfect Forward Secrecy (PFS).

PFS makes keys more secure because new keys are not made from previous keys. If a key is compromised, new session keys are still secure. When you specify PFS during Phase 2, a Diffie-Hellman exchange occurs each time a new SA is negotiated.

The DH group you choose for Phase 2 does not need to match the group you choose for Phase 1.

How to Choose a Diffie-Hellman Group

The default DH group for both Phase 1 and Phase 2 is Diffie-Hellman Group 1. This group provides basic security and good performance. If the speed for tunnel initialization and rekey is not a concern, use Group 2 or Group 5. Actual initialization and rekey speed depends on a number of factors. You might want to try DH Group 2 or 5 and decide whether the slower performance time is a problem for your network. If the performance is unacceptable, change to a lower DH group.

Performance Analysis

The following table shows the output of a software application that generates 2000 Diffie-Hellman values. These figures are for a 1.7GHz Intel Pentium 4 CPU.

DH Group No. of key pairs Time required Time per key pair
Group 1 2000 43 sec 21 ms
Group 2 2000 84 sec 42 ms
Group 5 2000 246 sec 123 ms

Dead Peer Detection – DPD on routers

Posted on by
Reply

Cisco routers support two DPD types: On-demand DPD and Periodic DPD:

crypro isakmp keepalive <threshold> <retry-interval> {[on-demand] | periodic}

In case of on-demand DPD a router sends its R-U-THERE message to a peer if there is a traffic to send to the peer and the peer was idle for <threshold> seconds (i.e. there was no traffic from the peer for <threshold> seconds). On-demand DPD was introduced in IOS 12.2(8)T and the implementation has changed multiple times since then.

In case of periodic DPD a router sends its R-U-THERE messages at regular intervals. It doesn’t take into consideration traffic coming from peer. This is the only Cisco platform that supports true periodic DPD. Periodic DPD was introduced in IOS 12.3(7)T and the implementation has changed multiple times since then.

Specifically, in the DDTS CSCin76641 (IOS 12.3(09.08)T) a decision was made to not send R-U-THERE request when the periodic DPD is configured and a traffic is received from the peer. Finally, it has reverted to the original behavior. See DDTS CSCsh12853(12.4(13.11)T 12.4(11)T02 12.4(09)T05 12.4(06)T08) for details.

Periodic DPD can improve convergence in some scenarios.

DPD is disabled by default on Cisco routers. The default mode is “on-demand” if not specified.

If the peer doesn’t respond with the R-U-THERE-ACK the router starts retransmitting R-U-THERE messages every <retry-interval>seconds with a maximum of five retransmissions. After that the peer is declared dead.

You cannot specify the number of retries on Cisco routers.

Also, it is possible to configure DPD in ISAKMP profiles. The caveat, however, is that there are no “periodic” and “on-demand”configuration options. So, the ISAKMP profile will inherit global setting. I.e., if you enable periodic DPD globally, all your ISAKMP profiles will operate in “periodic” DPD mode with profile-specific DPD timers.

crypto isakmp profile QQQ
 keepalive <interval> retry <retry-interval>

Another caveat is that you cannot disable DPD completely. DPD is always negotiated, even if not configured or disabled in ISAKMP profile with “no keepalive”. In this case the router will answer DPD requests with R-U-THERE-ACK, but will not initiate DPD requests with R-U-THERE (“one-way” mode).

In brief, on routers we have the following:

  • true periodic DPD and on-demand DPD
  • DPD cannot be completely disabled
  • one-way mode is supported and is the default mode
  • retry interval can be configured
  • retry count cannot be configured and equals to five

Dead Peer Detection – DPD on ASA

Posted on by
Reply

ASA and PIX firewalls support “semi-periodic” DPD only. I.e. they send R-U-THERE message to a peer if the peer was idle for<threshold> seconds. ASA may have nothing to send to the peer, but DPD is still sent if the peer is idle. If the VPN session is comletely idle the R-U-THERE messages are sent every <threshold> seconds. If there is a traffic coming from the peer the R-U-THERE messages are not sent.

Unlike routers, you can completely disable DPD on ASA and it will not negotiate it with a peer (“disable” configuration option).

Also, you can configure “one-way” DPD mode on ASA. The ASA will respond to R-U-THERE messages, but will not initiate DPD exchange (“threshold infinite” configuration option).

isakmp keepalive {disable | threshold <threshold> retry <retry-interval> | threshold infinite}

If the peer doesn’t respond with the R-U-THERE-ACK the ASA starts retransmitting R-U-THERE messages every <retry-interval>seconds with a maximum of three retransmissions. After that the peer is declared dead.

You cannot specify the number of retries on ASA.

DPD is enabled by default on ASA for both L2L and RA IPSec:

tunnel-group DefaultL2LGroup ipsec-attributes
 isakmp keepalive threshold 10 retry 2
tunnel-group DefaultRAGroup ipsec-attributes
 isakmp keepalive threshold 300 retry 2

In brief, on ASA we have the following:

  • only “semi-periodic” DPD is supported
  • DPD can be completely disabled
  • one-way mode is supported
  • bidirectional mode is the default one
  • retry interval can be configured
  • retry count cannot be configured and equals to three