Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

ospf point to point links on a lan

Hi all, we are redesigning the lan network using the 3 layer model, the consultant says we are going to use point to point config between the l3 switches, why would we do this instead of using the normal broadcast mode ?

cheers

Carl

22 REPLIES
Super Bronze

Re: ospf point to point links on a lan

One valid reason might be to avoid multicast issues between routers (although PIM snooping might deal with that, if supported), but you might ask your consultant why. Their reason or reasons might make for an interesting post.

Cisco Employee

Re: ospf point to point links on a lan

Carl,

The most compelling reason is the fact that there is no DR/BDR election on a p2p network type, which will cause neighbor router to become adjacent much more rapidly.

Regards

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México 
Paseo de la Reforma 222 Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
New Member

Re: ospf point to point links on a lan

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

Re: ospf point to point links on a lan

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

Super Bronze

Re: ospf point to point links on a lan

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?

Cisco Employee

Re: ospf point to point links on a lan

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

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México 
Paseo de la Reforma 222 Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
New Member

Re: ospf point to point links on a lan

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.

Super Bronze

Re: ospf point to point links on a lan

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.

Bronze

Re: ospf point to point links on a lan

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.

Super Bronze

Re: ospf point to point links on a lan

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.

Cisco Employee

Re: ospf point to point links on a lan

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

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México 
Paseo de la Reforma 222 Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
Super Bronze

Re: ospf point to point links on a lan

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

Bronze

Re: ospf point to point links on a lan

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.

Super Bronze

Re: ospf point to point links on a lan

(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.

Super Bronze

Re: ospf point to point links on a lan

(Part 2 of 2)

There's also restoration convergence to consider. Unsure whether OSPF will send an immediate hello packet upon a link "up", but even if it does, subsecond hellos could start the OSPF exchange process about as quickly. Probably a wash between the two.

More information about OSPF convergence can be found in this older Cisco presentation: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/ps6629/prod_presentation0900aecd80310f6d.pdf. Look through the "Fast Convergence" section. Of possible special interest is LSA and SPF timers.

On the issue of OSPF database size, my concern isn't with whether we have 11 vs. 21 LSA entries, it's with what those LSA entries represent and what OSPF has to do with them.

Why do we use OSPF areas? Why does slide 13, in the above referenced link assert "OSPF is not very good for hub and spokes"? Both I think are because of the possible impact of large and/or complex topology may have with SPF. If you graph out the topology view from your example of a core router with ten distribution routers and viewing topology from the core, using both p2p or multiaccess you have 11 nodes, but with p2p you also have 10 links to track, with multiaccess only 1 link to track. If you graph out the view from one distribution router to another, with p2p, there's two (serial) links to track, with multiaccess only 1. What I'm suggesting is, multiaccess can decrease the size of the topology that OSPF must manage, so the advantage is just more than conservation of address space.

I do want to make clear, that I'm not suggesting everyone use multiaccess vs. p2p, but that there's more involved choosing one vs. the other than just DR/BDR election or not. Harold's initial point about saving some time avoiding unnecessary DR/BDR election, and Geert's mention of different failure times for physical vs. logical, are excellant examples of such issues involved when making these type of design decisions.

The reason I asked Carl to ask the consultant to explain their p2p choice is, I often run into "we always do it that way"; often without any real understanding why it's done that why, and perhaps more important, when and why you shouldn't.

New Member

Re: ospf point to point links on a lan

Without knowing all of the specifics of the network you are designing for I will just speak about my own experience. When I first built the network I maintain now, I configured it with the multiaccess configuration you are talking about, because my core routers didn't have enough interfaces. My concern became apparent a year down the road when I had to keep installing distribution routers. How many was I going to keep adding in this linear flat capacity? I finally have replaced my core routers with boxes that have the interfaces to hook everything up ptp and I'm actively doing the conversion. My argument against the multiaccess method would be scale. I also think that if the "core" is just a vlan then it is not participating in the OSPF routing process and you would more of a flat routing domain than a tiered one.

In closing my personal opinion comes down to design and scalability. I would use the PTP links and use areas so that you can protect your SPF process since it is calculating for the area that it is in. Troubleshooting will also be more straightforward and you have a model that can grow as the network grows.

Super Bronze

Re: ospf point to point links on a lan

Could you explain further why you "had to keep installing distribution routers" and "keep adding in this linear flat capacity"? I understand lack of ports on a core router precluding direct p2p links with your distribtion routers, but these other issues are unclear to me.

New Member

Re: ospf point to point links on a lan

Sure, these boxes were 7206VXRs that we originally had 8port serial octopus cables plugging into a paradyme comsphere CSU/DSU nest. We had two of these chassis and never thought in our wildest dreams that we would fill them up. Well, it was less than a year before we were in serious trouble. we have since removed the serial cards in favor of 2 port channelized T3 cards. not only have I filled every slot on the router up with these T3 cards, I have had to add 3 more routers. As our access grows, our distribution grows. Now if your distribution routers are sized to vertically scale for the next 10 years then maybe you won't have the same issue. You are dealing with a campus environment, I'm assuming, while I'm dealing with a SP environment where our access networks take on new and wondrous shapes all the time and you can't use the same distribution routers that are earmarked for a certain function. I ran into the fact that we had to continue installing routers because I wasn't sitting on any BFRs that could terminate all of the various connectivity. Either way, I'm pointing out that things change and the best way to roll with the punches is to create a modular design from the beginning because we're not fortune tellers. By plugging everything into a vlan you have already limited yourself in some aspects by having to carry this subnet across multiple boxes if you increase your core by one box. I understand your detailed technical arguments for the multiaccess system, I consoled myself at night that it was "ok", but there are good reasons that always aren't readily apparent in the wisdom of modular design and PTP links. If your network is never going to expand then fine, but the only networks that haven't expanded are the ones powered off because they are going out of business. I know this sounds like a lot of generalist gibberish, but your talking about swimming against the current when you could just swim with it.

New Member

Hi Joseph,

Hi Joseph,

am fully aware that im replying to a 7 year old thread and many thing have changed in IOS & platforms, let alone IOS-XR, however reading this thread was very useful, as Im researching the disadvantages of using p2p vs multiacess on an ethernet segment, and I would really like to understand what caused a meltdown you mention above, if you remember at all.

Is it the fact that the SPF calculation with 60 ptop links make the router CPU sweat that was the issue, and one single shared multiaccess 'domain' (as in one DR/BDR) did not ?  

In my case im looking at p2p links from various access boxes hooking up to an ASR9k, single area 0, so I believe its do-able, but happy to hear otherwise.

thanks

Mark

Super Bronze

Disclaimer

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Yea, it's been a while but I still remember a bit.

What I believe the cause of the OSPF meltdown was, was a flapping link that kept having all the OSPF routers deal with a OSPF topology change.

Something very important to also know, the LAN L3 switches, at that time were Brand X.  Their OSPF implementation didn't have, I believe, Cisco's OSPF features like their SPT exponential backoff timers (nor even Cisco's newer ISPF).  (Cisco, over the years, has often implemented other subtle enhancements to their router protocol implementations that improve stability and often scale better.)

At the time, the fix was as noted.  If the equipment had been Cisco then, or now, I don't think the meltdown would have occurred.

BTW, over the years, I too have found logical p2p has some useful advantages.  The two most significant, I think, if the p2p link is also a physical p2p connection, link down (and logical path loss) is generally detected faster, faster than even BFD.  The other is dealing with multicast, as p2p avoids the need for something like PIM snooping between routers on a multi-access segment.

(Today, I deal with networks that have much more very time sensitive traffic, such as VoIP, video conferencing, VDI, etc., then I did seven years ago.  Keeping a flow from taking any kind of noticeable interruption is more important than ever.)

The biggest disadvantages, I believe, with using p2p vs. multi-access are the SPT is more complex with additional p2p, but Cisco's ISPF helps there, and it burns more IPs, but support for /31s also helps that too.

New Member

many thanks for a fast reply.

many thanks for a fast reply.

I too had some issues with multicast traffic (but on another network) and PIM snooping wasnt even available on that platform, so I concur with that and fast detection being big advantages for P2P over multiaccess.

For OSPF exponential backoff that you mention, this is inbuilt into the IOS code right, not something that needs explicit configuration, unless i guess you want to modify the defaults for stuff like the hold timer etc...

Out of interest, would link ip event dampening not helped too in such situation ?

cheers

Mark

Super Bronze

Disclaimer

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Yup, OSPF exponential back-off is built in and its timers can be adjusted.  Cisco has a least one paper on adjusting timers for OSPF or EIGRP to work toward subsecond routing convergence.

Also yup, IP damping would be another approach.  If fact, we might have used that too, but it's been so long, I'm not sure.  (Might have enabled BGP dampening, as our WAN edge were Cisco routers.)  I do recall looking at using it on our Cisco routers.  (However, again, something that I don't recall our Brand X provided.)

2670
Views
5
Helpful
22
Replies