I use a sniffer. I also use IEEE documents (which are free now!) and RFCs. For Novell information, I would go directly to Novell's site, which is slow (runs on Novell servers? ;-) but useful.
In the case of Ethernet frame types, here's what I would do: On a Cisco router, configure the following commands, one by one: Albany(config-if)#ipx network 400 encapsulation ? arpa Novell Ethernet_II hdlc HDLC on serial links novell-ether Novell Ethernet_802.3 sap IEEE 802.2 on Ethernet, FDDI, Token Ring snap IEEE 802.2 SNAP on Ethernet, Token Ring, and FDDI Albany(config-if)#ipx network 400 encapsulation snap Albany(config-if)#ipx network 100 encapsulation arpa secondary Albany(config-if)#ipx network 200 encapsulation sap secondary Albany(config-if)#ipx network 300 encapsulation novell-ether secondary Then I would look at each of these with a sniffer. This is what I recommend in the Ethernet lab scenario on www.certificationzone.com, which by the way, is another set of documents that I trust, (although the ARP tutorial has the usual misconceptions in it, which is very disappointing.) It's a tough world out there, I know. For some reason, there's an awful lot of BS published on both the Web and in books. Amazon reviews are helpful. I trust those. Check out the reviews for Doyle, for example, and for Clark and Kennedy. All excellent and right on. Check out the reviews for the "get rich quick by feeding yourself with cliches about networking" books (i.e. certification study guides). Not all so good. Priscilla At 03:04 PM 11/12/01, Kane, Christopher A. wrote: >Priscilla, > >You bring up a good point, "where did you get that description of >Ethernet...". > >It seems that for every topic/subject I research in my IE studies, I have >to check 2 or 3 other sources for fear of inaccuracies. I've been trying >to focus more on RFCs and then using the other books to help me understand >"how Cisco does it". > >Without requesting you to promote anyone's books, what do you typically >use as source material? I'd like to pose that question to Howard as well. >Specifically since I've seen his name cited by authors (i.e. Jeff Doyle) >as contributors to their works. > >Does there exist other sources other than RFCs that contain a level of >accuracy that leaves one feeling confident after reading it? > >Thanks, >Chris > >-----Original Message----- >From: Priscilla Oppenheimer >[mailto:[EMAIL PROTECTED]] >Sent: Monday, November 12, 2001 2:00 PM >To: [EMAIL PROTECTED] >Subject: Re: 802.2 Frames [7:25925] > >Where did you get that description of Ethernet frame types? It's riddled >with mistakes, I'm afraid. > >At 09:21 AM 11/12/01, [EMAIL PROTECTED] wrote: > >Ok - four different encapsulation types are commonly found on an > >"ethernet" network. All versions have a frame format that includes > > > >* preamble > >* destination MAC address > >* source MAC address > >* a field who's purpose differs with encapsulation type > >* payload > >* frame check sequence (CRC) > > > >The encapsulation types differ as follows > > > >* Ethernet II (Cisco keyword "arpa") - uses a payload length field. > >Since the ether MTU is 1518 with 18 octets of overhead, this field is > >never more than 1500. > >There's no length field in an Ethernet II frame. It Dest Src Type. That's it. > > >* 802.3 Raw - This type is said to be raw because service access points > >are not specified, as in 802.2 or SNAP. The field used for length in > >ethernet II carries instead "type" information that specifies the layer > >three protocol. Key values are (in hex) > >Nope, this one has length, not type. It's Dest Src Length IPX. Novell calls >this 802.3, although it's non-standard to use an 802.3 header without the >following 802.2 header and Novell raw is the only instance of this. > > >* 802.2 (SAP) - If the 802.3 type field specifies SAP, fields specifying > >source and destination service access points (DSAP and SSAP) have been > >inserted between the length field and the payload. The service access > >points specify the higher level entity that will process the message - > >thus, they effectively specify the higher level protocol encapsulated in > >the frame. > >This is a standard 802.3/802.2 frame. Dest Src Length, 802.2 (LLC). The >802.2 header has the DSAP, SSAP, and Control fields. This frame format is >confusing if you are used to Novell terminology because Novell calls it >802.2. But it's also 802.3 and IEEE assumes an 802.3 header has an 802.2 >header that follows and would just call this 802.3. > > >* SNAP - If the LLC header (DSAP and SSAP are both AA), a SNAP sub > >header between the SAP header and payload add a 5 byte field that allows > >specification of additional layer three protocol types. > >That is correct. > >Priscilla > > >CCIE TB wrote: > > > > > Microsoft devices defaults to 802.2 frame format when using NWLink, I'm > > > having a problem categorizing this type. > > > > > > Ethernet II ------> uses Type instead of Length > > > 802.3 ------------> uses Length and SSAP/DSAP > > > SNAP ------------> uses Length with fixed SSAP/DSAP and adds SNAP >header. > > > Based on this what is the format of 802.2 frames > > > > > > > >-- > >Jason > > > >Boson BCMSN1 BSCN2 BSCI2 practice tests > >E-Quizware CCIE practice test >________________________ > >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=25990&t=25925 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
