<grisly old techie tag>

I've found that, after playing with every vendor's gear, every vendor is 
bound to do it their own way.  The end goal is always the same (these 
four ports can talk to each other but not the rest of the switch at line 
rate layer2), but the method getting there might be a little cumbersome 
on some devices.  I know this is somewhat contrary to the usual method 
of pigeonholing ones thinking into "the way" that "some gear" "should be".

QA and real world feedback tend to help out but not fix the problem - 
They are just part of the deep analysis of the task flow and work output 
that must be done to figure out what's going on when someone has to type 
15 lines of configuration to setup an ethernet interface...

My annoyance is generally with myself when I've become too stiff to 
unlearn a muscle memory command.  There is no one supreme vendor, and 
there are almost always more than ten ways to do the same thing. 
Sometimes I get a bit miffed when I've read the marketese wrong and the 
device doesn't work as expected... but that's just my own expectation 
biting me in the ankle :-)



As for the managed/unmanaged switch discussion:

I define it based off of what an unmanaged switch is, to me:

1 flat layer2 segment of bridged ethernet ports that isn't a hub.  it 
will have autonegotiation for the speed and duplex and hopefully have 
autonegotiation of the wiring polarity (auto-mdix).  In other words, 
it's automanaged, not so much unmanaged.

For a while, there were some "semi-managed" devices on the market, ones 
that would let you get into them and see statistics on ports, but not do 
much with them.  Basically, these weren't switches - just hubs.  You 
can't do much with a repeater and intelligent management.  I believe 
that this is what most people think of when they're thinking/saying 
"semi-managed".  If any actual products have been made in the 
"semi-managed" space for switches in the past five years I'd be rather 
surprised.  Allied Telesyn and others had products like this.

Beyond that, if I'm able to carve up the switch into VLANs whatsoever, I 
consider it managed.  If i'm able to manually set the speed/duplex and 
other layer2 protocol bits, it's probably managed (I've yet to see 
something where I could do that but not carve out a VLAN... this doesn't 
mean it doesn't exist, it just means that it sounds like I've managed to 
stay away from semi-functional network gear in my life - I assure you 
that I have not.  )



</grisly old techie close tag>


Jewell, Michael wrote:
> I agree with the conf t command,  pisses me off everytime I have to work on the damn things... 
luckily I only have 3,  2 connect my datacenter racks to my core, the other one is hooked up to an
iscsi array and a couple servers...  only bought them because it was the end of the year, and I was
almost out of money and couldn't justify the cost of Cisco's...  :(
>  
> -Mike
>  
> 
> ________________________________
> 
> From: Chris Buechler [mailto:cbuechler at gmail dot com]
> Sent: Thu 8/2/2007 9:38 PM
> To: unlisted-recipients
> Cc: m0n0wall List
> Subject: Re: [m0n0wall] Semi-managed switches
> 
> 
> 
> On 8/2/07, Jewell, Michael <mjewell at law dot umaryland dot edu> wrote:
>> The comment about the dell being quarky is right,  it's very silmilar to the Cisco CLI
>> (supposedly it's an older version of IOS) but missing some of the features (like tab to
>> complete commands for 1).
> 
> It's definitely not an older version of IOS, it's not related to Cisco
> in any way. It's just Yet Another IOS Clone. A poor one at that. It
> does have tab completion (at least on the models I've worked with,
> which are all gig ports, 5324, 6024, and 6224, all with the latest
> firmware), but has annoying quirks like it's just 'conf' and 'conf t'
> errors out, which is really annoying for me since I spend far more
> time on Cisco gear and that 't' is quite the ingrained habit. Other
> little annoying things like context sensitive help with '?' isn't very
> good.
> 
> 
>> It wasn't bad,  but one oddity I found( was when setting up a trunk, you have to define all > the
vlans allowed on the trunk,  as opposed to the Cisco's where it's default all trunks and > remove
unallowed.
>>
> 
> On the all gigabit models you can add all VLAN's with one command just
> like on IOS. There are some differences, but one of the good things is
> it's so close to IOS switches that if you're familiar with them you
> won't have any problems.
> 
> 
>> The netgear wasn't too bad,  but very limited in it's abilities,  had trouble getting it to trunk
> to a Cisco Cat4006...  never did solve that problem,  just ran 2 cables to it, 1 for each vlan > I
needed it to hold onto...
>>
> 
> My first guess is because you didn't tell the Cat to use 802.1Q
> encapsulation. 'switchport trunk encap dot1q' on IOS switches, and
> with the 'set trunk' command on CatOS. Cisco defaults to ISL.
> 
> -Chris
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> 
>