Hello all! I need some advice. I'm conducting a PoC for WAN optimization which is built of the following devices: 1.) Two Cisco 4451-X routers on each side of the WAN. 2.) On one side of the WAN (the branch side), we have UCS-E series server with ESXi Cisco customer image installed. The vCM (Central Manager) is running on this ESXi server. Also, each router has ISR-WAAS 4.5.1 installed with AppNav-XE used for traffic redirection. 3.) Two Cisco Catalyst switches, one on each site of the WAN (branch and DC) to connect all of the devices (PCs, servers, routers). 4.) On the DC side, there is a physical checkpoint FW which servers as the DG of all devices on the DC. There is also a physical domain controller server installed. 5.) On the branch side, there is a virtual FW installed on the ESXi server, which serves as the DG of all devices on the branch side. There is also a VM on which a virtual domain controller server is installed. 6.) The WAN characteristics: 256K link, 400-450ms one-way delay. The speed and delay are introduced using a physical WAN emulator device which is connected between the two routers. 7.) The two routers form a GRE tunnel between them, and also running OSPF between them and between each one of them and the FW on each site. The test we'd like to perform: A user needs to login to its PC, which is part of a domain. The PC performs the login by connecting to the physical domain controller. It performs the login and retrieves a GPO. This procedure, of course, is performed over the WAN with the characteristics I described. The protocols involved in this procedure are: CIFS/SMB, Kerberos and LDAP. We wanted to test the login procedure and GPO retrieval with Cisco WAAS and see if it optimizes the login  and GPO retrieval process. Without WAAS, the entire procedure (from the moment when the user enters its credentials until it sees the desktop) takes 3 minutes. With WAAS, it takes 3:40 minutes (even slower. On "show statistics connection" command, we can see that traffic is being optimized (there is a reduction rate and all CIFS traffic is using the SMB AO - we see TXDL). We noticed that one of the CIFS sessions is actually less optimized (there is a bad reduction rate). We also noticed that all CIFS sessions are handed-off to the generic AO (by using the "show statistics accelerator smb detail" command). Furthermore, by looking at SMB AO logs, we see the following two messages: 08/28/14 10:26:17.851(11068 0.0) NTCE (851741) intercepted new connection new flow 46, source A.B.C.D:49263(fd:22), destination A.B.C.D:445(fd:23) @smb_new_conn_handler [AoSmbFlow.cpp:429] 08/28/14 10:26:19/601(11068 0.2) NTCE (601866) (fl=76) f:YC2 FL:Invoking pushdown (src fd: 22, dst fd: 23) with reason: digitally signed traffic @smb_flow_handler [AoSmbFlow.cpp:664] Anyway, we wanted to try and optimize standard CIFS application - just sending some files using //A.B.C.D/c$ from the PC to the physical domain controller. Without WAAS, it takes more than 3 minutes. With WAAS, it takes approximately 40 seconds. So standard file transfer is being optimized successfully. However, we still see the same error messages above and we still see that CIFS sessions are handed-off to the generic AO on the "show statistics accelerator smb detail" command. So, it means that the sessions being handed-off are not causing the login and GPO retrieval to not be optimized (and even to be more slow), but there is some other issue with the WAAS during this process. Needless to say that when we use the virtual domain controller for the login process, it takes a few seconds for the login process and GPO retrieval to complete, since the domain controller is local on the branch, on the ESXi server on the UCS-E. Do you aware of such issue, with WAAS does not optimize login and GPO retrieval process, that use standard CIFS protocol? Please be aware that I'm not able to share configuration or sniffer captures, since the security policy of the organization forbids it. I'd be thankful for your assistance. Thanks. ... View more

Hello, I have a customer running CPI 1.2 and was running into bug CSCuf13631. In bug search tool, I see that this bug is in "Fixed" status, but release-pending. Do you know what is the ETA and version number of PI on which this bug will be fixed? Thanks. ... View more

Hello, I'd like to consult with the forum on an issue I have with the topology services in LMS 4.2.4: When I add a device to LMS, as soon as it completes data collection successfully and added to the topology services map, the map's layout is being messed up. That is even though the layout has been saved before adding the device. Is it the expected behavior ? Thanks. ... View more

Hello, I use LMS 4.2.4 on Linux (virtual appliance). I have a Cisco 4500X switch in VSS mode (SysObjectId is 1.3.6.1.4.1.9.1.1732). I looked up at the LMS supported device list for all LMS 4.X versions and I coud only find it in the document for 4.2.2. I see that UT is not supported on this device. The problem is that I didn't find the supported device list for LMS 4.2.4 and I don't know if user tracking is supported on this device in LMS 4.2.4. Does anybody know? Thanks. ... View more

Hello, Does Cisco ACE30 module, in its latest version, support NTLM authentication in its HTTP probes? Or only basic authentication? Thanks. ... View more

Hello, I have an LMS 4.2.4 running on Solaris. When I try to add a device with SNMPv3 auth and/or priv passwords that are less than 8 characters long, I get an error message. Here is an example of the error message seen when the privacy password length is less than 8 characters (the auth password length is longer than 8 characters in this case): Password and verify values for Privacy Password must be minimum of 8 characters length. The error message appears as well if the authentication password length is less than 8 characters or if both auth and priv passwords length is less than 8 characters. Only the error message text is a bit different for authentication password. The message appears either when trying to fill in the SNMPv3 credentials manually when adding a device or when creating a default credential set. I found a known bug (CSCtr21972) which should have been already fixed in LMS 4.2 according to LMS 4.2 release notes. I was running LMS 4.2 before the upgrade to 4.2.2 and 4.2.4 but I never tried adding a device with SNMPv3 credentials while running LMS 4.2, so I don't know if it had that limitation as well in 4.2. I only tried this today after the upgrade to 4.2.2 and then again after the upgrade to 4.2.4. In both versions I saw the error message. Do you familiar with this limitation? Do you know if there is any place where I can change it? I didn't find any SNMPv3 password policy like we have with the local users on LMS. Attached is: 1.) Screenshot of the error message. 2.) Screenshot showing LMS version. 3.) Output of pdshow command. 4.) Output of uname -a command. Thanks! ... View more

Hello,   I'd like to consult with you guys regarding an issue I have on an N5K device:   I have an N5K device running software version 5.1(3)N2(1), to which the SSH access is being locked out every couple of days. When the issue occurs, I connect it using a console cable and see a lot of open connections from our Cisco Prime Infrastructure 1.2.1 system.   In the "show users" N5K command output, I see connections which are opened for almost a month so probably the N5K or PI 1.2.1 does not clear them. When I login to the Linux shell of the PI 1.2.1, and run the command netstat -ano, I also see a lot of open SSH sessions to the IP address of the Nexus device. These connections remain open unless I shut down the services of PI or disable/enable the SSH feature on the N5K.   To Further investigate the issue, I also captured some traffic on the PI server using tcpdump, for a period of about a minute. I saw no SSH traffic, so clearly these sessions are idle for a lot of time and are not in use now, so no reason for them to remain open.   This leads me to the conclusion that either PI 1.2.1 or N5K (or both) does not clear the idle sessions that are not in use anymore, and this, to my opinion, leads to the issue, where the N5K locking the SSH access to the device.   When looking at the output of "show process cpu" on the N5K during the issue, I see 98% idle cpu and the sshd process is consuming 0%, so it is not stuck.   I found four known bugs which seems to be related:   CSCty90928 - Cisco Prime LMS related bug (not PI 1.2.1) and it is already fixed. Our LMS system that we use in parallel with PI 1.2.1 is already upgraded to the release which fixes this bug. I believe that this is the reason why we don't see stale SSH sessions on the N5K, coming from the LMS IP address (we saw that before the upgrade). On the other hand, I have another customer of mine that has LMS upgraded to the fixed version, and also sees this issue with its N5K devices. So maybe it is not yet fixed in the LMS side.   CSCty00044 - Categorized as LMS related, although my Cisco SE said it is a mistake and it should be N5K related. Anyway, it is in open (waiting) state.   CSCuc90628 - N5K related, in open (postponed) state.   CSCtz83708 - superceded by CSCty00044.   I consulted with my Cisco SE about bugs CSCuc90628 and CSCty00044 which seems to be related to my issue and are not fixed yet: He said that they were postponed or terminated because Cisco thinks that the issue was fixed in LMS with bug CSCty90928.   Do you know what is the ETA for a fix for these two bugs (CSCuc90628 and CSCty00044), and if the fix will be on the N5K devices or on LMS/PI systems? Or maybe there are some other related bugs?   Attached are the following files:   ssh_limit_200213173389.gz -> tac-pac from the N5K during the issue. pi-tech-support -> show tech-support from the PI CLI during the issue. pi-tcpdump.pcap -> tcpdump takem from the Linux shell of PI during the issue, for a period of about a minute. netstat_ano.txt -> netstat -ano output from the Linux shell of PI, taken during the issue. 5596-firewall2-usesr+sockets -> output of "show users" and "sh sockets connection tcp" commands from the N5K, taken during the issue.   I'll be greatful for any advice.   Thanks. ... View more