Make sure you are running the most recent version of 5.2 firmware.....also you need to be running then in AP-WDS and CPE-WDS mode.
Faisal On Jun 24, 2010, at 9:08 AM, Jayson Baker <jay...@spectrasurf.com> wrote: > I didn't quite follow all of that, it must be too early. > But I can tell you we have 4 of the PtP UBNT links using their M-series. 3 > of those OSPF fine. The other won't OSPF for the life of me. All same > config and firmware on all units. > > On Thu, Jun 24, 2010 at 4:38 AM, Scott Lambert <lamb...@lambertfam.org>wrote: > >> We have been putting up some Ubiquity RocketM5 point-to-point bridge >> links, running airos 5.2, lately to replace some overloaded StarOS >> backhauls. Where these links have gone in, we static route the traffic >> across them. They happen to be on the OSPF/OLSR divider boundry. I >> would like to find a good way to redistribute between the routing >> protocols, but that's for another day. When I get time, I'll probably >> just convert the 20 odd OLSR towers to OSPF. >> >> These are our first experience with Ubiquity. The first two were no >> muss, no fuss. The third link went up nicely. It's configured the same >> as the other two links. About an hour after we plugged the local end >> at our office into the main switch, rather than a laptop, we started >> loosing routes to sites which pass through the tower at the far end of >> the link. >> >> All hosts on the tower LAN can see each other. We can reach all of >> them from anywhere else on our network. It is just routes for hosts >> connected wirelessly to that tower which are no longer known to the >> staros box which has the existing backhaul to our office. >> >> We rebooted everything at the remote tower. The links came up. The >> routes were good. Approximately an hour later, the same routes fell >> out. So, we decided it must be due to some sort of wierd multicast OLSR >> issue when these towers were suddenly able to see each other across >> the bridges. I unplugged the ethernet at the office and waited until >> tonight to try again. The routes straightened themselves out as soon as >> I unplugged the office end. Wild. >> >> This afternoon, I setup a seperate VLAN on the switch for this link. >> Before I left the office I plugged it in about, 8:00pm. I didn't have >> any other devices configured on that VLAN. >> >> There were no problems for several hours until I configured the new VLAN >> on the Cisco that was sometime between 1:01 and 1:10am. The RANCID >> run at 1:01 didn't see any changes but the run at 2:01 found them. At >> 1:10am Nagios noticed that it couldn't reach the equipment through those >> same routes. >> >> + interface GigabitEthernet0/3.13 >> + description "Wireless VPN 3 >> + encapsulation dot1Q 13 >> + ip address 10.127.3.1 255.255.255.0 >> + no cdp enable >> + ! >> >> That's the subnet for the RocketM5s. The StarOS gear on the tower uses >> a public /29 subnet. >> >> I tried various things with reboots and restarts of OLSR on the staros >> gear at the tower. The routes came back for four or five minutes then >> went away again. No good. >> >> So, at about 2:10am, I logged into the RocketM5 at the tower and >> disabled it's ethernet interface. Within a few seconds, my pings to >> equipment through the lost routes began succeeding. >> >> It's now 3:25, and all's well. I am puzzled. We really need the >> additional bandwidth the ubiquity link can give us on this link. >> >> At 3:26 I enabled the LAN at the tower just to make sure. Within 2 >> minutes, splat. This time I left the LAN enabled at the tower and >> disabled the WLAN interface at the office. All better in seconds. >> >> Administratively shutting down interface gig0/3.13 at the office seems >> to be enough to heal OLSR at the tower. If the tower LAN can see the >> cisco, we drop routes. But the other ubiquity links connect back to the >> same cisco at the office. >> >> I think we will probably replace the switch at the tower tomorrow to see >> if it has problems we haven't tickled before. I'm stumped. Does anyone >> else have any ideas? >> >> >> -- >> Scott Lambert KC5MLE Unix SysAdmin >> lamb...@lambertfam.org >> >> >> >> >> -------------------------------------------------------------------------------- >> WISPA Wants You! Join today! >> http://signup.wispa.org/ >> >> -------------------------------------------------------------------------------- >> >> WISPA Wireless List: wireless@wispa.org >> >> Subscribe/Unsubscribe: >> http://lists.wispa.org/mailman/listinfo/wireless >> >> Archives: http://lists.wispa.org/pipermail/wireless/ >> > > > -------------------------------------------------------------------------------- > WISPA Wants You! Join today! > http://signup.wispa.org/ > -------------------------------------------------------------------------------- > > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
