OSPF Clarification Differences

[fatalXerror]

Hi Guys,

Please enlighten me what is the difference about the following about the OSPF.

1. "Network" command in OSPF process versus "IP OSPF" command in the interface level?

2. Which are the best practice?

Thank you

[Joseph W. Doherty]

The biggest difference is the network statements works like an ACL matching interface IPv4 IPs.

As for which is best practice maybe/possibly the interface variant as to be consistent between IPv4 and IPv6.

The interface variant is a johnny-come-lately.  First seen with OSPFv3.  I don't recall (?) the network system supporting IPv6.

[Harold Ritter]

Hi @Joseph W. Doherty ,

>  I don't recall (?) the network system supporting IPv6.

You are correct Joseph.  For IPv6, you need to go with the interface level statement to activate ospfv3 on the interface.

Regards,

[Torbjørn]

As @Joseph W. Doherty mentioned they are equal in most ways. The only practical difference that I can think of is that they behave slightly differently when it comes to secondary IPs. In interface configuration you are only able to advertise all or none of the secondary addresses, while with network commands you can match specific secondary addresses.

I don't believe there is any globally recognized best practice for this, but the interface commands seem to be most popular in most modern networks that I touch these days.

[vishalbhandari]

@fatalXerror  

• "Network" Command: Best for broad, initial OSPF configuration on multiple interfaces. Simple and scalable.
• "IP OSPF" Command: Best for detailed, per-interface OSPF configurations. Allows for fine-tuning and granular control.

Choosing between these commands depends on the specific needs of your network configuration and the level of control you require over OSPF behavior on individual interfaces. Using both methods appropriately can help maintain an efficient and well-functioning OSPF deployment.

[Joseph W. Doherty]

As the network statement can target individual IPs, unclear how the interface variant has an advantage of "granular" control.

I will say, the interface variant has the advantages of "seeing" the OSPF assignment with the interface.  I.e. you don't need to correlate an interface IP with a network statement.

[MHM Cisco World]

If you have many small subnet using ip opsf command under interface more simple and easy to use 

If you have unnumbered interface  use ip ospf is the only solution (this common in tunnel interface)

Other cases use network command under ospf 

That it

MHM

[Joseph W. Doherty]

"If you have many small subnet using ip opsf command under interface more simple and easy to use"

Personally I've found using an aggregate network to match multiple interfaces simpler.  E.g. network 0.0.0.0 255.255.255.255 area #.

[MHM Cisco World]

That not correct'

If we use network 0.0.0.0 then all interface in router will try established ospf and send multicast hello even if the neighbor is not run ospf. 

And if we have small subnet and use network command as much as we try tune the network command and wildcard we still permit some sunbet we dont need. So instead we can use ip opsf under interface

MHM

[Harold Ritter]

Hi @MHM Cisco World ,

> And if we have small subnet and use network command as much as we try tune > the network command and wildcard we still permit some sunbet we dont need.

I am not sure what you mean by that. You can be as specific as you want with the network command.

For instance,  "network 192.168.1.1 0.0.0.0 area 0", which would only include the interface that has this specific address configured. Nothing else.

Regards,

[MHM Cisco World]

And if I have 100 IP like this' I add one by one or I use 

Ip ospf x area x 

Copy it and add it under any interface I want.

Simple and easy

MHM

[Harold Ritter]

@MHM Cisco World ,

> And if I have 100 IP like this' I add one by one or I use 

I was just pointing out that the network statement could be as granular as the "ip ospf" statement.

The choice of using one or the other might also be related to other things like, for instance if you are configuring ospfv2 and ospfv3, it might be simpler for the operation team if you use the "ip ospf <area #> and "ipv6 ospf <area #>" to include the interface under ospfv2 and ospfv3 in place of using the network for ipv4 and "ipv6 ospf <area>" under the interface for ipv6.

One way of doing things is simpler than two.

Regards, 

[Joseph W. Doherty]

---

@Harold Ritter wrote:

The choice of using one or the other might also be related to other things like, for instance if you are configuring ospfv2 and ospfv3, it might be simpler for the operation team if you use the "ip ospf <area #> and "ipv6 ospf <area #>" to include the interface under ospfv2 and ospfv3 in place of using the network for ipv4 and "ipv6 ospf <area>" under the interface for ipv6.

One way of doing things is simpler than two.

---

Yup, my thinking too.  If you're running both OSPFv2 and OSPFv3, consistency can be good.  Possibly a prime reason Cisco retrofitted this feature to OSPFv2 (as I recall, initially this feature only worked with OSPFv3).

[Joseph W. Doherty]

---

@MHM Cisco World wrote:

And if I have 100 IP like this' I add one by one or I use 

Ip ospf x area x 

Copy it and add it under any interface I want.

Simple and easy

---

If adding 100 statements to your config is your preference, enjoy.

Personally, if I can use just one or a few network statements, in lieu of 100, that's my preference.

[Joseph W. Doherty]

"That not correct'"

Regarding which approach is simpler, i.e. network statement vs. interface statement?  If so . . .

Well, beauty is in the eye of the beholder, which is why I prefaced my statement with personally.  If you think otherwise, I'm sure that's true for you.

"If we use network 0.0.0.0 then all interface in router will try established ospf and send multicast hello even if the neighbor is not run ospf."

Firstly, I didn't recommend using an all encompassing network statement, just mentioned it could be used.  It's the extreme case of aggregation.

"then all interface in router will try established ospf and send multicast hello"

Not necessarily on both points.  Firstly, I determine whether interfaces are active or passive in OSPF (both by default and specific interface settings).  If passive, they do not try to establish an OSPF neighbor and will not send hellos, but good chance I want all IP interfaces known to OSPF, so surprisingly often, the extreme case of matching all IPs is useful anyway.

"And if we have small subnet and use network command as much as we try tune the network command and wildcard we still permit some sunbet we dont need. So instead we can use ip opsf under interface"

@Harold Ritter (correctly) addressed that point in his reply to yours.

BTW, again, remember selecting OSPF interface inclusion was a later feature.  The network statement was the only way to do this for decades.  Somehow, we used to manage to configure OSPF as we wanted.

BTW, often inexperienced network engineers misunderstand OSPF network statements and believe you need to match the network.  If so, that's incorrect.  You match the IP of the interface, again, much as you would with an ACL.