Does anyone know if these crappy dell powerconnect switches (in my case a 3448p) have a convenient or at least working way of exporting/backing up the configuration to a different place? The only thing I can find is using a tftp server but it's not working...
Thanks,
Jeroen
Jeroen van Aart(jeroen@mompl.net)@Fri, Mar 16, 2012 at 12:04:04PM -0700:
Does anyone know if these crappy dell powerconnect switches (in my
case a 3448p) have a convenient or at least working way of
exporting/backing up the configuration to a different place? The
only thing I can find is using a tftp server but it's not working...
I'm using RANCID against a few 54xx PowerConnect switches, and it's
working well enough. I'm pretty sure my dlogin and drancid came from
http://web.rickyninja.net:81/rancid/drancid and
http://web.rickyninja.net:81/rancid/dlogin .
Bill Weiss wrote:
> I'm using RANCID against a few 54xx PowerConnect switches, and it's
working well enough. I'm pretty sure my dlogin and drancid came from
http://web.rickyninja.net:81/rancid/drancid and
http://web.rickyninja.net:81/rancid/dlogin .
A number of people suggested that, thanks.
I will look into that.
Thanks,
Jeroen
We have a few 6248s, and as I recall the web UI is confusing and clearly
not designed or coded by a native English speaker. You have to use the
"upload" link to export config, and put in the address of your TFTP server,
since you are "uploading" from the switch to the tftp server.
It's a bit more sane from the cli (which is actually decent in the recent
firmware for the 6248s at least).
It is of course possible the software is entirely different on the
3400-series though.
Despite the terrible GUI and passable CLI, we're found the our 6248s to be
remarkable stable and bug free. Some have been up for more than 3 years,
and all the things you expect to be problematic on cheap switches
(cross-stack LACP, multicast, MSTP, QoS) work perfectly.
It's as if the web ui was coded up to just _barely_ work, and shipped out
the door. It felt like I was using someone's high school project.
I agree though, if you can survive the initial config nightmare, they (54xx
62xx series here) keep on trucking.
-Iain
+1, MSTP/VRRP inter-op with both Cisco 3650-X & Brocade CER worked without fault (well, at a previous position).
tl;dr dlogin worked a goddamn treat for me. Props to the guy that wrote it and also Brightbox for helping him out with their 6200's. As I recall it also worked for our 5400's 
<rant> never, EVER, let your 62xx's do any routing. Even a little bit. Push 500Mbit of traffic through it for a few days (or 30Mbit for a few months) and watch it forget how to re-learn ARP entries.
ARP timers default to 1200s, so it would learn all address for 20 minutes, refuse for the next 20, then learn again for 20 minutes...
Had to pull it down to 60s to make it slightly more obvious. The work-around was to configure "arp dynamicrenew", which fixed it totally. Is it on by default? Is it obvious that you should ask it to do this? Hell no.
Dell cared; one guy (Piotr Majunka) from the UK/IE PowerConnect team spent ages helping me diagnose the fault after I'd pulled it out of service. Broadcom on the other hand, couldn't give a shit and to my knowledge it was never fixed (I'm not sure if the 70xx "spiritual successors" still do it) so buyer beware.
</rant>
Tom
Ryan Malayter wrote:
not designed or coded by a native English speaker. You have to use the "upload" link to export config, and put in the address of your TFTP server, since you are "uploading" from the switch to the tftp server.
Yes I tried that. However the switch complains with an error about file not found. That's funny because I am uploading a file that's present on the switch to an tftp server. And I supposedly can give it any name for the destination.
Despite the terrible GUI and passable CLI, we're found the our 6248s to be remarkable stable and bug free. Some have been up for more than 3 years, and all the things you expect to be problematic on cheap switches (cross-stack LACP, multicast, MSTP, QoS) work perfectly.
Yeah they're stable, but then we barely use it for more then 2 or 3 vlans. Nothing else fancy going on. The cli is weird though and the help texts are useless, you need a manual.
Reason I want to backup the config is that some time ago after a power outage the thing reset to its default configuration...
Greetings,
Jeroen
Jeroen van Aart wrote:
Ryan Malayter wrote:
not designed or coded by a native English speaker. You have to use the "upload" link to export config, and put in the address of your TFTP server, since you are "uploading" from the switch to the tftp server.
Yes I tried that. However the switch complains with an error about file
I got that figured out. My experience with tftp is a bit limited. I had to create the file first and then change permissions to 666. Then run this on the switch:
copy running-config tftp://x.x.x.x/name
I first thought I also had to add a path.
Thanks,
Jeroen
If it's tftp on Linux there's a flag you can pass tftpd at startup to allow creation of files, can't remember off the top of my head what it is, it may be -s.
--jm
-c for create
Jeroen van Aart wrote:
> Ryan Malayter wrote:
>> not designed or coded by a native English speaker. You have to use the
>> "upload" link to export config, and put in the address of your TFTP
>> server, since you are "uploading" from the switch to the tftp server.
>
> Yes I tried that. However the switch complains with an error about fileI got that figured out. My experience with tftp is a bit limited. I had
to create the file first and then change permissions to 666. Then run
this on the switch:copy running-config tftp://x.x.x.x/name
I first thought I also had to add a path.
That, just to be clear, is not the TFTP device's fault, it's the TFTP
server's fault. Not even really a fault, exactly, but a bit of security
paranoia on the part of the typical tftpd implementation, plus a lack of
a robust means of propagating the server administrator's configuration
error back to the frustrated user who is just trying to do what ought to
be a simple and sensible operation.
So it's not really Dell's fault.
... JG
I would agree they are passable, but they have broken sFlow support (e.g., not supported on LAGs, though this is documented nowhere, sFlow generates invalid data when it does work, stack management is not even close to appropriate for production environments, almost any change requires a full stack reset, and stack member flash storage failures are way too common). That said, at least they try with sFlow, just wish they would get it working.
Mark