*** Official Ubiquiti Discussion Thread ***

Apologies if this has been bought up before (long thread is long) but has anyone here tried using a ERLite-3 with a Draytek 130 with PPPoE? I spent most of yesterday afternoon faffing tried offloading everything I could think of to HW via CLI, but still get reduced internet speed through the router.
I'm synching at 80 Mbps on the modem and can confirm that full speed for my line is achievable (connected directly to the modem and tested) but as soon as the ER is attached it seems to cap out at 45 Mbps.

From what I've read, the PPPoE functionality in general with ubnt kit seems a bit lacklustre, but thought I'd see if anyone else has encountered and overcome this issue. ISP is Vodafone Business btw.
 
Apologies if this has been bought up before (long thread is long) but has anyone here tried using a ERLite-3 with a Draytek 130 with PPPoE? I spent most of yesterday afternoon faffing tried offloading everything I could think of to HW via CLI, but still get reduced internet speed through the router.
I'm synching at 80 Mbps on the modem and can confirm that full speed for my line is achievable (connected directly to the modem and tested) but as soon as the ER is attached it seems to cap out at 45 Mbps.

From what I've read, the PPPoE functionality in general with ubnt kit seems a bit lacklustre, but thought I'd see if anyone else has encountered and overcome this issue. ISP is Vodafone Business btw.

Seems odd. The ERL3 is good for 1Gbit throughout with NAT/Firewalling only (No IDS, Packet Inspection etc).

You are not bonding 2 ethernet ports onto LAN1 are you? The ERL3 wont do hardware switching between two physical LAN ports and does it in software. You really want a 1WAN 1LAN config.

What is your WAN port MTU set to, not getting fragmentation are you?

A fresh ERL3 setup with a 1WAN 1LAN Wizard configuration should easily handle 80mbps.
 
Last edited:
Has anyone seen the alta labs stuff? Getting some reasonable press and looks very ubiquiti like.

I went to a distributor presentation in Suffolk. It looks to be good gear and the pricing is excellent. The challenge is that to be a truly disruptive entrant into the market you have to have something the others don’t and that’s the only place this falls over. Installers will install it because you can literally make £50 per access point. Ubiquiti have basically destroyed the installers margin on equipment. If I order £10K worth of Ubiquiti gear I basically pay the same price as someone buying £100 worth. And I still have to do the warranty support and carry stock of replacement parts. That doesn’t work because I can’t make a profit on it.

If Alta Labs can stay in the marketplace long enough to build a brand they will succeed because there is money in it. I love UniFi but they’re making it harder all the time.
 
Last edited:
Ubiquiti would be improved overnight if they just added a cloud redirector that will take care of giving APs and switches the inform URLs to use, so you can ship stuff out without having to prestage it first, and so that it can survive someone smashing the reset button on the side. The people who make VoIP phones have been doing this for decades, steal their idea.
 
Last edited:
Ubiquiti would be improved overnight if they just added a cloud redirector that will take care of giving APs and switches the inform URLs to use, so you can ship stuff out without having to prestage it first, and so that it can survive someone smashing the reset button on the side. The people who make VoIP phones have been doing this for decades, steal their idea.

I‘m a bit confused as to what you‘re suggesting.

We don’t pre-stage anything. We either have a warm-swap device locally that the customer can swap out or we just ship a brand new unit that the customer installs and we join the controller and adopt and, if necessary, configure, the new component remotely.

That option won’t survive someone hitting the reset button but even if they do we just have to readopt the reset device. Unless the customer resets the Cloud Key in which case we’re stuffed and a site visit is required.
 
We don’t pre-stage anything. We either have a warm-swap device locally that the customer can swap out or we just ship a brand new unit that the customer installs and we join the controller and adopt and, if necessary, configure, the new component remotely.

That option won’t survive someone hitting the reset button but even if they do we just have to readopt the reset device. Unless the customer resets the Cloud Key in which case we’re stuffed and a site visit is required.

Where's the controller, in the same local site as this new device I guess?

What @Caged is suggesting is a way to pre-stage the controller URL in instances where you're doing layer 3 adoption. I'm very much in favour of, it'd be a very nice time saver.
 
Where's the controller, in the same local site as this new device I guess?

What @Caged is suggesting is a way to pre-stage the controller URL in instances where you're doing layer 3 adoption. I'm very much in favour of, it'd be a very nice time saver.

Yes, we always install a local controller. I can see what you’re suggesting and I don’t really see how UBNT could implement that given how they run the controller software at the moment. That might have to change with the UCK Enterprise though.
 
Yes, we always install a local controller. I can see what you’re suggesting and I don’t really see how UBNT could implement that given how they run the controller software at the moment. That might have to change with the UCK Enterprise though.

They could change it by doing what VoIP phone vendors do. When you buy hardware you add it's device ID (usually MAC address) into their portal or if you buy directly from the vendor they'll do that bit automatically. You then go to that portal and either upload a config file or enter the relevant bits. Save.

When a new phone boots without config it'll connect to a server out on the internet and retrieve it's settings. So zero touch config on the device itself. Ubiquiti could do that sort of thing and whilst the device could still be factory reset via the reset button the newly reset device would then connect back to that server and retrieve it's settings.
 
They could change it by doing what VoIP phone vendors do. When you buy hardware you add it's device ID (usually MAC address) into their portal or if you buy directly from the vendor they'll do that bit automatically. You then go to that portal and either upload a config file or enter the relevant bits. Save.

When a new phone boots without config it'll connect to a server out on the internet and retrieve it's settings. So zero touch config on the device itself. Ubiquiti could do that sort of thing and whilst the device could still be factory reset via the reset button the newly reset device would then connect back to that server and retrieve it's settings.


Nothing to add here other than @the-evaluator has the correct idea of what I was getting at

My ’friend’ in Kraków reckons that would be very difficult given the way the controller is currently designed. Have you suggested it as a feature request? They do actually look at the feature requests and if it’s something enough people want they will give it a shot.
 
My ’friend’ in Kraków reckons that would be very difficult given the way the controller is currently designed. Have you suggested it as a feature request? They do actually look at the feature requests and if it’s something enough people want they will give it a shot.

I haven't suggested it, but I think I might.
 
Ubiquiti would be improved overnight if they just added a cloud redirector that will take care of giving APs and switches the inform URLs to use, so you can ship stuff out without having to prestage it first, and so that it can survive someone smashing the reset button on the side. The people who make VoIP phones have been doing this for decades, steal their idea.
DHCP option 43 and point to anything you want.
Redirect not needed.
 
I'm aware that DHCP is an option, it's not always available. I'd just like their APs/switches to do (in order):
  • Look for local controller using whatever that method is
  • Look for DHCP saying where the controller is
  • Look up unifi in DNS for the controller location
  • Reach out to redirect.ui.com or whatever, supply the MAC address and serial number of the hardware, get the inform URL in response, go and talk to this controller and wait to be adopted. There's no reason this can't be a really lightweight serverless app that costs next to nothing to run - Poly, Yealink, Snom etc. don't charge for their equivalents.
And how would it pass the information it received to the controller? Sorry if I’m being dim but I can’t see the mechanism by which the switch or access point gets adopted to the controller.

It's a layer 3 adoption, the AP or whatever would just sit waiting to be adopted, the same as if you SSHd into it and did the set-inform thing.
 
Last edited:
Back
Top Bottom