Wireless: %DTL-1-ARP_POISON_DETECTED

CSCsm25943 Change label for %DTL-1-ARP_POISON_DETECTED message
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsm25943

Symptom:

A Wireless LAN Controller may emit a message similar to the following:

DTL-1-ARP_POISON_DETECTED: STA [00:01:02:0e:54:c4, 0.0.0.0] ARP (op 1) received with invalid SPA 192.168.1.152/TPA 192.168.0.206

However, when one peruses the entry in the Cisco Wireless LAN Controller System Message Guide, 4.2, for this message, he may find it to be misleading and bereft of useful information.

Conditions:

This message does not necessarily imply that any actual "ARP poisoning" (ARP spoofing) is going on. Rather, it is emitted whenever the following conditions pertain:

- WLAN is configured with DHCP Required
- A client, after associating on that WLAN, transmits an ARP message without first DHCPing

This may be normal behavior - for example, when the client is statically addressed, or when the client is holding a valid DHCP lease from a prior association.

The effect of this condition is that the client will be unable to send or receive any data traffic, until it DHCPs thru the WLC.

In more detail, here is how to interpret the example message above:

DTL-1-ARP_POISON_DETECTED: STA [00:01:02:0e:54:c4, 0.0.0.0] ARP (op 1) received with invalid SPA 192.168.1.152/TPA 192.168.0.206

DTL-1-ARP_POISON_DETECTED
- WLC received an ARP packet from a client in DHCP_REQ state

STA [00:01:02:0e:54:c4, 0.0.0.0]
- the client ("STA" - 802.11 wireless station) has a MAC address of 00:01:02:0e:54:c4, and an IP address unknown to the WLC ("0.0.0.0")

ARP (op 1)
- the offending packet received from client was an ARP request (opcode 1)

invalid SPA 192.168.1.152/TPA 192.168.0.206
- the source IP address (SPA - "sender protocol address") of the ARP request was 192.168.1.152
- the target IP address (TPA - "target protocol address") of the ARP request was 192.168.0.206

Workaround:

1. figure out whether or not you want to force your wireless clients to DHCP first, after associating, before they can send IP packets.



2. If no, then unconfigure DHCP required, and you won't get this problem.



3. If yes, then configure all clients to use DHCP.



4. If the client is configured for DHCP, but still sometimes sends IP packets after associating without re-DHCPing, then:
   
   
   • See if the client eventually does re-DHCP & if so doesn't suffer an unacceptable outage before re-DHCPing. If the outage before re-DHCPing is acceptable, then you can just ignore this message.
   
   
   
   • If the client never does re-DHCP after associating, then it will never be able to pass L3 traffic. So in that case, either figure out how to change the client's behavior so that it always does re-DHCP after associating, or else just accept that this client won't work in this application, or else reconsider your decision to use "DHCP required".

Further Problem Description:

If the source IP address (SPA) of the ARP is an APIPA address (i.e. one in 169.254.0.0 /16), then this may be indicative of the STA's attempting but failing to acquire an address via DHCP. In which case you may want to verify that your DHCP implementation works.

1st Found-In:
4.2(61.0)

Fixed-In:
7.0(63.0)

Wireless: %APF-3-USER_DEL_FAILED

Event : %APF-3-USER_DEL_FAILED: Unable to delete username unknown for mobile mac-address

Explanation: This error can mean slightly different things depending on EAP method. Basically it is a side effect of an EAP method with identity protection.

EAP authentication is done in two phases. The first phase of authentication uses generic anonymous external identity in order to establish the tunnel. In phase 2, client authentication is done in the established tunnel. The client sends the original username and password to authenticate and establish a client authorization policy. As this authentication method hides the original user name at the first phase of authentication, the controller does not have a way to add the correct username to the authenticated user list. So the controller uses the anonymous username. The end result generates this error.

Further details on the related bug below:

---

%APF-1-USER_DEL_FAILED: apf_ms.c:5055 flooding msglogs.
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsz51403

Symptom:
The "%APF-1-USER_DEL_FAILED: apf_ms.c:5055" message floods msglogs

Conditions:
1. Multiple clients connect to the controller with the same user name, or
2. AAA server returns a user name that is different to what is registered by the client.

Workaround:
No, but it does not affect any controller feature

1st Found-In

5.2(178.12)

5.2(178.13)

Fixed-In

6.0(176.0)

5.2(186.0)

6.1(34.0)

6.0(182.0)

4.2(205.1)

5.2(193.0)

4.2(207.0)

BIG-IP License Error - Permission denied

Scenario:
After a reboot, the BIG-IP returns a licensing error. Reactivating the license does not work as well.

In the qkview output, we see the following:

2009-07-19 22:56:17,428 ERROR [Thread-15] util.F5Error: - An error has occurred while trying to process your request.

java.io.FileNotFoundException: /var/tmp/bigip.license (Permission denied)

Workaround:

Delete /var/tmp/bigip.license file if it exists.

Ensure that the user you are logged into has full premissions / full admin rights to the BIG-IP box.

Reactivate the license file.

Basic MQC Configuration

Three easy steps to MQC (Modular QoS CLI) Configuration:
Step 1: Classify traffic via class-map
Step 2: Assign policies to the traffic classes via policy-map
Step 3: Apply above policies to an interface via service-policy

! ------------------------------------
! Sample Scenraio:
! ------------------------------------
For the following traffic going out Serial0/1 of the device, do the following:
* for voice traffic, reserve 256kbps priority bandwidth
* for email traffic (pop3, imap, smtp), reserve 128kbps bandwith
* for telnet traffic coming from 10.10.10.10, limit to 3200bps bandwidth

! ------------------------------------
! BEGIN CONFIGURATION
! ------------------------------------
Router(config)#access-list 101 host 10.10.10.10 any eq 23
Router(config)#class-map VOICE
Router(config-cmap)#match protocol rtp
Router(config-cmap)#exit
Router(config)#class-map match-any EMAIL
Router(config-cmap)#match protocol pop3
Router(config-cmap)#match protocol imap
Router(config-cmap)#match protocol smtp
Router(config-cmap)#exit
Router(config)#class-map ACL_101
Router(config-cmap)#match access-group 101
Router(config-cmap)#exit

Router(config)#policy-map MY_POLICY
Router(config-pmap)#class VOICE
Router(config-pmap-c)#priority 256
Router(config-pmap-c)#exit
Router(config-pmap)#class EMAIL
Router(config-pmap-c)#bandwidth 128
Router(config-pmap-c)#exit
Router(config-pmap)#class ACL_101
Router(config-pmap-c)#police 3200
Router(config-pmap-c)#exit
Router(config-pmap)#exit

Router(config)#interface Serial0/1
Router(config-if)#service-policy output MY_POLICY
Router(config-if)#exit
Router(config)#

! ------------------------------------
! NOTES
! ------------------------------------

Router(config)#class-map [match-all|match-any] class_name

match-all - the class must match all the succeeding criteria

match-any - the class must match any of the succeeding criteria

if not specified, defaults to match-all

Router(config-cmap)#match {protocol|access-group} value

protocol - based on known traffic classes via NBAR

access-group - based on ACLs

not limited to the above criteria; other criteria include class-map (i.e. nested class-maps), CoS, DSCP, IP Precedence, input-interface, MAC address, QoS group, UDP Port Ranges

Router(config-if)#service-policy {input|output} policy-name

only one policy per direction per interface can be applied;

that is, each interface can have at most one inbound policy and one outbound policy.

Other command syntax will be dealt with in another post.