so, do I just need to set the interface to point to point ?

HI

U need to specify under the interface the ospf network-type as point-to-point.

As Harold said it will avoid DR/BDR election.

Thanks

Mahmood

I agree that avoiding DR/BDR election will save some time, but I'm wondering whether you can provide any references to how much more rapid this can be? Reason I ask, I investigated this, although only briefly, when I read your post, but unable to find anything, at least on the Cisco site, beyond a debug log which showed an OSPF election but it was very fast (subsecond, I recall). Further, whatever the time savings might be, I wonder whether there might be some break even point when dealing with multiple neighbors where you have the choice of making each a p2p or neighbors on a broadcast multi-access segment. For the multiple neighbors, much might depend on whether all routers come on-line at the same time on whether just one is coming on-line. I also wonder, again in the case of multiple neighbors that could be p2p or DR/BDR/other, how the savings in actual election time contrasts with all the other things that OSPF needs to do for a router to understand the topology, such as LSA exchange between neighbors, impact to SPF analysis, etc.

In other words, p2p probably would be the best method to peer to an OSFP neighbor if they really are p2p regardless of media, but if you have a topology that's effectively a mesh, then is defining p2p or DR/BDR better, and where's the optimal point in choosing one or the other?

Joseph,

I might have overstated the time it takes for the adjacency to come up on a broadcast network. It shouldn't take that much more time than on a p2p indeed. There is definitely other benefits though, such as topology simplification and LSA reduction (remove the need for an LSA type 2 for each and every one of these broadcast networks).

Regards

Yes to implement pointo-to-point do the following

interface #interface you want to est point to point connection

ip ospf network point-to-point

In the event of NBMA network (No election of DR/BDR). You can specify the IP OSPF priority command the a higher value at the Hub router to ensure the Hub becomes the Dr in the network.

Harold, thank you for your response. I write again because your bring up two new issues. My understanding might be different, and if incorrect, I would appreciate correction.

You mention the benefit of "topology simplification, when using p2p vs. multi-access. Let's assume a core router with downlinks to 4 distribution routers. If we configure p2p between the distribtion routers and the core, the area database will need to track 4 links rather than 1 shared multiaccess link between the core and distribution. Further, from the view point of one distritution to another, it would see two hops rather than just one. It seems to me that shared links, would decrease the size and depth (for some routers) of the topology. (NB: Actually, if we use shared multiaccess in this example, traffic wouldn't even pass through the "core" router - logically.)

With regard to LSA reduction, there would be type 1 LSAs for the 4 downlinks if p2p, but only one type 2 LSA if a shared link?

Let's take another example where we have 5 routers and desire to connect them as a full mesh routed (all with p2p to each other), or on a shared multiaccess (such as provided by a L2 switch - i.e. switched core). With the former we have 10 links (N[N-1]/2) vs. just one. I would think the latter topology would be smaller within the OSPF area database. (BTW: I realize in this last example, current best practice would have core router, but I'm strictly addressing p2p vs. shared multiaccess impact to OSPF topology.)

In the real world, I worked with a customer that was designing a new large campus using OSPF using about 60 routers (actually large chassis L3 switches) per one OSPF area. They too wanted to use p2p everywhere, I advised against, but they chose to keep p2p. (I also mentioned 60 routers within an area was a concern.) After the campus OSPF meltdown a couple of years later, changing some p2p to shared multiaccess (along with some passive interfaces on the routed edge), has precluded any further OSPF meltdowns. These changes decreased the size of the OSPF topology, although additional area segmentation would likely have worked too.

Very interesting discussing. Some time ago, i was also puzzled with this issue.

Joseph, i think you misread the suggestions from Harold a bit. He is NOT talking about replacing 4 point-to-point downlinks with 4 shared downlinks. This is actually a discussion about using a L3 or a L2 network.

The main discussion should be: if we have a network with 4 point-to-point ROUTED downlinks, by default, when you configure OSPF on these links, OSPF used the broadcast model. So you will have 4 network LSAs and 1 router LSA (for the switch). If we convert these links to OSPF point-to-point links (using "ip ospf network type point-to-point"), we eliminate 4 times the DR/BDR election on each of these links. Also, the links will now be included in the router LSA (there is only one router LSA. This LSA holds ALL p-t-p links) and we won't have any network LSA anymore. This does not change the number of hops going from distri to disti.

PS. The MAIN disadvantage of using one shared subnet that holds all routers, as you explain above, is that convergence is TIMER-based. The DR needs to wait until the OSPF hello packets to a member router time out (dead-interval) BEFORE he can send a type 2 network LSA update. This can be tuned to 1 second at best. Using multiple p-t-p routed interfaces, convergence is based on layer1 interface down detection (< 200 ms, on fiber < 20 ms). Once the interface goes down, the router can immediatly declare the neighbor down and submit a network or router LSA update.

Geert, I hope Harold wasn't thinking about replacing 4 routed p2p links with 4 shared links; at least I wasn't. However, the original post didn't make clear this aspect of the topology, so what I have in mind may be unclear.

Since the original post did mention LAN and L3 switches, what I have in mind is something like five 6500s connected with Ethernet. Assuming one is a core, and four are distribution, and you have 1 link between each distribution and the core, you could configure them (routed) p2p or you could host a VLAN on the core L3 switch and have the five routers all in the same multiaccess VLAN, i.e. a shared segment. The question I'm wondering about then is whether to have (routed) p2p or whether to have a common (routed) multiaccess segment that the five routers become neighbors on. (BTW: if you do have p2p Ethernet, I fully agree with overriding the default DR/BDR for Ethernet.)

You raise a good point about timers in your postscript, but that's almost a subject in itself since there are different media defaults, timers can be adjusted, Cisco's support of subsecond OSPF hellos, Cisco's support of OSPF and BFD, and whether another (L2) switch is between the L3 switches (i.e. both ends might not see link down), etc.

What I did want to contrast, the topology, as it appears from various OSPF routers within an OSPF area, might have possible impact. Just as OSPF area design impacts topology, so does how LAN routers are logically interconnected.

What's often overlooked with modern L3 switches, that can move an impressive amount of packets, their internal CPU processing, such as for OSPF SPF analysis, can become an issue.

My concern with p2p is it may increase the area topology and make SPF analysis a possible issue. I'm not suggesting to use p2p vs. shared multiaccess or the converse, but both have advantages and disadvantages, which should be considered.

Joseph,

My point was that more and more people today use ethernet to interconnect routers in a p2p fashion as this technology is ubiquitous and cheap. In this case, it is definitely worth to change the default ospf network type of broadcast to point-to-point as it will reduce the size of the LSDB. Why bother to go through the DR/BDR election and the creation of extra LSAs if there is only two devices on the subnet anyway.

Regards

On that point, 100% agreement. (I.e. if doing p2p on Ethernet, makes sense to avoid default DR/BDR processing.)

Personally, i would never suggest to use one dedicated multiaccess vlan to connect all your distribution switches. I only see one possible advantage: ip address conservation. To connect 10 distribution switches, you need 11 ip addresses. Using ptp links, you will need 20 if you can use /31 masks, or 40 using /30 masks.

Maybe someone else can contribute to the thread showing some 'advantages'. I can only think about following disadvantages:

- You must make sure your core is DR AT ALL TIMES. (i hope we all agree on that).

- Convergence is timer-based. Since your DR can't declare the subnet down, when one interface to distri goes down. Using OSPF subsecond hello's, the dead interval still remains 1 second ALWAYS. You would have to use BFD to all your neighbors to get below this. I would be a bit reluctant to implement BFD in this scenario, but that is just personal :-)

- Regarding the OSPF database size, in the multi-access scenario, you would have one router LSA for each distri and core, and one network LSA for the subnet, so 10(d)+1(c)+1(network)=12 LSAs. In a point to point scenario, using ip ospf p-t-p type (!), you would have just 11 router LSA for each device. If you 'forget' to use p-t-p type, yes, than you would have 1 router LSA for each devices (11) and 10 network LSAs for each link, so 21 LSAs. So the database would be larger.

(Part 1 of 2)

Geert, you raise some interesting points, but I thought I would provide another point of view.

I agree that one advantage of using multiaccess could be preservation of IP addressess, although assuming you're using 10.x.x.x addressing, that shouldn't be much of an issue. However, my concern is with topology conservation, a point I'll come back to later on.

You note a disadvantage is "You must make sure your core is DR AT ALL TIMES". I'm unsure of your reasoning. I don't see why the core must be the DR. Since the primary purpose of the core is to push packets, anything that can be delegated to the distribution layer should be done there, and since any OSPF router on the multiaccess segment can be DR (and assuming core multiaccess with distribution), perhaps the core should be the last router you would want as DR or BDR. Granted if you're hosting the multiaccess segment on the core, it may take some effort to keep the core from becoming DR and even more so BDR, but I don't believe it's impossible.

Convergence issues, and the time convergence might take, can get rather involved. So, I'll just touch on some high points.

For starters, unless we have an available alternative path, failure detection convergence time may mean little. The path is broken. Applications using the path, aren't generally going to care much whether the network, itself, understands the failure in 20 ms vs. 20 seconds. Perhaps an application might benefit from getting an ICMP message network unreachable sooner than later, but perhaps not too. (Also there's the issue whether the network even generates ICMP to sending hosts, and whether the sending host would even understand the message and react to the message.)

If there is an alternative path, although faster generally is good, how much faster and whether any packets are lost, could be critical, so much so, 20 ms or 200 ms might not be good enough. If 200 ms vs. 1 second is so critical, perhaps instead of relying on network rerouting based on the IGP (OSPF), you might be better to depend on other technology, such as NSF, multichannel - multicard, VSS, etc. Also, the alternative path might not be another next hop off the device with the broken path, if it's via other devices, they need to converge too. If other routers need to converge, then we also must deal with the time it takes for that to happen and potential impact to active flows.