At 09:44 AM 7/19/01, Phil Barker wrote:
>Guy,
>   it would yield 726 only if you were using an
>Ethernet SNAP frame.

My guess is that he was counting the preamble. The preamble doesn't really 
count as part of the frame, but newbies often do count it.


>For Ethernet 802.3 (6 byte destination + 6 byte source
>(mac addresses) + 2 byte length field + 1 byte SSAP +
>1 byte DSAP + 1 byte control + 700 payload + 4 byte
>CRC) = 721.
>
>For Ethernet Raw (6 byte destination + 6 byte source
>(mac addresses) + 2 ethertype + 700 payload + 4 byte
>CRC) = 718.

Call that Ethernet Version II.

Ethernet raw is the term used for Novell's frame type that has length but 
no LLC SSAP, DSAP or control.

Ethernet Raw (6 byte destination + 6 byte source
(mac addresses) + 2 length + 700 payload + 4 byte
CRC) = 718.

The payload launches right into the IPX layer with the IPX checksum, which 
isn't used and is always FF FF.

May I recommend a good paper on this topic? It's called Troubleshooting 
Ethernet Networks and it is currently free at 
http://www.certificationzone.com. The frame formats are nicely drawn in a 
GIF by yours truly. ;-)

Priscilla


>For Ethernet SNAP (6 byte destination + 6 byte source
>(mac addresses) + 2 byte length field + 1 byte SSAP +
>1 byte DSAP (both = 0xAA) + 1 byte control + 5 byte
>OUI + 700 payload + 4 byte CRC) = 726.
>
>Regards,
>
>Phil.
>
>PS: I think there is a pocket handbook by Miller that
>explains this in more detail.
>
>
>  --- "Lupi, Guy"  wrote: >
>Thank you to all who replied to this post.  I do
> > have another question for
> > you.  When the packet is sent to layer 2 for
> > encapsulation and transmission,
> > if it is Ethernet, an Ethernet header is placed on
> > and the frame is
> > transmitted.  As far as I know the only requirement
> > is that the frame must
> > end on a 32 bit boundary, must be at least 64 bytes,
> > and is not padded
> > further.  So that if the packet is 700 bytes, and is
> > encapsulated in an
> > Ethernet frame, the total would be approximately 726
> > bytes.  Is this
> > correct?
> >
> > -----Original Message-----
> > From: Priscilla Oppenheimer
> > [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, July 18, 2001 2:52 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Packet Sizes [7:12826]
> >
> >
> > FTP generally uses a full-size packet: 1500 bytes on
> > Ethernet, not counting
> > the header, CRC, preamble, inter-frame gap, or any
> > VLAN or MPLS tagging.
> >
> > HTTP does not use a full-size packet usually. You
> > would think it would, but
> > it tends to use a 500-600 byte packet size. Using a
> > shorter packet size
> > improves perceived performance because the screen
> > can show partial data
> > while more data is en route.
> >
> > ICMP depends on what you are doing and what
> > parameters you use. Most error
> > or warning messages would be very short, probably 64
> > bytes or so. If it's
> > ICMP echo (ping), then the user can specify the
> > number of bytes.
> >
> > TFTP sends data in 512 byte blocks. Add the 8-byte
> > UDP and 20-byte IP
> > header.
> >
> > For all of these examples, there may be additional
> > shorter packets for ACKs
> > and other overhead.
> >
> > Priscilla
> >
> > At 11:41 AM 7/18/01, Lupi, Guy wrote:
> > >Does anyone have a list of average packet sizes for
> > different services?
> > >Things like FTP, HTTP, ICMP, TFTP and the like.
> > Just something general is
> > >fine, I am aware that there is no hard and fast
> > rule.
> > ________________________
> >
> > Priscilla Oppenheimer
> > http://www.priscilla.com
>[EMAIL PROTECTED]
>
>____________________________________________________________
>Do You Yahoo!?
>Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
>or your free @yahoo.ie address at http://mail.yahoo.ie
________________________

Priscilla Oppenheimer
http://www.priscilla.com




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=12990&t=12826
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to