Look at the first column. That interface is dynamic, so you can’t remove it.
Either remove the entry under “/routing ospf interface” that says “all” and add specific entries for the interfaces you want OSPF to run on, or edit the entries under “/routing ospf network” to only match IP addresses on interfaces you want OSPF to run on. I think the first option is cleaner.
I’m unsure on how to find the “interface=all” entry.
“/routing ospf interface print” is not showing all entries.
It seems ROS is having trouble scanning the OSPF interface list.
I have also tried both commands below, but they never end.
That doesn’t seem right. Just having an instance and an area defined shouldn’t activate OSPF, you need to define interfaces and networks defined as well.
Sorry, I failed to make it clear, by “the command freezes” I meant it never returns a result past that point, and the command prompt is not issued again. It seems the command is having trouble scanning the “routing ospf interface” portion of configuration. Please see below.
I think you should email support@mikrotik.com with a supout.rif (http://wiki.mikrotik.com/wiki/Manual:Support_Output_File) and a description of the problem as well as a link to this topic. That is definitely not right, and needs looking at by the official support team (which may or may not see this thread, these are user forums and official support may not respond here).
No, the Mikrotik OSPF implementation does not add interfaces automatically. All interfaces have been explicitely added to OSPF thru “/routing ospf interface add interface=all”. Problem is, I am unable to undo it.
The 0.0.0.0/0 network on OSPF is working fine, as expected.
network > (IP prefix; Default: ) - the network prefix associated with the area. OSPF > will be enabled on all interfaces that has at least one address falling within this range> . Note that the network prefix of the address is used for this check (i.e. not the local address). For point-to-point interfaces this means the address of the remote endpoint.
But that is exactly what he’s having a problem with. When he runs the command to remove the entry he has that enables OSPF on all interfaces, the command never finishes and dies, just like when printing the interface list. At least that’s what was posted above, where he describes that “/routing ospf interface { remove [find] }” fails.
You described what I was trying to achieve when I hit the problem. Since I have lots of VLAN interfaces to handle, I now suppose that to control OSPF interfaces thru the use of network statements seems safer…?
I just want to look at /rou ospf interface section - maybe supout generator won’t hang on it =)
well, not =) I’m using exactly the way I described. because you explicitly set OSPF interfaces, and any interface that can appear dynamically in list will be passive (i.e. disabled for OSPF)