FlemmingFrandsen
01-22-2010, 09:41 AM
Is there an ETA on OSPF support in the default firmware?
View Full Version : OSPF (quagga) support in default firmware
twinkletoes
01-22-2010, 04:58 PM
this is a stupid request. please leave these ****ing radios alone. let them be cheap $89 radios. do you really expect to see VRRP or CARP and OSPF and BGP and MPLS BGP VPN and what else on your radio??
or do you want to get the best wireless bridging performance so you can use appropriate router gear?
why not do what most other people with large, successful networks are doing, and use mikrotik, quagga, cisco, juniper or openbsd for your routers???
the firmware on these radios is constantly going through changes, and you will get the best performance on the radio and the most stability if you don't keep trying to manipulate it for every possible use you can think of.
or do you want to get the best wireless bridging performance so you can use appropriate router gear?
why not do what most other people with large, successful networks are doing, and use mikrotik, quagga, cisco, juniper or openbsd for your routers???
the firmware on these radios is constantly going through changes, and you will get the best performance on the radio and the most stability if you don't keep trying to manipulate it for every possible use you can think of.
opampca
01-23-2010, 02:59 PM
That was also asked by an humanitarian ngo Nethope in Haiti this morning on other networks.
It would make deployment a lot easier than using more gears...
Just my 2 cents on ideas like this !!
Richard
It would make deployment a lot easier than using more gears...
Just my 2 cents on ideas like this !!
Richard
Ron
01-23-2010, 07:57 PM
please leave these ****ing radios alone. let them be cheap $89 radios.
or do you want to get the best wireless bridging performance so you can use appropriate router gear?
why not do what most other people with large, successful networks are doing, and use mikrotik, quagga, cisco, juniper or openbsd for your routers???
.Seconded.
or do you want to get the best wireless bridging performance so you can use appropriate router gear?
why not do what most other people with large, successful networks are doing, and use mikrotik, quagga, cisco, juniper or openbsd for your routers???
.Seconded.
tierpath
01-23-2010, 08:34 PM
OMG someone said OpenBSD, there is intelligence!
FlemmingFrandsen
01-25-2010, 01:12 AM
this is a stupid request. please leave these ****ing radios alone. let them be cheap $89 radios.
Do you really expect to see VRRP or CARP and OSPF and BGP and MPLS BGP VPN and what else on your radio??
Yes I do expect any router to be able to talk OSPF and in this case when quagga is already running on the plaform there is absolutely no reason not to do it.
There is no law that says that you can't run quagga on a machine just because it's not overly expensive.
Having an extra router adds not only extra cost to the initial deployment and extra upkeep, but also an extra hop to the network that ends up being a single point of failure.
It's much nicer to have every AP on a tower independently balance the load over several routes to where ever the traffic is going than piping everything through a single router.
Leaving out OSPF support in AirOS also makes it impossible for me to run OSPF all the way down to the CPE, which I'd really like to do to make it easier to maintain special exceptions like routing an extra address space to a single customer.
Bottom line is that others have already gotten OSPF working on AirOS, all that's needed from Ubiquiti at this point is to include it in the default firmware so we can stop having to patch the firmware.
Do you really expect to see VRRP or CARP and OSPF and BGP and MPLS BGP VPN and what else on your radio??
Yes I do expect any router to be able to talk OSPF and in this case when quagga is already running on the plaform there is absolutely no reason not to do it.
There is no law that says that you can't run quagga on a machine just because it's not overly expensive.
Having an extra router adds not only extra cost to the initial deployment and extra upkeep, but also an extra hop to the network that ends up being a single point of failure.
It's much nicer to have every AP on a tower independently balance the load over several routes to where ever the traffic is going than piping everything through a single router.
Leaving out OSPF support in AirOS also makes it impossible for me to run OSPF all the way down to the CPE, which I'd really like to do to make it easier to maintain special exceptions like routing an extra address space to a single customer.
Bottom line is that others have already gotten OSPF working on AirOS, all that's needed from Ubiquiti at this point is to include it in the default firmware so we can stop having to patch the firmware.
FlemmingFrandsen
01-30-2010, 08:50 AM
... do you really expect to see VRRP or CARP and OSPF and BGP and MPLS BGP VPN and what else on your radio??
VRRP: Nope, that's Cisco patent encumbered and I'll not touch it.
BGP: Nope, the routing table is much too large to fit in memory.
VPN: Nope, VPN belongs at the edges of the network or it's useless.
MPLS: Nope, I don't have the need.
... but CARP and OSPF have just been implemented, it's a 6420 byte download that does everything needed to get a AirOS 5.1 image with UCARP and Quagga:
http://dren.dk/airos-plus.html
There is plenty of RAM free even when running, zebra, ospfd and ucarp, so there really isn't anything silly about having dynamic routing protocols:
XM.v5.1.plus.19137# ls -l /etc/persistent/ucarp.conf
-rw-r--r-- 1 ubnt admin 571 Jan 30 15:18 /etc/persistent/ucarp.conf
XM.v5.1.plus.19137# free
total used free shared buffers
Mem: 30312 20524 9788 0 3072
Swap: 0 0 0
Total: 30312 20524 9788
XM.v5.1.plus.19137# ps
PID USER VSZ STAT COMMAND
1 ubnt 1976 S init
2 ubnt 0 SWN [ksoftirqd/0]
3 ubnt 0 SW [watchdog/0]
4 ubnt 0 SW< [events/0]
5 ubnt 0 SW< [khelper]
6 ubnt 0 SW< [kthread]
7 ubnt 0 SW< [kblockd/0]
8 ubnt 0 SW< [khubd]
9 ubnt 0 SW [pdflush]
10 ubnt 0 SW [pdflush]
12 ubnt 0 SW< [aio/0]
11 ubnt 0 SW [kswapd0]
13 ubnt 0 SW [mtdblockd]
14 ubnt 0 SW [pktgen/0]
200 ubnt 1132 S /sbin/hotplug2 --persistent --set-rules-file /usr/etc
203 ubnt 1968 S < /bin/watchdog -t 1 /dev/watchdog
308 ubnt 2704 S /usr/sbin/zebra -d
315 ubnt 3312 S /usr/sbin/ospfd -d
322 ubnt 2320 S /usr/sbin/watchquagga -d -z -T 60 -R /usr/sbin/quagga
335 ubnt 1560 S /sbin/ucarp --interface=br0 --srcip=192.168.1.20 --vh
338 ubnt 1976 S init
339 ubnt 1984 R /bin/infctld -m -c
340 ubnt 5016 S /bin/lighttpd -D -f /etc/lighttpd.conf
341 ubnt 1936 S /bin/dropbear -F -d /etc/persistent/dropbear_dss_host
354 ubnt 1992 S /bin/dropbear -F -d /etc/persistent/dropbear_dss_host
355 ubnt 1980 S -sh
358 ubnt 1992 R /bin/dropbear -F -d /etc/persistent/dropbear_dss_host
359 ubnt 1992 S -sh
368 ubnt 1976 R ps
VRRP: Nope, that's Cisco patent encumbered and I'll not touch it.
BGP: Nope, the routing table is much too large to fit in memory.
VPN: Nope, VPN belongs at the edges of the network or it's useless.
MPLS: Nope, I don't have the need.
... but CARP and OSPF have just been implemented, it's a 6420 byte download that does everything needed to get a AirOS 5.1 image with UCARP and Quagga:
http://dren.dk/airos-plus.html
There is plenty of RAM free even when running, zebra, ospfd and ucarp, so there really isn't anything silly about having dynamic routing protocols:
XM.v5.1.plus.19137# ls -l /etc/persistent/ucarp.conf
-rw-r--r-- 1 ubnt admin 571 Jan 30 15:18 /etc/persistent/ucarp.conf
XM.v5.1.plus.19137# free
total used free shared buffers
Mem: 30312 20524 9788 0 3072
Swap: 0 0 0
Total: 30312 20524 9788
XM.v5.1.plus.19137# ps
PID USER VSZ STAT COMMAND
1 ubnt 1976 S init
2 ubnt 0 SWN [ksoftirqd/0]
3 ubnt 0 SW [watchdog/0]
4 ubnt 0 SW< [events/0]
5 ubnt 0 SW< [khelper]
6 ubnt 0 SW< [kthread]
7 ubnt 0 SW< [kblockd/0]
8 ubnt 0 SW< [khubd]
9 ubnt 0 SW [pdflush]
10 ubnt 0 SW [pdflush]
12 ubnt 0 SW< [aio/0]
11 ubnt 0 SW [kswapd0]
13 ubnt 0 SW [mtdblockd]
14 ubnt 0 SW [pktgen/0]
200 ubnt 1132 S /sbin/hotplug2 --persistent --set-rules-file /usr/etc
203 ubnt 1968 S < /bin/watchdog -t 1 /dev/watchdog
308 ubnt 2704 S /usr/sbin/zebra -d
315 ubnt 3312 S /usr/sbin/ospfd -d
322 ubnt 2320 S /usr/sbin/watchquagga -d -z -T 60 -R /usr/sbin/quagga
335 ubnt 1560 S /sbin/ucarp --interface=br0 --srcip=192.168.1.20 --vh
338 ubnt 1976 S init
339 ubnt 1984 R /bin/infctld -m -c
340 ubnt 5016 S /bin/lighttpd -D -f /etc/lighttpd.conf
341 ubnt 1936 S /bin/dropbear -F -d /etc/persistent/dropbear_dss_host
354 ubnt 1992 S /bin/dropbear -F -d /etc/persistent/dropbear_dss_host
355 ubnt 1980 S -sh
358 ubnt 1992 R /bin/dropbear -F -d /etc/persistent/dropbear_dss_host
359 ubnt 1992 S -sh
368 ubnt 1976 R ps
gunther_01
01-30-2010, 02:57 PM
Some people route, Others use Vlans. It's just wasted market share that some people may choose a different product that does have dynamic routing available.
I am personally not looking forward to having to include additional equipment to deploy new UBNT gear on my network. But lifes a "B" sometimes. BUT, what a wonderful thing to have a truly routed network and pass on "Public subnets" to customers without a bunch of tags and stuff to worry about. Just add the subnet at the end, and Waalah!!
I am personally not looking forward to having to include additional equipment to deploy new UBNT gear on my network. But lifes a "B" sometimes. BUT, what a wonderful thing to have a truly routed network and pass on "Public subnets" to customers without a bunch of tags and stuff to worry about. Just add the subnet at the end, and Waalah!!
FlemmingFrandsen
01-30-2010, 03:20 PM
Agreed, I've always been quite leery of the reduced MTU with PPOE and the complete lack of debugability with bridging. I've done my entire network with routing at every unit, but with all static routes until now, with any luck I can move to a completely OSPF and redundant backbone soon.
doush
02-04-2010, 02:49 PM
Isnt it possible for you to run OSPF on the routers where you auth your users ?
bluestu
02-04-2010, 03:01 PM
What a lot of pretend / bedroom WISPS think is that OSPF can be run on a router behind the radios. These tend to be the people who dont understand OSPF or dynamic routing. If you wish to run OSPF for redundancy or any type of real application then it must be run on the AP. This is because if you run a site with multiple sectors you need to route traffic only to a specific sector. We run a seperate /27 on each sector. Layer 2 / ARP becomes problematic with large networks, especially over multiple wireless links.
I belive OSPF will be coming to Ubiquiti gear soon, I raised this in another post last week.
I belive OSPF will be coming to Ubiquiti gear soon, I raised this in another post last week.
bluestu
02-04-2010, 03:06 PM
Also one final point is that link state detection will not work unless OSPF is running on the radio i.e. how does a router know if the WLAN is up or not?
Need to be on the AP.
s
Need to be on the AP.
s
FlemmingFrandsen
02-05-2010, 01:33 AM
I agree completely, OSPF needs to be on every router in the network or it's of limited utility.
Take a look at my new network topology, this is what I'm going to roll out this summer:
http://dren.dk/net3.png
Every router except my edge-router (called edgy) is a ubnt router, the redundant links at the bottom are done with Bullet 5M, the one closet to the edge is 5 km the other is 800 m.
Each cloud has 5-10 CPEs (NS5, NS5L and B5) in them, there's currently 60 members in the network in total.
Every single router (except edgy) is automatically firmware upgraded and configured from factory-fresh to production-ready by my scripts in 2 minutes, so if any part of the network fails I can replace it very quickly.
The old AirOS 3.x APs will start out using a default GW provided by the two uplink-bullets with failover provided by CARP.
In time I'll replace all the APs with NS 5M and those will then stop using the CARP'ed default gw and use OSPF as well.
The big advantages of OSPF on the APs over letting them use a static, but CARP'ed gw is:
1) Routing is easier to maintain with fewer static routes to worry about.
2) The APs will be able to use multi-path and balance the load over the different uplinks.
Take a look at my new network topology, this is what I'm going to roll out this summer:
http://dren.dk/net3.png
Every router except my edge-router (called edgy) is a ubnt router, the redundant links at the bottom are done with Bullet 5M, the one closet to the edge is 5 km the other is 800 m.
Each cloud has 5-10 CPEs (NS5, NS5L and B5) in them, there's currently 60 members in the network in total.
Every single router (except edgy) is automatically firmware upgraded and configured from factory-fresh to production-ready by my scripts in 2 minutes, so if any part of the network fails I can replace it very quickly.
The old AirOS 3.x APs will start out using a default GW provided by the two uplink-bullets with failover provided by CARP.
In time I'll replace all the APs with NS 5M and those will then stop using the CARP'ed default gw and use OSPF as well.
The big advantages of OSPF on the APs over letting them use a static, but CARP'ed gw is:
1) Routing is easier to maintain with fewer static routes to worry about.
2) The APs will be able to use multi-path and balance the load over the different uplinks.
drwho17
02-05-2010, 09:17 AM
Why not just use PPPoE on the client radios? I can't see how I would utilize OSPF other then for AP management, or some sort of redundancy/load balancing (but I wouldn't run it on the radios for this). What benefits would it bring me to run OSPF with PPPoE clients without the PPPoE clients being terminated on the OSPF AP's, which I don't believe is what Ubiquity is talking about (IP Pool per AP).
Shouldn't PPPoE be used if you are shooting for carrier class service, so you can absolve yourself from routing/policing/terminating on the AP's themselves?
Shouldn't PPPoE be used if you are shooting for carrier class service, so you can absolve yourself from routing/policing/terminating on the AP's themselves?
drwho17
02-05-2010, 09:22 AM
Also one final point is that link state detection will not work unless OSPF is running on the radio i.e. how does a router know if the WLAN is up or not?
Need to be on the AP.
s
I think this would typically be done at least on a Cisco by defining the ports as a MLPPP bundle or as an Etherchannel, both of which will transparently remove the dead link, without the actually ethernet port being down on the Cisco.
Need to be on the AP.
s
I think this would typically be done at least on a Cisco by defining the ports as a MLPPP bundle or as an Etherchannel, both of which will transparently remove the dead link, without the actually ethernet port being down on the Cisco.
Scott@Wisp-Router
02-05-2010, 10:02 AM
What a lot of pretend / bedroom WISPS think is that OSPF can be run on a router behind the radios. These tend to be the people who dont understand OSPF or dynamic routing. If you wish to run OSPF for redundancy or any type of real application then it must be run on the AP. This is because if you run a site with multiple sectors you need to route traffic only to a specific sector. We run a seperate /27 on each sector. Layer 2 / ARP becomes problematic with large networks, especially over multiple wireless links.
I belive OSPF will be coming to Ubiquiti gear soon, I raised this in another post last week.
Currently, we have been recommending that our customers have a router at the bottom of their tower that plugs directly into the Ubiquiti PoE on each end. As far as the routers on each end are concerned there's only a long ethernet cable between them. At that point you can do your routing as you need to. That will accomplish everything you could do with OSPF on the router itself.
Personally, I actually like it this way. Keep the radios focused on doing what their good at and the routers focused on doing what they're good at. The fewer non-wireless features they have to worry about implementing and keeping current, the more stable the firmware will be. Just my personal view.
I belive OSPF will be coming to Ubiquiti gear soon, I raised this in another post last week.
Currently, we have been recommending that our customers have a router at the bottom of their tower that plugs directly into the Ubiquiti PoE on each end. As far as the routers on each end are concerned there's only a long ethernet cable between them. At that point you can do your routing as you need to. That will accomplish everything you could do with OSPF on the router itself.
Personally, I actually like it this way. Keep the radios focused on doing what their good at and the routers focused on doing what they're good at. The fewer non-wireless features they have to worry about implementing and keeping current, the more stable the firmware will be. Just my personal view.
rebel2234
02-05-2010, 12:30 PM
Why I think OSPF is needed:
Backhaul, Backhaul, and Backhaul. To me it's just silly to need to put in a OSPF speaking router for your backhaul to hook ubnt gear to (adding more failure points, more power draw (solar)). We have repeater sites that are strictly 5.8 and remote and solar (two boxes better than 3). The gear has got the ability! Why not? For those that don't want it just disable it and use it as you normally would with a 3rd party router. For Client Acess Points, bridge to a Mikrotik box and jazz it up how ever you feel.
Backhaul, Backhaul, and Backhaul. To me it's just silly to need to put in a OSPF speaking router for your backhaul to hook ubnt gear to (adding more failure points, more power draw (solar)). We have repeater sites that are strictly 5.8 and remote and solar (two boxes better than 3). The gear has got the ability! Why not? For those that don't want it just disable it and use it as you normally would with a 3rd party router. For Client Acess Points, bridge to a Mikrotik box and jazz it up how ever you feel.
FlemmingFrandsen
02-05-2010, 01:12 PM
PPPoE is a nasty hack that makes the network harder to debug and it messes with the MTU too so some gear will not be able to figure out pmtu correctly.
The reason I like OSPF on the UBNT routers is that I need OSPF to get fault tolerance, adding extra routers that can fail and take down the entire network would defeat the purpose.
My reasoning goes something like this:
Fewer complex parts (routers) => more reliability.
Simpler centralized parts (switches) => more reliability.
As the UBNT routers already need to be in the mix, even if they are only acting as bridges, those can't be eliminated.
Quagga (and UCARP for that matter) are both relatively light processes, there is almost no CPU usage and very little RAM usage as well (with UCARP and Quagga running OSPF there's still 8 MB free RAM), complaining about resource usage in this regard is a bit misinformed.
There is a point in wanting the UBNT units to be simple to set up and manage, who wouldn't want that?
Well, I have provisioning scripts that configure my AirOS backbone routers, APs and CPEs, with UCARP and Quagga, the scripts do *everything*, even upgrading the firmware if needed, that's needed to get a unit from factory-fresh to production-ready, all I need to do is swap cables when the script finishes.
In my case using only AirOS routers for just about everything means that I can re-use my scripts for every kind of router.
There is nothing inherently stupid or limited about the UBNT routers, they are full Linux machines that can do everything you could possibly want to do with network traffic.
The reason I like OSPF on the UBNT routers is that I need OSPF to get fault tolerance, adding extra routers that can fail and take down the entire network would defeat the purpose.
My reasoning goes something like this:
Fewer complex parts (routers) => more reliability.
Simpler centralized parts (switches) => more reliability.
As the UBNT routers already need to be in the mix, even if they are only acting as bridges, those can't be eliminated.
Quagga (and UCARP for that matter) are both relatively light processes, there is almost no CPU usage and very little RAM usage as well (with UCARP and Quagga running OSPF there's still 8 MB free RAM), complaining about resource usage in this regard is a bit misinformed.
There is a point in wanting the UBNT units to be simple to set up and manage, who wouldn't want that?
Well, I have provisioning scripts that configure my AirOS backbone routers, APs and CPEs, with UCARP and Quagga, the scripts do *everything*, even upgrading the firmware if needed, that's needed to get a unit from factory-fresh to production-ready, all I need to do is swap cables when the script finishes.
In my case using only AirOS routers for just about everything means that I can re-use my scripts for every kind of router.
There is nothing inherently stupid or limited about the UBNT routers, they are full Linux machines that can do everything you could possibly want to do with network traffic.
Scott@Wisp-Router
02-05-2010, 01:36 PM
The reason I like OSPF on the UBNT routers is that I need OSPF to get fault tolerance, adding extra routers that can fail and take down the entire network would defeat the purpose.
You still have to have a switch there, right? That's a single point of failure. In fact, by putting 2 routers at the bottom of the tower and having an interconnect between them, you could actually get better redundancy than you have now. Designed correctly dividing out the router and the Ubiquiti units can actually mean better protection, not worse. It just depends on how you design it and what your needs really are. Neither option is explicitly wrong.
My biggest concern is that by adding a new feature like this to the Ubiquiti firmware, they could potentially open themselves up to new avenues for the firmwares to potentially have bugs or stability issues. For the people that have the needs of these features they can always add them behind the scenes, as you pointed out in your message. So why open themselves up to extra maintenance issues when the problem has already been solved by the few people that have the need for it?
BTW, when you're actually routing with the Ubiquiti units, how much total throughput can you get? Do you see any bandwidth reductions when pushing the limits of the link?
Scott
**edited: changed a right to a wrong to clear up meaning**
You still have to have a switch there, right? That's a single point of failure. In fact, by putting 2 routers at the bottom of the tower and having an interconnect between them, you could actually get better redundancy than you have now. Designed correctly dividing out the router and the Ubiquiti units can actually mean better protection, not worse. It just depends on how you design it and what your needs really are. Neither option is explicitly wrong.
My biggest concern is that by adding a new feature like this to the Ubiquiti firmware, they could potentially open themselves up to new avenues for the firmwares to potentially have bugs or stability issues. For the people that have the needs of these features they can always add them behind the scenes, as you pointed out in your message. So why open themselves up to extra maintenance issues when the problem has already been solved by the few people that have the need for it?
BTW, when you're actually routing with the Ubiquiti units, how much total throughput can you get? Do you see any bandwidth reductions when pushing the limits of the link?
Scott
**edited: changed a right to a wrong to clear up meaning**
UBNT-Mike.Ford
02-05-2010, 01:46 PM
Guys,
On this subject, my feelings are right in line with Scott from WISP. However, we are still keeping this on our roadmap.
Thanks,
Mike
On this subject, my feelings are right in line with Scott from WISP. However, we are still keeping this on our roadmap.
Thanks,
Mike
FlemmingFrandsen
02-05-2010, 02:17 PM
You are right about the switch being a SPOF, but I have only ever seen a switch fail once and when the switches are dumb they are very easy to replace.
I've thought about the switch failure problem before and I'm not terribly worried about it, but with STP (available on $15 switches we use) it's possible to have full redundancy (a dead switch only takes down one bullet).
Quagga is not updated very often, so it would certainly not be a huge burden for UBNT to turn it on in their firmware builds.
Wrt. performance there is zero difference in the work that the kernel needs to do for a packet in bridging and routing mode, one is looking up a mac address in the arp table, the other is looking up an IP in the routing table, both operations are highly optimized and perform about the same.
I've not done any benchmarking on the M units yet, but the old pre-M performed as expected when routing and there's no reason to think the Ms are any different. Here's a paper that talks a bit about routing vs. switch performance in Linux: http://facweb.cti.depaul.edu/jyu/Publications/Yu-Linux-TSM2004.pdf
It's a mistake to think that bridging is simpler than routing, it only looks simpler, the work being done by the hardware and the kernel is pretty much the same, but without the guidance from routing debugging and management becomes harder.
Bottom line is that I already have the UBNT machines, so it's a waste of money to add extra boxes just to do routing, the fact that it adds more complexity and that it lowers reliability is a detail.
I've thought about the switch failure problem before and I'm not terribly worried about it, but with STP (available on $15 switches we use) it's possible to have full redundancy (a dead switch only takes down one bullet).
Quagga is not updated very often, so it would certainly not be a huge burden for UBNT to turn it on in their firmware builds.
Wrt. performance there is zero difference in the work that the kernel needs to do for a packet in bridging and routing mode, one is looking up a mac address in the arp table, the other is looking up an IP in the routing table, both operations are highly optimized and perform about the same.
I've not done any benchmarking on the M units yet, but the old pre-M performed as expected when routing and there's no reason to think the Ms are any different. Here's a paper that talks a bit about routing vs. switch performance in Linux: http://facweb.cti.depaul.edu/jyu/Publications/Yu-Linux-TSM2004.pdf
It's a mistake to think that bridging is simpler than routing, it only looks simpler, the work being done by the hardware and the kernel is pretty much the same, but without the guidance from routing debugging and management becomes harder.
Bottom line is that I already have the UBNT machines, so it's a waste of money to add extra boxes just to do routing, the fact that it adds more complexity and that it lowers reliability is a detail.
drwho17
02-05-2010, 03:55 PM
Sorry, I have 10,000 customers (mostly wireline), PPPoE works fine whether it is a "hack" or not. It works perfectly for wireless as well, as it stops broadcast traffic on the WLAN between clients, allows the AP's to function a simple bridges, allows me to control speed through radius attributes, and all the IP routing is handled on my Redbacks. Really PMTU? That's been a non-issue for several years, if there is a PMTU problem it's because your network is misconfigured or a website you are visiting is misconfigured at which point millions of pppoe using DSL users will all have the same issue and it will be fixed quickly.
FlemmingFrandsen
02-06-2010, 10:27 AM
Well, I didn't say there weren't any advantages in pppoe, I just said I didn't like it, I prefer to have just one protocol to debug in stead of a some matroska-like stack of mpls, vpn, pppoe and what have you.
I guess I could be forced to change my mind if I had 10k customers, but for now I'd rather avoid pppoe.
... but that's really not that relavant to the whole dynamic routing issue.
I guess I could be forced to change my mind if I had 10k customers, but for now I'd rather avoid pppoe.
... but that's really not that relavant to the whole dynamic routing issue.
sxpert
02-06-2010, 10:34 AM
I do have a firmware compiled with the sdk with quagga, ipv6, ospf, the whole thing...
-rw-r--r-- 1 sxpert sxpert 7442514 Feb 6 18:17 XM.v5.1.sdk.3635.100206.1817.bin
the only sad part, is that the kernel appears to be 2.6.15... when kernel.org lists 2.6.32...
-rw-r--r-- 1 sxpert sxpert 7442514 Feb 6 18:17 XM.v5.1.sdk.3635.100206.1817.bin
the only sad part, is that the kernel appears to be 2.6.15... when kernel.org lists 2.6.32...
doush
02-06-2010, 10:48 AM
if your claims hold;
there wont be any proper wireless network design in the world apart from those who use Mikrotik.
Im not counting Motorolas, Alvarions and bunch others that are producing only pure radios, not a router.
there wont be any proper wireless network design in the world apart from those who use Mikrotik.
Im not counting Motorolas, Alvarions and bunch others that are producing only pure radios, not a router.
sxpert
02-06-2010, 11:00 AM
there, here's the link ;)
http://atria.bluenetech.com/icons/XM.v5.1.sdk.3635.100206.1817.bin
sha1sum:
f8bde43322ca27d8c8d75e7a63bde7fd909afff2 XM.v5.1.sdk.3635.100206.1817.bin
thanks for reporting how it works
http://atria.bluenetech.com/icons/XM.v5.1.sdk.3635.100206.1817.bin
sha1sum:
f8bde43322ca27d8c8d75e7a63bde7fd909afff2 XM.v5.1.sdk.3635.100206.1817.bin
thanks for reporting how it works
bluestu
02-06-2010, 04:18 PM
Any network that isn't simply reselling a DSL connection will require OSPF. It's simple, when your routing subnets arround to different sectors, you need a dynamic routing protocol. We use BGP as our anterior protocol and at present have to static route on our UBNT gear. With OSPF link state detection will reroute traffic when a link dies.
At the moment traffic traveling between subnets has to travel back to our core router. This wastes bandwidth. Traffic should go from point A to poin B as quickly and efficiently as possible hence OSPF ses the shortest path between two routes. Static routes quickly become troublesome when you have more than a few customers, AP's and backhauls.
Anyway Ubiquiti has already said OSPF is coming. Good decision on their part.
At the moment traffic traveling between subnets has to travel back to our core router. This wastes bandwidth. Traffic should go from point A to poin B as quickly and efficiently as possible hence OSPF ses the shortest path between two routes. Static routes quickly become troublesome when you have more than a few customers, AP's and backhauls.
Anyway Ubiquiti has already said OSPF is coming. Good decision on their part.
drwho17
02-06-2010, 07:27 PM
Any network that isn't simply reselling a DSL connection will require OSPF. It's simple, when your routing subnets arround to different sectors, you need a dynamic routing protocol. We use BGP as our anterior protocol and at present have to static route on our UBNT gear. With OSPF link state detection will reroute traffic when a link dies.
At the moment traffic traveling between subnets has to travel back to our core router. This wastes bandwidth. Traffic should go from point A to poin B as quickly and efficiently as possible hence OSPF ses the shortest path between two routes. Static routes quickly become troublesome when you have more than a few customers, AP's and backhauls.
Anyway Ubiquiti has already said OSPF is coming. Good decision on their part.
Yes, but then you have to allocate subnets to each access point and rely on them to handle ip management for your customers, been there done that, in the early days of dialup with an access server in each pop 10 years ago (until we got our CLEC and could bring all the numbers into a centralized access server).
Centralized IP management and authentication is the way to go for scaling up/supporting a large network. I have suggested an l2tp tunneling option for the Ubiquities that would be pretty nice, but PPPoE serves the same purposes (with the added ability to turn up/down/provision customers centrally and in an automated manner, without needed to ever touch the AP).
You are correct about the customers having to go to a core router, and it is possible if customers are communicating directly with each other for this to "waste bandwidth", but in our experience this rarely happens.
Anyways I've gained an understanding why you want it, as it was necessary for us in our early days as well when we were using a similar model for dialup.
At the moment traffic traveling between subnets has to travel back to our core router. This wastes bandwidth. Traffic should go from point A to poin B as quickly and efficiently as possible hence OSPF ses the shortest path between two routes. Static routes quickly become troublesome when you have more than a few customers, AP's and backhauls.
Anyway Ubiquiti has already said OSPF is coming. Good decision on their part.
Yes, but then you have to allocate subnets to each access point and rely on them to handle ip management for your customers, been there done that, in the early days of dialup with an access server in each pop 10 years ago (until we got our CLEC and could bring all the numbers into a centralized access server).
Centralized IP management and authentication is the way to go for scaling up/supporting a large network. I have suggested an l2tp tunneling option for the Ubiquities that would be pretty nice, but PPPoE serves the same purposes (with the added ability to turn up/down/provision customers centrally and in an automated manner, without needed to ever touch the AP).
You are correct about the customers having to go to a core router, and it is possible if customers are communicating directly with each other for this to "waste bandwidth", but in our experience this rarely happens.
Anyways I've gained an understanding why you want it, as it was necessary for us in our early days as well when we were using a similar model for dialup.
mgibbons
02-07-2010, 04:59 AM
Yes, but then you have to allocate subnets to each access point and rely on them to handle ip management for your customers, been there done that, in the early days of dialup with an access server in each pop 10 years ago (until we got our CLEC and could bring all the numbers into a centralized access server).
Centralized IP management and authentication is the way to go for scaling up/supporting a large network. I have suggested an l2tp tunneling option for the Ubiquities that would be pretty nice, but PPPoE serves the same purposes (with the added ability to turn up/down/provision customers centrally and in an automated manner, without needed to ever touch the AP).
You are correct about the customers having to go to a core router, and it is possible if customers are communicating directly with each other for this to "waste bandwidth", but in our experience this rarely happens.
Anyways I've gained an understanding why you want it, as it was necessary for us in our early days as well when we were using a similar model for dialup.
Interesting discussion - we are half way between the two positions. We used to be very much individual subnets but have moved to a flatter backbone model now that the equipment is much more stable. However how do you get around broken links and create link redundancy when you do not have dynamic routing?
Centralized IP management and authentication is the way to go for scaling up/supporting a large network. I have suggested an l2tp tunneling option for the Ubiquities that would be pretty nice, but PPPoE serves the same purposes (with the added ability to turn up/down/provision customers centrally and in an automated manner, without needed to ever touch the AP).
You are correct about the customers having to go to a core router, and it is possible if customers are communicating directly with each other for this to "waste bandwidth", but in our experience this rarely happens.
Anyways I've gained an understanding why you want it, as it was necessary for us in our early days as well when we were using a similar model for dialup.
Interesting discussion - we are half way between the two positions. We used to be very much individual subnets but have moved to a flatter backbone model now that the equipment is much more stable. However how do you get around broken links and create link redundancy when you do not have dynamic routing?
netmaster
02-08-2010, 12:43 AM
You are correct about the customers having to go to a core router, and it is possible if customers are communicating directly with each other for this to "waste bandwidth", but in our experience this rarely happens.
believe me, once they realize, this is possible, they will use it, and you cant do almost anything about that.
we also hanging here between two networking models (pppoe vs. routed). Still mostly using one routed /26 bit subnet per AP and customers with NATted CPE's and hardcoded external IP's.
in my opinion, pppoe having only one advantage - user management will be easier, but everything else is harder to do, especially fault tracking etc. PPPoE on "low density" wireless network, with countless wireless hops between sites, will result a huge bridged net, where all problems will get very quickly out of hands and diagnosing something is nearly impossible.
Anyway, I'am not sure, OSPF should be integrated into CPE's or not. Probably not, because simpler wireless device is more reliable, and routers will do OSPF better.
believe me, once they realize, this is possible, they will use it, and you cant do almost anything about that.
we also hanging here between two networking models (pppoe vs. routed). Still mostly using one routed /26 bit subnet per AP and customers with NATted CPE's and hardcoded external IP's.
in my opinion, pppoe having only one advantage - user management will be easier, but everything else is harder to do, especially fault tracking etc. PPPoE on "low density" wireless network, with countless wireless hops between sites, will result a huge bridged net, where all problems will get very quickly out of hands and diagnosing something is nearly impossible.
Anyway, I'am not sure, OSPF should be integrated into CPE's or not. Probably not, because simpler wireless device is more reliable, and routers will do OSPF better.
FlemmingFrandsen
02-08-2010, 03:15 AM
WRT OSPF in the CPEs: I'm pretty sure it's a bad idea as that would make it possible for a bad customer to inject all sorts of routes into the network if he sets his mind to it.
Imagine a user who starts advertizing a low-cost route to a local netbanks IP, the phishing and MITM attacks are limitless and very hard to track after the fact.
I keep OSPF on the wired side of my APs and run rfc1918 on the entire internal network, my edge router does NAT and DNAT so that every customer gets his rfc1918 /24 NATted to one real IP and the same IP is DNATed to his .1 address which is not handed out by the DHCP server on the CPE.
Both my APs and my CPEs are routers, so that takes care of all those chatty windows boxes that want to broadcast a lot. Each CPE has a 2 Mb/s transmit limit so the customer doesn't get to flood the channel he's on.
My edge router also does traffic shaping so each /24 (ie. each customer) on the rfc1918 network gets an equal share of both up and downstream on a per-package-round-robin basis, so far this has been close to perfectly fair (within a few percent of the available bandwidth).
I'm quite impressed by the hardware and software quality of the UBNT gear, even after a year of service I have yet to see a UBNT unit hang or otherwise fail in the field.
Imagine a user who starts advertizing a low-cost route to a local netbanks IP, the phishing and MITM attacks are limitless and very hard to track after the fact.
I keep OSPF on the wired side of my APs and run rfc1918 on the entire internal network, my edge router does NAT and DNAT so that every customer gets his rfc1918 /24 NATted to one real IP and the same IP is DNATed to his .1 address which is not handed out by the DHCP server on the CPE.
Both my APs and my CPEs are routers, so that takes care of all those chatty windows boxes that want to broadcast a lot. Each CPE has a 2 Mb/s transmit limit so the customer doesn't get to flood the channel he's on.
My edge router also does traffic shaping so each /24 (ie. each customer) on the rfc1918 network gets an equal share of both up and downstream on a per-package-round-robin basis, so far this has been close to perfectly fair (within a few percent of the available bandwidth).
I'm quite impressed by the hardware and software quality of the UBNT gear, even after a year of service I have yet to see a UBNT unit hang or otherwise fail in the field.
sxpert
02-08-2010, 03:27 AM
WRT OSPF in the CPEs: I'm pretty sure it's a bad idea as that would make it possible for a bad customer to inject all sorts of routes into the network if he sets his mind to it.
hmm... you let your customers access your CPEs ?
hmm... you let your customers access your CPEs ?
FlemmingFrandsen
02-08-2010, 03:46 AM
One detail that's been nagging at me is that people seem to use "router" as though it's a description of a piece of hardware and that's wrong, "router" like "server", "firewall" and quite often "bridge" is a piece of software, some times it's the most important bit of software running on a box that the box itself gets the same name.
In the context of the UBNT hardware, bridging is just as much a software feature of the Linux kernel as routing is and the work the kernel has to do for each packet is very close to the same for both.
There is no reason to think that the UBNT machines are less good at running OSPF than any other Linux machines with comparable resources, they have plenty of CPU and RAM left over when running Quagga and the Linux kernel is the same anywhere (or same enough it doesn't matter).
The Quagga-enabled firmware, has been rock solid over the past week of gentle testing and when I get the last B5Ms I'm waiting for I'll set up a randomly failing system that will turn routers on and off automatically for a month or more before putting the new backbone into production. I'm fairly confident I'll be able to reach 100% reliability* even with several dead routers and possibly switches at a time.
*) Weasel clause: I'll probably have to accept packet loss for up to 10 seconds when a router fails, but it doesn't happen often enough in real life that this will be a problem.
Depending on how you prefer to manage your network it's perfectly ok to use a separate box for routing (maybe some people like IOS, Junos or routeros, who knows?), but don't for a second think that you are doing it because you can't run the same function on the UBNT hardware and I for one would like it to be easier to use OSPF (and CARP) on AirOS.
In the context of the UBNT hardware, bridging is just as much a software feature of the Linux kernel as routing is and the work the kernel has to do for each packet is very close to the same for both.
There is no reason to think that the UBNT machines are less good at running OSPF than any other Linux machines with comparable resources, they have plenty of CPU and RAM left over when running Quagga and the Linux kernel is the same anywhere (or same enough it doesn't matter).
The Quagga-enabled firmware, has been rock solid over the past week of gentle testing and when I get the last B5Ms I'm waiting for I'll set up a randomly failing system that will turn routers on and off automatically for a month or more before putting the new backbone into production. I'm fairly confident I'll be able to reach 100% reliability* even with several dead routers and possibly switches at a time.
*) Weasel clause: I'll probably have to accept packet loss for up to 10 seconds when a router fails, but it doesn't happen often enough in real life that this will be a problem.
Depending on how you prefer to manage your network it's perfectly ok to use a separate box for routing (maybe some people like IOS, Junos or routeros, who knows?), but don't for a second think that you are doing it because you can't run the same function on the UBNT hardware and I for one would like it to be easier to use OSPF (and CARP) on AirOS.
FlemmingFrandsen
02-08-2010, 03:49 AM
hmm... you let your customers access your CPEs ?
Well, they have physical access to them, so anything is possible with a tftp and jtag:)
In practice I doubt there is a single customer who knows what jtag is, so the boxes should be safe enough, but if one does get compromised the worst that can happen is that they flood their channel or sniff the traffic from other CPEs on the same channel.
If the CPE ran OSPF they could kill the entire network just by originating the default route ;)
Well, they have physical access to them, so anything is possible with a tftp and jtag:)
In practice I doubt there is a single customer who knows what jtag is, so the boxes should be safe enough, but if one does get compromised the worst that can happen is that they flood their channel or sniff the traffic from other CPEs on the same channel.
If the CPE ran OSPF they could kill the entire network just by originating the default route ;)
sxpert
02-08-2010, 06:00 AM
Well, they have physical access to them, so anything is possible with a tftp and jtag:)
In practice I doubt there is a single customer who knows what jtag is, so the boxes should be safe enough, but if one does get compromised the worst that can happen is that they flood their channel or sniff the traffic from other CPEs on the same channel.
If the CPE ran OSPF they could kill the entire network just by originating the default route ;)
true.
my customers don't even want to know what's in the cpe, as long as they can use facebook & you[tube|porn], so I'm pretty safe ;)
In practice I doubt there is a single customer who knows what jtag is, so the boxes should be safe enough, but if one does get compromised the worst that can happen is that they flood their channel or sniff the traffic from other CPEs on the same channel.
If the CPE ran OSPF they could kill the entire network just by originating the default route ;)
true.
my customers don't even want to know what's in the cpe, as long as they can use facebook & you[tube|porn], so I'm pretty safe ;)
FlemmingFrandsen
02-15-2010, 06:19 AM
I have just ported the latest stable version of BIRD to AirOS and enabled multipath routing in the kernel, it's included in the current version of my patch set:
http://dren.dk/airos-plus.html
I need multipath support in my network and BIRD doesn't support it yet, so I've left it disabled in the default build.
I get strange hanging processes when Quagga installs multipath routes, so it looks like the ancient 2.6.15 kernel used by AirOS has a problem wrt. multipath that needs fixing.
I might try to get a more modern kernel to run, but that's deep into serial-console and bricking territory, so I'd rather do with a workaround in stead if I can find one.
http://dren.dk/airos-plus.html
I need multipath support in my network and BIRD doesn't support it yet, so I've left it disabled in the default build.
I get strange hanging processes when Quagga installs multipath routes, so it looks like the ancient 2.6.15 kernel used by AirOS has a problem wrt. multipath that needs fixing.
I might try to get a more modern kernel to run, but that's deep into serial-console and bricking territory, so I'd rather do with a workaround in stead if I can find one.
spiehn
02-15-2010, 08:33 AM
We use OSPF at every tower site (over 30). while OSPF would be nice on the UBNT product eventually.
I would prefer development time to be spent on items that can't be done with another piece of equipment. such as: virtual AP, OSPF passthrough support (2 MT's can pass OSPF on a UBNT bridged link), find and fix bugs on the wireless links, etc
I would prefer development time to be spent on items that can't be done with another piece of equipment. such as: virtual AP, OSPF passthrough support (2 MT's can pass OSPF on a UBNT bridged link), find and fix bugs on the wireless links, etc
FlemmingFrandsen
02-16-2010, 12:19 AM
I'm heading in the opposite direction, I now have a couple of external routers in my network that I'm looking to get rid of ASAP.
I can't disagree with your wish for getting bugs in the core functionality fixed, that has to be the highest possible priority for UBNT, in a way I hope that by doing the OSPF work for UBNT that I can help them to dedicate some time to bugfixing the important stuff.
Untill UBNT gets the time to do a proper job integrating Quagga I'll be happy to maintain the AirOSplus patchset, It's pretty easy to re-tool to a new SDK release, all that UBNT needs to do is to get the SDK out in a timely fashion.
Why would you want virtual AP, though?
I can't disagree with your wish for getting bugs in the core functionality fixed, that has to be the highest possible priority for UBNT, in a way I hope that by doing the OSPF work for UBNT that I can help them to dedicate some time to bugfixing the important stuff.
Untill UBNT gets the time to do a proper job integrating Quagga I'll be happy to maintain the AirOSplus patchset, It's pretty easy to re-tool to a new SDK release, all that UBNT needs to do is to get the SDK out in a timely fashion.
Why would you want virtual AP, though?
TheCowStir
02-19-2010, 11:59 AM
If you have taken a look at IPv6 it is recommended practice to provide your end customer with a subnet, not an address. So yes, some type of dynamic routing protocol will be helpful to have in the mix, so those that decide to start testing/implimenting IPv6 have a viable way to make it happen.
If you want more information on IPv6 and some reall hands on work with it, go to http://tunnelbroker.net/ they will give you upto 5 /64 networks and a /48 network to use and play with. they even have scripts to get you started on a lot of different platforms: cisco, Juniper, Mikrotik, Linux, windows, etc...
When ("if" when some people are asked) IPv6 will/can be a big change for how we ISPs handle addressing.
So I guess I would add, OSPFv3 and IPv6 support please :)
If you want more information on IPv6 and some reall hands on work with it, go to http://tunnelbroker.net/ they will give you upto 5 /64 networks and a /48 network to use and play with. they even have scripts to get you started on a lot of different platforms: cisco, Juniper, Mikrotik, Linux, windows, etc...
When ("if" when some people are asked) IPv6 will/can be a big change for how we ISPs handle addressing.
So I guess I would add, OSPFv3 and IPv6 support please :)
FlemmingFrandsen
02-20-2010, 02:07 AM
Well, both Quagga and BIRD have IPv6 support, I just didn't compile it to save some space, but it's pretty damn easy to put back in.
techacq
03-02-2010, 04:20 PM
Why I think OSPF is needed:
Backhaul, Backhaul, and Backhaul. To me it's just silly to need to put in a OSPF speaking router for your backhaul to hook ubnt gear to (adding more failure points, more power draw (solar)). We have repeater sites that are strictly 5.8 and remote and solar (two boxes better than 3). The gear has got the ability! Why not? For those that don't want it just disable it and use it as you normally would with a 3rd party router. For Client Acess Points, bridge to a Mikrotik box and jazz it up how ever you feel.
Yes, for there are two distinct sets of users in this market -
those building permanently hard-wired solutions for 'brick-and-mortar' markets
and those of us who are running far-flung networks which are constantly being
revised and remapped to suit geographical changes in the deployment.
I found this thread after following up a problem where some of our distant machines
were having their traffic routed all the way out from the ends of the network
(across 55km of swamp/jungle) to the 'Default Gateway' :icon_eek:
and then all the way back to the same site
because of a lack of some sort of OSPF capability.
(And for where we are, the trip is by boat/canoe/helicopter/long treks on foot to get to the hardware,
not to mention the risks we deal with in terms of the local environment.
Wiring in yet another piece of equipment to handle something
the local gear should be able to resolve creates yet another failure point
in a place where access is not a matter of popping into your car
and travelling around the block from your local $tarbucks (http://www.ubnt.com/forum/album.php?u=28152))
Backhaul, Backhaul, and Backhaul. To me it's just silly to need to put in a OSPF speaking router for your backhaul to hook ubnt gear to (adding more failure points, more power draw (solar)). We have repeater sites that are strictly 5.8 and remote and solar (two boxes better than 3). The gear has got the ability! Why not? For those that don't want it just disable it and use it as you normally would with a 3rd party router. For Client Acess Points, bridge to a Mikrotik box and jazz it up how ever you feel.
Yes, for there are two distinct sets of users in this market -
those building permanently hard-wired solutions for 'brick-and-mortar' markets
and those of us who are running far-flung networks which are constantly being
revised and remapped to suit geographical changes in the deployment.
I found this thread after following up a problem where some of our distant machines
were having their traffic routed all the way out from the ends of the network
(across 55km of swamp/jungle) to the 'Default Gateway' :icon_eek:
and then all the way back to the same site
because of a lack of some sort of OSPF capability.
(And for where we are, the trip is by boat/canoe/helicopter/long treks on foot to get to the hardware,
not to mention the risks we deal with in terms of the local environment.
Wiring in yet another piece of equipment to handle something
the local gear should be able to resolve creates yet another failure point
in a place where access is not a matter of popping into your car
and travelling around the block from your local $tarbucks (http://www.ubnt.com/forum/album.php?u=28152))
techacq
03-02-2010, 04:32 PM
...
My biggest concern is that by adding a new feature like this to the Ubiquiti firmware, they could potentially open themselves up to new avenues for the firmwares to potentially have bugs or stability issues. For the people that have the needs of these features they can always add them behind the scenes, as you pointed out in your message. So why open themselves up to extra maintenance issues when the problem has already been solved by the few people that have the need for it?
...
Scott
We would hope that any such solution is wired in as an "Advanced Usage" _option_
to be enabled (or disabled without affecting the rest of the units operational capability).
For those who need it the option would be present to use.:icon_mrgreen:
For those who do not need it, it would just be an untoggled menu option.
My biggest concern is that by adding a new feature like this to the Ubiquiti firmware, they could potentially open themselves up to new avenues for the firmwares to potentially have bugs or stability issues. For the people that have the needs of these features they can always add them behind the scenes, as you pointed out in your message. So why open themselves up to extra maintenance issues when the problem has already been solved by the few people that have the need for it?
...
Scott
We would hope that any such solution is wired in as an "Advanced Usage" _option_
to be enabled (or disabled without affecting the rest of the units operational capability).
For those who need it the option would be present to use.:icon_mrgreen:
For those who do not need it, it would just be an untoggled menu option.
FlemmingFrandsen
03-03-2010, 01:25 AM
We would hope that any such solution is wired in as an "Advanced Usage" _option_
to be enabled (or disabled without affecting the rest of the units operational capability).
For those who need it the option would be present to use.:icon_mrgreen:
For those who do not need it, it would just be an untoggled menu option.
Well, in the case of adding Quagga to speak OSPF it's actually very, very safe, Quagga (and BIRD for that matter) is a simple user space application, if it screws up it can be killed and restarted without affecting anything else and if it's not running at all then nothing sets a unit with Quagga apart from one without.
The only kernel change I did with the plus patchset was to switch on the multipath routing feature, but that really ought to be quite safe and stable, especially if you don't install any multipath routes:)
I'm actually much more worried about the binary-only drivers for wired and wireless, that nobody outside of UBNT can ever help debug, because those run in the kernel, touch every single packet and can't be switched off.
The biggest stability threat against AirOS is that the binary blobs tie us to a 5 year old kernel, that means that we are currently lacking 5 years worth of bug fixing, given the choice I'd rather not run any software that's been unmaintained for several years.
to be enabled (or disabled without affecting the rest of the units operational capability).
For those who need it the option would be present to use.:icon_mrgreen:
For those who do not need it, it would just be an untoggled menu option.
Well, in the case of adding Quagga to speak OSPF it's actually very, very safe, Quagga (and BIRD for that matter) is a simple user space application, if it screws up it can be killed and restarted without affecting anything else and if it's not running at all then nothing sets a unit with Quagga apart from one without.
The only kernel change I did with the plus patchset was to switch on the multipath routing feature, but that really ought to be quite safe and stable, especially if you don't install any multipath routes:)
I'm actually much more worried about the binary-only drivers for wired and wireless, that nobody outside of UBNT can ever help debug, because those run in the kernel, touch every single packet and can't be switched off.
The biggest stability threat against AirOS is that the binary blobs tie us to a 5 year old kernel, that means that we are currently lacking 5 years worth of bug fixing, given the choice I'd rather not run any software that's been unmaintained for several years.
Thanks to vBET 3.5.4 enjoy automatic translations