more comments within and below ( nice phrasing, by the way ) -----Original Message----- From: Paul Werner [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 05, 2001 10:26 AM To: Chuck Larrieu; Cisco Mail List Subject: Re: RE: Subject: EIGRP's interpretation of NBMA and "disabling [7:14934] Chuck et al, Comments within and below. ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag ---- On Sun, 5 Aug 2001, Chuck Larrieu ([EMAIL PROTECTED]) wrote: > hey, Paul, what's going on? Not much, just waiting for the economy to pick up :-) CL: me too. the bonus situation is non existent :- now I'm more confused than ever. how does PIM relate to EIGRP behavior > on > NMBA networks? I would state that slightly differently, such as this: How does EIGRP behavior on NMBA networks relate to PIM? CL: if at all. I would wager that most of us have never configured PIM in a production environment, no matter what routing protocol we choose. > I interpreted the original question and CCO quote as discussing how > EIGRP > sets its hello timers based on the physical/data link layer of SMDS or > frame > relay, which can be configured (in cooperation with the telco) as a > multicast net or a series of point to point links. I confess I do not have the original link you mentioned, so I was looking at the generalized discussion of EIGRP timers which is here: http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/c book/ciproute.htm#xtocid1674334 If the discussion in those paragraphs is what you are referencing, my belief about EIGRP timer automatic adjustments based upon physical media is not from an interaction of that media to the protocol, rather a recognition by the protocol on how the media functions. If you have an NBMA media (recognized by the encapsulation command) and a low speed interface (recognized by the bandwidth command), EIGRP will make an automatic adjustment of its timers from 5 seconds to 1 minute. It goes on to further state that high speed NBMA networks (frame or SMDS) will get he "LAN equivalent" timer of 5 seconds. The only possible exception to this is a low speed NBMA networks (Frame and SMDS are mentioned). In that particular instance, somebody may have turned on a feature or functionality to cause that interface to behave differently than it normally does, thus causing an exception to the rule. CL: again, my read of the paragraph "Note that for the purposes of Enhanced IGRP, Frame Relay and 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 considered not to be NBMA." and the specific reference to "physical multicasting" led me to look into the nature of SMDS, where I came up with the reference to configuration of SMDS addresses as group "You can map an SMDS group address to a broadcast or multicast address used by a higher-level protocol" CL: dratted CCO configuration guides tell you to see the configuration examples, but a look through several IOS version config guides back to 11.3 all fail to provide any such examples, and again, not having worked on any of this stuff, I am left unclear on the concept. CL: on the other hand, while it is true that in terms of conceptualization, a layer three protocol is not aware of nor dependent upon layer two or layer one configurations, the fact is that the internal workings of the IOS are not strictly segregated by layer. my reading of both frame and SMDS indicate that there exist the means to change certain behaviours that most of us take for granted because truth be told we just never see them in the real world. an extreme case in point is the globally significant frame relay dlci, which makes it possible to create in effect an ethernet on a frame cloud. http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1/tr1918.htm#xtocid126 685 "Each router interface has a distinct value as its node identifier, so individual devices can be distinguished. This permits adaptive routing in complex environments. Global addressing provides significant benefits in a large, complex internetwork. The Frame Relay network now appears to the routers on its periphery like any LAN. No changes to higher-layer protocols are needed to take full advantage of their capabilities." CL: that's what I thought was being discussed. of course, I've been known to wander off on tangents unrelated to the true point. :-> That is when I went to the section on PIM. It made a reference to a "PIM nbma-mode". The intro paragraph would seem to indicate that the default behavior of the interface is being changed to conform with the exception noted in my paragraph above: "PIM nonbroadcast, multiaccess mode allows the router to replicate packets for each neighbor on the NBMA network. Traditionally, Cisco routers replicate multicast and broadcast packets to all "broadcast" configured neighbors. This might be inefficient when not all neighbors want packets for certain multicast groups. NBMA mode allows you to reduce bandwidth on links leading into the NBMA network, as well as CPU cycles in switches and attached neighbors." CL: yep. I agree. I've briefly reviewed my PIM notes from ECP1 and I recall some discussion along this line. but PIM - protocol independent multicasting - isn't it by it's very nature unrelated to routing protocol behaviour? While I am not saying that this is what the author's were really trying to communicate between the two references, it seems plausible. CL: agreed > my admittedly brief reading indicates that given the right > configurations on > the telco side, both SMDS and frame can become layer two multicast > networks, > behaving in a similar manner to ethernet, in that packets are > automatically > replicated to all end points. While this is rare in the frame relay > world, > because it involves enlisting the option that permits globally unique > DLCIs, > it is not uncommon in the SMDS world. Okay, since I will hardly admit to knowing much about SMDS, the logical question that has to be drawn from your discussion above is how will the router be able to tell the difference between these two different types of WANs? Something has to be present in a standardized manner that the IOS can readily recognize as a trigger to indicate that non-standard protocol behavior is in force. Which field would indicate this and on which header? CL: to repeat a previous point, I would say that the IOS, being the overlord, would recognize the interface configuration and would then pass a parameter into EIGRP. being Cisco proprietary, EIGRP does not have to conform to any of those pesky interoperability standards, and so the IOS can be optimized to do things that are not permitted with the open standards. no headers involved. no packet formats to consider. the secret inner working of the EIGRP/IOS relationship make it possible to do things that other protocols can not. admittedly a bit paranoid on my part. > EIGRP apparently understands these kinds of layer two configuration > options, > and adjusts its timers accordingly. My only understanding of EIGRP's knowledge of layers 1 and 2 are driven by the obvious choices, namely the encapsulation that is set, and the bandwidth statement involved. There is another way to approach this issue, which is my preferred method of resolving inconsistencies in the Cisco documentation. If time is available, I can set all of this up in my lab and see exactly what happens. It may not happen today since there is a significant backlog of honey-do's that are in the queue:-) Still, it would be interesting to test. CL: me too. sketch out a methodology, and I'll turn on the routers and see what happens. although it could probably spend all day just trying to get an SMDS multicast cloud to work. :-> That's my take on it all. I could be wrong, but it seems plausible. HTH, Paul Werner > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Paul Werner > Sent: Saturday, August 04, 2001 11:37 PM > 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 > > ________________________________________________ > Get your own "800" number > Voicemail, fax, email, and a lot more > http://www.ureach.com/reg/tag [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=14962&t=14962 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
