Re: response time between PIX with VPN [7:60981]
Well..well..well.. in a way I feel like idiot.. but in another it was a very much a learning experience. After checking over everything and recreating the 800mS to 2 second delays, I found the problem. When I first set up the lab, I spent some time working with the debugs for ipsec, isakmp and icmp. I was bouncing between PIXs looking at the results and working out the configs. Apparently, on the 520 PIX, I left a debug process running or it hung there on it's own from one of the times the ssh window timed out. I would have thought it would have died on its own but..then again maybe not. I had to reboot the 520 but that clear the problem and pings went to an expected 2mS response time. I had not rebooted the 520 since I was trying to replicate using a production PIX. I'm starting to think that when working with VPNs and the like, a reboot is a useful thing to do. Yes? no? Thanks again for the comments.. as it turns out I learned things from the comments and my own struggles. Sometimes it's best this way :) MikeS Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=61261t=60981 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: response time between PIX with VPN [7:60981]
What eric is refering to is a couple different items. One is the forward lookup of the name given on the command prompt, which I don't recall any traceroute implementations which cause high latency for that. Secondly is the reverse lookup many traceroute's will do if you give an IP address as the destination. Many of these send the first packet out, then make a call for reverse lookup.Sun Solaris is the notable OS who does this with ping and causes the first response(s) to be reported as extremely high latency due to the program waiting on the reverse lookup to finish. 3rd is the reverse lookup of individual hops as seen in traceroute output. I can't recall any implementation mangling RTT results due to this, but I wouldn't be surprised to see it. Mostly this just delays the next round packets from being sent. Finally kernel level ICMP rate limiting has been done in a number of OS's and makes agressive ping tests a poor tool. And makes using low rate ping against a busy host something to trust with skepitism. I doubt you are seeing any of these Mike, but just wanted to clarify why someone would see those kinds of results. I know I've had to have long conversations explaining these things to *nix admins who believed the network had extremely high latency. :-) There is obviously something going on, not sure what it is myself. I agree with the other posters that L2 could be causing performance problems. Have you broken down testing so it's not just end-to-end between these two windows hosts but also from one windows host to each of the endpoints along the way? Has IKE finished already when you send these packets? Are the lifetimes of your SA's long enough or are they aging out between individual test packets? Darrell Mike Sweeney wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... In answer to Eric, there is not any DNS involved as the traceroute is IP only... no name resolution needed. In answer Ed's comments, I have both plugged into a switch and so it's not *back to back* in the normal sense of the word. MikeS Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=61235t=60981 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: response time between PIX with VPN [7:60981]
Darrell- I like the tidbit about reverse lookup with traceroute.. I always wondered why the Sun boxes were so slow at times during pings . Now I need to fire up the sniffer and the x86 Solaris and see what I can see :) It would be my luck that the x86 Solaris is different .. Anyways.. this config was a Win2K laptop to a Win98 laptop. The back to back between PIXs is made via two ports on a 2900. I plan to run through it again this weekend and get some better notes. Priscilla.. I started with ping but went with traceroute to play with access lists allowing traceroute to pass. The telnet was just a quick and dirty test that I could in fact make the connection through the tunnel. It was an observation that the response time of the telnet was very *bursty slow*. It would almost *pause* and then send a sequence of keystrokes. Almost like the tunnel was flapping but the debug did not show this. That slowness tied into the 800ms times posted by traceroute since 100ms is preceptible by a user. Like I said, I'll run a more formal test and gather up some more data. I posted just to see if anyone had some ideas off the top of their heads. Thanks MikeS Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=61240t=60981 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: response time between PIX with VPN [7:60981]
it has nothing with the VPN tunnel but everything to do with DNS. if you specify the IP address in the /etc/hosts file, that will speed it up very quickly. I have the same setup like yours with the exception that I have franken pixes (Pix520) on both ends By the way, use version 6.2(2) on the pix firewall. Version 6.2(1) is very buggy. Mike Sweeney wrote:I just set up a back to back PIX firewall test. Using IKE and IPsec with a laptop on either end. One is a 520 (6.2) and the other is a 501 (6.2) and Win2K and Win98 as clients. Everything works as it should but.. isnt there always a but? the traceroute response time is something like 800mS. When I telnet into the 2K box from the 98 client, it's pretty slow in the echo back to the telnet session. Ideas of what to check? I cant believe that is considered normal unless it's directly related to the 501 being pokey and the 520 being an older PII300?? Thanks MikeS Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=60982t=60981 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: response time between PIX with VPN [7:60981]
Mike, How are the PIXes connected? If via a crossover, you might be experiencing excessive collisions. I've tested a similar configuration as well, and I've found that placing a switch in between the two PIXes will eliminate the collisions. Ed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mike Sweeney Sent: Monday, January 13, 2003 11:40 AM To: [EMAIL PROTECTED] Subject: response time between PIX with VPN [7:60981] I just set up a back to back PIX firewall test. Using IKE and IPsec with a laptop on either end. One is a 520 (6.2) and the other is a 501 (6.2) and Win2K and Win98 as clients. Everything works as it should but.. isnt there always a but? the traceroute response time is something like 800mS. When I telnet into the 2K box from the 98 client, it's pretty slow in the echo back to the telnet session. Ideas of what to check? I cant believe that is considered normal unless it's directly related to the 501 being pokey and the 520 being an older PII300?? Thanks MikeS Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=60983t=60981 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: response time between PIX with VPN [7:60981]
In answer to Eric, there is not any DNS involved as the traceroute is IP only... no name resolution needed. In answer Ed's comments, I have both plugged into a switch and so it's not *back to back* in the normal sense of the word. MikeS Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=60984t=60981 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: response time between PIX with VPN [7:60981]
Check for duplex and speed settings on switch as well as interface errors and collisions. Mike Sweeney wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... In answer to Eric, there is not any DNS involved as the traceroute is IP only... no name resolution needed. In answer Ed's comments, I have both plugged into a switch and so it's not *back to back* in the normal sense of the word. MikeS Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=60985t=60981 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: response time between PIX with VPN [7:60981]
Is ping that slow too? What else did you try? FTP? TFTP? Traceroute and Telnet are sort of weird ways of testing response time, but a good start. Can you put a sniffer on one of the Windows machines and see where the delays are actually occuring? Try to distinguish between a slow network and slow applications. By looking at the timing of ACKs and other replies at the different layers, you could probably determine where the slowness occurs. Good luck. ___ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com Mike Sweeney wrote: I just set up a back to back PIX firewall test. Using IKE and IPsec with a laptop on either end. One is a 520 (6.2) and the other is a 501 (6.2) and Win2K and Win98 as clients. Everything works as it should but.. isnt there always a but? the traceroute response time is something like 800mS. When I telnet into the 2K box from the 98 client, it's pretty slow in the echo back to the telnet session. Ideas of what to check? I cant believe that is considered normal unless it's directly related to the 501 being pokey and the 520 being an older PII300?? Thanks MikeS Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=60992t=60981 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
