From: TCP IP4 (tcp.ip4@gmail.com)
Date: Tue Dec 09 2008 - 18:29:19 ARST
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
This archive was generated by hypermail 2.1.4 : Thu Jan 01 2009 - 12:53:08 ARST