HDTenEightyP/NetNews huggingface dataset:
From: nabil@ogicse.ogi.edu (Aaron Nabil)
Newsgroups: comp.dcom.sys.cisco
Subject: Netblazer vs CS-500, bang vs buck?
Date: 17 Nov 92 13:54:35 GMT
Article-I.D.: ogicse.46018
Distribution: world
Organization: Explosive Space Modulators - R - Us


Since my inquiry re: CS-500 vs ASM perormance has simply set the newsgroup
abuzz with followups, lemme try something else.

My company needs to pick a platform for async access to our network.  The
choices are the Netblazer (cheap) vs the Cisco families (nice).  We need
to make the right choice now, since we want to commit to a platform that
we can be happy with over the next n years.  We're probably looking at
about 160 ports over the next 2 years.

The reliabilty is sorta important, for example we just ordered a
Hayes Millenium 8000 series (which is INCREDIBLY overpriced), but it looks
like a real SOLID piece of engineering.  They also have some intriguing
future plans for the platform, but that's another story...

Some advantages of the Netblazer...
	1 box can support 24 ports

	ISDN ready (?)

	Cheap(er).  Note that this may be peculiar to our situation,
	we have about a zillion of their 8 port boards lying around.
	(Anyone need any?)

	Good support for dialup modems (scripts, configs, etc..)

	THEY WILL ACTUALLY TAKE MY MONEY AND ONE WILL SHOW UP
	ON MY DOORSTEP IN A REASONABLE TIME FRAME.


Netblazer disadvantages...
	It's a complex system with lots of components, lower MTBF

	No Xremote

Cisco advantages...
	Well, hey, it's a Cisco!  Ie, it's probably going to work
	in very short order after we plug it in.

	CS-500 is a small, simple, reliable platform.

	IGRP? OSPF?

Cisco disadvantages...
	Zillion year wait to get one.  Christ, I'd like to just
	*borrow* one, how long is the waiting list for that?
	
Can anyone who has, or had, both give me some feedback?  I think it's
noteworthy that Alternet is choosing Netblazers...

-- 
Aaron Nabil
nabil@cse.ogi.edu
From: leinwand@mead.cisco.com (Allan Leinwand)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: SNM 2.0 schema for Cisco MIB?
Date: 23 Nov 92 15:25:21
Organization: Cisco Systems, Inc., Menlo Park, Ca.
NNTP-Posting-Host: mead.cisco.com
In-reply-to: rnb@alsys1.aecom.yu.edu's message of 23 Nov 92 17:06:52 GMT

In article <1228@alsys1.aecom.yu.edu> rnb@alsys1.aecom.yu.edu (Robert N. Berlinger) writes:

>   Anyone know where I might find up to date SunNet Manager 2.0 schema/oid
>   files for the Cisco MIB?

Hello Robert,

   You can make your own SunNet Manager file by getting our cisco MIB
from ftp.cisco.com via anonymous ftp.  Grab the README file to see the
file names and all the goodies we offer.  Once you have the schema for
your routers, you can use the SunNet Manager utility mib2schema to
generate the schema/oid files.

   We do offer a schema already parsed by mib2schema as part of our
CiscoWorks 1.0 product, if you care to purchase that.  Send us mail at
cs@cisco.com for more details.

Thanks,

Allan Leinwand
cisco Systems
(415) 688-7653
leinwand@cisco.com
From: ddunwood@dsc.blm.gov (Dave Dunwoodie 6042)
Newsgroups: comp.dcom.sys.cisco
Subject: IGS 9.0(1) HELLLLP!!!
Date: 20 Nov 92 16:27:16 GMT
X-Mailer: SCO System V Mail (version 3.2)
X-Note1: mail msgid was <9211200927.aa06863@dsc.blm.gov>
X-Note2: message-id generated by recnews

I have 2 routers connected by ethernet.  One (a 3-COM) connects me
to the internet.  The other (the Cisco) is managing our routing to
an X.25 network.  If I login in to the Cisco and try to ping
the 3-COM, it chokes.  What's the deal here?
I've tried a default route on the Cisco that points as:
0.0.0.0 158.68.31.254.  No go.  I tried taking it out.
No go.
The bottom line is that our X.25 clients can't get any further
than our Campus LAN as the Cisco isn't connecting to the other
router to get the caller to his internet target.
The two routers are on the same physical and logical network.
The cisco: 158.68.31.253, the 3-COM: 158.68.31.254.  There's
gotta be a way to get packets from one to the other!
Newsgroups: comp.dcom.sys.cisco
From: merike@alw.nih.gov (Merike Kaeo)
Subject: Re: optical characteristics of cisco FDDI gear
Organization: National Inst. of Health, DCRT, CSL
Date: Fri, 20 Nov 1992 00:19:39 GMT

I've tested the multimode transmitters and got somewhere around 15.4dB when testing with a 1m 62.5/125 fiber jumper at 1300nm.  Singlemode I don't remember off-hand but I believe it was about the same.

Yes, the singlemode appliques have FC connectors.  If you are attaching 2 singlemode appliques together, no attenuator is needed. I've had some connected in a lab scenario with only 2 meter jumper cables.

However, we also have a situation here where we have a short singlemode run (~500m) where we go:
    multimode applique -> mm/sm converter -> singlemode applique. 
Here we needed attenuators going from the sm to the converter.

-- 

Merike Kaeo			merike@alw.nih.gov
National Institutes of Health	(301) 402-1548 


                          o
                            \
                          \0/
       ||==================|=====||
       ||-+-+-+-+-+-+-+-+-/\+-+-+||
       ||=================\=\====||
       ||                        ||
       ||                        ||
       ||                        ||

    ......kill or be killed.....



Newsgroups: comp.dcom.sys.cisco
From: Carl Schaefer <schaefer@cisco.com>
Subject: Re: How to interrupt 
             <1992Nov23.042505.14346@midway.uchicago.edu> 
Date: 23 Nov 92 02:01:17 PST
X-Note1: mail msgid was <9211231001.AA13099@wolf.cisco.com>
X-Note2: message-id generated by recnews

> cc-tip>mistake
> Translating "MISTAKE"...domain server (128.135.12.73)...name server 
> (128.135.12.73) (128.135.4.2)
> % Unknown command or computer name, or unable to find computer address

If you're on a physical terminal line you can interrupt with the
terminal escape character, which defaults to ^^ (control-caret, or
control-shift-six on most keyboards).

What you see above are both DNS ("domain server") and IEN116 ("name
servers") queries.  The DNS query probably returned NXDOMAIN
reasonably quickly, but the IEN116 queries to two server addresses
seem to have timed out.  If you have no IEN116 name servers you could
save time by disabling IEN116 queries.

In the latest software release IEN116 name resolution is turned off by
default, but this hasn't always been the case.  It can be disabled
with the "no service ipname" configuration command.

Carl
Newsgroups: comp.dcom.sys.cisco
From: wrl@wdl1.wdl.loral.com (Bill Lewandowski)
Subject: Re: bridging->routing AppleTalk, FastPaths
Followup-To: comp.dcom.sys.cisco
Organization: Loral Western Development Labs
Date: Fri, 20 Nov 1992 18:10:54 GMT

In article <1ej4dqINNavg@barnard.usc.edu>, siemsen@barnard.usc.edu (Pete
Siemsen) wrote:
> 
> We plan to switch from bridging AppleTalk Phase II to routing it.  We
> have 8 ciscos running 8.3(3), with about 45 Shiva FastPaths on various
> Ethernet segments off the ciscos.  They are all FastPath 4s with 4.1.2
> ROMs and 256k of RAM, and are running K-Star 8.1.1.  We are concerned
> about the effect of the switch on the FastPaths.
> 
> The change from bridging to routing means that we have to increase the
> number of AppleTalk networks, and thus increase the size of the RTMP
> tables maintained in each of the FastPaths.  At the same time, the
> switch from bridging to routing will reduce the total amount of
> AppleTalk traffic seen by the FastPaths.  We hope the two will cancel
> each other out, so we don't have to upgrade the memory and/or
> operating system version in the FastPaths.  Upgrading to 5.1 Roms and
> adding 256k more to each FastPath will run us about $11k.
> 
> Anyone have any experience with this?
> 
We converted several sites from bridged to routing. We have about 36
GatorBoxes and 5 FastPaths (soon to be 0 FastPaths). We also have a
nationwide WAN that routes AppleTalk (no tunnels).

There was really nothing to it. You just have to have a very good plan
of zone names and zones numbers for each cisco ethernet interface and
apple router.

Only problems we had was that we entered all the information correctly in
to the cisco config file but made mistakes in the other routers. If you
have a zone called "WDL B260-3R" on the Cisco and "WDL b260-3R" on another
router, big problems. Case and spelling of zones must be exact.

We made a very detailed Excel spreadsheet for each zone with:

Extended Network Numbers (ethernet side)
AppleTalk Network Numbers (AppleTalk Side)
IP Number (ethernet side)
IP Number (AppleTalk Side)
Deafult Zone (AppleTalk Side)
Other Zones (ethernet side)
Default Router (ethernet side)
Zone Names (AppleTalk Side)

The more detail, less problems.

Follow These steps:
o Turn off all routers
o Turn off all Macintoshes (all AppleTalk devices).
o Configure cisco
o Take a Mac to each router and program with new information with
ethernet disconnected to router. Once configured, restart router
and connect to ethernet (at same time).
o Once done, turn all Macs back on so they get new network and
zone information.

Lots of work but not hard.

==========================================================
Bill Lewandowski            Loral Western Development Labs
     (408) 473-4362         wrl@wdl1.wdl.loral.com
FAX: (408) 473-4440         wdl1!wrl
From: sgarcia@cisco.com (Steven Garcia)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: MEC 2.4 microcode
Date: 16 Nov 1992 18:32:19 GMT
Organization: cisco Systems, Incorporated
Distribution: world
NNTP-Posting-Host: lager.cisco.com

In article <721458642.6010@news.Colorado.EDU>, vsg%tron!plaza.dnet@uunet.UU.NET (Marty Adkins, (W) ESG Distributed Systems, MS 1615, WIN 285-1479) writes:

|> CIO still has no mention of MEC 2.4 yet so I'm going to the source.
|> Is there an equivalent version for the older MEC rev 5.0 boards -- i.e, V1.8?
|> Does V2.4 have any other prequisites beyond what V2.3 requires (e.g., CCTL)?

Sorry CIO was not yet able to answer your questions regarding
mec2.4.  Hopefully it was because mec2.4 has only been formally
released within the last few days.  They probably still know it by
it's unreleased number, 130-6.

There is no mec2.4 equivalent for 5.0 hardware.  Microcode version
1.7 was the final rev for MEC hardware rev 5.0.  Customers who need
things beyond that version need to upgrade to rev 5.1 hardware.
(If you are familiar with the 5.1 hardware microcode revisions, your
mec1.7 is equivalent to mec2.2.  Version numbers 2.x are for 5.1 boards.)

As to the cost of the upgrade -- I'm told it depends on what kind of
service contract you have.  The best thing to do is to talk to your
technical assistance contact, so CE can determine if there is a charge,
and if so, how much.

Mec2.4 does not require anything beyond what mec2.3 requires.


Steve Garcia

Newsgroups: comp.dcom.sys.cisco
From: "Ivan (C.I.) Suharly" <ivansuh@bnr.ca>
Subject: RFC1315 implementation 
Content-Identifier: RFC1315 imple... 
X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.207:17.10.92.21.15.16] 
X400-Content-Type: P2-1984 (2) 
Date: 17 Nov 1992 16:14:00 +0000 
X400-Originator: /DD.ID=1331764/G=Ivan/I=CI/S=Suharly/@bnr.ca 
Original-Encoded-Information-Types: ia5, undefined 
X-Note1: mail msgid was <"15251 Tue Nov 17 16:15:48 1992"@bnr.ca> 
X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; 
               Tue, 17 Nov 1992 11:14:00 -0500 
X-Note2: message-id generated by recnews

cisco router supports SNMP ifType frame_relay(32) for frame relay
interfaces. This allows SNMP network surveillance and monitoring of
frame relay interface status as well as basic performance parameters
with SNMP MIB-II.

I walked through the MIB in cisco 8.3(3) and 9.0(2), it seemed that
frame-relay specific MIB, RFC1315, has not been implemented yet.

RFC1315 is useful for proactive network performance and fault
management on public frame relay network in the area of individual
PVC status and frame relay congestion control (FECN and BECN).
The tool available today to look at these parameters is a W&G DA-30
with FR application program.

When will cisco implement RFC1315 ?

Regards,

Ivan Suharly
Network Analyst,
Information Technology, BNR Ottawa.
Newsgroups: comp.dcom.sys.cisco
From: Peter Elford <P.Elford@aarnet.edu.au>
Subject: Re: Variable subnet masks
Date: 20 Nov 92 16:18:01 +1100
X-Note1: mail msgid was <9211200518.AA10780@jatz.aarnet.edu.au>
X-Note2: message-id generated by recnews


>Date: Thu, 19 Nov 1992 21:30:04 -0500
>From: henryc@oar.net
>
>No, you need to be running at least 9.1 to support VLSM.

I have a CS-516 running the Interim release of 9.1 and it's
kind of weird to see this:

GS>sh ip rout
 
Codes: I - IGRP derived, R - RIP derived, H - HELLO derived, O - OSPF derived
       C - connected, S - static, E - EGP derived, B - BGP derived
       * - candidate default route, IA - OSPF inter area route
       E1 - OSPF external type 1 route, E2 - OSPF external type 2 route
 
Gateway of last resort is 139.130.22.1 to network 0.0.0.0
 
     139.130.0.0 is variably subnetted, 5 subnets, 2 masks
S       139.130.0.0 255.255.0.0 [1/0] via 139.130.22.1
C       139.130.18.0 255.255.255.192 is directly connected, Async2
C       139.130.22.0 255.255.255.192 is directly connected, Ethernet0
C       139.130.98.0 255.255.255.192 is directly connected, Async3
R       139.130.116.0 255.255.255.192 
           [120/1] via 139.130.22.1, 0:00:14, Ethernet0

Also, something that threw me initially, is that with VLSM, the
default-network command for setting a subnet default goes away. This is
a tail router that is connected to a piece of our network via a loaded
48K link, so rather than send routes for all 81 subnets of 139.130, we
normally use a subnet default route. Under 9.1, if you enter

ip default-network 139.130.22.0

you get in your configuration

ip route 139.130.0.0 255.255.0.0 139.130.22.0

Note the subnet mask, and the gateway address (the later is *wrong*). 

I replaced this with 

ip route 139.130.0.0 255.255.0.0 139.130.22.1

(the gateway address is now a host address, rather than a subnet address)

This works just fine.

Peter Elford,                             e-mail: P.Elford@aarnet.edu.au
Network Co-ordinator                      phone: +61 6 249 3542
Australian Academic Research Network      fax:   +61 6 249 1369
c/o, Computer Services Centre             pager: +61 6 245 3035
Australian National University            post: GPO Box 1142     
Canberra, AUSTRALIA                             Canberra ACT 2601
Newsgroups: comp.dcom.sys.cisco
From: corbato@cosmic.physics.utah.edu (Steve Corbato)
Subject: Strange behavior associated with MTU change on Cisco serial ports
Followup-To: comp.dcom.sys.cisco 
Originator: corbato@cosmic.physics.utah.edu
Organization: Cosmic Ray Physics Group, University of Utah
Distribution: na
Date: Fri, 20 Nov 92 22:26:20 GMT

Hello-
   Recently we've observed Cisco box `crashes' after modifying the MTU
values on both ends of a serial line.  Below I will describe the problem.
   In an effort to improve telnet and rlogin performance on heavily used
(for ftp and decnet copies) 56 kb lines to our remote experimental sites,
we have made several modifications to the configuration files on our two
Ciscos (gw-umc and gw-hires1).  A networking colleague here suggested one
possible improvement -- reducing the MTU value on the serial interfaces
from 1500 to ~500 bytes:

	int ser N
	mtu 536
	ip mtu 536

   As an initial experiment, I have twice attempted this change on both
serial interfaces comprising the line between gw-hires1 and gw-umc.  Each
time several minutes after the change, the gw-umc box stopped forwarding
packets on all interfaces.  The removal of the offending MTU lines was
required before the gw-umc Cisco worked properly again.

   Does anyone have any explanation for this behavior or any other
suggestions for improving "asynchronous packet" (e.g., telnet, rlogin)
performance on this line (we've already implemented packet type/size
prioritization...)?

   Many thanks, Steve Corbato

				Remote	:   U of Utah
               E0 (MTU=1500)	 site   :  main campus
	        |	                :
            +------+ S0(MTU=1500)     56 kb    S2(MTU=1500) +----------+  AGS+
    MGS     |gw-umc|----------------------------------------|uu-gw-utah| 8.2(7)
   CSC/2    +------+     	      	:                   +----------+ 
   8.3(5)      / S1 (MTU=1500->536)     :                    Main campus
              /          		:		       gateway
             / 56 kb                    :
            /		       
           / S0(MTU=1500->536)        
      +---------+              
 IGS  |gw-hires1|		
9.0(2)+---------+		
           | 
           |			
      E0(MTU=1500)		
-- 
Steve Corbato		          corbato@cosmic.physics.utah.edu (Internet)
Cosmic Ray Physics Group          utahco::corbato, 47623::corbato (HEPnet, NSI)
Physics Dept., Univ. of Utah      corbato@utahcca (BITnet)
Salt Lake City UT 84112 USA       (801) 581-5053 (office), -4801 (Fax)
Newsgroups: comp.dcom.sys.cisco
From: henryc@oar.net
Subject: Re: Variable subnet masks
Date: 19 Nov 1992 21:30:04 -0500
Return-Path: <henryc@oar.net>
X-Note1: mail msgid was <199211200230.AA28017@thor.oar.net>
X-Note2: message-id generated by recnews


In article <1992Nov18.190251.26172@picker.com> you write:
>Neither the AGS+ nor IGS firmware supports variable length subnet masks. Are
>there any solutions to this problem other than changing back to an 8 bit mask
>or buying new firmware?

No, you need to be running at least 9.1 to support VLSM.

>should I expect any problems using OSPF and RIP together? 

Nope, we're doing that right now.  A side-effect, though, is that RIP only
advertises on class/[maybe incorrect] address boundaries and may not work 
correctly in the presence of non-typical subnet masks.  You must be
careful when setting up subnets to insure that the correct information
is being propagated.  

Henry
-- 
Henry Clark                      Network Guy, OARnet
Ohio Supercomputer Center        henryc@oar.net
1224 Kinnear Rd.                 Voice: (614) 292-6483, Fax: (614) 292-7168
Columbus, OH  43212              #include <disclaimer.h>
From: siemsen@barnard.usc.edu (Pete Siemsen)
Newsgroups: comp.dcom.sys.cisco
Subject: bridging->routing AppleTalk, FastPaths
Date: 20 Nov 1992 08:40:26 -0800
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: barnard.usc.edu

We plan to switch from bridging AppleTalk Phase II to routing it.  We
have 8 ciscos running 8.3(3), with about 45 Shiva FastPaths on various
Ethernet segments off the ciscos.  They are all FastPath 4s with 4.1.2
ROMs and 256k of RAM, and are running K-Star 8.1.1.  We are concerned
about the effect of the switch on the FastPaths.

The change from bridging to routing means that we have to increase the
number of AppleTalk networks, and thus increase the size of the RTMP
tables maintained in each of the FastPaths.  At the same time, the
switch from bridging to routing will reduce the total amount of
AppleTalk traffic seen by the FastPaths.  We hope the two will cancel
each other out, so we don't have to upgrade the memory and/or
operating system version in the FastPaths.  Upgrading to 5.1 Roms and
adding 256k more to each FastPath will run us about $11k.

Anyone have any experience with this?

-- 
Pete Siemsen                         Pete Siemsen            siemsen@usc.edu
University of Southern California    645 Ohio Ave. #302      (213) 740-7391 (w)
1020 West Jefferson Blvd.            Long Beach, CA 90814    (213) 433-3059 (h)
Los Angeles, CA 90089-0251
Newsgroups: comp.dcom.sys.cisco
From: Havard.Eidnes@runit.sintef.no
Subject: Re: RIP and cisco 
Originator: he@ugle.unit.no
Organization: University of Trondheim, Norway
Date: Mon, 16 Nov 92 09:57:36 GMT

In article <721784789.1993@news.Colorado.EDU> "Brad (B.M.) Glidewell" <NVBMG01@nt.com> writes:
>RIP should not be redistributed into IGRP. This will cause your IGRP
>to become corrupt!

How? As long as all you care about is the announcement of "reachability",
and you control the redistribution in an orderly manner, I do not see any
problems with doing that. True, the IGRP metrics for the redistributed
nets will use the "default-metrics" specified at the redistribution point,
but again, if all one really care about is reachability information that
really doesn't matter, does it?

- Havard
Newsgroups: comp.dcom.sys.cisco
From: crawdad@fncent (Matt Crawford)
Subject: cslip or ppp on ASM?
Organization: FERMILAB, Batavia, IL
Distribution: na
Date: Wed, 18 Nov 1992 15:25:28 GMT

Does anyone know the current status of CSLIP support on the Cisco ASM
terminal server?  And how about the future status of that and PPP?
_________________________________________________________
Matt Crawford       crawdad@fncent.fnal.gov      Fermilab
From: billw@regal.cisco.com (WilliamChops Westfield)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: How to interrupt
Date: 23 Nov 92 19:38:07 GMT
X-Note1: mail msgid was <CMM.0.90.2.722547487.billw@regal.cisco.com>
X-Note2: message-id generated by recnews


    > cc-tip>mistake
    > Translating "MISTAKE"...domain server (128.135.12.73)...name server 
    > (128.135.12.73) (128.135.4.2)
    > % Unknown command or computer name, or unable to find computer address

    If you're on a physical terminal line you can interrupt with the
    terminal escape character, which defaults to ^^ (control-caret, or
    control-shift-six on most keyboards).

If you are on a router, and actually making outbound connections is rare,
you can configure your lines with "transport preferred none", in which case
you MUST say "telnet host" to make a connection.

Bill Westfield
cisco Systems.
From: bruce@camb.com (Barton F. Bruce)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Asincronous in   Serial?
Date: 17 Nov 92 14:03:12 EDT
Organization: Cambridge Computer Associates, Inc.

In article <1992Nov5.110603.1@si.upc.es>, jesusg@si.upc.es writes:
> Hola NetWorkers:
> 	Do anyone of you know about how to get an Asincronous serial
> 	interface in a cisco router ?.
>         In order to use modem's MNP compresion.

If it is just to a remote site with no other connections beyond,
consider NOT using cisco hardware at the far end, and using an Ethernet
port rather than a SYNC WAN port at the near end. Use a pair
of Gandalf's **COMPRESSING** bridges to ferry that ethernet to the far site.

You still get all the cisco routing stuff feeding that port, and you get
really heavy duty compression to the remote site (if it is 56/64kb SYNC 
or slower) and the bridge pair costs no more than sticking say an IGS 
at the far end.

Gandalf's compression should easily out perform v.42bis. Each end
lists for ~$22xx, and is sold through both Gandalf sales AND nationwide
class PC distribution, so at least via the latter there WILL be good
deals available. It is priced and marketed as a commodity product.
The i960 processor is idling while compressing - even with the optional 
2nd WAN port running ($150 option!).

OTOH, if you really want async to use something like cheap $325 16.8kb 
ZyXELs on, use a terminal server running SLIP or PPP. Latest cisco
Trouter software goes up to 57.6kb, but cisco folks still havn't answered if
I can run all 16 ports at that rate. ZyXELs do 57.6kb but not 115.2kb
on the DTE side. Be sure to use out of band flow control between the
modem and terminal server (RTS/CTS style - not x-on/x-off). 

We have ZyXELs running SLIP into a cisco Trouter. The ZyXELs run 16.8
FDX between themselves, and we have the DTE side at 38.4kb (not sure how
safe cisco is at 57.6kb). On the LCD display of the more expensive
(~$500) ZyXELs we can see actual throughput only occasionally able to
use the full 38.4kb using v.42bis. I suspect running at 57.6kb would
only give very slight benefit. FWIW, the more expensive ZyXELs don't go
any faster, but do have a display and 2/4 wire leased line capabilities.

In any case, a DEC DS700-16 can run all 16 ports at 115.2kb, and DEC 
just cut their price 17%.

I wonder if anyone else thinks cisco is too epensive?
Newsgroups: comp.dcom.sys.cisco