From: Narbik Kocharians (narbikk@gmail.com)
Date: Tue Dec 09 2008 - 19:52:57 ARST
Huan,
*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.*
**
So you put broadcast even if the network type is non-broadcast? and your
attitude is "well it will NOT hurt?" I have to disagree with that. As a CCIE
or even an experienced Eng. you should NOT use what is NOT needed, that is
my attitude. I believe that the ONLY reason i configure a command or even a
keyword, i think about it and i realised that i need that keyword and
therefore, i configure it. I never say to myself, well this won't
hurt. Yours might be different.
*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!*
**
Then why use it????????????????????
*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?*
If its not needed, the best habit is not to configure the extra commands or
keywords, now if you did not need the keyword in there, and the same client
that is paying you top dollar asks you about that keyword, what will you
answer? Will you tell the client, "Hey the router in this configuration does
not need the keyword, but you NEVER KNOW. That will NOT go down well. Its
like taking pills every morning just in case you get constipated.
*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!*
This is very different to our original discussion, in this case you need it
and you must have it.
*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.*
Note when you used MAY BE needed by routing protocol, and other multicast
applications, the later may be added anytime in the future
i agree with you.
On Tue, Dec 9, 2008 at 10:00 AM, Huan Pham <pnhuan@yahoo.com> wrote:
> 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.
> > >>
>
>
-- Narbik Kocharians CCSI#30832, CCIE# 12410 (R&S, SP, Security) www.MicronicsTraining.com www.Net-Workbooks.com Sr. Technical InstructorBlogs 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