RE: TCP Ack numbers suddenly regress [7:56189]
Thanks for the info, but at this time it looks as though MFC was correct. Both hosts are running Tru64 (DEC Unix) and for whatever reasons the system admin for Host B has 'enabled' modified keepalives and modified the timers - amongst other things - at which probes are sent to 37 seconds, which fits with the problems we are seeing. Actually what they have set is 75 half seconds to wait before issuing a probe. What we now also know is that the behaviour for sending ACK minus 1 is correct and that also the ACK's in response to the probe at least according to DEC/Compaq/HP may not be received causing a reset. The ACK minus 1 forces the other end to send back the correct ACK and in fact saying I am still here. Its down to host implementations as to how this is done but the standard practice is as described above or more precisely in Vol II TCP/IP Illustrated. Anyway having persuaded the system admin guy to stop playing around with key systems as his personal toys the timers have been reset to default and all is now well. Thanks again Matt T -Original Message- From: [EMAIL PROTECTED] [mailto:nobody;groupstudy.com] Sent: 24 October 2002 17:55 To: [EMAIL PROTECTED] Subject: RE: TCP Ack numbers suddenly regress [7:56189] The keepalive process shouldn't cause ACKs to go backwards. It should cause them to stay the same. This doesn't sound like a keepalive situation which should proceed smoothly. This situation involves a RESET which usually indicates a problem of some sort, although possibly just a minor problem. It sounds more like a bug in the TCP implementation to me. We would have to see both sides of the conversation, including what both sides send, not just what they ACK, to troubleshoot this. The TCP RFC doesn't cover keepalives. They are mentioned in the Host Requirements RFC 1122, which is pretty critical of them, but admits that they MAY be included in a TCP implementation. After 2 hours (by default) a UNIX system that is using keepalives sends either any empty segment or a segment with one byte of garbage data. For the sequence number, it uses the sequence number of the last byte already sent. This should cause the other side to send the last ACK that it sent. Example: Host A sends bytes 100-200, SEQ number = 100 Host B ACKs, ACK number = 201 two hours Host A sends segment with SEQ number = 200 Host B ACKS, ACK number = 201 To troubleshoot, you can't just look at ACKs anyway. You have to look at both sides of the conversation. Also look at the timing. Did 2 hours go by? Also, what's the actual user complaint? Or is this just something you happened to notice in a trace? What is the network topology? Where are these hosts and what's in between them? Is there some sort of feature running between them that messes with TCP? For example a firewall or a router that does TCP Intercept?? ___ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com Matthew F. Crane wrote: Ok you don't say what they host systems are but I am going to guess Unix of some variety, in which case has anyone been playing around with the keepalive timers ? If the session keepalive timer is reached a probe is sent with the ACK number set to ACK-1 i.e. telling the other end that the recipient lied previously when it said it had received all the data. This forces the origin to resend with the correct ACK number TCP/IP Illustrated Vol 2 p830 There are probably other instances where this is done but that's the one I've come across most often. MFC -Original Message- From: [EMAIL PROTECTED] [mailto:nobody;groupstudy.com]On Behalf Of Matthew Tayler Sent: 24 October 2002 09:04 To: [EMAIL PROTECTED] Subject: TCP Ack numbers suddenly regress [7:56189] Anyone come across a situation where the ACK number suddenly steps back 1 and the link then resets ? Host A to Host B is running fine with the app using port 2400 on A talking to an app on B using ports 3564 3565 are in use. We have several traces showing the steady increase of sequence numbers then all of a sudden the ACK number takes step back by 1. There are no FIN segments in the preceeding traffic, but the now regressed ACK number is repeated in 7 segments sent and then a reset segment is issued and the two start exchanging data again. I am not allowed to post any of the data from the trace given the nature of the two systems involved, but here is an example of the way the ACK numbers run From A to B port 2400 to 3564 4567 is ACK'd 4785 . 4948 4947 From A to B port 2400 to 3565 466 is ACK'd 483 . 500 499 The link between the two is fine during this problem, utilisation drops but is nevera bove 20% anyway. Both host applicationms are still running and there are no process issues. The Cisco kit at either end is happy no error messages or the like so I we knows its host/app related. I can't find anything this specific in the archives
TCP Ack numbers suddenly regress [7:56189]
Anyone come across a situation where the ACK number suddenly steps back 1 and the link then resets ? Host A to Host B is running fine with the app using port 2400 on A talking to an app on B using ports 3564 3565 are in use. We have several traces showing the steady increase of sequence numbers then all of a sudden the ACK number takes step back by 1. There are no FIN segments in the preceeding traffic, but the now regressed ACK number is repeated in 7 segments sent and then a reset segment is issued and the two start exchanging data again. I am not allowed to post any of the data from the trace given the nature of the two systems involved, but here is an example of the way the ACK numbers run From A to B port 2400 to 3564 4567 is ACK'd 4785 . 4948 4947 From A to B port 2400 to 3565 466 is ACK'd 483 . 500 499 The link between the two is fine during this problem, utilisation drops but is nevera bove 20% anyway. Both host applicationms are still running and there are no process issues. The Cisco kit at either end is happy no error messages or the like so I we knows its host/app related. I can't find anything this specific in the archives and the nearest any of my textbooks come is to say a FIN has been issued - which the trace says is not the case. The reason for asking is that I didn't think it was possible to regress the sequence numbers, with the exception of the example from TCP/IP Illustrated Vol 2 noted above. Any ideas would be appreciated. Thanks Matt T Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=56189t=56189 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: CCDA beta exam topic ECNM [7:55829]
Is it nit just a 'poshed' up title for the old Access Distribution Core model ? -Original Message- From: [EMAIL PROTECTED] [mailto:nobody;groupstudy.com]On Behalf Of Andy Barkl Sent: 18 October 2002 06:25 To: [EMAIL PROTECTED] Subject: RE: CCDA beta exam topic ECNM [7:55829] Thank you for the response. I thought perhaps I was going crazy (not that I'm not already) because I couldn't find anything. -Original Message- From: Priscilla Oppenheimer [mailto:nobody;groupstudy.com] Sent: Thursday, October 17, 2002 7:34 PM To: [EMAIL PROTECTED] Subject: RE: CCDA beta exam topic ECNM [7:55829] Andy Barkl wrote: The new CCDA beta exam lists many new topics including; applying design solutions using the Enterprise Composite Network Model (ECNM). I've never heard of such a model. I don't think it's an industry-standard model. I'm having difficulty locating anything on CCO and wonder if anyone can offer alternative locations or resources? I couldn't find anything either. Hmm. Doesn't bode well for the beta. It sounds like you would have to have access to the beta class to pass the beta test. That's not good. The old CCDA was passable by someone with design experience even if they didn't know Cisco made-up marketing terms. And I think that was a good thing. :-) Also, the old class taught design methods that could be applied regardless of new marketing solutions. The new approach may be more cookbook or based on specific models, which I think would be unfortunate. If you read most descriptions of specific models, they say this may not work for your network. It's better to teach methods that will work for any network. Back to the so-called Enterprise Composite Network Model, my guess is that it has something to do with Cisco's SAFE security blueprint. There's more info here: http://www.cisco.com/warp/public/779/largeent/issues/security/safe.html Good luck! ___ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com Thanks! Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=55888t=55829 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
How fast do bits travel ? [7:41192]
Ok I have spent ages trying to find an answer to this question, and probably only added to my confusion. You know how it is you spend ages looking at something and become snow blind or get tunnel vision or whatever, but I cannot see the answer to the following: How far does a bit travel in say 1 second or put another way how long does a bit take to travel a certain distance ? I understand, or think I do that if the line is say 128kbps then I can, in theory at least, expect 128,000 (approx) bits start down that line every second. But how long do they take to reach the other end, assuming a point to point link and both ends being the same speed, obviously. There has to be a nice simple formula for this somewhere, you know the sort of thing x= line speed, y = distance z = time etc Any ideas or poitners would be appreciated Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41192t=41192 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
OT: Stitched up on .NET [7:38919]
My boss has landed me in it and I have to do some form of presentation on Thursday of the value of .NET. Being told 20 minutes ago hasn't helped the situation. Ok I can out about what it does or allegedly does, but has anyone any idea where to find critical assessments of .NET please Thanks in advance Matt T Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=38919t=38919 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
CCSI and how to get there [7:37938]
Ok I have tried cco - which gives very little away - and the Groupstudy archives which seem to relate to ICRC and other out of date material. How I get to CCSI ? Basically I have an inheritance - with certain conditions - which should finance the process, but, what's the process. I would prefer not to be tied in to an employer as part of it, if that makes sense. The aim being to be come a freelance trainer. Thanks for any advice Matthew Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=37938t=37938 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: ACL Gurus [7:27361]
Ok I am a little confused here, but 1. What does access-list 101 actually deny ? 2. If you permit all ip are you not also allowing all tcp udp ? Matt T Jeff wrote: Looking to block icmp-echo on my external router... just want to doublecheck that I'm putting these on the right interfaces. Please, suggestions welcome! Cheers, Jeff access-list 101 permit icmp x.x.54.0 0.0.0.255 any echo access-list 101 permit icmp x.x.55.0 0.0.0.255 any echo *Permits internal network to ping any host access-list 101 permit ip any any *Permits any other traffic to and from the network. Need for the explicit deny access-list 102 permit icmp host x.x.x.x any echo-reply *Permits a ping reply from ISP servers for monitoring access-list 102 permit icmp any any packet-too-big *Permits Fragmentation Required ICMP packets (Used of MTU-PD) access-list 102 deny icmp any any echo-reply deny any echo reply from any other sources access-list 102 deny icmp any x.x.54.0 0.0.0.255 echo access-list 102 deny icmp any x.x.55.0 0.0.0.255 echo deny any echo from any other sources access-list 102 permit ip any any *Permits any other traffic to and from the network. Needed due to the explicit deny rule. Both Access-list are applied to the Serial Interfaces of the Edge router. Access list 102 is assigned to inbound traffic and Access list 101 is assigned to outbound traffic. See below.. Internet (same ISP, different BGP peers) S0/0 S0/1 \ / \/ \ / Edge Router | E0/0 | FW | LAN x.x.54.0 and x.x.55.0 networks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=27392t=27361 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Spanning Tree Protocol [7:26538]
Ok dumb question of the day, what do you mean by Big Endian Little Endian please ? Priscilla Oppenheimer wrote: At 10:12 PM 11/16/01, Kane, Christopher A. wrote: Someone was a Douglas Adams fan? Of course! Also another cool thing about 42 is that it's a palindrome (the same backwards and forwards in binary) and avoided the Little Endian/ Big Endian wars! Priscilla -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 8:27 PM To: [EMAIL PROTECTED] Subject: Re: Spanning Tree Protocol [7:26538] At 04:55 PM 11/16/01, John Neiberger wrote: You asked that question right when I had EtherPeek running on my PC. So, the answer is: 0180.c200. Source and Destination SAP: 0x42 :-) See? The answer *is* 42! According to Radia Perlman, the IEEE chose this SAP on purpose. ;-) Randy Lopez 11/16/01 2:27:57 PM What Multicast address does STP use? Priscilla Oppenheimer http://www.priscilla.com Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=26693t=26538 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
