Posts

cisco acs command-line linux shell

So how does one drop to the linux shell on the Cisco ACS, recently I needed to get to the Cisco ACS Linux shell to change some permissions due to the fact we were hitting the following bug:

ACS – new configuration of RSA authentication would not take effect

CSCur93568
Description
Symptom:
ACS cannot apply configuration that contain node secret from RSA server:

Users and Identity Stores > External Identity Stores > RSA SecureID Token Servers > Edit “RSA-SecureID-Token-Server” at tab “ACS Instance Settings” the Node Secret Status will display: “-not created-”

On the RSA server
-in the monitor window the authentication will fail with message “pre-shared-secret mismatch”
-at the very first try to sync up the ACS with RSA the authentication might show as successful on RSA appliance.

Conditions:
-new setup
-ACS version 5.5 and 5.6
-when ACS is configured to perform an addition authentication against an RSA server

Workaround:
Change group and owner for directory /opt/CSCOacs/config/RSA (TAC assistance required):
-chown acsuser:gadmin -R /opt/CSCOacs/config/RSA

Access to the Cisco ACS Linux Shell

In order to do the workaround you need access to the Cisco ACS Linux Shell, in order to be able to do this you need to follow the below steps:
download the following package which was provided by cisco:
rpsshv2.tar.gz
and follow the below steps:

Root shell patch for Cisco ACS.

  • Setup a Cisco ACS Repo:
  • application install rpsshv2.tar.gz
  • log out and back in
  • root_enable, this will prompt you to configure a root password
  • root

Cisco Nexus syslog logging server custom port

So it seems when Cisco worked on the nexus operating system they decided for whatever reason not to initially allow custom port for the syslog server on IOS its quite simples as you can see below:

This is quite annoying when you have infrastructure setup using non-default ports for syslog, on the cisco nexus 7000 series versions <= 6.1 do not allow you to use custom logging server port. There is a ray of hope if you are using versions >=7.x and nexus 7k then this is fixed.

Cisco feature request to change syslog destination port:
https://tools.cisco.com/bugsearch/bug/CSCug55348

From the looks of it seems that this is only supported on the nexus 7k in our situation it was easier to accommodate the default syslog port on the logging infrastructure as it seems cisco does NOT support custom syslog destination port on the cisco nexus 3000 series. If this changes at all or someone knows any different please leave a comment.

cisco nexus bcm_usd_isr_switch_event_cb error cause bit 0x10020a8

Recently we found the following issue on our nexus switches running code 5.0(3)U5(1a), the problem would be that the switch would not be able to reach a destination address even if its in the arp table, cisco commented on this with the below

From case notes I understand there are the following messages in log buffer on N3k switch and you need assistance investigating this

————————–
2013 Apr 10 05:37:06 TOR-2053a.LHR7 %USER-3-SYSTEM_MSG: bcm_usd_isr_switch_event_cb:432: slot_num 0, event 2, memory error type 0x1, mem addr 0x8ab4, cause bit 0x10020a8 – bcm_usd
2013 Apr 10 05:48:28 TOR-2053a.LHR7 %USER-3-SYSTEM_MSG: bcm_usd_isr_switch_event_cb:432: slot_num 0, event 2, memory error type 0x1, mem addr 0x8ab4, cause bit 0x10020a8 – bcm_usd
2013 Apr 10 05:52:01 TOR-2053a.LHR7 %USER-3-SYSTEM_MSG: bcm_usd_isr_switch_event_cb:432: slot_num 0, event 2, memory error type 0x1, mem addr 0x8ab4, cause bit 0x10020a8 – bcm_usd
2013 Apr 10 05:52:41 TOR-2053a.LHR7 %USER-3-SYSTEM_MSG: bcm_usd_isr_switch_event_cb:432: slot_num 0, event 2, memory error type 0x1, mem addr 0x8ab4, cause bit 0x10020a8 – bcm_usd
————————–

From the above log we can see that cause bit is 0x10020a8 – this is translated to ‘L2_ENTRY_PAR_ERR’ reason.

Impact:
There is a parity error in the MAC address table, which is not ECC protected. This parity error will result in packet being dropped.

Recommended Action:
If the switch is running 5.0(3)U5(1a) or earlier versions, it is recommended to upgrade to 6.0(2)U2(1) or later version. Your switch runs 5.0(3)U4(1).
This error is automatically correct after 6.0(2)U2(1) by running consistency checker.

Parity errors are not a bug

Background

What is a processor or memory parity error?

Parity checking is the storage of an extra binary digit (bit) in order to represent the parity (odd or even) of a small amount of computer data (typically one byte) while that data is stored in memory. The parity value calculated from the stored data is then compared to the final parity value. If these two values differ, this indicates a data error, and at least one bit must have been changed due to data corruption.

Within a computer system, electrical or magnetic interference from internal or external causes can cause a single bit of memory to spontaneously flip to the opposite state. This event makes the original data bits invalid and is known as a parity error.

Such memory errors, if undetected, may have undetectable and inconsequential results or may cause permanent corruption of stored data or a machine crash.

There are many causes of memory parity errors, which are classified as either soft parity errors or hard parity errors.

Soft Errors

Most parity errors are caused by electrostatic or magnetic-related environmental conditions.

The majority of single-event errors in memory chips are caused by background radiation (such as neutrons from cosmic rays), electromagnetic interference (EMI), or electrostatic discharge (ESD). These events may randomly change the electrical state of one or more memory cells or may interfere with the circuitry used to read and write memory cells.

Known as soft parity errors, these events are typically transient or random and usually occur once. Soft errors can be minor or severe:

Minor soft errors that can be corrected without component reset are single event upsets (SEUs).
Severe soft errors that require a component or system reset are single event latchups (SELs).
Soft errors are not caused by hardware malfunction; they are transient and infrequent, are mostly likely a SEU, and are caused by an environmental disruption of the memory data.

If you encounter soft parity errors, analyze recent environmental changes that have occurred at the location of the affected system. Common sources of ESD and EMI that may cause soft parity errors include:

Power cables and supplies
Power distribution units
Universal power supplies
Lighting systems
Power generators
Nuclear facilities (radiation)
Solar flares (radiation)

Hard Errors

Other parity errors are caused by a physical malfunction of the memory hardware or by the circuitry used to read and write memory cells.

Hardware manufacturers take extensive measures to prevent and test for hardware defects. However, defects are still possible; for example, if any of the memory cells used to store data bits are malformed, they may be unable to hold a charge or may be more vulnerable to environmental conditions.

Similarly, while the memory itself may be operating normally, any physical or electrical damage to the circuitry used to read and write memory cells may also cause data bits to be changed during transfer, which results in a parity error.

Known as hard parity errors, these events are typically very frequent and repeated and occur whenever the affected memory or circuitry is used. The exact frequency depends on the extent of the malfunction and how frequently the damaged equipment is used.

Remember that hard parity errors are the result of a hardware malfunction and reoccur whenever the affected component is used.

If you encounter hard parity errors, analyze physical changes that have occurred at the location of the affected system. Common sources of hardware malfunction that may lead to hard parity errors include:

Power surges (no ground)
ESD
Overheating or cooling
Incorrect or partial installation
Component incompatibility
Manufacturing defect

Freeup memory on cisco 6500 router with full BGP route tables

In the olden days, we had to have the soft-reconfig setting on our BGP sessions to accept route updates without reloading the entire BGP table.

This takes up a lot of memory, especially when you have 3 ISP;s connecting with full BGP Tables, In these times where the Internet route table is ~488,000 routes and we accept full tables from multiple providers, we can’t afford the memory usage – and we don’t have to!

Today’s Internet providers support a better idea, route-refresh, effectively doing the same thing without the negative. This feature provides a soft reset mechanism that allows the dynamic exchange of route refresh requests and routing information between BGP peers and the subsequent re-advertisement of the outbound or inbound routing table.

is route-refresh supported on cisco 6500

is route-refresh supported on juniper device

According to the above it sure is supported in fact most devices enable and support this, so if you are memory concoius and you can afford to be without soft-reconfig then route-refresh is sufficient enough. On the 6500 device you will not see the memory free up until the router is rebooted.

Firewall VPN ISAKMP (IKE Phase 1) status messages

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

ASA ISAKMP STATES

  • MM_WAIT_MSG2 – Initial DH public key sent to responder. Awaiting initial contact reply from other side. 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 – Both peers have agreed on the ISAKMP policies. Awaiting exchange of keyring information. Hang up’s here may be due to mismatch device vendors, a router with a firewall in the way, or even ASA version mismatches.
  • MM_WAIT_MSG4 – In this step the pre-share key hashes are exchanged. They are not compared or checked, only sent. If one side sends a key and does not receive a key back, this is where the tunnel will fail. I have seen the tunnel fail at this step due to the remote side having the wrong Peer IP address. Hang up’s here may also be due to mismatch device vendors, a router with a firewall in the way, or even ASA version mismatches.
  • MM_WAIT_MSG5 – This step is where the devices exchange pre-shared keys. If the pre-shared keys do not match it will stay at this MSG. I have also seen the tunnel stop here when NAT Traversal was on when it needed to be turned off.
  • MM_WAIT_MSG6 – This step is where the devices exchange pre-shared keys. If the pre-shared keys do not match it will stay at this MSG. I have also seen the tunnel stop here when NAT Traversal 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 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.

enable Netflow top-talkers on a cisco ios

How to enable Netflow top-talkers on a cisco ios device, This is a short article on the NetFlow “top-talkers” CLI feature. NetFlow is a tool for monitoring traffic flows, it’s particularly handy when you’€™re trying to find out what host or protocol is saturating a network. The CLI method can be really helpful if you’re looking for something quickly. Here’€™s the config:

Config from my outside interface.

I’ve enabled NetFlow with the “ip flow” commands.

Here’s how to enable the “top-talkers” feature at the CLI.

Pretty simple, we’ve set how many flows to show, then we can sort by bytes or packets, finally we set our timeout (in milliseconds).

Now we’€™ll look at the show command:

Troubleshoot

if you’re getting the following error when doing a “sho ip flow top-talkers”:

This would be because you have not issued the ip flow egress/ingress on an interface.

How to re-order an ACL on cisco devices

To re-order an ACL on cisco devices you can do so with the below example:

reference:
http://packetlife.net/blog/2010/apr/30/resequencing-acl-entries/

Cisco ASA vpnsetup command

I was browsing around the command line on the cisco asa vpnsetup and came across this hidden command, this gives you the steps to setup a VPN.

Cisco ASA Custom ftp passive port inspection

When an ftp server is configured with a custom ftp passive port, to ensure passive FTP continues working as expected the below configuration will help ensure passive FTP will work when the custom ftp server port is 10021

VoIP QOS