P.S. -- You said you have no idea what that is. This is actually quite a confusing and fun part of network history : ) Originally you had DEC, Intel, and Xerox that came out with the Ethernet standard. They had the ethertype field in the ethernet header that described the layer 3 protocol being carried. simple.
Then, the IEEE INSISTED on created their OWN different ethernet standard. They called it 802.3, and they completely screwed things up : ) Instead of having a 16-bit ethertype field to describe the next layer protocol, they had to get all fancy and decided to instead have a field called "length" followed by ANOTHER header called the 802.2 LLC header. In the LLC header you had a single 8-bit field called SSAP and an 8-bit field called DSAP. The SSAP and DSAP were supposed to describe the next layer protocol at the source and destination. NOW, the problem with that was the SSAP and DSAP were still only 1 byte each whereas the original ethernets ethertype field was 2 bytes long. This created compatibility issues so... The IEEE in all their wisdom expanded the already irritating 802.3 into 802.3 SNAP which then added yet ANOTHER header after the LLC header that allowed for more of these codes. With 802.3 SNAP you still have the LLC header, but you set both SSAP and DSAP to 0xAA. This tells the device that what follows the LLC header is a SNAP header. In the SNAP header, you had OUI which described the vendor that came up with the protocol being used, and you had type which was essentially your 16 bit ethertype. So essentially, they had a perfectly working protocol, DIX ethernet which they completely screwed up. Then in an effort to fix the issues, they screwed it up even more by adding yet another header that essentially carried the same information they could have just left alone in the original ethernet header. Now, here is the really funny bit -- The IEEE finally basically decided that their standard and all their mucking about was ridiculous, and revised their 802.3 ethernet standard in 1997. The hilarious part is that they went back to essentially what we had to begin with!!! THIS is the modern 802.3 revised ethernet standard we see today -- simple ethertype field and none of the LLC/SNAP madness HTH. Damn, I should have made this a blog : ) On Wed, Jan 20, 2010 at 4:20 PM, Joe Astorino <[email protected]> wrote: > Your understanding is correct -- Setting LSAP to 0xAAAA (DSAP = 0xAA, > SSAP = 0xAA) only tells us that there is indeed another SNAP header > that follows. However, the switch does not let us get that detailed. > There is no way to match the individual SNAP PID that I know of. > > On Wed, Jan 20, 2010 at 3:10 PM, Frank <[email protected]> wrote: >> >> All, >> >> Trying to understand the proctor guide thoroughly, I'm now struggling >> with an explanation in the proctor guide. It says that PVST+ is using an >> LSAP with value 0xAA. I have no clue what an LSAP is, but seeing the >> value it is presumably the concatenation of the DSAP and the SSAP. >> However, permitting frames with LSAP 0xAA simply permits all frames that >> have a SNAP LLC header. Should there not be additional filtering to >> allow ONLY spanning tree traffic frames? >> >> Finally, something completely unrelated just to satisfy my curiosity; in >> the Cisco manual the mac filter is described as: >> >> { deny | permit} {any | host src-MAC-addr | src-MAC-addr mask} {any | >> host dst-MAC-addr | dst-MAC-addr mask} [type mask | aarp | amber | cos >> cos | dec-spanning | decnet-iv | diagnostic | dsm | etype-6000 | >> etype-8042 | lat | lavc-sca | lsap lsap mask |mop-console | mop-dump | >> msdos | mumps | netbios | vines-echo | vines-ip | xns-idp] >> >> Question: why do they have a specific option for etype-6000 and >> etype-8042, that in my opinion could be written as: >> >> permit any any 0x6000 0x0000 and permit any any 0x8042 0x0000 >> >> Once again kind regards, >> >> Frank >> >> >> >> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> > > > > -- > Regards, > > Joe Astorino CCIE #24347 (R&S) > Sr. Technical Instructor - IPexpert > Mailto: [email protected] > Telephone: +1.810.326.1444 > Live Assistance, Please visit: www.ipexpert.com/chat > eFax: +1.810.454.0130 > > IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA > (R&S, Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice, > Security & Service Provider) Certification Training with locations > throughout the United States, Europe and Australia. Be sure to check > out our online communities at www.ipexpert.com/communities and our > public website at www.ipexpert.com > -- Regards, Joe Astorino CCIE #24347 (R&S) Sr. Technical Instructor - IPexpert Mailto: [email protected] Telephone: +1.810.326.1444 Live Assistance, Please visit: www.ipexpert.com/chat eFax: +1.810.454.0130 IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA (R&S, Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice, Security & Service Provider) Certification Training with locations throughout the United States, Europe and Australia. Be sure to check out our online communities at www.ipexpert.com/communities and our public website at www.ipexpert.com _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
