Au contraire. I never actually said that routing was
established or neighbor relationships were formed. Quite the
opposite was true. I only commented on the protocol behavior as
it involved EIGRP timers (5 seconds versus one minute). I had a
classic hub and spoke. My hub was a 2511 (just because:-) and
the spokes were respectively a 2503, 2520 and a 2522. The
cloud was provided very nicely by a 2523.
Here are some of the things seen on a spoke:
c2503#sh fram pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE
= Serial0
input pkts 685 output pkts 46 in bytes
26408
out bytes 3144 dropped pkts 0 in FECN
pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN
pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
pvc create time 04:46:48, last time pvc status changed
04:46:48
and,
c2503#sh fram map
Serial0 (up): ip 10.0.0.11 dlci 100(0x64,0x1840), static,
CISCO, status defined, active
and,
c2503#sh ip eigrp nei
IP-EIGRP neighbors for process 1
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=15066&t=15066
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
