From: TCP IP4 (tcp.ip4@gmail.com)
Date: Tue Dec 09 2008 - 19:45:12 ARST
Thanks for clarification. So in multicast SM case both hub and
spoke all need pseudo broadcast keyword?
On Tue, Dec 9, 2008 at 12:49 PM, Huan Pham <pnhuan@yahoo.com> wrote:
>
> Hi TCP,
>
> If you do not have that broadcast keyword on, Multicast will not work.
>
> In your case, "broadcast" keyword is not 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