We are investigating using mikrotik hardware to provide a seamless backhaul link for bandwidth across a low density population area. We are investigating a 400 mile multihop link. Are we crazy in thinking that we can accomplish such a feat? We are looking at a link with 10 - 15 towers…possibly less, if you think we can get a way with it. We will deploy a solution with antennas for both send and receive and use diversity. The link will be accomplished mainly over desert and we will be deploying voice(VOIP) and data services over it. I am mainly concerned with latency for the link and curious of what we should be expecting. We are wanting to pass around 40mbs sustained each way. We may deploy multiple down links for 80mbs down and 40mbs up.
Just keep in mind that Mikrotik RouterOS does not support antenna diversity. Your best bet is to use nStreme2 with 2 wireless interfaces, one interface to send, another interface to receive. this way you will achieve full duplex.
10-15 antenna’s = hops should be no problem. In a properly setup network speeds in a 10-15 hob network will still be faster from head to toe then on the real internet.
In my network a ping from my most distant (measured in hops) client to my border gateway is still only 5 to 6 ms while a ping from my border gateway into a given server on the internet is 40-80ms.
If your network is just a long serial line of antenna’s which further more are not serving networks in between it would be interesting to see what the opinion of the more experienced on this forum are going to advice: fully routed with each link its own network, or all hobs in one big network (with WDS).
And yes, if the the link has to carry an average high load of traffic, dual nstreme (with both a receiving and separate transmitting station for each link in each tower) is the best option.
If your routers in the towers have to work hard to get all the traffic processed (specially if compression is also used) keep an eye on the heat factor. See other threads in this forum. Some have serious doubts about some boards under ´hot´ conditions with several radio’s in them.
I loose 1ms per hop, that would be 15 for 15 hops. My network counts 10 hops max. and the ping time from the far end is 10-11ms to my main gateway, even when plenty of traffic goes around.
I loose 50ms going to my ISP’s internet gateway seen from my network gateway, google give me >95ms.
I have 3 different gateways to the internet, with two different ISP’s, they all have the same results.
Clients in my network have 3Mb and even if they use that fully the time of a ping hardly rises.
15-20ms loss (15-20 hops) in a routed network should be not a single problem.
WirelessRudy you are very much right about it. And BTW your ping latency to google is 95ms? We use SEA-ME-WE 4 link to our country but never heard that kind of little ping latency to the web, here we get 250-350 ms to most of the web sites.
Well, it was when I checked this morning. Now it is a bit slower. But I have also seen above 300ms. It fluctuates pretty much. It is prime time now here in Spain. So internet backbone might be a bit slower then during the day.
Create a mesh of backhaul links between towers, use OSPF for routing and run EOIP from the edge back to core where PPPoE is terminated. This will provide for easier management and failover, but will use more bandwidth on your inter-tower links as all traffic has to pass over these and via the core PPPoE concentrator.
Option 2:
Create a mesh of backhaul links between towers, use OSPF for routing and have a PPPoE concentrator on each tower. This will be harder to manage, but will use less bandwidth on your backhaul links as traffic does not necessarily have to pass via the core.
There are probably more solutions, but these are the ones that popped into my head immediately.
I’ll come to his aid on this one. I don’t see any point in routing a 15 hop PtP link. And what if he is using RIP.
RIP and Hop Counts
RIP uses a hop count as the metric for the route stored in the IP routing table. The hop count is the number of routers that must be crossed to reach the desired network. RIP has a maximum hop count of 15; therefore, there can only be 15 routers between any two hosts. Networks 16 hops and greater away are considered unreachable. Hop counts can be customized so that slow links are set to multiple hops; however, the accumulated hop count between any two networks must not exceed 15.
I would certainly bridge a 15 hop PtPtPtP… rather than route it. If not I would at least tunnel through it to remove the hops.
Now if there was a reason to split some of the hops off to multipoint or creat a ring or other healing topology then routing would make some sense.
Surely you would not have 15 hops in a row! I would think there would be 15 towers in a geographic area, with each tower probably having LOS to 2 others, hence why I suggested OSPF. This would provide redundant paths.
We’re 22 hops from edge to edge and it works great. There is absolutely NO REASON for not running 15 hops on a backbone.
Route it with OSPF or bridge it, it matter not except you are going to have to watch broadcast traffic control much more closely on a bridge, and a bridge of that size can be unhappy about reconverging quickly when you make changes to it. OSPF would be better.
But the OP wanted to know about 10-15 hops. The answer, using MT, is no problem. I’m more concerned about his bandwidth requirement being too high for a desert environment with only 15 hops across 400 miles. Long hops in the desert may be a kicker as we don’t have spatial diversity in our toolbox yet…
My understanding is you can only have 30 hops total to any given site on the Internet without having timeout problems. If I am wrong on that I stand corrected. At 15 hops on your internal network the likelihood of exceeding 30 hops total is extremely high.
traceroute typically only goes 30 hops, however the internet will route up to the TTL. TTL on many boxes is 64 or 128 or 255. You could be extra safe and change the TTL to a higher one on the way out, but probably not necessary really.
