Is there any way to change the link state (without rebooting the routers) on 2 routers connected with ospf. One of my routers shows a link state of init. I can reboot the opposite end of the connection that shows init and it will reset. I think I have disabled the ethernet port of the opposite end and also accomplished this. And shouldn't the link continually try to reset if it isn't connected?

Next I have 3 routers connected with ospf in a ring configuration. A to B to C connected back to A with A being my connection to the internet. I have a point to point wireless radios between B and C. Should I list the ip/subnet assigned to the point to point radios in both router B and C's ospf network? This would basically duplicate the ospf network in both routers to guarantee that they are accessible, if the connection goes down from A to B or A to C, but I think they would already be relayed over the connection from B to C. This was the original config that I received when I took over the routers, but it looks to me like each network should only be one of the routers ospf networks?

Any ideas on either would be appreciated.

Is there any way to change the link state (without rebooting the routers)

You can remove and then re-add all "Interfaces" in /routing ospf interface, which apparently kicks OSPF (or possibly kills it outright) enough to get it to reset the interfaces, but this is a bit of a pain. Otherwise you can reboot the router. It would be nice if there was a way to restart (and find, in the case of 100% CPU usage, for example) errant processes.

shouldn't the link continually try to reset if it isn't connected?

Yes, but the current implementation seems to have some problems. In particular, we've noticed:

If an interface was in a bridge but is no longer in a bridge, OSPF will probably not work correctly until the router is rebooted. A symptom of this condition is that a router on one side of the link will be stuck in "Init" in the OSPF Neighbor display, while the router on the other side may show either "Full" or nothing at all (the other router doesn't appear as a neighbor).

Changing an address on an interface may also behave similarly to the above. And just today, i've discovered that adding a comment to an interface or possibly to an address, can screw up OSPF on that interface. (2.9.44ish versions) (rebooting fixes this also).

有时,一个路由器会决定其nei之一ghbors is no longer valid and change the neighbor state to down. (2.9.46 and earlier). I'm still trying to track this one down, but so far doing packet captures I see no reason for this behaviour, but its causing a problem in our network because its resulting in unnecessary route flapping. It appears that it may be related to routers that have static entries in their route tables, but I haven't confirmed this yet. (there are other problems with OSPF and static route entries though).

As for A->B->C->back to A, assuming the following:
A <- 192.168.0.0/30 -> B
< - 192.168.0.2/30 > C
B <- 192.168.0.4/30 -> C

On router A: networks should be: 192.168.0.0/30 and 192.168.0.2/30
On router B: networks should be: 192.168.0.0/30 and 192.168.0.4/30
On router C: networks should be: 192.168.0.2/30 and 192.168.0.4/30

The Networks portion of OSPF only controls whether an interface (or actually, in RouterOS's case, a subnet on an interface) is speaking the OSPF protocol or not, and what area that interface is in. it does NOT control whether a network will be advertised by OSPF or not. Another router, D, connected to B would still hear about the 192.168.0.2/30 network via OSPF, even though that network is not listed in B's or D's networks. In Cisco land, if one just wants to run OSPF on all interfaces, one can get away with doing either 0.0.0.0/0 or, in the case above 192.168.0.0/28, but on RouterOS, while this may appear to work initially, it will eventually fail, as RouterOS does not properly recognize supernets (something in the underlying ospf implementation does not recognize that 192.168.0.0/30 is "included" in 192.168.0.0/28); which is irritating because one must then list each individual network, which on a router with lots of interfaces that is only in the backbone (or other OSPF area, but not participating in a second area or the backbone), the networks list almost becomes redundant with the addresses list. Furthermore, in cisco land, if one wants all but "some" interfaces to be in the backbone, you can do things like:

0.0.0.0/0 = backbone
192.168.0.0/30 = area2
...

Also, note that an interface does NOT have to be listed in interfaces for OSPF to run over that interface (thats what "networks" controls), but interfaces lets you change the defaults/parameters for an interface, which will otherwise use defaults (or the "all") interface for its settings. (it may be however that if there are NO interfaces listed at all, then OSPF does not run, otherwise the remove/re-add reset trick metioned at the beginning might not work). This may seem redundant, but an interface can have more than one address, and each address "looks" like a different interface (and possibly different area) to OSPF.

Sorry to go off on some tangents, I hope your questions got answered in the process, but i've been having some OSPF problems with RouterOS, and this seemed like a good place to vent about them.

The above is based on a combination of extensive cisco experience, fairly extensive RouterOS experience, a reading of the OSPF RFC, and several other OSPF related documents. If anything in the above is incorrect or works differently than I think it does, please elaborate, and please explain why that is the case.

If you have a relatively simple "hub-and-spoke" network you probably won't notice most of these issues, if you have a complex network with rings in it, these problems are more likely to crop up. (or to put it another way, a network where which router is the parent, and which is the child, can change, such as in the a->b->c->a example.)

P.S. integrating cisco (IOS) and Mikrotik (RouterOS) Networks:

RouterOS interface priority X is equivalent to IOS message-digest-key X.

RouterOS can "run" ospf on every network on an interface, IOS will only run it over the primary IP address. (mikrotiks will send a hello with a source address of every defined address on an interface, if that address's subnet is listed in "networks". IOS will only send hellos from the primary IP address; VLANs can be used to get around this limitation).

IOS允许用于定义supernet面积标准ticipation, RouterOS requires exact matches (or bad things happen later. sometimes RouterOS seems to recognize supernets, and sometimes it doesn't. The mismatch eventually leads to problems.)

Static routes can get "stuck" in the mikrotik OSPF process even though they don't appear in the routing table. This is especially true for 0.0.0.0/0 static routes, so try to avoid having static routes (or at least ones which may change) when using OSPF. (For instance, you have a static route 0.0.0.0/0 somegateway in the routing table. you delete it, disable it, or it becomes invalid; however, RouterOS ospf will still advertise this route (given appropriate Redistribute OSPF settings) to its neighbors. This may result in a routing loop as the information being advertised via OSPF does not match the routing tables).

Hopefully this has been helpful to one or more people.

Hi,

thanks for the hints. Some of the problems I´me struggling wlth.
The static route distribution is my actual problem. I need static
routes for some reasons:
- default route: my bgp routers generate it so outbound traffic is
routed to a bgp router
- Servers with additional ips which do not talk ospf

I see static routes from a cisco dominating. I tried to influence
it with interface costs, but nothing happens I do redistribute
with metric-type 1 so that interface costs should come into play.

What makes me crazy is that there is no info on MT why one
route is prefered. And booting after each change is not possible
on production systems. So its like running in the dark.

Stefan

Thanks for the ideas/suggestions. I found the majority of my problems were in that there wasn't anything setup as backbone and no primary router to get routes from. Once we set up the backbone network and then we got consistent primary router across the network. Before each router on the network may select a different router as the primary (because it thought the whole network was a stub network) and then when you reboot one part of the network, another gets goofy. One we set the backbone up then it really stabilized. I was having the ospf network in init state and rebooting fixed that but I think it was the backbone setup problem. I also couldn't do anything with costing etc because of the whole network was a bunch of stubs.

I also had all of the local networks on each router setup in the ospf network section. I think they thought this was the routes to be advertised etc. instead of just defining the ospf network.

Once I had all of my mikrotiks setup, the last piece of the puzzle was to setup ospf between them and my foundry backbone router and it all stablized and cleared up a lot of the flakyness.

I did get some good assistance from wisp routers in pittsburg kansas to help change some of the setup and educate us. I spent a $1000 in consulting, but my sys admin had just left the company and we needed to get things fixed in a hurry plus educate me to be able to keep the system up etc. They have some mikrotik training that I'm thinking about going to also.

cktbruce said:

I also had all of the local networks on each router setup in the ospf network section. I think they thought this was the routes to be advertised etc. instead of just defining the ospf network

I think this is a fairly common misunderstanding. Aspects of OSPF are counter-intuitive and confusing. I haven't studied the IPV6 version of OSPF yet, but from a cursory glance at it it seems that a lot of this stuff has been cleaned up and streamlined. Fortunately the whole world will be converted to IPV6 by 1999 at the latest...

In rereading my previous post, I implied, but didn't quite make it clear (or possibly i'm belaboring the point) that OSPF will advertise the state of ALL interfaces (addresses/networks), independently of whether those interfaces are participating in a routing protocol or not (this can be influenced with routing->filters, and with the "Redistribute Connected Routes" setting in OSPF settings).

ste said:

I see static routes from a cisco dominating. I tried to influence
it with interface costs, but nothing happens I do redistribute
with metric-type 1 so that interface costs should come into play.

What makes me crazy is that there is no info on MT why one
route is prefered. And booting after each change is not possible
on production systems. So its like running in the dark.

I was told that OSPF related info will be available eventually, (it might already be in 3.0rc4, but I haven't checked. Additionally, it would be available via the command line before it shows up in winbox). Meanwhile, i've resorted to packet captures and using Ethereal (or wireshark) to analyze them. Oh, you can also add a log rule for ospf, and one for route (make sure they are separate rules), and be prepared for a barrage (probably want to send it to a remote syslog server).

With interface costs, something to keep in mind is that they only apply in the "outgoing" direction:

router A defines ether1 cost as 10
router B defines FastEthernet0/0 and FastEthernet0/1 cost as 20
router C defines ether1 cost as 30
A.1 <-> B.0 and B.1<->C.1
In this case, the path from A to C costs 30.
The path from C to A will cost 50.
(so, you can do anything to the cost of ether1 on A, and it won't change the cost/routing from C to A).

(This is an OSPF thing, and not particular to any brand of router, barring bugs).

This comes in handy when dealing with asymmetric links, like DSL, where the path really is more expensive in one direction than the other. This, however, can make your routinginteresting, especially when trying to diagnose something (and traceroutes from one end only may no longer give you a clear picture).

Also, the route-table "cost" will always be 110 (by default), but what actually gets inserted into/removed from the route table will be controlled by the OSPF costs (based on that particular router's view outward).