It does help to have the option of copy and pasting from one's current work! ;-)
A few people have asked, and I responded a couple times, but I think they all got filtered (hmm what does that mean?), but I am working on a new book on troubleshooting and protocol analysis. It will cover all Cisco Support test topics and many topics for the Routing & Switching CCIE written test. The writing is almost done, but the production, editing, etc. takes forever, so stay tuned. Thanks for asking! Priscilla At 08:37 AM 12/14/01, Elmer Deloso wrote: >Priscilla, >I have a feeling that this type of post is a preview of the >sequel to Top Down Network Design, right? > >Elmer > >-----Original Message----- >From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] >Sent: Thursday, December 13, 2001 9:18 PM >To: [EMAIL PROTECTED] >Subject: RE: Correction - about multicast address! [7:29057] > > >And you probably also meant to say that the MAC header only has room for >one data-link-layer address also. So the IP multicast address is converted >to a single MAC multicast address. > >Applications on end systems register with the NIC to receive packets >addressed to particular multicast addresses. > >The application may also use the Internet Group Management Protocol (IGMP). >IGMP allows a host to join a group and inform routers of the need to >receive a multicast data stream. When a user (or software) starts a process >that requires the host to join a multicast group, the host transmits an >IGMP Membership Report message to inform routers on the segment that >traffic for the group should be multicast to the host's segment. Although >it is possible that a router is already sending data for the group, the >IGMP specification states that a host should send a Membership Report in >case it is the first member of the group on the network segment. > >The router does not need to know how many or which specific hosts on a >segment belong to a group. The router just needs to recognize that a group >has at least one member on a segment so that the router will forward group >traffic to that segment using the IP and MAC multicast addresses for the >group. > >By default, a data-link-layer switch floods multicast frames out every >port. The Cisco Group Management Protocol (CGMP) and the IETF IGMP Snooping >method allow switches to participate in the process of determining which >segments have hosts in a particular multicast group. CGMP is a >Cisco-proprietary method that lets a router send a message to switches to >tell the switches about Membership Reports and Leaves occurring on their >segments. IGMP is an IETF standard that causes no extra traffic, but allows >a switch to learn from the IGMP messages sent to routers. > >In addition to determining which local network segments should receive >traffic for particular multicast groups, a router must also learn how to >route multicast traffic across an internetwork. Multicast routing protocols >provide this function. Multicast routing protocols extend the capabilities >of a standard routing protocol, which learns paths to destination networks, >to include the capability of learning paths to multicast destination >addresses. There are numerous multicast routing protocols, some of which >are considered obsolescent at this time. The most commonly-used multicast >routing protocol today is the Protocol-Independent Multicast (PIM) protocol. > >Just wanted to add to your excellent explanations. > >Priscilla > > >At 05:10 PM 12/13/01, Karen E Young wrote: > >Reding this over I realize that I should have explained a little better... > > > >What I should have said is "An IP header only has room for one destination > >address, therefore a MAC must be manufactured for the group rather than a > >specific device so that the layer-2 protocol (ethernet, token-ring, etc.) > >can deliver to those routers/switches that belong to the group. The > >routers/switches can then forward to those group members it has listed if > >necessary. > > > >I should also have mentioned that this means that the NIC needs to be able > >to recognize the MAC address associated with any multicast groups the >device > >belongs to. > > > >Just shows what happens when you try to do too many things at once.... > > > > > > > >Karen > >*********** BEGIN FORWARDED MESSAGE *********** > > > >On 12/13/2001 at 3:27 PM Karen E Young wrote: > > > >Elmer, > > > >In fact I have done soem teaching, however, it was the months spent doing > >phone-tech-support for an ISP that honed the explanation skills. Most of > >our customers didn't know much about computers and felt alot more confident > >doing what you tell then to do if you explain WHY in a manner that they can > >understand. > > > >As far as the "you can't fit multiple destination MAC addresses into an IP > >header"... I was just explaining why a special multicast MAC address is > >required for messages sent to a specific Multicast group address. An IP > >header only has room for one dest. MAC, therefore a MAC must be > >manufactured for the group rather than a specific device. > > > >Glad I was able to help, > > > >Karen > > > >*********** REPLY SEPARATOR *********** > > > >On 12/13/2001 at 3:27 PM Elmer Deloso wrote: > > > > >(Corrected message for an earlier posting.) > > >Karen, > > >I have a feeling that you've been in some kind of teaching role > > >before based on how you explain concepts. This makes the picture > > >complete especially when revisiting the previous post by Shawn Kaminski. > > >However, when you say "you can't fit multiple destination > > >MAC addresses into an IP header" it seems you're referring to > > >the device's mapping of the IP-to-MAC address, since there is no > > >place in the IP header itself to even contain the value of the > > >MAC address being used to frame the IP packet. At least that's what > > >Doyle's book shows. If so, then I'm perfectly enlightened now. > > >It's good to hear from you again. Thanks to all reponses. > > > > > >Elmer > > > > > >-----Original Message----- > > >From: Karen E Young [mailto:[EMAIL PROTECTED]] > > >Sent: Thursday, December 13, 2001 2:00 PM > > >To: [EMAIL PROTECTED] > > >Subject: RE: about multicast address! [7:29057] > > > > > > > > >Elmer, > > > > > >Since an IP address needs to be mapped to a MAC address for delivery, a > > >multicast frame needs a destination MAC address in the header. As a > > >multicast frame is going to multiple destinations that are probably not > > >known to the sender, a special MAC address needs to be used. After all, >you > > >can't fit multiple destination MAC addresses into an IP header. The base > > >MAC > > >address used for multicast is 0100.5E00.0000. In order to tailor the MAC > > >address to the specific multicast group, the least significant 23 bits of > > >the group address are mapped to the least significant 23 bits of the > > >multicast MAC address. > > > > > >The first four bits of the IP address (1110) identify it as a class D > > >address (multicast) and will never change. Therefore, they are not > > >considered when figuring the IP to MAC conversion. This leaves 28 bits. > > >Since you are copying only 23 bits to the MAC address, you are left with >5 > > >bits in the address that don't get used in thed MAC. > > > > > >Multicast IP address: > > >1110xxxx.xmmmmmmm.mmmmmmmm.mmmmmmmm > > >x = un-used bits > > >m = bits copied to the MAC address. > > > > > >Multicast MAC address: > > >0000000100000000.0101111000mmmmmm.mmmmmmmmmmmmmmmm > > >m = bits copied from IP address > > > > > >That help? > > > > > >Karen > > > > > >*********** REPLY SEPARATOR *********** > > > > > >On 12/13/2001 at 12:00 Pm Elmer Deloso wrote: > > > > > >>Richard, > > >>This is an excellent post, but i need a little bit of clarification >on... > > >>1. I've understood multicast as at Layer 3, so I'm confused when you say > > >> that a "25-bit prefix is assigned" for the Layer 2 frame. I can't >seem > > >>to > > >> follow what is happening in multicast addressing between the Layers >2-3 > > >> to arrive at this 25-bit prefix. I can't figure out where to place > > >this > > >> prefix bit setting while looking at the 802.3 frame format on Uyless > > >>Black's > > >> book on Data Link Protocols. > > >>2. You state "there is a short fall of five bits and 2 to the 5 is 32". > > >> What is this 2^5 referring to? > > >>3. Finally, "are all allocated a MAC of 0100.5e01.0101." Please >confirm... > > >> is this the Destination MAC on the DA field of the frame? If so, what > > >> happens when you have to pass this multicast stream of data from one > > >> interface to another, e.g. from mBone -> r1 -> r2 -> multicast >enabled > > >> Intranet endstations, will the same "multicast MAC address" stay the > > >>same? > > >> > > >>Thanks for your input. > > >>Elmer Deloso > > >>-----Original message----- > > >>From: richard beddow [mailto:[EMAIL PROTECTED]] > > >>Sent: Thursday, December 13, 2001 9:18 Am > > >>To: [EMAIL PROTECTED] > > >>Subject: RE: about multicast address! [7:29057] > > >> > > >> > > >>An IP m'cast address is 32 bits long (as with any IP address), the first > > >>for > > >>bits are 0x1110 leaving 28 bits. (Still with me :)) > > >> > > >>Any m'cast ethernet borne frame has a 48 bit MAC (as do all ethernet > > >>frames). A 25 bit prefix is assigned leaving 23 bits. > > >> > > >>As 28 won't go into 23 there must be some duplication, there is a short > > >>fall > > >>of five bits and 2 to the 5 is 32. Hence and one m'cast MAC represents > > >32 > > >>IP addresses. > > >> > > >>For instance > > >> > > >>224.1.1.1 > > >>224.128.1.1 > > >>225.1.1.1 > > >>225.128.1.1 > > >>etc > > >>etc > > >>238.1.1.1 > > >>238.128.1.1 > > >>239.1.1.1 > > >>239.128.1.1 > > >> > > >>are all allocated a MAC of 0100.5e01.0101. > > >> > > >>Hope this is explained OK. > > >> > > >>RB > > >> > > >> > > >> > > >> > > >>message Posted at: > > >>http://www.groupstudy.com/form/read.php?f=7&i=29095&t=29057 > > >>-------------------------------------------------- > > >>FAQ, list archives, and subscription info: > > >>http://www.groupstudy.com/list/cisco.html > > >>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > >*********** END FORWARDED MESSAGE *********** >________________________ > >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=29222&t=29057 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
