Opened a ticket at Cisco and got the info: There is no plan to add this feature as per road-map on Nexus.
There is a workaround that might work for someone, please see below, however it does not work for me as I need to fully automate on a lot of switches:
Automatically get the list of names of VRFs configured on each switch.
Automatically configure snmp communities, snmp context and mib mapping based on the #1 above.
Automatically get some important information from individual VRFs through 'per-VRF' snmp communities.
Workaround: BRU-N9K3-1# sh run | i vrf
vrf context name_a
vrf context name_b
vrf context name_c
BRU-N9K3-1# sh run snmp | i context
snmp-server context test1 vrf name_c
snmp-server context test2 vrf name_b
snmp-server context test3 vrf name_c
snmpwalk -v2c -c public 10.48.50.165 18.104.22.168.22.214.171.124.4126.96.36.199.2
SNMPv2-SMI::enterprises.9.9.4188.8.131.52.184.108.40.206.115.116.49 = STRING: "name_c"
SNMPv2-SMI::enterprises.9.9.4220.127.116.11.18.104.22.168.115.116.50 = STRING: "name_b"
SNMPv2-SMI::enterprises.9.9.422.214.171.124.126.96.36.199.115.116.51 = STRING: "name_c"
... View more
I run an app that gathers all IP subnets ( IP addresses, subnet masks ) configured on all network devices worldwide within our company . It uses SNMP.
I would need to add IP subnets defined in non-Default VRFs on Nexus N9K switches.I know how to query entries for a non-Default VRF through SNMP. Because I need to automate the whole process, first I would need to get the list of all VRFs ( their names ) configured on a switch and query entries in specific VRFs then by using individual SNMP community strings that include VRF names.
I am searching all available resources, however cannot find anything that would give me a clue.
Any ideas are appreciated.
... View more
I opened a TAC case and after some time got an answer:
Upon researching I have learnt that this issue expected an cause due to a different generation of PHY being used in Switch and the Laptop.
PHY’s used on the Laptop are more recent when compare to the PHY’s of a switch, causes functional differences especially when it comes to link up event and ready to transmit/receive the traffic
Thus, the Discover packet is being lost at the switch PHY when it was not in ready state to accept the traffic, though the link negotiation is already performed and is up.
The BOOTP frame is a very first frame generated by the laptop and is quick as soon as the link is up, but when it is transmitted across the port, at the other end the switch is not forwarding the traffic.
However, the subsequent BOOTP Discover frame is switched as expected due to the fact that the PHY at the switch side was side by the time
This behavior should not cause any disruption to the user traffic, as it is most likely to drop the very first packet, the other functionally of the PHY’s remain same be it a recent or old generation
I am afraid, there would not be any enhancements to this behavior at the hardware level as well as software tweaking. The behavior is expected in such special scenarios.
... View more
Many thanks for your valuable inputs.
By a bug I mean both, SW ( code ) and HW ( design ) bugs as I have experience with both :)
Yes, it is obvious this is something on the physicial layer. I have tried many things, also changed carrier-delay, but did not get anything that would improve.
For me as a networker this issue should not be a big deal. PXE boot for sure works, it adds just a little delay. With Windows this seems it might cause troubles. As we have now very fast laptops with SSD a user might logon before the network is up and might get troubles with Windows shares or other things then. These issues were reported, but I have never seen or experience it by myself. There might be also a link to how Windows ( AD etc. ) parameters are set.
We've reported this to our Cisco partner and maybe it will be wise to report also to HP even if we know some other switch platforms do not have this behaviour.
... View more
Today I tried WS-C3560CG-8PC-S with c3560c405ex-universalk9-mz.152-2.E3.bin, this has not helped.
I tried WS-C3560CX-12PC-S and 15.2(3)E with exactly the same config and this one works perfectly fine.
Seems like a bug on WS-C3560CG-8PC-S.
... View more
We seem to have an issue with HP laptops and desktops connected to Cisco WS-C3560CG-8PC-S.
First DHCP Discover frame is lost 90% times ( sometimes it works ). I am also testing with PXE boot ( BIOS ), so even before the operating system starts. The symptom is that the first DHCP Discover frame arrives to the PC port on the switch, but is not switched to the uplink port, and there is no answer from the DHCP server then. The second DHCP Discover frame is always processed succesfully, but it takes 3-5 seconds until PXE boot or operating system sends it out. I am using monitor session and another machine with Wireshark to capture the traffic on the PC port and uplink port. This is the same for PXE boot and for the phase when operating system ( Windows 7 ) starts. I am trying another piece of HW, which is Shuttle with Ubuntu, and this one always works fine, means the very first DHCP discover frame is always properly switched to the uplink and the Linux machine gets a DHCP address immediately.
I am trying c3560c405ex-universalk9-mz.150-2.SE5.bin and the most recent c3560c405ex-universalk9-mz.150-2.SE8.bin images, but both the same.I started with our standard port config, which is full of features (switchport security, ARP inspection, DHCP snooping etc.), removed them one by one, but did not help. Now I have a very simple port config ! interface GigabitEthernet0/1 switchport access vlan 5 switchport mode access switchport nonegotiate spanning-tree portfast !
I tried many things, removed CDP, LLDP. inline power, played with speed/duplex, flowcontrol, used spanning-tree bpdufilter enable and many others, but nothing helped. Tried to debug, but do not see anything suspicious.
If anyone has an idea what could be a cause please let me know.
... View more
I tried to change admin status of 2.4 Radio to to Disable through GUI and then back to Enable. Can see the messages on AP: *Aug 7 12:18:10.277: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to administratively down *Aug 7 12:18:18.512: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset And this on the controller ( have debug for AP enabled ) ( Ctrl1 ) >*spamApTask7: Aug 07 14:21:04.643: 58:97:1e:23:50:d0 AP: *Aug 7 12:21:02.052: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to administratively down *spamApTask7: Aug 07 14:21:24.021: 58:97:1e:23:50:d0 AP: *Aug 7 12:21:20.977: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
... View more
Unfortunately I do not have the console available so cannot see the boot process, but I will have next week and will provide. AP#dir flash: Directory of flash:/ 44 drwx 704 Aug 7 2015 10:47:53 +00:00 c1140-k9w8-mx.152-4.JB6 3 drwx 128 Jul 29 2015 09:05:38 +00:00 configs 4 -rwx 95008 Aug 7 2015 11:19:24 +00:00 lwapp_reap.cfg.bak 5 -rwx 35488 Aug 7 2015 11:19:56 +00:00 lwapp_non_apspecific_reap.cfg 6 -rwx 280 Aug 7 2015 11:19:20 +00:00 lwapp_officeextend.cfg 7 drwx 128 Mar 1 2002 00:07:42 +00:00 c1140-rcvk9w8-mx 37 -rwx 73119 Aug 7 2015 11:16:10 +00:00 event.log 11 -rwx 7192 Aug 7 2015 11:19:25 +00:00 private-multiple-fs 12 -rwx 95008 Aug 7 2015 11:19:56 +00:00 lwapp_reap.cfg 14 -rwx 76247 Aug 7 2015 08:23:58 +00:00 event.capwap 16 -rwx 267 Aug 7 2015 11:19:18 +00:00 env_vars 32126976 bytes total (14773248 bytes free)
... View more
Thanks. Not sure what that means. I have plenty of other controllers with many country codes configured and many APs with many regulatory domains ( placed in many countries worldwide ). What's conflicting? The radio is not disabled, but is reset. I think this is suspicious. It is reset before the AP joins controller.
... View more
Thanks, show sysinfo and showtime below. I tried: Changed the mode from flexconnect to local on one AP on the same controller, Radio is on and the AP works fine. Moved one other AP from this controller to another running 188.8.131.52, using completely different WLAN and Flexconnect groups, and have the same problem. I guess it is not related to Regulatory Domain. The Radio is reset before the AP joins the controller ( reading that from the AP log ). I do not know if this is normal behaviour or not. There are only these two Interface Dot11Radio0 status change messages in the AP log, they appear before the AP joins the controller. *Mar 1 00:08:22.170: %LINK-6-UPDOWN: Interface Dot11Radio0, changed state to up *Mar 1 00:08:22.392: %LINEPROTO-5-UPDOWN: Line protocol on Interface BVI1, changed state to uplwapp_crypto_init: MIC Present and Parsed Successfully *Mar 1 00:08:38.974: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset (Ctrl1) >show sysinfo Manufacturer's Name.............................. Cisco Systems Inc. Product Name..................................... Cisco Controller Product Version.................................. 184.108.40.206 RTOS Version..................................... 220.127.116.11 Bootloader Version............................... 18.104.22.168 Emergency Image Version.......................... 22.214.171.124 Build Type....................................... DATA + WPS System Name...................................... Ctrl1 System Location.................................. Loca System Contact................................... IT System ObjectID.................................. 126.96.36.199.188.8.131.52.1615 Redundancy Mode.................................. Disabled IP Address....................................... 184.108.40.206 System Up Time................................... 26 days 23 hrs 51 mins 43 secs System Timezone Location......................... (GMT +1:00) Amsterdam, Berlin, Rome, Vienna System Stats Realtime Interval................... 5 System Stats Normal Interval..................... 180 Configured Country............................... Multiple Countries:CN,CZ,HK,JP,KR --More-- or (q)uit Operating Environment............................ Commercial (10 to 35 C) Internal Temp Alarm Limits....................... 10 to 38 C Internal Temperature............................. +24 C Fan Status....................................... OK RAID Volume Status Drive 0.......................................... Good Drive 1.......................................... Good State of 802.11b Network......................... Enabled State of 802.11a Network......................... Enabled Number of WLANs.................................. 20 Number of Active Clients......................... 254 Burned-in MAC Address............................ 10:05:CA:BE:ED:80 Power Supply 1................................... Present, OK Power Supply 2................................... Present, OK Maximum number of APs supported.................. 300 (Ctrl1) >showtime Incorrect usage. Use the '?' or <TAB> key to list commands. (Ctrl1) >show time Time............................................. Fri Aug 7 11:33:42 2015 Timezone delta................................... 0:0 Timezone location................................ (GMT +1:00) Amsterdam, Berlin, Rome, Vienna NTP Servers NTP Polling Interval......................... 3600 Index NTP Key Index NTP Server NTP Msg Auth Status ------- ---------------------------------------------------------------------------------- 1 0 10.128.39.21 AUTH DISABLED* 2 0 10.128.39.22 AUTH DISABLED* (Ctrl1) >
... View more
I do have several AIR-LAP1041N-E-K9 APs joined AIR-CT8510-K9 running 220.127.116.11 in Flexconnect mode. These APs were used in Local mode on an older controller before. I had an issue that the APs were in Admin disable when they reloaded. I had to enable manually. I wanted to get rid of it and cleared them to factory defaults ( GUI/ClearAllConfig ) and have them configured from the scratch. Admin disable issue disappeared, but there is now another problem, even worse. Dot11Radio0 is in reset and cannot bring it up Dot11Radio0 unassigned NO unset reset down AP log sequence is: *Mar 1 00:08:22.170: %LINK-6-UPDOWN: Interface Dot11Radio0, changed state to up *Mar 1 00:08:22.392: %LINEPROTO-5-UPDOWN: Line protocol on Interface BVI1, changed state to uplwapp_crypto_init: MIC Present and Parsed Successfully *Mar 1 00:08:38.974: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset Tried couple of things, played with PoE settings on the switch, tried to use recovery image on the AP, and others, but nothing helped. Does anyone have an idea what could help? Many thanks, Vlad
... View more
Hi, Thanks for the idea. Yes, this I am using, but it is purely related to the client's TCP traffic that is encapsulated into Capwap channel UDP port 5247 . It does not affect the other types of traffic that have nothing to do with client's TCP, such as for example authentication frames etc. Vlad
... View more
Cisco LWAP in FlexConnect mode uses two Capwap channels: • CAPWAP control traffic—Identified by UDP port 5246 • CAPWAP 802.11 traffic—Identified by UDP port 5247 For some reason I would need to route user data ( UDP port 5247 ) through other WAN path with lower IP MTU, say 1326B, different from the WAN path used for Capwap control traffic ( UDP port 5246 ) that has say 1500B MTU. Seems the process is that the AP finds the IP MTU through the control Capwap channel, sets Capwap Path MTU to 1485B and uses it as a maximum also for the packets routed via UDP port 5247. Because some IP packets sent via UDP port 5247 might be larger, means over 1326B, the AP gets fragmentation needed and DF set unreachable ICMP from the router and sets its Capwap Path MTU to 1325B. After a while the AP sends 1485B IP packet through UDP port 5246 and resets its Capwap Path MTU to 1485B and this repeats. Correct me if I am wrong and the process works different way. This is what I am reading from Wireshark sniff. I would like to avoid this and also other potential troubles while having the two separate WAN paths with different MTUs. Does anyone know how I could either Change the initial AP 1485B test packet to something lower, like 1325B. Means the AP would not try IP packets larger than 1325B. I tried to change MTU on BVI interface on the AP, this works, but unfortunately is re-written to default after AP reload. or Persuade the AP to use UDP port 5247 for the path MTU discovery process rather than UDP port 5246. Unfortunately there is no way for me to do this on some other network device between the AP and WAN , like on a switch. It would be optimal, but no way. Thanks, Vlad
... View more
I am using several scripts that dig the data from XML files created through Cisco Prime Infrastructure Rest API. It worked fine until 2.1. Now, with 2.2, seems Cisco stopped adding LF to each line and everything is 'one' line. Here is an example with 2.1, there is a LF to the end of each line: ?xml version="1.0" encoding="UTF-8" standalone="yes"?> <queryResponse type="AccessPointDetails" rootUrl="https://server/webacs/api/v1/data" requestUrl="https://server/webacs/api/v1/data/AccessPointDetails?type=contains(UnifiedAp)&.full=true&.maxResults=1000&.firstResult=0" responseType="listEntityInstances" count="715" first="0" last="714"> <entity url="https://server/webacs/api/v1/data/AccessPointDetails/1505569" type="AccessPointDetails" dtoType="accessPointDetailsDTO"> <accessPointDetailsDTO id="1505569" displayName="1505569"> <adminStatus>ENABLE</adminStatus> <apType>AP1240</apType> <cdpNeighbors> <cdpNeighbor> <capabilities>Switch IGMP </capabilities> <duplex>Half Duplex</duplex> <interfaceSpeed>100Mbps</interfaceSpeed> <localPort>2</localPort> <neighborIpAddress>10.1.1.1</neighborIpAddress> <neighborName>switch</neighborName> <neighborPort>FastEthernet0/1</neighborPort> <platform>cisco WS-C3560-8PC</platform> </cdpNeighbor> Now, with 2.2, there is not LF anywhere: ?xml version="1.0" encoding="UTF-8" standalone="yes"?><queryResponse type="AccessPointDetails" rootUrl="https://server/webacs/api/v1/data" requestUrl="https://server/webacs/api/v1/data/AccessPointDetails?type=contains(UnifiedAp&.full=true&.maxResults=1000&.firstResult=0" responseType="listEntityInstances" count="715" first="0" last="714"> <entity url="https://server/webacs/api/v1/data/AccessPointDetails/1505569" type="AccessPointDetails" dtoType="accessPointDetailsDTO"> <accessPointDetailsDTO id="1505569" displayName="1505569"><adminStatus>ENABLE</adminStatus><apType>AP1240</apType><cdpNeighbors><cdpNeighbor> Does anyone know, is this intentional or a mistake? Or is there a way how I control this? I am reading on-line CPI Rest API docs, but seems cannot find anything. Thanks, Vlad
... View more
I have tried another test. Because of voice implementation we have our own queueset 1 defined: # show mls qos queue-set Queueset: 1 Queue : 1 2 3 4 ---------------------------------------------- buffers : 10 80 5 5 threshold1: 100 225 400 400 threshold2: 100 225 400 400 reserved : 50 50 50 50 maximum : 400 225 400 400 Queueset: 2 Queue : 1 2 3 4 ---------------------------------------------- buffers : 25 25 25 25 threshold1: 100 200 100 100 threshold2: 100 200 100 100 reserved : 50 50 50 50 maximum : 400 400 400 400 I've changed the settings of g0/10 interface ( interface going to the router ) so that the standard Cisco ( default values ) queueset is used, means I used queue-set 2 ! interface GigabitEthernet0/10 ip arp inspection trust load-interval 30 queue-set 2 ip dhcp snooping trust Even with that I have interface output drops ( seen in both sh int g0/10 and sh mls qos int g0/10 statis ) and the Capwap tunnel unstable. Obviously the Capwap tunnel is very sensitive to output drops. I wonder what is different in Capwap implementation on C3602 and C1142 ? I think this might be the key.
... View more
I feel have narrowed this down. I realized this is not ip mtu issue. I changed ip mtu from 1376 up to 1500 and even with 1500 this occurs, but just not so often so I had to wait for a longer time until the AP dropped the tunnel I tried to connect the 3602 AP directly to the built-in switch in the 1812 router that I am using for the test and it worked perfectly fine even if I had ip mtu set to 1376 on the path to the controller. So it is clear the WS-C3560CG-8PC-S switch that I use in front of the router to power AP over PoE is a cause, in combination with 3602 or 3702 AP. We have a standard company config for the switches and this has been applied. There are many config lines and features set, but what I did is that I removed them one by one and seem to have found it. Our standard port config for the LWAPP for the small sites is switchport mode access switchport access vlan 1 switchport port-security maximum 25 switchport port-security switchport port-security aging time 2 switchport port-security violation restrict switchport port-security aging type inactivity ip device tracking maximum 10 ip arp inspection trust ip dhcp snooping trust no logging event link-status priority-queue out mls qos trust dscp srr-queue bandwidth share 10 80 5 5 srr-queue bandwidth shape 0 0 0 0 queue-set 1 snmp trap mac-notification change added snmp trap mac-notification change removed spanning-tree portfast spanning-tree bpduguard enable I've configured the port lines in a one by one way to see the effect on the AP. With this config ! interface GigabitEthernet0/8 switchport mode access switchport port-security maximum 25 switchport port-security violation restrict switchport port-security aging time 2 switchport port-security aging type inactivity switchport port-security ip device tracking maximum 10 ip arp inspection trust no logging event link-status priority-queue out ip dhcp snooping trust it works perfectly fine, but when I added this line mls qos trust dscp and had this config ! interface GigabitEthernet0/8 switchport mode access switchport port-security maximum 25 switchport port-security violation restrict switchport port-security aging time 2 switchport port-security aging type inactivity switchport port-security ip device tracking maximum 10 ip arp inspection trust no logging event link-status priority-queue out mls qos trust dscp ip dhcp snooping trust the 3602 AP started dropping the Capwap tunnel. It works perfectly fine when I plug the 1142 AP in, means I keep the port config the same and the 1142 AP is stable. I tried another WS-C3560CG-8PC-S HW, means another same switch, and also tried two IOS versions c3560c405ex-universalk9-mz.150-2.SE6.bin and c3560c405ex-universalk9-mz.152-2.E1.bin, but there is no dependency, means it does not work correctly no matter what IOS or HW I take.
... View more
We have TCP MSS set to 1240 globally on the controller, but this has nothing to do with a Capwap tunnel. We cannot change MTU on the network path. I am not sure how we could change permanently MTU on an AP, not even taking into account that it could be also on the other side - controller. It seems to me the description of the older bug below perfectly fits the problem with 3602 and 3702 and newer controller OS version. I tried also higher MTU sizes on the Ethernet interfaces of the routers in the network path, like for example 1492 and any number below 1500 causes that. As said 1142 AP works perfectly fine, so this seems to be AP model related and might be a bug in the code. Problem 14: LWAPP APs do not join WLC if network MTU is less than 1500 bytes This is because of Cisco bug ID CSCsd94967. LWAPP APs might fail to join a WLC. If the LWAPP join request is larger than 1500 bytes, LWAPP must fragment the LWAPP join request. The logic for all LWAPP APs is that the size of the first fragment is 1500 bytes (including IP and UDP header) and the second fragment is 54 bytes (including IP and UDP header). If the network between the LWAPP APs and WLC has a MTU size less than 1500 (as might be encountered when using a tunneling protocol such as IPsec VPN, GRE, MPLS, etc.), WLC cannot handle the LWAPP join request. You will encounter this problem under these conditions: WLC that runs version 3.2 software or earlier Network path MTU between the AP and WLC is less than 1500 bytes In order to resolve this issue, use any one of these options: Upgrade to WLC software 4.0, if the platform supports it. In WLC version 4.0, this problem is fixed by allowing the LWAPP tunnel to reassemble up to 4 fragments. Increase the network path MTU to 1500 bytes. Use 1030 REAPs for the locations reachable via low MTU paths. REAP LWAPP connections to 1030 APs have been modified to handle this situation by reducing the MTU used for REAP mode.
... View more
I had a trouble while implementing WLAN services at our branch being connected over a Cisco VPN link. The APs were constantly associating and disassociating the controllers, establishing a Capwap tunnel and dropping it. I have simulated this on my table, having two spare routers configured for a VPN link. I got the same AP misbehavior even if the routers were interconnected by a cable, means no ISPs in between and no Internet issues. I tried different WLAN controllers with different OS versions, tried a local and flexconnect AP mode, always instable. Tried to exercise the IOS version on the routers, this did not help either. Then I took an older 1142 AP and this one worked well, being perfectly stable. Then I tried to configure the interlink on the routers with just pure Ethernet ( no IPSEC, no GRE ) and configured ip mtu 1376 on the Ethernet interfaces and got the same instability on 3602 and 3702 APs. 1142 AP works fine. Controllers used are AIR-CT5508-K9 with 18.104.22.168, and AIR-CT8510-K9 with 22.214.171.124 Is anyone aware of any troubles on 3602 and 3702 while having lower MTU in the network path. Seems like it might be an MTU path discovery issue. Thanks. Vlad
... View more
We have Cisco Security Manager 4.5.0 Patch 3 and using it to manage hundreds of Cisco ASA FWs. We found many failure attempts on our Radius servers. These records say the radius client is an ASA FW and calling station is Cisco Security Manager. Debug on one of the Cisco ASA FWs revealed Cisco Security Manager uses first a NULL username to access Cisco ASA FWs and then the configured username ( we have it configured as 'use primary credentials' and the same for all FWs ). This is not dependent on the OS version we have on ASA FWs. Here is the debug from a Cisco ASA FW, first Cisco Security Manager uses a username with no characters in it and when this attempt fails it uses the username that is configured in Cisco Security Manager by us as primary credentials. %ASA-6-113005: AAA user authentication Rejected : reason = AAA failure : server = IPADDRESSREMOVED : user = %ASA-6-611102: User authentication failed: Uname: %ASA-6-605004: Login denied from IPADDRESSREMOVED/59208 to inside:IPADDRESSREMOVED/https for user "" %ASA-6-725007: SSL session with client inside:IPADDRESSREMOVED/59208 terminated. %ASA-6-302013: Built inbound TCP connection 1221667 for inside:1IPADDRESSREMOVED/59222 (1IPADDRESSREMOVED/59222) to identity:IPADDRESSREMOVED/443 (IPADDRESSREMOVED/443) %ASA-6-725001: Starting SSL handshake with client inside:IPADDRESSREMOVED/59222 for TLSv1 session. %ASA-7-725010: Device supports the following 4 cipher(s). %ASA-7-725011: Cipher : RC4-SHA %ASA-7-725011: Cipher : AES128-SHA %ASA-7-725011: Cipher : AES256-SHA %ASA-7-725011: Cipher : DES-CBC3-SHA %ASA-7-725008: SSL client inside:PADDRESSREMOVED/59222 proposes the following 15 cipher(s). %ASA-7-725011: Cipher : RC4-MD5 %ASA-7-725011: Cipher : RC4-SHA %ASA-7-725011: Cipher : AES128-SHA %ASA-7-725011: Cipher : DHE-RSA-AES128-SHA %ASA-7-725011: Cipher : DHE-DSS-AES128-SHA %ASA-7-725011: Cipher : DES-CBC3-SHA %ASA-7-725011: Cipher : EDH-RSA-DES-CBC3-SHA %ASA-7-725011: Cipher : EDH-DSS-DES-CBC3-SHA %ASA-7-725011: Cipher : DES-CBC-SHA %ASA-7-725011: Cipher : EDH-RSA-DES-CBC-SHA %ASA-7-725011: Cipher : EDH-DSS-DES-CBC-SHA %ASA-7-725011: Cipher : EXP-RC4-MD5 %ASA-7-725011: Cipher : EXP-DES-CBC-SHA %ASA-7-725011: Cipher : EXP-EDH-RSA-DES-CBC-SHA %ASA-7-725011: Cipher : EXP-EDH-DSS-DES-CBC-SHA %ASA-7-725012: Device chooses cipher : RC4-SHA for the SSL session with client inside:1IPADDRESSREMOVED/59222 %ASA-6-725002: Device completed SSL handshake with client inside:1IPADDRESSREMOVED/59222 %ASA-6-302014: Teardown TCP connection 1221666 for inside:IPADDRESSREMOVED/59208 to identity:1IPADDRESSREMOVED/443 duration 0:00:01 bytes 1054 TCP FINs %ASA-6-113004: AAA user authentication Successful : server = IPADDRESSREMOVED : user = USERNAMEREMOVED %ASA-6-113008: AAA transaction status ACCEPT : user = USERNAMEREMOVED %ASA-6-611101: User authentication succeeded: Uname: USERNAMEREMOVED %ASA-6-605005: Login permitted from IPADDRESSREMOVED/59222 to inside:1IPADDRESSREMOVED/https for user "USERNAMEREMOVED" %ASA-7-111009: User 'USERNAMEREMOVED' executed cmd: show vpn-sessiondb full svc %ASA-6-725007: SSL session with client inside:IPADDRESSREMOVED/59222 terminated. Does anyone know is this a bug and is workaround known? Thank you, Vlad
... View more
We have a kind of BYOD access to Internet for iPhone users. We have a site C5508 controller with 126.96.36.199 and a DMZ ( anchor ) C5508 controller running 188.8.131.52 version as well. We have several APs associated with the site WLAN controller; models are AIR-LAP1252AG, AIR-CAP3502I. The iPhone clients work well with these APs, in both 2.4 and 5 GHz. Recently we bought AIR-CAP3702I AP, got it associated with the site controller and iPhone users being connected to this AP complained they did not have access to Internet. All other SSIDs ( we have several ) worked fine. I tried to make couple of changes and finally realized that if I turn off 5GHz ( 802.11a ) hard on this AP, the clients work well – means via 2.4 GHz. I tried to upgrade the site controller to version 184.108.40.206, but this did not help and behaves the same way. The site is a remote site and it is quite hard to perform tests directly with the users. Does anyone have a clue what the issue could be about. Is it a kind of incompatibility between Cisco AIR-CAP3702I and iPhone in 802.11a ? Thanks, Vlad
... View more
Hi Rasilka, Thank you. It's not about SSIDs, we broadcast the same SSIDs, but is more about WLANs and their settings. We have our specific security and other internal rules, for example we cannot use the same PSK at all sites etc. Some of the WLANs are the same everywhere, but quite many not. That's why I need to differentiate and have many separate WLANs. It is my understanding C8510 is a top box so to be honest 512 WLAN limit quite surprised me. I want to use it up to its maximum before I need to buy another box. Regards, Vlad
... View more
Hi Ishant, Thank you. I was already thinking that but because of the other limit - 512 WLANs in total - I did not want to waste the first 16 ones. This is because 512 WLAN limit is quite tight for us as we have many sites and several SSIDs per a site. Vlad
... View more
We have deployed many Cisco site specific WLAN controllers worldwide. We are now testing APs in Flexconnect mode at our branches with regional C8510 controllers running 220.127.116.11 . One of the issues that we see is that if we deploy a new AP and get it associated with C8510 controller the AP automatically falls under Default AP group and transmits the first couple of SSIDs that are by default enabled in Default AP group. This is not good as we plan to have hundreds of SSIDs configured for many branches and we do not want a new AP to transmit any SSID until it is assigned to site specific AP and Flexconnect groups. We know the AP can be admin disabled ( or its Radios ) after the first initial procedure and then moved to the right groups but this is a manual process and we want to have something automated in our hands. Does anyone know if we can get rid of this default behavior? Thanks, Vlad
... View more