It doesn't surprise me that 75% of the traffic you see when you put a Sniffer on a switch port is IPX. It's probably SAPs and RIPs. Remember that you only see broadcasts unless you mirror other ports. So you may be getting a skewed view.
Regarding your comment about multicasts: A good driver will register with the NIC to receive only those Layer 2 multicasts it cares about. So a good NIC and driver on a PC that doesn't understand AppleTalk just drops AppleTalk multicasts. Routers don't forward these multicasts. Even routers configured for AppleTalk don't forward them. They are Layer 2 multicasts. Regarding AppleTalk's dynamic addressing, sorry that you think it's lame. The IPv6 developers don't. Their stateless autoconfiguration if very similar. comments below). Regarding your CCNA comment about obtaining a unique address with AppleTalk, it doesn't take many packets to get a unique address is most cases. For one thing, a device uses the one that it used last time it booted. It's unlikely some other device would have taken the address in the meantime on a well-designed network. Now, I would like to turn this into a "teaching moment." ;-) Here's how IPv6 stateless autoconfiguration works. If you know AppleTalk, you will see the similarities. This is from my upcoming book. Stateless autoconfiguration requires no manual configuration of hosts, minimal (or no) configuration of routers, and no servers. For a network engineer who is not concerned about which addresses are used, as long as they are unique and routable, stateless autoconfiguration offers many benefits. Stateless autoconfiguration is discussed in RFC 2462. With stateless autoconfiguration, a host generates its own address using locally available information plus information advertised by routers. The process begins with the generation of a link-local address for an interface, which is generated by combining the well-known link-local address prefix (1111 1110 10) with a 64-bit interface identifier. The interface identifier is usually derived from the hardware address in ROM on the NIC. The next step determines the uniqueness of the tentative address that has been derived by combining the link-local address prefix with the interface identifier. The host transmits a Neighbor Solicitation message with the tentative address as the target address. If another host is using this address, a Neighbor Advertisement is returned. In this event, autoconfiguration stops and some manual intervention is required. (Because the address is partially based on a NIC address, duplicates are very unlikely.) If no responses are returned, the tentative address is considered unique, and IP connectivity with local hosts is now possible. Before sending a Neighbor Solicitation message, an interface must join two groups: the all-nodes multicast group and the solicited-node multicast group for the tentative address. The former ensures that the node receives Neighbor Advertisements from other nodes, the latter that two nodes attempting to use the same address simultaneously detect each other's presence. To check an address, a node sends Neighbor Solicitations with the IP destination set to the solicited-node multicast address of the target address. The final phase of the autoconfiguration process involves listening for Router Advertisement messages that routers periodically transmit. A host can also force an immediate Router Advertisement by transmitting a Router Solicitation message to the all-routers multicast address. Router Advertisements contain zero or more prefix information options that contain information used by the host to generate a site-local address that has a scope that is limited to the local site. The router advertisements also include a global address with unlimited scope. The advertisement may also tell a host to use a stateful method to complete its autoconfiguration. Priscilla At 11:17 PM 4/29/02, Michael L. Williams wrote: >"Priscilla Oppenheimer" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > AppleTalk traffic doesn't bother other people. AppleTalk devices don't > > broadcast; they multicast, and they don't do that very often. AppleTalk > > routers and servers don't ever broadcast (or multicast) service > > announcements like they do in an IPX environment. And the Chooser doesn't > > broadcast either. A Mac sends a unicast packet to a router when the user > > pulls up the Chooser. The router figures out which networks are in the >zone > > and forwards the unicast. The recipient routers then multicast. And, no, > > this doesn't repeat forever at short intervals. Since Mac OX 7.0 (1989) >the > > Mac has backed off on the unicasts it sends to start the process. > >Okay...at the risk of facing the wrath of Priscilla, here goes. =) > >Just off the top of my head, why would multicasting be any better than >broadcasting.... in fact, wouldn't that be worst as broadcasts (L2 or L3) >are stopped at the router whereas multicast could traverse your entire >network, even through routers...? > >You gotta give me this tho: AppleTalk picks a layer three address at >random, then checks to see if it's in use and repeats until it finds one it >can use..... How lame is that?.... I was digging thru my CCNA notes from 2+ >years ago and read a comment I wrote saying (about it choosing an L3 addr at >random) "imagine if that were used on the internet... it could take >days/weeks to get an IP address".. =) > > > You knew you would push one of my buttons, didn't you? ;-) > > > > As far as IPX traffic, it's not really that bad either, but the SAP > > broadcasts can get excessive. There are many ways to keep them contained, > > if that's what the poster had in mind. I think he better give us more info > > on what he's trying to accomplish. > >I have to disagree here....... IPX traffic is horrible (admittedly due to >Novell, not as a protocol itself per se..... also as you pointed out, in all >fairness, a large %-age is SAP broadcasts and admittedly, the people whom I >inherited the network from didn't do squat to limit any kind of SAP >traffic)..... If you pick a random switchport out of the 28000+ >switchports on our network and do a sniffer capture, you'll find probably >75% of it is IPX related... and we use IP for probably 90% of our apps (and >web/internet access)..... that's not acceptable..... we cannot wait to get >rid of IPX altogether (which will happen when our migration from Netware to >2000 is complete)..... I'm not a Microsoft zombie, by any means, and I >won't even claim that Win2K and Active Directory is any better than Novell >NDS, but getting rid of IPX is a godsend no matter if it means running >Microslop Win2K.... that's how much we hate dealing with IPX =) > > > Hopefully he didn't just buy into the BS that "IPX is chatty" (the same BS > > that you hear about AppleTalk. ;-) You want chatty, watch a Windows >machine > > running NetBIOS and SMB boot! > >Sounds like sour grapes. LOL (just kidding =) > >Hey.... I've seen your website with you @ your I-SCHMAC laptop.... so it >doesn't surprise me to see you defending AppleSquawk... =) > >Mike W. ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=42913&t=42913 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
