(E)IGRP ( and OSPF for that matter ) always use the multicast address for their operations. the layer 3 multicast address is independent of the way in which the layer two broadcast or multicast are handled. I'll admit that I get a bit confused on the specifics of the operations. my current understanding, pen to correction, is that with the "broadcast" parameter, frame relay replicates the packets and automatically sends them to all defined end points. without the "broadcast" parameter, other things have to happen, such as layer 3 neighbor statements, which in turn define which PVC the messages go over. I for one would enjoy reading a very clear explanation of this stuff. Maybe one of the cert zone papers covers it? David Wolsefer wrote a frame relay paper, if memory serves. I just don't remember the contents. Chuck -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tony Medeiros Sent: Monday, August 06, 2001 7:31 AM To: [EMAIL PROTECTED] Subject: Re: RE: Subject: EIGRP's interpretation of NBMA and "disabling [7:15017] Thanks Paul, That puts that one to rest. Were you forced to use the "neighbor" statements under EIGRP to get the Hellos out when you turn off broadcast?? It looks like the ip address is still multicast. Tony M. #6172 ----- Original Message ----- From: "Paul Werner" To: Sent: Sunday, August 05, 2001 9:49 PM Subject: Re: RE: Subject: EIGRP's interpretation of NBMA and "disabling [7:14996] > Well, I had a chance to do a little testing on this situation. > It seems what Cisco really meant to say was, "physical > multicasting" or "physical broadcasting". PIM specifically had > nothing at all to do with it. > > When I set up the frame cloud to test this, it was not readily > apparent my test was less than valid. It was only when I went > to the "sh frame map" command that I saw this: > > 2522#sh fram map > Serial0.1 (up): point-to-point dlci, dlci 100(0x64,0x1840), > broadcast > status defined, active > > It then immediately dawned on me what the problem was. I > proceeded to undo all of my frame configs until they all read > similar to this: > > 2511#sh fram map > Serial0.4 (up): ip 3.0.0.1 dlci 110(0x6E,0x18E0), static, > CISCO, status defined, active > Serial0.4 (up): ip 20.0.0.1 dlci 120(0x78,0x1C80), static, > CISCO, status defined, active > Serial0.4 (up): ip 22.0.0.1 dlci 130(0x82,0x2020), static, > CISCO, status defined, active > > Note that I made the conversion from auto frame to static > mappings. In the process, I conveniently left off the > keyword "broadcast" on the frame-relay static mappings. Here > is what the EIGRP hellos looked like prior to static mapping: > > 02:05:52: EIGRP: Received HELLO on Serial0.4 nbr 22.0.0.1 > 02:05:52: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 > peerQ un/rely 0/ > 1 > 02:05:52: EIGRP: Sending UPDATE on Serial0.4 nbr 22.0.0.1, > retry 3, RTO 5000 > 02:05:52: AS 1, Flags 0x1, Seq 44/0 idbQ 0/0 iidbQ un/rely > 0/0 peerQ un/rely 0 > /1 serno 11-13 > 02:05:57: EIGRP: Received HELLO on Serial0.4 nbr 22.0.0.1 > 02:05:57: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 > peerQ un/rely 0/ > 1 > 02:05:57: EIGRP: Sending UPDATE on Serial0.4 nbr 22.0.0.1, > retry 4, RTO 5000 > 02:05:57: AS 1, Flags 0x1, Seq 44/0 idbQ 0/0 iidbQ un/rely > 0/0 peerQ un/rely 0 > /1 serno 11-13 > 02:06:01: EIGRP: Received HELLO on Serial0.4 nbr 22.0.0.1 > 02:06:01: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 > peerQ un/rely 0/ > 1 > > If you note the timestamps, they are approximately every five > seconds. Here is what it looks like with the static mapping > statements and the *broadcast* keyword removed from the static > mapping statements: > > 2522# > 03:21:15: EIGRP: Sending HELLO on Serial0 > 03:21:15: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 > 03:21:45: EIGRP: Received HELLO on Serial0 nbr 22.0.0.2 > 03:21:45: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 > 03:22:07: EIGRP: Sending HELLO on Serial0 > 03:22:07: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 > 03:22:40: EIGRP: Received HELLO on Serial0 nbr 22.0.0.2 > 03:22:40: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 > > You will note that send/receive hellos are approximately one > minute apart. It would appear that instead of making matters > clearer by just stating the obvious, Cisco chose instead to > state the correct information in a somewhat convoluted and less > than clear manner:-) > > As far as turning off multicasting capability on the interface, > you definitely lose it when you lose broadcast capability since > they both share the same bit to signify a broadcast packet(bit > 8 going from left to right of the MAC address). I guess their > thinking was that since they were discussing EIGRP and EIGRP > timer adjustments, it was understood that the underlying method > of layer 2 transmission would be via multicasting. > > Final note. I did find an interesting little command that may > achieve what Chuck was trying to do. The command is as follows: > > ip multicast rate-limit in 0 > > and > > ip multicast rate-limit out 0 > > The intent of this command was to rate limit or throttle > multicast streams such as video (IPTV) or audio (Real Audio) by > ensuring that a multicast stream did not saturate a link. > Based upon quick testing I did, It did not appear to affect any > EIGRP multicast related traffic which leads me to believe it is > possibly filtering on UDP based multicast. > > v/r, > > Paul Werner > > > ________________________________________________ > Get your own "800" number > Voicemail, fax, email, and a lot more > http://www.ureach.com/reg/tag > > > ---- On Sun, 5 Aug 2001, Leigh Anne Chisholm ([EMAIL PROTECTED]) > wrote: > > > Here's the link I got the quote from: > > > > > http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/ > 122cgcr/fipr > > _c/ipcprt2/1cfeigrp.htm#xtocid2271313 > > > > Check out the third paragraph for the quote. > > > > > > -- Leigh Anne > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of > > Paul Werner > > Sent: Sunday, August 05, 2001 12:37 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Subject: EIGRP's interpretation of NBMA > and "disabling > > [7:14934] > > > > > > I read this a different way. I interpreted the author's > > discussion of "physical multicasting" to mean multicast > > routing. Multicast routing can be turned on and off > individual > > interfaces. Moreoever, when you get to the discussion on CCO > > about optimizing multicast routing, there is this section: > > > > > http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/c > > book/ciproute.htm#xtocid16743149 > > > > I agree the wording could be better. As far as disabling > > multicast from an interface, my gut reaction would be, why > > would you want to? > > > > HTH, > > > > Paul Werner > > > > > > > > > On Cisco's site, I've been searching for information as to > > when the > > > hello > > > interval is set to 5 seconds and when it is set to 60 > > seconds. Hellos > > > are > > > sent every 5 seconds except on low-speed, NBMA media. Low- > > speed is > > > defined > > > as 1.544 Mbps and under. No problems there. > > > > > > What I don't understand is this statement: > > > > > > "Note that for the purposes of EIGRP, Frame Relay and > Switched > > > Multimegabit > > > Data Service (SMDS) networks may or may not be considered to > > be NBMA. > > > These > > > networks are considered NBMA if the interface has not been > > configured to > > > use > > > physical multicasting; otherwise they are not considered > > NBMA." > > > > > > How can you configure an interface not to use multicasting? > > This is > > > something I haven't come across how to do yet. Is this > > configuring > > > EIGRP > > > multicasts to use unicasts (I think I saw something like > that > > last night > > > but > > > I was too tired to comprehend it or even remember where I > saw > > it). > > > > > > > > > -- Leigh Anne Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=15029&t=15029 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
