From: Huan Pham (pnhuan@yahoo.com)
Date: Tue Dec 09 2008 - 16:10:52 ARST
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
This archive was generated by hypermail 2.1.4 : Thu Jan 01 2009 - 12:53:08 ARST