Prev: Remote peer no longer responding -- please help
Next: Prolific USB-Serial/Mac OSX
From: JF Mezei on 28 Dec 2006 08:12
Doug McIntyre wrote:
> Looks like the webfiles are gone from your switch.

Thanks for confirming this. Should I go back to the ebay vendor to
complain about this ? (probably not his fault since he got those from some
corporation that probably unloaded unneedded switches).

Or is the lack of html files common enough that a switch is still
considered complete without them ?

With no support contract, I assume I am not able to download the missing
pieces from the CISCO site ?

If i have no hope of getting the missing HTML files, could I setup my own
mini web site on the switch and IP HTTP PATH myindex.html and then
whenever my web servers are down, I could point HTTP requests to my switch
during maintenance ?
From: Doug McIntyre on 28 Dec 2006 15:27
JF Mezei <jfmezei.spamnot(a)vaxination.ca> writes:
>Doug McIntyre wrote:
>> Looks like the webfiles are gone from your switch.

>Thanks for confirming this. Should I go back to the ebay vendor to
>complain about this ? (probably not his fault since he got those from some
>corporation that probably unloaded unneedded switches).

The vendor probably has no idea whats there, the switch works, only
the silly almost useless webinterface doesn't. As I posted before,
hardley anybody uses the cisco web interfaces on these things I suspect.

>Or is the lack of html files common enough that a switch is still
>considered complete without them ?

Its complete in my view. :) The switch works otherwise, you just won't
get the web-status view.

>With no support contract, I assume I am not able to download the missing
>pieces from the CISCO site ?

Its possible that they released a security patch release of the code
with the full web management files (it comes in a .tar file, not a .bin).
The release notes detail how to upgrade a switch with the proper
extraction from the tar file onto the switch itself.

>If i have no hope of getting the missing HTML files, could I setup my own
>mini web site on the switch and IP HTTP PATH myindex.html and then
>whenever my web servers are down, I could point HTTP requests to my switch
>during maintenance ?

Not sure why you'd even consider such a thing? The cisco webserver is
probably very low capacity, very low feature, etc. etc. You could
probably find a box lying around doing something else that would have
much more capacity and capabilities.

From: JF Mezei on 28 Dec 2006 21:25
Doug McIntyre wrote:
> The vendor probably has no idea whats there, the switch works, only
> the silly almost useless webinterface doesn't. As I posted before,
> hardley anybody uses the cisco web interfaces on these things I suspect.


Based on the documentation I had stumbled on, it seemed that CISCO was
placing a lot of emphasis on its web interface. How do most manage their
switches ?

Direct access to the CLI ?
Or use TFTP to pickup config files from a repository ?

In the case of large enterprise networks, are switches configured
individually, or as a single cluster ?
From: Doug McIntyre on 29 Dec 2006 00:34
JF Mezei <jfmezei.spamnot(a)vaxination.ca> writes:
>Doug McIntyre wrote:
>> The vendor probably has no idea whats there, the switch works, only
>> the silly almost useless webinterface doesn't. As I posted before,
>> hardley anybody uses the cisco web interfaces on these things I suspect.

>Based on the documentation I had stumbled on, it seemed that CISCO was
>placing a lot of emphasis on its web interface. How do most manage their
>switches ?

Its probably a marketing decision to combat most of the competitors
who tout the lack of decent cisco web config as cisco's main
deficiency, rather than performance or feature set or managability,
etc. etc. Ie. the stuff that really matters.

>Direct access to the CLI ?

Yes. If you have to do the same commands to 10 switches, would you
rather be able to telnet to them, copy and paste or run some sort of
expect script and script out the commands you need? Or log into each
one with a webbrowser, and click into each port, and then click into
each option set, and set each option by hand for 10 switches x 24/48 ports?

>Or use TFTP to pickup config files from a repository ?

Not so often that I run across.

>In the case of large enterprise networks, are switches configured
>individually, or as a single cluster ?

Well, a really large enterprise tends to buy some pretty big switches,
so there's only a few to manage in each area. I don't run across too
many in stack/cluster configs, although there are some out there.

From: JF Mezei on 31 Dec 2006 07:31
Bod43(a)hotmail.co.uk wrote:
> Just as an extra voice.
>
> Everybody uses the CLI.


Thanks. I didn't realise that CISCO's attempt at a GUI was so unpopular. I
figured that the ability to visualise port statuses, and focus on a single
prot quickly by clicking on it might have been very popular. But in the
end, you are right that applying changes to port configs via a GUI would be
long and tedious.

Once I configured one port right, I transfered the config over to my
systems with TFTP, and then used a GUI editor to edit the commands and
generate a config for all relevant ports and then sent the config back. to
the switch. (and I then have a backup of the config on my system).

Of course, once I have gotten the hang of this and gotten the switch into a
stable/final configuration, it will probably be in "leave it run alone" for
a very long time.


The one thing I dislike of the CLI is that when you have begun to configure
an interface (configure terminal, interface fa0/xx, you can no longer issue
SHOW INTERFACE commands to see what is configured in it already.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Remote peer no longer responding -- please help
Next: Prolific USB-Serial/Mac OSX