Hi Paul
accordingly to my experience:
1) you could run with net instability with this "triangle" configuration
2) it's up to you to stay with OSPF and keep the instability, or change
the configuration of the network in some way
You could isntall a second link on node A and do a second p2p link (1
link with B and 1 link with C).
Regarding static routing (on that part of the network if B and C are
leaves) it scales, it works much better than OSPF and it solves the issue
Regards
I am not following the reasoning on how this applies to the problem I
described? I certainly don't want to use static routes, and as I described, it
was just an attempt to work around a problem. I love OSPF and the way it
works. However, I have this problem where it is NOT working.
If you can re-read what I described as the actual problem, I'd like to see if there is an
"on-track" solution.
The only thing I have seen posted that might be related to my problem is a
possible firmware version issue on UNBT. All three Rocket M5s are on 5.5.3,
BTW.
Thanks!
Paul
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Paolo Di Francesco
Sent: Tuesday, February 25, 2014 2:26 PM
To: Mikrotik discussions
Subject: Re: [Mikrotik] OSPF "problem" situation #1
it depends on the topology, but (one) static route works much better than ospf
for a lot of reasons.
Regards
My opinion, if you can, seldom static route, use OSPF.
Network changes are seamless with properly configured OSPF. Add
device, everything works. Add a tower, everything works. Not additional work.
In the case of the OP, I would guess that doing static routing would
just hide a problem that is going to impact things other than OSPF at
some point.
If the routes are changing on a regular basis, best to fix the
link(s), not avoid OSPF.
On 2/25/2014 6:35 AM, Paolo Di Francesco wrote:
I would add :
1) as said, the interfaces should be in ptpm or p2p, broadcast will
make things "strange" (some bugs in ubnt, not sure they solved)
2) if you can, avoid ospf and use static routing. If they are leaves
of the net, just use static routing + tunnel and you will solve
everything
3) is ospf flapping? take a look to the routes of the 3 routers, you
should see that every N minutes the routes are changing. If so,
better to avoid OSPF for this link
In case contact me off list
Not sure what you have setup, but a couple of things come to mind.
A router ID on any router of 0.0.0.0 will cause funny things to
happen occasionally. Make sure all routers have an unique ID.
Routes with equal costs will sometimes change. Make sure you have
the costs setup correctly on the routers. Make sure the cost is the
same for both directions on a link unless you really do want traffic
to use a different path inbound than outbound.
More specific routes have priority over more general routes. Not
everything takes the default route, if there are other ways to get
somewhere.
There have been some issues with some levels of UBNT firmware. If
you are a WISPA member, check the archives on the mail lists. (If
you aren't a WISPA member, get signed up as soon as you can.) If you
want help offlist, feel free to e-mail me directly.
On 2/24/2014 2:34 PM, Paul McCall wrote:
Tower A has a Rocket M5 feeding Tower B (as its primary OSPF path)
and Tower C (as its secondary OSPF Path and that works correctly)
Seemingly since A (xxx.xxx.214.49), B (xxx.xxx.214.50) and C
(xxx.xxx.214.51) are on the same subnet and the same OSPF network,
sometimes Tower B will go through Tower C before going to Tower A.
Even with a static route from B (214.50) to A (214.49), the OSPF
default route wants to prefer the tower C (214.51) path. In the IP,
Route List it shows that the default should go the right direction
with a "distance" of 1. In the OSPF, Routes it shows Tower C
(214.51) as the default path with a cost of 1 and a state of Ext 2.
Any thoughts ?
Paul McCall, Pres.
PDMNet / Florida Broadband
658 Old Dixie Highway
Vero Beach, FL 32962
772-564-6800 office
772-473-0352 cell
www.pdmnet.com<http://www.pdmnet.com/>
[email protected]<mailto:[email protected]>
-------------- next part -------------- An HTML attachment was
scrubbed...
URL:
<http://mail.butchevans.com/pipermail/mikrotik/attachments/20140224
/67e85431/attachment.html>
_______________________________________________
Mikrotik mailing list
[email protected]
http://mail.butchevans.com/mailman/listinfo/mikrotik
Visit http://blog.butchevans.com/ for tutorials related to Mikrotik
RouterOS
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4335 / Virus Database: 3705/7120 - Release Date:
02/24/14
--
Ing. Paolo Di Francesco
Level7 s.r.l. unipersonale
Sede operativa: Largo Montalto, 5 - 90144 Palermo
C.F. e P.IVA 05940050825
Fax : +39-091-8772072
assistenza: (+39) 091-8776432
web: http://www.level7.it
_______________________________________________
Mikrotik mailing list
[email protected]
http://mail.butchevans.com/mailman/listinfo/mikrotik
Visit http://blog.butchevans.com/ for tutorials related to Mikrotik RouterOS
