Scott, Thanks for those suggestions. I understand and agree with what you are saying. Eventually, we would move each one to its own BH PTP for all the reasons you mention. Each one of the "fed" towers in our network has another solid path in the network, so losing an AP feeding it would not really bring down the sub-towers if you will. BW has not been a bottleneck yet. Frequency planning to do all the PTPs off the one tower (one tower feeds 5 others) has proved to be challenging with GPS sync. That's been a factor in wanting to tackle that before we are ready to deal with all that.
I will look at all these options and report later. Thanks! -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Scott Reed Sent: Wednesday, February 26, 2014 6:41 AM To: Mikrotik discussions Subject: Re: [Mikrotik] OSPF "problem" situation #1 From my experience and knowledge of OSPF (I am not an expert, but have read a lot and have over 700 devices on the network running OSPF) this is to be expected. There is no OSPF cost difference in the route to the AP and to the other tower. From Tower A the cost to the AP is the same as the cost to the other tower. You may be able to "fix" it by disabling inter-client communication on the AP wireless interface. You may be able to "fix" it by creating a virtual interface on the AP wireless interface and using a different subnet on that virtual interface. Then the cost from remote tower to AP is less than the cost from remote tower to remote tower. You may also "fix" it by setting the router IDs so that the AP gets elected as the Designated Router. I don't recall if MT uses the highest or lowest ID, but one of them has preference as DR. Honestly, my opinion is the best fix is to use two PTP links to get to the 2 towers and put them on separate subnets. Since all the traffic for both towers goes in and out one interface, there is a bandwidth limitation for each tower. Troubleshooting gets easier with separation. A single radio failure only takes down one tower instead of 2 towers. I realize there are lots of valid reasons to share the AP, but one of my network design criteria is to not share backhaul links between towers. On 2/26/2014 6:21 AM, Paul McCall wrote: > This network is routed. We have this scenario a few places in our network > but this is the only section not working. > > A Single AP (single interface) connects to SMs at multiple towers to be their > primary (lowest cost) path to the internet. All on the same subnet. We have > as many as 5 towers fed like this from a single AP/single subnet/single OSPF > network. > > This particular AP feeds 2 towers. One of the "fed" towers works as > expected, always going to the "AP" tower. The other "fed" tower jumps to its > "brother" instead of the AP tower. > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Scott Reed > Sent: Wednesday, February 26, 2014 6:08 AM > To: Mikrotik discussions > Subject: Re: [Mikrotik] OSPF "problem" situation #1 > > If I understand what you are saying correctly, then I must ask, is this a > bridged/switched network or a routed network. > If it is bridge, you are not going to get OSPF to do what you want as there > is no "shortest" path from a routing point of view. > If it is routed, then it should work. OSPF does things by interface, so if > you have 2 towers being fed from a single interface, it doesn't know how to > determine which interface to use as there is only one. > Please give us some more information about the total topology that you have. > Topology is critical in knowing how to setup the OSPF parameters. > > On 2/25/2014 7:38 PM, Paul McCall wrote: >> Costs are all set right, both incoming and outgoing. The problem is >> that the TIK does not seem to differentiate between the two towers >> that it could possibly go to because they are on the same subnet and >> same OSPF network. That's the problem, in a nutshell >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Scott Reed >> Sent: Tuesday, February 25, 2014 6:21 AM >> To: Mikrotik discussions >> Subject: Re: [Mikrotik] OSPF "problem" situation #1 >> >> 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/ >>> 6 >>> 7 >>> e85431/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 >>> >>> >> -- >> Scott Reed >> Owner >> NewWays Networking, LLC >> Wireless Networking >> Network Design, Installation and Administration Mikrotik Advanced >> Certified www.nwwnet.net >> (765) 855-1060 (765) 439-4253 Toll-free (855) 231-6239 >> >> >> _______________________________________________ >> Mikrotik mailing list >> [email protected] >> http://mail.butchevans.com/mailman/listinfo/mikrotik >> >> Visit http://blog.butchevans.com/ for tutorials related to Mikrotik >> RouterOS _______________________________________________ >> 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/7124 - Release Date: >> 02/25/14 >> >> > -- > Scott Reed > Owner > NewWays Networking, LLC > Wireless Networking > Network Design, Installation and Administration Mikrotik Advanced > Certified www.nwwnet.net > (765) 855-1060 (765) 439-4253 Toll-free (855) 231-6239 > > > _______________________________________________ > Mikrotik mailing list > [email protected] > http://mail.butchevans.com/mailman/listinfo/mikrotik > > Visit http://blog.butchevans.com/ for tutorials related to Mikrotik > RouterOS _______________________________________________ > 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/7124 - Release Date: > 02/25/14 > > -- Scott Reed Owner NewWays Networking, LLC Wireless Networking Network Design, Installation and Administration Mikrotik Advanced Certified www.nwwnet.net (765) 855-1060 (765) 439-4253 Toll-free (855) 231-6239 _______________________________________________ Mikrotik mailing list [email protected] http://mail.butchevans.com/mailman/listinfo/mikrotik Visit http://blog.butchevans.com/ for tutorials related to Mikrotik RouterOS _______________________________________________ Mikrotik mailing list [email protected] http://mail.butchevans.com/mailman/listinfo/mikrotik Visit http://blog.butchevans.com/ for tutorials related to Mikrotik RouterOS
