OSPF network statement clarification needed

[gjmoran1984]

I came across an interesting question during my studying in my exam simulator regarding the choices OSPF makes when selecting which network statement/area to put an interface in. Everything I am reading online is that the more specific the network statement will match the interface before a less specific network statement.

However the answer to the question stated that whichever network command was configured first will match the interface. So it kind of confused me a bit. 

Just for example - Interface has an IP address of

10.10.10.1/24

OSPF has 3 potential network statements that *could* match it:

network 10.10.10.0 0.0.0.255 area 5

network 10.10.0.0 0.0.255.255 area 6

network 0.0.0.0 0.0.0.0 area 10

I picked the first one and got the question right but again the 'first configured network statement will match' is throwing me off.

[Richard Burts]

I find this post a bit puzzling. First you say " the more specific the network statement will match the interface before a less specific network statement" I believe this is correct.

Then you say " whichever network command was configured first will match the interface". I am not sure where this comes from, and frankly not sure what it means. But I am clear that the longest match wins in real life.

[gjmoran1984]

Yes that's why I'm confused as well. The statement 'whichever network command was configured first will match the interface' was directly from the CCNA exam simulator. I couldn't find anything referencing that statement online or in the CCNA books though.

[balaji.bandi]

yes correct and agreed - Longest the better"

network 10.10.10.0 0.0.0.255 area 5

if you looking to

use /24

in to specific area 5 this should work.

if all the interface in area 10  then should work

network 0.0.0.0 0.0.0.0 area 10

you can refer OSPF deployment guide :

https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/7039-1.html

[MHM Cisco World]

I send you message check it

[Joseph W. Doherty · Accepted solution]

Definitely, many years ago, the sequence of OSPF process network statements worked like an ACL ACEs, i.e., first match was used.

Years later, I recall (???) seeing a Cisco L3 device reorder OSPF network statements, in the config, such that more specific matches were listed first.

Possibly, there's been a change at some point.  If so, might account for conflicting how it works documentation.

Current behavior would be easy enough to lab up.  Possibly, later today I'll try it on PT and possibly CML.

If there was a change in behavior, it's rather significant, but a behavior difference most would not bump into.

[Joseph W. Doherty]

BTW, in your example, the most specific match is also the first network statement.

Invert the order, and then what happens?

Logically, if you invert the order and first statement matches, the following statements wouldn't ever match.  Likely implying an error in the config.

Possibly, if IOS now reorders, it insures there are no unmatchable network statements, but first match is true too.

[David Ruess]

As most have mentioned here yes the mosre specific match will win and as @Joseph W. Doherty pointed out (at least in IOS) it will reorder the statements to reflect as such. See lab below:

-David

[Joseph W. Doherty]

Ah, didn't see David's posting, until now.  (Likely I was still composing mine, when he posted it.)

Laugh - had I seen it earlier, I might not have bothered also doing my lab, but then, I did find PT and CML worked differently.  Possibly, such is true between real platform IOS versions (very old vs. newer/current).

It also confirms what I recall, i.e. IOS might reorder OSPF network statements.

Interestingly, David's also shows the log message I reported.  I hadn't explicitly mentioned in my posting, that message seems to be triggered when you show the config (see my posting).  Which makes me wonder what happens if you apply the OSPF statements, don't show the config, but show what area the interface is in.  (I would expect, and hope, show config isn't required to actually cause the reordering of the OSPF network statements.)

[edit Addendum]

In CML, just exiting the config updating, appears to trigger the reordering (as expected/hoped).

inserthostname-here(config-router)#end
inserthostname-here#
*Aug 15 16:26:06.900: %OSPF-6-AREACHG: 10.10.0.0/16 changed from area 10 to area 6
*Aug 15 16:26:06.946: %OSPF-6-AREACHG: 10.10.10.0/24 changed from area 6 to area 5
*Aug 15 16:26:06.952: %SYS-5-CONFIG_I: Configured from console by console
*Aug 15 16:26:07.734: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
inserthostname-here#

[Joseph W. Doherty]

conf t
int lo0
 ip address 10.10.10.1 255.255.255.0
router ospf 10
 network 0.0.0.0 0.0.0.0 area 10
 network 10.10.0.0 0.0.255.255 area 6
 network 10.10.10.0 0.0.0.255 area 5
end

Just tried entering the above in PT and CML:

PT shows in config:

router ospf 10
 log-adjacency-changes
 network 0.0.0.0 0.0.0.0 area 10
 network 10.10.0.0 0.0.255.255 area 6
 network 10.10.10.0 0.0.0.255 area 5

PT retains network statements entry sequence and:

Router#sh ip os int b
Interface     PID   Area                     IP Address/Mask          Cost  State  Nbrs F/C
Lo0            10   0.0.0.0                 10.10.10.1/255.255.255.0   1     WAIT  0/0
Lo0            10   0.0.0.0                 10.10.10.1/255.255.255.0   1     WAIT  0/0

CML shows in config:

router ospf 10
 network 10.10.10.0 0.0.0.255 area 5
 network 10.10.0.0 0.0.255.255 area 6
 network 0.0.0.0 255.255.255.255 area 10

CML changed network statements entry sequence and:

inserthostname-here#sh ip os in b
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          10    5               10.10.10.1/24      1     LOOP  0/0

Also, CML logged:

Building configuration...

*Aug 15 15:11:20.940: %OSPF-6-AREACHG: 10.10.0.0/16 changed from area 10 to area 6
*Aug 15 15:11:20.985: %OSPF-6-AREACHG: 10.10.10.0/24 changed from area 6 to area 5
Current configuration : 3134 bytes

So, both PT and CML match on first matching OSPF network statement, but CML reordered the network statements, which PT did not.  Again, decades ago, I recall Cisco routers working like PT.  I also recall, somewhere along the line of IOS version updates, the Cisco L3 device (don't recall if L3 switch or router) reordered my OSPF network statements, as CML did.  I don't recall console message, but I wasn't making changes via the console and I didn't think to check syslog.

Assuming PT and CML both represent what I recall, they have different behavior to the same OSPF statements that are entered.

To recap, it appears both behaviors will match an interface IP on first matching OSPF network statement, but in later/current IOS versions, IOS will reorder OSPF network statements, so that most specific matching statements will be first.

BTW, I recall (?) when I noticed the Cisco L3 device reordering my OSPF network  statements, there weren't different results, just that all network statements were in prefix length match sequence.  Wonder if that will happen in CML . . .

conf t
no router ospf 10
router ospf 10
network 10.10.0.0 0.0.255.255 area 6
network 192.168.1.0 0.0.0.255 area 6
end

Which results in:

router ospf 10
 network 10.10.0.0 0.0.255.255 area 6
 network 192.168.1.0 0.0.0.255 area 6

So, it looks like, at least in CML, it's only when the prefixes actually overlap.  Either my recollection is faulty, very possible, or the latest IOSs are "smarter" about when they actually do reorder network statements.  In this last case, as there's no prefix overlap, logically you obtain the same results regardless of how the network statements are ordered.

[gjmoran1984]

Thanks all, this information was very helpful.