From: Huan Pham (pnhuan@yahoo.com)
Date: Tue Dec 09 2008 - 18:50:24 ARST
Hi TCP,
If you do not have that broadcast keyword on, Multicast will not work.
In your case, "broadcast" keyword is not _JUST_ recommended. It is a _requirement_.
Cheers,
--- On Wed, 12/10/08, TCP IP4 <tcp.ip4@gmail.com> wrote:
> From: TCP IP4 <tcp.ip4@gmail.com>
> Subject: Re: Broadcast keyword in FR Hub & Spok
> To: ccielab@groupstudy.com
> Date: Wednesday, December 10, 2008, 7:29 AM
> Hi Huan,
>
> In the multicast case with nbma mode on on the hub would
> you still recommend
> to leave broadcast keyword on? Would that go against the
> original purpose
> of having "ip pim nbma-mode"?
>
> Thanks,
> Tom
>
> On Tue, Dec 9, 2008 at 10:10 AM, Huan Pham
> <pnhuan@yahoo.com> wrote:
>
> > My typo:
> >
> > If your OSPF network is non-broadcast type, then your
> routing protocol will
> > send hello and/or updates via unicast, and will simply
> not send updates via
> > MULTICAST.
> >
> >
> >
> > --- On Wed, 12/10/08, Huan Pham
> <pnhuan@yahoo.com> wrote:
> >
> > > From: Huan Pham <pnhuan@yahoo.com>
> > > Subject: Re: Broadcast keyword in FR Hub &
> Spoke
> > > To: "Pavel Bykov"
> <slidersv@gmail.com>, "Narbik Kocharians"
> <
> > narbikk@gmail.com>
> > > Cc: "John Edom"
> <jedom123@gmail.com>, ccielab@groupstudy.com
> > > Date: Wednesday, December 10, 2008, 5:00 AM
> > > Hi Narbik,
> > >
> > > I have to disagree with you on this. My approach
> is to
> > > always put broadcast keyword, unless the FR tasks
> > > SPECIFICALLY ask not to use broadcast. Of course,
> never put
> > > broadcast keyword for spoke-to-spoke mapping.
> > >
> > > > what if OSPF is to be configured in a
> non-broadcast
> > > > network type? Now.. you have to remember to
> go back
> > > > and take that keyword off.
> > >
> > > Why you have to take the keyword broadcast off,
> unless the
> > > FR task ask NOT to use broadcast if not needed?
> > >
> > > If your OSPF network is non-broadcast type, then
> your
> > > routing protocol will send hello and update via
> unicast, and
> > > will simply not send updates via broadcast. It
> will operate
> > > the same way as if you configure the map without
> the keyword
> > > broadcast. Having that broadcast keyword does
> not force the
> > > router to generate rudundant broadcast! Nothing
> different!
> > >
> > > Adding "broadcast" keyword in this case
> is not
> > > required but will not make your network operation
> and your
> > > configuration sub-optimal.
> > >
> > > Let's consider this example:
> > >
> > > Client upgrades their WAN network that is
> currently running
> > > on IPSec tunnels over the Internet to
> Frame-Relay, using
> > > OSPF physical interface (none-broadcast). Client
> has no idea
> > > what protocols their applications and underlying
> network
> > > protocols use. They just know that their
> applications
> > > working fine, but need to increase their security
> by going
> > > to FR.
> > >
> > > Wouldn't you use broadcast keyword, as a good
> habit?
> > >
> > > As a consultant, would you draft a configuration
> without
> > > the broadcast keyword, and ask the implementation
> engineer
> > > to "trouble-shoot for 2 hours before calling
> me"
> > > if the configuration does not work?
> > >
> > > When you were called you start doing
> trouble-shooting,
> > > debuging and decide to add that little keyword,
> and here you
> > > go all their multicast applications (which use
> broadcast
> > > keyword) start working again!
> > >
> > > Which one would you think as a best practice?
> > >
> > >
> > > > >> I do not recommend adding extra
> commands if
> > > they
> > > > are not needed, that can
> > > > >> become a real bad habbit.
> > >
> > > This is really true, but depending on what you
> mean by
> > > "not needed".
> > > Broadcast keyword for spoke to spoke mapping (via
> PVC to
> > > hub) is DEFINATELY not needed.
> > >
> > > Broadcast keyword for Spoke to Hub and vice virsa
> may be
> > > needed by routing protocol, and other multicast
> > > applications, the later may be added anytime in
> the future.
> > >
> > >
> > >
> > >
> > > > > On Tue, Dec 9, 2008 at 7:49 AM, Narbik
> Kocharians
> > > > <narbikk@gmail.com>wrote:
> > > > >
> > > > >> I personally recommend NOT to use
> the
> > > > "Broadcast" keyword at all when
> > > > >> configuring the frame-relay
> section, unless
> > > the
> > > > task in the
> > > > >> *frame-relay*section specifically
> asks for
> > > that
> > > > keyword.
> > > > >>
> > > > >> Since I do not recommend flipping
> between
> > > > sections, there is no way to
> > > > >> know
> > > > >> what will be asked from you in the
> future
> > > tasks,
> > > > as you mentioned, what if
> > > > >> OSPF is to be configured in a
> non-broadcast
> > > > network type? Now.. you have
> > > > >> to
> > > > >> remember to go back and take that
> keyword
> > > off.
> > > > >>
> > > > >> I do not recommend adding extra
> commands if
> > > they
> > > > are not needed, that can
> > > > >> become a real bad habbit.
> > >
> > >
> > > Blogs and organic groups at http://www.ccie.net
> > >
> > >
> _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> >
> _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Thu Jan 01 2009 - 12:53:08 ARST