"Mikrotik will happily speak OSPF PTP on multiple networks on one interface. That is something I've taken advantage of when changing routers at key locations. It would not work with a Cisco in the mix."
THANK YOU for saying this. I just discovered this limitation on Cisco the other day. I am just now implementing OSPF on my network and was having trouble getting the Cisco to talk to a Mikrotik until I realized that Cisco will ONLY speak OSPF from it's primary IP on an interface. I have many Mikrotiks with link-nets back to this Cisco at the edge so I am no trying to solve this problem. Not to hijack the thread, but could I use a single Mikrotik connected to the same interface on the Cisco as an OSPF agent of sorts? Have it share with the Cisco and also share with the other Mikrotiks? -Ty On Wed, Feb 26, 2014 at 11:42 AM, Scott <[email protected]> wrote: > On 2/26/14 6:25 AM, Paul McCall wrote: > >> 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:mikrotik-bounces@mail. >> butchevans.com] 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. >>> >>> > In this situation, do you have client isolation enabled on the AP? Scott > Reed suggested that but I'm not sure if you said one way or another. > > I believe that the best way for this to work, with multiple links off one > radio, all in the same subnet, is to enable client isolation on the AP, > then use PTMP for the network type. PTMP is designed for networks where > everyone needs to talk to one designated router, but cannot or should not > speak directly to the other devices on the same media. It doesn't save you > any resources to have Tower B send packets directly to Tower C. The > traffic still crosses the AP twice. > > NBMA is more for where everyone is supposed to talk to more than one other > designated router. You could probably make NBMA work, by limiting the NBMA > neighbors you specify on the client towers. > > In a PTMP OSPF network, Tower A would build an adjacency with Tower B and > Tower C. Tower B and Tower C would never speak directly to one another. > With client isolation they should never know the other existed. > > Going forward, you may want to switch to using a /30 per tower link. You > wouldn't need any virtual APs or anything. MikroTik will happily speak > OSPF PTP on multiple networks on one interface. That is something I've > taken advantage of when changing routers at key locations. It would not > work with a Cisco in the mix. > > Then you can run OSPF PTP and when you switch to a dedicated link to one > tower or another, you the association should just switch to the new > interface when you move the IP address for that /30 to the new interface, > assuming the OSPF interface is already created. But that is not necessary. > You can deal with dedicated links when they happen. > > I've not run PTMP on my wireless links, so there may be some bugs of which > I am unaware. If it give you fits, I would switch to PTP and see if that > stabilizes things. With just two links on the AP you don't really save IP > space having a /29 vs two /30s. If you have 3 links, you can conserve some > IP space. > > _______________________________________________ > Mikrotik mailing list > [email protected] > http://mail.butchevans.com/mailman/listinfo/mikrotik > > Visit http://blog.butchevans.com/ for tutorials related to Mikrotik > RouterOS > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.butchevans.com/pipermail/mikrotik/attachments/20140226/bdceed93/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
