Category Archives: Cisco Routing & Switching

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.

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.

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) >

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

Adding a Guest VLAN to a network (and blocking access to other networks)

Posted on by
Reply

To be configured on switch, first create vlan (L2/L3)

(in config mode)

!
vlan 99
name Guest_LAN
!
interface Vlan99
description Guest VLAN
ip address 192.168.99.1 255.255.255.0

!

Create DHCP pool for Guest network

!
ip dhcp pool GUEST_LAN
network 192.168.99.0 255.255.255.0
dns-server 8.8.8.8 198.153.192.1
default-router 192.168.99.1

!

Exclude hosts if required, e.g.

!

ip dhcp excluded-address 192.168.99.1 192.168.99.10

!

Configure required ports for guest VLAN e.g 25 to 48

!
interface range GigabitEthernet1/0/25-48
description Guest User VLAN
switchport access vlan 99
spanning-tree portfast
!

We now need to prevent users from the Guest VLAN from accessing other networks (if required) so we need to first create an extended access list and then apply it to the Guest VLAN interface. We will call this guest-in for this example and we will block access to the networks below.

!
ip access-list extended guest-in
deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.0.255.255
deny ip any 192.168.0.0 0.0.255.255
permit ip any any
!

And that is the basic plumbing done for you Guest VLAN. Your router will also need a route to this network and access-list(s) configured.

 

Logging Cisco Login Attempts

Posted on by
Reply

Specifiy a syslog server on the router

Router(config)#logging a.b.c.d
Enable notification logging on the router
Router(config)#logging trap notifications

Enable logging for successfull and unsuccessfull login attempts

Router(config)#login on-success log
Router(config)#login on-failure log

You can also block login attempts to the device if numbers of failure occures during a specific amount of time (eg, block for 120 sec if 3 failure attempts within the 60 sec)

Router(config)#login block-for 120 attempts 3 within 60

If you like you can change the source address that will be shown on the syslog server

Router(config)#logging source-interface FastEthernet0/0

You can enable a specific amount of delay in seconds between logins to the router

Router(config)#login delay 5

If you would like to send a log of all changes that have been made on the router configuration to the syslog server as well, you need to do these steps:

!## Enter archive configuration mode

Router(config)# archive
!## Enter the configuration change logger mode
Router(config-archive)# log config
!## Enable logging for configuration change
Router(config-archive-log-config)# logging enable
!## Change the loggin queue size (Optional)
Router(config-archive-log-config)# logging size 200
!## Hide passwords from being sent to syslog in clear text (Optional)
Router(config-archive-log-config)# hidekeys
!## Send logs to syslog server
Router(config-archive-log-config)# notify syslog
Router(config-archive-log-config)# end

Cisco IP Inspect command explained

Posted on by
Reply

IP inspect helps a router act more like an ASA, so the goal is to only allow certain traffic inbound.

For example, lets consider an inbound access-list that is very restrictive or “deny ip any any”. Using this logic, the inside hosts can make requests to outside servers, but they don’t receive the responses. A TCP 3 way handshake can’t even happen. So what we can do is inspect traffic outbound. What that does is builds a state table in the router that allows the return traffic to bypass the inbound acl. The inspect actually does some protocol validation on the initial outbound traffic in this case. So a very simple configuration might look like the following.

ip inspect name FWOUT tcp
ip inspect name FWOUT udp
ip inspect name FWOUT icmp
ip inspect name FWOUT ftp

//ftp is important to inspect because it can use a secondary port initiated from the outside

ip access-list extended INBOUND
deny ip any any

int fa0/0
description OUTSIDE
ip access-group INBOUND in
ip inpsect FWOUT out
ip address 1.1.1.1 255.255.255.0
ip nat outside

int fa0/1
description INSIDE
ip address 192.168.0.1 255.255.255.0
ip nat inside