--- "Erik S. Johansen" <[EMAIL PROTECTED]> wrote: > ICMP - This is a protocol with many of the properties of a layer 4 > protocol, > but as it is an integral part of IP it is implemented as a layer 3. > ICMP used > the standard IP header, and includes an additional type field (e.g. > "echo > request" and "echo reply" used for ping) + data relevant to the icmp > type. > ICMP is sort of a helper protocol, with which machines with an IP can > > transmit information in between each other in order to notify of > events or > request changes in the way IP is treated.
This helps my understanding allot better and also clarifies that ICMP is a layer 3 protocol not layer 4. Your statements also back what others have said so far. Thanks. I'm studying for a Cisco exam and I want to make sure that I understand every area covered within the exam. This is just one of those grey area's for me. > A typical traceroute happens as follows: > > A wants to traceroute E. In between them you have B, C and D. > > A sends a UDP (yes UDP is what default traceroutes use) packet to E, > with a > TTL (Time To Live) value of 1. B receives this packet, and sees that > it has > travelled TTL machine-machine hops. It then drops the packet as the > TTL is > exceeded, and sends an icmp ttl-exceeded back to A, including a > specification > of which packet it dropped. A now resends the UDP packet, this time > with a > TTL of 2. The packet travels to C this time, and again a ttl-exceeded > icmp is > sent back. This continues until the UDP packet actually reaches E. > While this > happens, the traceroute application shows the IPs of the machines it > receives > ttl-exceeded ICMPs from, and you'll get a nice map of how traffic > *from A to > E* travels. You still can't know how traffic from E to A travels, as > that can > be a totally different path (async routing), although in many cases > it is the > same. This also clears up some confusion as well. I understand how ping and traceroute work as you described for the most part. My confusion was in the fact that I remember seeing (maybe Win95 or 98) using tcp when either ping'ing or tracert'ing. This isn't true of Win2k or XP. Don't have Win98 or 95 to test with though. As well, when I further researched ping on linux via Ethereal I noticed that it infact uses Plain vanillia ICMP, but when "traceroute"'ing it uses UDP unless otherwise told by using the "-I" option. "man traceroute" gave me all the info that I needed. So, all in all, thanks for your input and everyone elses. Just to clarify: So when I'm using ipsec/vpn ESP/IP=50 between two endpoints all the data that is sent after authenticating (IKE UDP 500) and bringing up the vpn tunnel is encapsulated/encrypted in IP 50 packets and its upto the vpn gateways to implement a solution for "IP 50" packets that get lost or corrupted in transit? Where, (not using ipsec as an example) if you were using TCP, it would tell you to resend if the packet wasn't received or corrupted in transit. Just trying to get a better understanding of how error handling would be handled when strictly using IP type protocols for data transmission. I would assume that this is like UDP or TCP in that it is up to the application or transmitting host (or both) to know or have programmed knowledge of how to correct errors that happen in transit?? I guess the other thing that I'm trying to understand is what are the benifits of using a IP protocol that doesn't use udp or tcp when transmitting data acrossed the internet? Less overhead because its connectionless with best effort delivery like UDP but don't seem to be "port/socket" specific but "raw protocol specific". Kind of a grey area still. But I feel that I'm getting a better understanding now. Thanks, Joshua Banks __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ -- [EMAIL PROTECTED] mailing list
