This is not really a Mikrotik problem because it is vendor and model specific but it did happen and is a gotcha that some folks need to watch out for…
The Netgear WGR614v8 ( http://kbserver.netgear.com/products/wgr614v8.asp ) router will not negotiate PPPoE reliably with RouterOS v3.10. This goes for v7, v8, and v9 of the device. We tried to downgrade one to v6 of the firmware but it would not downgrade. Fortunately that POS can be reflashed with DD-WRT and probably OpenWRT. We have tested it flashed with DD-WRT and it does negotiate PPPoE reliably with RouterOS v3.10.
Ah, after a bit of further reading, I see that Netgear brilliantly decided that the router should “automagically” upgrade its firmware whenever it logs into the internet. I further see that Netgear released version 1.1.11 of its new firmware on 20 June 2008 the day after I upgraded our Mikrotiks. So what appeared on the surface to be an issue with a change in Mikrotik firmware was not. It was an issue with a change in Netgear firmware.
Ahhhm … the continuing saga of PPPoE
I have now tried to install every version of the Netgear firmware for that device and run it against the 2.9.51 version of RouterOS. The units will not associate with that PPPoE server.
IS ANYONE HAVING TROUBLE WITH THESE NETGEAR DEVICES AND PPPOE???
OK so we have isolated the PPPoE issues we are having to Netgear WGR614v8, WGR614v9, and WNR834Bv2.
We have no idea why these devices have suddenly quit working with our PPPoE servers.
In summary:
Thursday (2008-06-19) we upgraded to ROS v 3.10 from ROS v 2.9.51. On Friday 2008-06-20 Netgear issued some firmware updates for some of the routers. We started having problems with the Netgear routers as mentioned.
Yesterday I took one of the test routers back to ROS v2.9.40 and these Netgears still will not associate with that Mikrotik PPPoE service.
The problem makes absolutely no sense because even Netgears which are flashed to the earlier firmware will not associate with these PPPoE servers.
Let this be a lesson in whether to bridge or to route.
First, however; a chronological “comedy of errors”.
Every pop in our network is a brouter. Each has three or more ethernet ports and almost all are on RB532’s with the RB562 board. Each has a world, a pppoe, and a local port. World and local are bridged. PPPoE and Local are plugged into the same switch. This allows us to provide our customers with static addresses which are bridged onto our network via local->bridge->world and pppoe services for customers who do not need public addresses. Those customers connect to pppoe and are routed through the world port.
This means that we must filter pppoe-discovery packets when they enter our switched network or all the pppoe servers will see them. If all 30 pppoe servers see a pppoe-discovery packet it causes a storm of pppoe-offers and bogs down the network making it impossible for some SOHO routers to connect to any pppoe server. In our case Netgear routers were the most affected.
Now, this rule:
/ interface bridge filter
add chain=input action=drop in-interface=!pppoe mac-protocol=0x8863 comment=“”
disabled=no
DOES NOT WORK in ROS v2.9.51 BUT THE COUNTERS INDICATE THAT IT IS WORKING.
but THIS kludge does work in ROS 2.9.51
/ interface bridge broute
add chain=brouting action=redirect mac-protocol=0x8863 comment=“” disabled=no
Guess what happens when you upgrade to ROS v3.10? Neither rule works until you check the “use IP firewall” box on the Bridge settings and even then the second rule (the kludge) still doesn’t work.
There are two lessons to learn here:
First, when in doubt route.
Second, vendors should not change default behaviors, especially in firewalls. Filters should default to on if they always did in the past.
Oh, well, it only cost us about $2500.00 US to figure out our mistake. But it almost cost Mikrotik all of our business. Before we understood the problem we started entertaining bids from other vendors to replace all of our installed base of Mikrotik. We don’t like surprises out here, especially surprises that BREAK EXISTING FIREWALLS.