campus network -ospf

[bluesea2010]

Hi,

Hi,

Access layer  is layer 3 , Do I  need to make to core and access layer  ospf links should be point to point or Broadcast ?

What are the pros and cons 

Thanks

[Richard Burts]

It is not clear but the diagram suggests that these connections are Ethernet. Is that the case? The default would be broadcast. I see very little benefit from the effort needed to make them point to point. On each link there would be a single neighbor, so no DROTHER neighbors. The neighbors would negotiate full adjacency. So what would be the benefit of point to point?

[paul driver]

Hello
If all 4 cores share the same subnet, then it would be recommended to use broadcast network type, in fact opsf by default selects it on ethernet links.

If ths ospf the connection between the two devices will ONLY be that single connection (Direct) then I would say its beneficial to use P2P, cut down on convergence and has no DR/BDR election to contend with.

[bluesea2010]

Hi,

If all 4 cores share the same subnet, then it would be recommended to use broadcast network type, in fact opsf by default selects it on ethernet links.

No its not the same subnet , every link  is  has /30 subnet 

Thanks

[paul driver]

Hello
Then I would use point-to-point and be as specific as possible, by enabling ospf directly on the interface or specifying the host address under the ospf process., the former being the most preferred option.

int x/x ( preffered option)
ip address 1.1.1.1 255.255.255.252
ip ospf x area x
ip ospf network type point-to-point

or
router ospf x
network 1.1.1.1 0.0.0.0 area x

int x/x 
ip ospf network type point-to-point

[MHM Cisco World]

/30 why then you use broadcast ? P2P is ok for your case. 

[bluesea2010]

Hi,

My question  is in the above topology, changing /30+braodcast  network type  to p2p will provide any benefit

Thanks

[MHM Cisco World]

NO need you connect only two Peer for each broadcast domain (each /30 is broadcast domain), and this no need network type broadcast at all. 

[Joseph W. Doherty]

As you later post these are truly p2p links, and you're using /30s, I too would suggest using OSPF p2p.

One principle reason, as most noted by @paul driver, OSPF generally will establish OSPF adjacency faster (and, I would assume, a tad less resource usage on the control plane).

Other advantages of using OSPF p2p, if your Cisco devices aren't ancient, you could also use /31s for your p2p connections.

Assuming yours is a modern network, where you might carry real-time traffic like VoIP, you might also consider reducing the hello timer to 1 second (unless you want to get into sub second timers).

I was also going to suggest perhaps enabling iSPF and/or "tuning" OSPF timers for faster convergence, but just came across this (interesting) TechNote that Cisco has changed default OSPF timers to reduce convergence time.  Further, they've deprecated iSPF.  Lastly, the Deployment section cautions about a mixed OSPF timer environment, which might easily be created by updating the IOS version on just some platforms (using new default timers).  See Change of Default OSPF and IS-IS SPF and Flooding Timers and iSPF Removal.

[bluesea2010]

Hi,

Assuming yours is a modern network, where you might carry real-time traffic like VoIP, you might also consider reducing the hello timer to 1 second (unless you want to get into sub second timers).

Is it good changing the hello timer and timer even if it is modern network

Thanks

[Joseph W. Doherty]

"Is it good changing the hello timer and timer even if it is modern network"

Possibly even more so.

OSPF's timers for p2p and broadcast, I recall, are 10/40. Blackholing traffic for 40 seconds, in modern networks, is a long, long time.  Actually even 4 seconds is a long, long time for real-time traffic, like VoIP and/or video conferencing.

If your p2p links are direct connections between two L3 devices, ideally, link will drop if some problem on link's far side L3 device.  I.e., OSPF hello timeout shouldn't be needed at all.  (BTW, a hardware link drop, I understand, is detected under 100 ms - so fast, you may need to adjust OSPF's LSA and SFP timers, when supporting real-time traffic.  [Or, hopefully, your OSPF design has ECMP, where you need not wait for SPF to recalculate to forward traffic on an alternative path.])

Real world, unexpected/unusual "bad stuff" happens.  So, OSPF timers are a bit of a hardware failure detection back-up.  For such, is 40 seconds okay?  Is 4 seconds okay?  It's your design choice.

Personally, I believe 4 seconds better than 40 (without imposing too much additional overhead).  If I'm relying on OSPF failure detection (as primary), on modern networks, I'll often configure subsecond hellos.  (With such, even with BFD, getting under a second's failure detection can be somewhat difficult.  [Of course, a second is also better than 4 seconds.])