Comments on: Tutorial: OSPF Network Types and Frame Relay Part 1

By: Dude

Dude — Sun, 19 Jul 2009 17:12:58 +0000

Explianed to the point and its clear.

Thanks

By: Muhammad Mansoor

Muhammad Mansoor — Mon, 13 Jul 2009 06:43:50 +0000

Nice Article…

By: anderson2005

anderson2005 — Fri, 03 Jul 2009 10:52:52 +0000

Thank you for your quick response. My question is…

“You can see above that the frame-relay map commands have the broadcast keywords added. If we use the OSPF broadcast network type, we have to make sure that our layer two topology supports broadcasts”

In the sentence above, how do we make sure that layer two topology supports broadcasts. Can we change anything other then broad cast keywork at the end of the frame-relay map command.

Other thing is, if the broadcast mode work in that manner across the frame-relay links then why do we acutally use the non-broadcast mode where we have to manually configure the neighbor relationships.

Am I missing something here, Do we actually have to choose one mode over the other depending upone the frame-relay network our frame-relay provider provides us.

By: Arden Packeer, CCIE #20716

Arden Packeer, CCIE #20716 — Fri, 03 Jul 2009 09:45:57 +0000

@anderson2005: Sure. Can you be more specific in what doesn’t make sense?

By: anderson2005

anderson2005 — Fri, 03 Jul 2009 09:07:46 +0000

Hi Arden,
I am bit confused by these sentence. Any chance you can clarify them pls.
” A DR is election is performed and updates are sent via multicast packets. Frame relay will need to be configured for broadcast support to support the network type.” and the other bit I didn’t understand was “You can see above that the frame-relay map commands have the broadcast keywords added. If we use the OSPF broadcast network type, we have to make sure that our layer two topology supports broadcasts”
Thanks in advance.

By: Marcel Lammerse

Marcel Lammerse — Mon, 22 Jun 2009 11:12:31 +0000

I noticed the neighbor commands are configured on the hub, but not on the spokes. I don’t know if that was intentional or not, but I found that when I configured neighbors on the spokes, as soon as I configure the ospf priority to be 0, the neighbor commands disappear from the running configuration. An ospf priority of anything but 0 makes the neighbor statements re-appear.

Other people ran into this and it seemed to have caused them some headaches :

http://ieoc.com/forums/p/6625/23367.aspx

Apparently, it is a feature, not a bug :)

Thanks for an excellent website btw. This is arguably one of the most important topics and you’ve explained it very well.

By: Anil R S

Anil R S — Thu, 05 Feb 2009 11:59:41 +0000

Hi Arden, was very helpful … and expecting some topics from Multicast using VPNV4 … if you are familiar with those technology ..

Once again thxs alot for the help you are doing .. really appreciated :)

By: Pavani

Pavani — Mon, 15 Sep 2008 17:18:36 +0000

Very useful explanation…Thank you so much.

By: rukia

rukia — Fri, 29 Aug 2008 11:52:19 +0000

Thank you, Arden! This is very helpful!

By: Arden Packeer, CCIE #20716

Arden Packeer, CCIE #20716 — Mon, 04 Aug 2008 22:48:22 +0000

You don’t need the broadcast keyword in a non-broadcast network type (hence the name!). For a hub and spoke topology, all you need is a broadcast keyword on the hub for all your spokes. The spokes just require a broadcast keyword for the hub. Check out part 5 of the article as it goes through why.