cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8116
Views
5
Helpful
22
Replies

ospf point to point links on a lan

carl_townshend
Spotlight
Spotlight

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 22

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

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.

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.

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.

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

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.

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

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco