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=7&i=37938&t=37938 -- 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=7&i=38919&t=38919 -- 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=7&i=26693&t=26538 -- 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=7&i=27392&t=27361 -- 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=7&i=41192&t=41192 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
PIX & Citrix/nfuse access [7:18938]
Has anybody any experience on how I can allow remote workers using Citrix/nfuse through a PIX to access internal servers please. I have tried using the notes from citrix but they cannot help further and all I get when making the connection is a long delay and timeout. The idea is our home workers go to the site home page and hit a link which redirects them to the Citrix/nfuse server, where they login. I am not a Citrix expert and the in house Citrix guys are saying that any problems are on the PIX. They are talking about kicking PIX out and just using some freebi firewall from microsoft. Any help or config extracts would be appreciated Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=18938&t=18938 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
PIX & Citrix/nfuse access [7:18938]
Re-posted due to mail problems Has anybody any experience on how I can allow remote workers using Citrix/nfuse through a PIX to access internal servers please. I have tried using the notes from citrix but they cannot help further and all I get when making the connection is a long delay and timeout. The idea is our home workers go to the site home page and hit a link which redirects them to the Citrix/nfuse server, where they login. I am not a Citrix expert and the in house Citrix guys are saying that any problems are on the PIX. They are talking about kicking PIX out and just using some freebi firewall from microsoft. Any help or config extracts would be appreciated Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=18939&t=18938 -- 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=7&i=55888&t=55829 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
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=7&i=56189&t=56189 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
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 >
