<color><param>0100,0100,0100</param><FontFamily><param>Times New
Roman</param><bigger>This debug looks normal. Here is a breakdown:
<color><param>7F00,0000,0000</param><FontFamily><param>Arial</param><smaller>NAT: o:
tcp (216.59.x1.x1, 59456) -> (208.4.x.131, 443) [12538]
NAT: i: tcp (20.10.5.13, 443) -> (216.59.61.131, 59456)
[46552]<color><param>0100,0100,0100</param><FontFamily><param>Times New
Roman</param><bigger>
o or i - indicates (i)nbound or (o)outbound from the perspective of the
NAT process
(216.59.x1.x1, 59456) - indicates the source IP address with source
TCP port of 59456
(208.4.x.131, 443) - indicates destination IP address with destination
TCP port of 443
[12538] - indicates the IP identification field of the packet, this is set by
the sender.
IP identification fields don't necessarily have to be sequential, although
the vast majority of OSes choose them sequentially (the RFC doesn't
specify how they are chosen, only that they must be unique for the
duration of the time they will be active in the network).
However, its not unusual in your case to see gaps in identification
numbers from the server since your not looking at every single packet
from the server, only those that were part of your NAT convesation. It's
very likely that the "missing" sequence numbers were just other packets
going to other destinations.
I don't see anything in this trace that indicates a problem. What you
really need is a sniffer trace of packets going to the workstation that is
having a response time issue and look at the timestamps to see when the
packets are coming in and going out. (or maybe a longer NAT debug
trace showing the same thing)
If you take more debug logs, I would suggest adding the command:
<bold>service timestamps debug datetime msec</bold>
And make sure your clock on the router is set correctly.
HTH,
Kent
<bold>
</bold><FontFamily><param>Arial</param><smaller>On 29 Jan 2001, at 19:04, bnk wrote:
<color><param>7F00,0000,0000</param>> Thanks for the input. I am not local to the
router, so I telnet in, go to the secure
> page on the web and login, but dont press enter. I then "debug ip nat detailed", hit
> login on the secure page and wait 10 seconds. then undebug all. Everything
>sequences
> just fine, except the 443 stuff. Here is an example. I post this because I think
>it is
> the server also, but I don't know if 443 sequences the same. Is it not in sequence
>as
> another form of security?
>
> Here is a sample:
>
> 1w4d: NAT: o: tcp (216.59.x1.x1, 59456) -> (208.4.x.131, 443) [12538]
> 1w4d: NAT: i: tcp (20.10.5.13, 443) -> (216.59.61.131, 59456) [46552]
> 1w4d: NAT: o: tcp (216.59.x1.x1, 59450) -> (208.4.x.131, 443) [12539]
> 1w4d: NAT: i: tcp (20.10.5.13, 443) -> (216.59.x1.x1, 59450) [46808]
> 1w4d: NAT*: o: tcp (216.59.x1.x1, 59450) -> (208.4.x.131, 443) [12540]
> 1w4d: NAT*: o: tcp (216.59.x1.x1, 59450) -> (208.4.x.131, 443) [12541]
>
> The 2x6 number is me out on the web. The 208 is the secure web site. The 20 is
>there
> number on the inside. See how the Me to Them is 12538, 12539. Them back to me is
> 46552, 46808 ??? Is sequencing for ssl the same? This has now turned into a lesson
>for
> me in ssl..I think?
>
> Thanks to all
>
> Brant Stevens wrote:
>
> > Unless there is an access list or route-map in place for SSL traffic, the
> > router would not care whether the traffic was http, or https (ports 80 and
> > 443 respectively). If it were an applied interface extended access-list
> > that only specified http traffic, then the ssl traffic would be denied. I
> > would take a look at the server. One thing you could do is take a network
> > trace to look at the packet respose times by checking the ACK sequences,
> > etc...
> >
> > -Brant
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> > ipguru
> > Sent: Monday, January 29, 2001 5:54 PM
> > To: [EMAIL PROTECTED]
> > Subject: ssl slowing down?
> >
> > I know that ssl can slow down a web site's response time. But someone
> > is complaining that a config on a 2610 wasn't saved and after a reboot
> > the ssl pages are taking 2 minutes to come down and the regular pages
> > are just fine. Is there any command that could have been left out (not
> > saved when it was done) to speed things up that much?
> >
> > thanks,
> > bk
> >
> > _________________________________
> > FAQ, list archives, and subscription info:
> > http://www.groupstudy.com/list/cisco.html
> > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> >
> > _________________________________
> > FAQ, list archives, and subscription info:
>http://www.groupstudy.com/list/cisco.html
> > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
> _________________________________
> FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
<nofill>
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
