All,

I have a weird issue. I have a CCR1036-12G-4S. It is running 6.37.1 and has had this issue with old firmwares as well.

My problem is the when a physical interface goes down withs lots of PPPoE connections on it, my ospf for the whole router goes nuts. When I says lots, I'm talking 96.

It reports the all my OSPF peers went from full to down. I have tested this with multiple ports and it only seams to crash when a port is unplugged with lots of PPPoE connections. I have tested it on ports with only a few connections, such as 23, and it didnt crash. Infact, I can cause the failure by simply disabling the PPPoE server on the port with many connections. It does the same thing.

OSPF is set to distribute connected as type 1, static as type 1, and the default if installed as type 1.

I am using /30 subnet for all OSPF network routes and have them set as PtP in the interface list.

This is causing crazy nightmares for me and has appeared to cause more and more issues as I get more PPPoE connections.

Let me know if there is any info I can provide to help.

Thanks in advance!

Have you assigned an address to your loopback and set the router-id for OSPF to be this loopback address?

It's always best to assign OSPF to the lookback address as this "interface" never goes down.

Have you assigned an address to your loopback and set the router-id for OSPF to be this loopback address?

It's always best to assign OSPF to the lookback address as this "interface" never goes down.

Yes, router id has been set to loopback IP address

My main thought is that OSPF has a limit as to how many route updates it sends some how.

Okay so I believe I have found out that when I have an interface with the high number of networks disconnect it overload the routing process and causes it to reset. This appears to be an issue that has come up in the past (v4.X) when the process uses 100%CPU only this time its on a cloudcore with multiple cores.

Is the routing process going to be multiple core capable?

What can I do to help prevent this from happening? It almost sounds like a bug but it also kinda sounds like its just underpowered CPU.

Distribute-connected will force OSPF recalculation whenever a pppoe interface goes down/up, you should probably have a different approach here.

Do you need to advertise OSPF over all these pppoe interfaces? If not, you should set distribute-connected to no and add pppoe network to your OSPF networks in a separate area. You should also make pppoe interfaces passive and create route summarization.

Distribute-connected will force OSPF recalculation whenever a pppoe interface goes down/up, you should probably have a different approach here.

Do you need to advertise OSPF over all these pppoe interfaces? If not, you should set distribute-connected to no and add pppoe network to your OSPF networks in a separate area. You should also make pppoe interfaces passive and create route summarization.

So my PPPoE interface are quite dynamic. I would not be able to set a interface rule for each connection.

I do not run OSPF over the PPPoE connection but I do need the routes to be shared VIA OSPF (so i do use Distrubute-Connected)

I have so many other Connected routes that disabling that would cause a very time consuming and hard to manage network.

Is this something that could be a bug? I counted and the interface that causes the overload has about 130 networks on it. If this causes the routing process to crash then this seams like a major limitation as to how many network you would want on an interface.

As emils stated you are going to need a redesign. I think you should try to use area-range and agregate the networks instead. And use a stub area.