Piece of crap Vigor 2830!

[tony sayer]

Very odd that one, never seen the ones we've got doing that!. Not just a duff unit perhaps?..

Is this just a fault or poor firmware or your asking to it do more than its capable of?...

[Tim Watts]

Draytek did get back and explain that the firmware I found to work was more suited for poor quality DSL lines. Which is weird as I can pull

16,5Mbit/sec down mine!

No, I don't think so.

If it says it can run DHCP servers on 1 or more VLANs, AND VLANs may be presented native or tagged at the ports, then it should be able to run multiple DHCP servers over tagged VLANs. It cannot. It gets confused and the DHCP service either:

a) Does not answer DHCP queries for LAN2/3/4 OR it answers AS IF the query was from LAN1 (that depends on which firmware - I tried several under Draytek's direction. They agreed there was a bug but could not solve it.)

b) If you are going to have multi subnet support, routing should clean and not "within the same class".

c) 50% of the config changes need a reboot - that's annoying.

d) If you have 3G failover, why don't you support WAN Aliasing like you do with DSL and PPPoE WANs? That's just weird.

It feels to me that the OS is not well designed and has had so many features tacked on that they are not integrated cleanly, which leads to inconsistent behaviour. I think the firmware is a hack.

Linux tends to get all this stuff right. If I could find a decently powerful embedded style or rock solid ITX linux box, I'll probably get more mileage...

However, as a DSL endpoint, the Vigor is VERY good. It's just rubbish beyond the simpler cases after that.

[John Rumm]

Its probably poor firmware, highlighted by Tim doing stuff with it that while its theoretically capable of, its probably in practice *very* rarely asked to actually do[1]. Hence I would not be surprised to find that most of the bits can be found to work in one version or another of the firmware, however getting them all working at once in a singe version may be hard! (I get the impression their regression testing when making changes / fixes is only limited)

[1] i.e. enterprise style networking, when most customers are more after basic SME class capabilities.

For the kind of stuff I do with them (dual wan - single IP each, no VLAN, NAT, WiFi, and a VPN end points) they seem to work well, even if there are a few flaky bits around the edges. (never managed to get the scheduling of VPN availability working for example)

[tony sayer]

AIUI that unit is old now there are more recent ones, perhaps an upgrade?..

[Tim Watts]

If they are all built off the same software stack (likely) I doubt that will help sadly. Apart from the rebooting, the errors I am seeing are in the logic, not the hardware.

[John Rumm]

Its not that old - it replaced the 2820 a few years back. The 2860 came out recently that can do VDSL out of the box as well. The also did a revamp on 2830 firmware recently that supposedly made a major improvement in WAN2 throughput when you have fast devices on it.

[tony sayer]

Well in terms of IT equipment life cycle a week is a long time;!..

Perhaps Tim ought to look at a more recent one to see if that does what he needs or copes with it.

We have a 2830 that we use VLAN's on and I can't say its been any bother but we're not quite as demanding of it quite the same way as he is...

[John Rumm]

I use untagged VLANs on mine just for the segregation of normal and "guest" wifi traffic (the latter can see the internet but not other LAN clients).

One of the problems I find is that the manuals don't always describe the feature set as well as could be hoped - leading to things not doing what you expect, although they might be doing what they were actually designed to do.

For example, I setup some clients with a automated "round robin" backup so that each branch office could offload a copy of today's data to another office each night.

They each have a NAS device that is capable of RSYNCing shares etc to other NAS devices. So the plan was LAN to LAN VPNs were stuck in place the allow one NAS to see the other LAN at another office. The NAS was then scheduled to replicate in the dead of night. Fine when its up and running, but for the initial backup (or days where there are big changes in the local filesystem), the job can run 24h/day for several days on ADSL connections. Left to its own devices this will saturate the outgoing bandwidth of one of their WAN connections. That would be a problem during the day, since it will slug the performance of that WAN drastically. Hence I thought, I would enable bandwidth throttling on the Vigor.

I found that sure enough I can spec a limit for Tx and Rx for all clients, and then additional more restrictive limits for certain internal IPs. So say give the NAS a limit of 400 Kbs on send. You do that, and the limits show up correctly in the data flow monitor page. THe "current TX would show 400 / 400 as in using 400 of an allowable

400. However look at the traffic graph and you will find that the Tx is still nailed to the line speed of 800 ish.

In later revisions of the firmware, I noticed that they changed the wording slightly, and added "smart bandwidth" as an option. I get the feeling from some experimentation that this is what they always did - just never described it. So if you set an arbitrary rate limit, its actually designed to ignore it when there is no competing traffic - and only takes an effect when there is. This is actually ideal behaviour - but it gives the initial impression that one bit of the UI is telling you something is happening, and another bit is showing its not!