HDTenEightyP/NetNews huggingface dataset:
From: art@acc.com (Art Berggreen)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: X.25 line utilization???
Date: 28 Aug 92 22:21:13 GMT
Organization: ACC, Advanced Computer Communications

In article <721.714404877@scrum> exubho@exu.ericsson.se writes:
>
>Hi,
>
>I have some statistics I have been gathering from one of my packet
>switch nodes within my company's private X.25 network.  I have been
>monitoring the incoming and outgoing bit/sec data rates between
>Richardson Texas and Stockholm Sweden.
>
>We have a full duplex communications link capable of 112
>kilobits/sec of data throughput.  We have recently gotten into a
>quarrel over what the utilization of the link is.  
>
>Here is the scenario.  My statistics tell me that I have the
>following:
>
>40,000 bits/sec input data rate
>60,000 bits/sec output data rate
>
>I think that the utilization of our line during this time (expressed
>as a percentage) is ((40,000 + 60,000)/112000) * 100%
>
>while some others here think that the utilization of our line
>(expressed as a percentage) is gotten by taking the higher of the
>two data rate figures and dividing that by the maximum data rate, or
>(60,000/112000)*100%.
>
>Does anyone have any input on which is the right way to express the
>utilization of our link?  Any input would be appreciated.
>
>Blake Holman
>Ericsson Network Systems, Inc.
>Richardson, Texas
>(214) 997-6784

Since you really have 112Kb/s of capacity IN EACH DIRECTION, I'd suggest that
you calculate the line utilization separately for each direction.

  Input: (40,000/112,000)*100%
  Output: (60,000/112,000)*100%

Art
Newsgroups: comp.dcom.sys.cisco
From: scsabir@tvgurus.hdtv.zenithe.com (Andrew Birner)
Subject: Re: X.25 line utilization???
Date: 31 Aug 92 12:05:14 CDT

You really need to keep link utilization stats for each direction, independent-
ly.  Any combination of the two will be arbitrary and relatively meaningless
(just the sort of thing management likes to see).  Combining the numbers also
will obscure useful information; asymmetries in the traffic can be enlightening,
especially if you can track the numbers minute-by-minute.

- Andrew E. Birner, Zenith Electronics Corporation -
From: bav@hobbes.ksu.ksu.edu (Brick Verser)
Newsgroups: comp.dcom.sys.cisco
Subject: AGS+ pauses for 800ms every 30 seconds
Date: 3 Sep 1992 07:21:40 GMT
Organization: Kansas State University
Distribution: world
NNTP-Posting-Host: hobbes.ksu.ksu.edu

We've got an AGS+ running Version 8.2(7) which seems to pause every 30 
seconds.  Seems likely this is RIP updates, but it seems unlikely that 
the router should do absolutely nothing else for that period.  Is there 
a simple configuration change that we've overlooked which will make this 
all better?

An example, running ~10 pings/second to it:

02:15:32  64 bytes from 129.130.7.240: icmp_seq=213 ttl=255 time=3 ms
02:15:32  64 bytes from 129.130.7.240: icmp_seq=214 ttl=255 time=3 ms
02:15:32  64 bytes from 129.130.7.240: icmp_seq=215 ttl=255 time=14 ms
02:15:33  64 bytes from 129.130.7.240: icmp_seq=216 ttl=255 time=3 ms
02:15:33  64 bytes from 129.130.7.240: icmp_seq=217 ttl=255 time=3 ms
02:15:33  64 bytes from 129.130.7.240: icmp_seq=218 ttl=255 time=12 ms
02:15:33  64 bytes from 129.130.7.240: icmp_seq=219 ttl=255 time=10 ms
02:15:34  64 bytes from 129.130.7.240: icmp_seq=220 ttl=255 time=720 ms
02:15:34  64 bytes from 129.130.7.240: icmp_seq=221 ttl=255 time=649 ms
02:15:34  64 bytes from 129.130.7.240: icmp_seq=222 ttl=255 time=540 ms
02:15:34  64 bytes from 129.130.7.240: icmp_seq=223 ttl=255 time=431 ms
02:15:34  64 bytes from 129.130.7.240: icmp_seq=224 ttl=255 time=322 ms
02:15:34  64 bytes from 129.130.7.240: icmp_seq=225 ttl=255 time=213 ms
02:15:34  64 bytes from 129.130.7.240: icmp_seq=226 ttl=255 time=104 ms
02:15:35  64 bytes from 129.130.7.240: icmp_seq=227 ttl=255 time=755 ms
02:15:35  64 bytes from 129.130.7.240: icmp_seq=228 ttl=255 time=658 ms
02:15:35  64 bytes from 129.130.7.240: icmp_seq=229 ttl=255 time=551 ms
02:15:35  64 bytes from 129.130.7.240: icmp_seq=230 ttl=255 time=442 ms
02:15:35  64 bytes from 129.130.7.240: icmp_seq=231 ttl=255 time=333 ms
02:15:35  64 bytes from 129.130.7.240: icmp_seq=232 ttl=255 time=224 ms
02:15:35  64 bytes from 129.130.7.240: icmp_seq=233 ttl=255 time=111 ms
02:15:35  64 bytes from 129.130.7.240: icmp_seq=234 ttl=255 time=6 ms
02:15:35  64 bytes from 129.130.7.240: icmp_seq=235 ttl=255 time=3 ms

--Brick
Newsgroups: comp.dcom.sys.cisco
From: a-steiner@nwu.edu (Albert Steiner)
Subject: Re: speed capabilities of cisco terminal servers
Followup-To: comp.dcom.sys.cisco
Organization: Northwestern University
Date: Wed, 2 Sep 1992 21:53:52 GMT

In article <Sep.1.22.12.11.1992.23056@athos.rutgers.edu>,
hedrick@athos.rutgers.edu (Charles Hedrick) wrote:
> 

We had problems loosing characters at 38400, just a few here and there.
Cisco acknowledges that this is a problem and suggested that CSC4 "might"
help, but of course it is not available yet.  

There is a programing problem that Cisco is planning to fix.

> Does anyone
> (including Cisco) know what the limits of a single box are for the
> normal telnet, SLIP, and X.remote?

These are not official opinions of ACNS at NWU
Albert Steiner      a-steiner@nwu.edu     708-491-4056
Academic Computing and Networking Service
Northwestern University  2129 Sheridan Road
Evanston, IL  60208      USA
Newsgroups: comp.dcom.sys.cisco
From: "Craig A. Finseth" <fin@unet.umn.edu>
Subject: X.25 line utilization???
Date: 31 Aug 1992 11:37:56 -0500

	...
   other direction.  To me, saying that a line is being utilized at 100%
   of capacity means that no more traffic will fit.  That is not the
   case when one bases such utilization numbers on just the larger of
   the IN/OUT traffic.  This may not be the most mathematical approach
   to this problem, but most users (and bosses) don't care about technically
   correct statistics - they want numbers that make sense, and that give
   a real measure of how much of what they're paying for is actually
   getting used.

I agree with you that most users want numbers that "make sense."
However, "making sense" is what is being suggested.  A line
utilization of 100% in one direction and 0% the other is "technically"
only 50%.  However, that user is probably screaming (well, asking at
least) for more bandwidth and is not interested in hearing that the
link is only used 50%....

Actually, I always treat the two directions of a serial link
separately and calculate separate utilizations.  (Of course, they have
to be upgraded at the same time (:-).)  It is often useful to look for
substantial asymmetries, as they provide clues as to what is going on
in the net.

Craig A. Finseth			fin@unet.umn.edu [CAF13]
Networking Services			+1 612 624 3375 desk
Computer and Information Services	+1 612 625 0006 problems
University of Minnesota			+1 612 626 1002 fax
130 Lind Hall, 207 Church St SE
Minneapolis MN 55455-0134, USA
Newsgroups: comp.dcom.sys.cisco
From: dumic@cc.swarthmore.edu (Mark J. Dumic)
Subject: Re: Telnet to Cisco Problem
Organization: Swarthmore College
Date: Tue, 25 Aug 1992 17:16:35 GMT

In article <1992Aug25.075628.14855@news.mentorg.com>,
hans@enc_hol.mentor.com (Hans van der Molen) wrote:
> 
> 
> Can you tell me what version of NCSA Telnet you have ?
> We use 2.4.19 and this works fine.
> I'm just curious since we have 8.3(3) on our cisco's and want
> to upgrade to 9.0 shortly.
> 
I'm using NCSA/BYU Telnet v2.5 with MacTCP v1.1.
From: tli@skat.usc.edu (Tony Li)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: 8.3(5) release notes ?
Date: 1 Sep 1992 13:10:50 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: skat.usc.edu

In article <O1L6Z1@minnie.zdv.uni-mainz.de> kapffer@Informatik.Mathematik.Uni-Mainz.DE (Matthias Kapffer) writes:
    I've just seen that the 8.3(5) software revision is available on ftp.cisco.com,
    but the accompaning release notes (file gsr_83.psf) is still at 8.3(3).
    
    Is there any chance that this will change ?
Fixed

-- 
Tony Li - Escapee from the USC Computer Science Department          tli@usc.edu
		       The net is not what it seems.
Newsgroups: comp.dcom.sys.cisco
From: Peter Hakanson <peter@cyklop.volvo.se>
Subject: TR-3-RESETFAIL: Unit 0, reset failed, error code 00007F32.
Mailer: Elm [revision: 66.33]
Date: 31 Aug 92 20:11:08 METDST

since you guys out there so rapidly answers my questions,
we have an acute problem with an AGS+ and t/r 16 Mbit board.
(AGS+ 8.3(3), CSC-R16 in 4Mbit mode, 5 4E4T boards in box)

After power on we get :
%TR-3-RESETFAIL: Unit 0, reset failed, error code 00007F32.
-Traceback= 97F98 97D0E 970B6 96FD2 9C5FC 12766 37F8 1D1E

and the manual states : 'if message recurs, contacr Cisco Systems.'

I did this, now i've waited the hour they said and noone has called me yet.

Does anyone out there knows what to do ?
--
Peter Hakanson  VolvoData Dep 2230 phone +46 31 66 74 27
From: lcz@dptspd.sat.datapoint.com (Lee Ziegenhals)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Errors on IGS/R console
Date: 24 Aug 92 04:15:31 GMT
Organization: Datapoint Corporation, San Antonio, TX

I write:

>I am getting a lot of the following errors on my IGS/R.  So far they do not

Oops.  Sorry, I forgot to mention my firmware version is 8.3(3).
Newsgroups: comp.dcom.sys.cisco
From: warlick@theophilus.msfc.nasa.gov (Chuck Warlick)
Subject: Re: DDR vs Dedicated bandwidth
Date: 31 Aug 92 13:57:54 CDT

This problem was resolved by turning off fast switching
on the interfaces.  After making the switch all of the 
interfaces in the test at simular rates.


# From warlick Thu Aug 27 09:39:13 1992
# To: Customer-Service@cisco.com, cisco@spot.colorado.edu
# Subject: DDR vs Dedicated bandwidth
# Cc: boeing-eng@tank1
# Content-Length: 658
# 
# I have been doing some testing with version 9.0-1 of the routing
# software and have come up with something that I can't explain.
# I was comparing an ISDN link running DDR through a terminal adapter (Ascend)
# and a dedicated link running through a DSU/CSU (Larse).  Both are 384k
# but the terminal adapter gives much better performance.  When we put
# an analyzer on the link we see periodic delays on the dedicated link but
# no delays on the terminal adapter link.  Both are running V.35 on a MCI
# card and are simularly configured.  Can anyone explain why these are giving
# a large difference in performance ?
# 
# Thanks
# 
# Chuck Warlick
# warlick@theophilus.msfc.nasa.gov
# 
Newsgroups: comp.dcom.sys.cisco
From: Omar Barazanji <barzanji@cisco.com>
Subject: [bjripp@watson.ibm.com: token-ring reset failed]
Date: 2 Sep 92 11:05:02 -0700



Dear Bill,

With regards to the TR-3-RESETFAIL error message, we have identified
and fixed this bug approximately three months ago. I am very sorry
that you have not been notified acordingly. In the future, please
use our escalation procedure should one of our engineers fails to
respond to your reported trouble ticket in a timely manner. I have
left you my direct number on your voice mail. Please call me as soon
as possible so that we can resolve this issue immediately.

If I can be of any further service, please do not hesitate to call
me.

Yours Sincerely

Omar Barzanji
Customer Engineering



>The problem (see attached) may be related to the level of
>Token-ring microcode you are running. I have a case opened
>with cisco dating back to February, case number 15766. They
>have not come up with a resolution yet. When I tried to
>upgrade from SBEMON 2.0(112) to 3.0(1) I had trouble on
>the 4Mb rings that were highly utilized to the point where
>the cisco would crash on a bus error. Prior to the crash I
>received reset failed messages for the interface. I am
>currently running my 16Mb rings on the 3.0 code and my
>4Mb rings on the 2.0 code. I just hope the problem doesnt
>surface on the 16Mb ring when my users are able to push
>it to 90+ %.

>Bill Rippon         Phone: 914-784-7479
>IBM Watson Research Center     Email: bjripp@watson.ibm.com

------- Forwarded Message

Date:    Mon, 31 Aug 92 20:11:08 +0700
From:    Peter Hakanson <peter@cyklop.volvo.se>
To:      cisco@spot.colorado.edu
Subject: TR-3-RESETFAIL: Unit 0, reset failed, error code 00007F32.

since you guys out there so rapidly answers my questions,
we have an acute problem with an AGS+ and t/r 16 Mbit board.
(AGS+ 8.3(3), CSC-R16 in 4Mbit mode, 5 4E4T boards in box)

After power on we get :
%TR-3-RESETFAIL: Unit 0, reset failed, error code 00007F32.
- -Traceback= 97F98 97D0E 970B6 96FD2 9C5FC 12766 37F8 1D1E

and the manual states : 'if message recurs, contacr Cisco Systems.'

I did this, now i've waited the hour they said and noone has called me yet.

Does anyone out there knows what to do ?
- --
Peter Hakanson  VolvoData Dep 2230 phone +46 31 66 74 27

------- End of Forwarded Message


Newsgroups: comp.dcom.sys.cisco
From: C.Chaundy@its.unimelb.edu.au
Subject: Cisco gateway software level and Vines 5
Content-Transfer-Encoding: 7BIT
Mime-Version: 1.0
Date: 02 Sep 1992 18:02:14 +1000
X-Vms-To: IN%"cisco@spot.colorado.edu"

Is there a minimum gateway software level that you should be running on
your cisco's to support Banyan Vines version 5 (versus earlier versions
of Vines) - other than the level that added Vines routing?  :-)

Thnaks, Chris Chaundy (Technical Manager, Networks)

Information Technology Services, Thomas Cherry Building,
The University of Melbourne, Parkville, Victoria 3052 Australia
Phone:    +61 3 344 7045                Fax:   +61 3 347 4803
Internet: C.Chaundy@its.unimelb.EDU.AU 	(X.121 505233430003)
Newsgroups: comp.dcom.sys.cisco
From: scsabir@tvgurus.hdtv.zenithe.com (Andrew Birner)
Subject: Re: bug in 9.0(1) ?
Date: 2 Sep 92 12:16:52 CDT

I use a filter that only passes what I want to bridge:  LAT and some other DEC
and XYPLEX protocols.  This limits the amount of unrecognized junk that goes
across my precious serial links, and avoids problems like the 9.0(1) ARP bridge
scenario.  To implement this, you need a fairly good source for Ethernet Type
codes and other assigned numbers; RFC 1060 is very useful, but there are other
lists, as well.  

- Andrew E. Birner, Zenith Electronics Corporation -

Newsgroups: comp.dcom.sys.cisco
From: brunner@ks.id.ethz.ch (Armin Brunner)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: PPP
Date: 26 Aug 92 14:51:14 GMT
Organization: Swiss Federal Institute of Technology, Zurich

In article <1992Aug25.151433.17186@ns.network.com>, robp@landru.network.com (Rob Peglar) writes:
|> In article 16122@picker.com, SYSNET@engvax.picker.com (Leonard A. Visconti) writes:
|> >Does anyone know if cisco can talk to a Vitalink router via PPP? Also,
|> >will this link support bridging? Thank you.
|> >
|> 
|> The Vitalink 6000 series routers will bridge and route over PPP, for
|> various protocols (IP,IPX,Appletalk phII,DECnet phIV,XNS), and interoperate
|> with Cisco.

The Vitalink/NSC 6000 series routers interoperate with Cisco via PPP 
for IP only. 

--Armin
From: sat@eng.tridom.com (Stephen Thomas)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: What terminal server should I buy?
Date: 28 Aug 92 18:16:16 GMT
Article-I.D.: tridom.BtpHF5.Eqy
Reply-To: sat@nut.tridom.com
Organization: AT&T Tridom

As much as I hate to be the bearer of bad tidings, I've seen some nasty
behavior with Xyplex terminal servers. Specifically, they apparently
use a simple TCP with a fixed retransmission timeout of 200-500 ms. As
you might expect, such a small timeout doesn't work too well when
you're trying to telnet across a WAN. It shouldn't be a problem when
telnetting on a LAN though.

I work for a vendor of multiprotocol routers for satellite links. We've
had to put Xyplex on our black list of products that don't work over
satellites, and we explicitly recommend to our customers that they look
elsewhere for terminal servers.

If there's a newer version out there that doesn't suffer from this
problem, I'd like to know about. (Is anyone from Xyplex listening?)
I'd be happy to arrange for a new interoperability test. If the
new version works okay, we'll take Xyplex off our black list and I'll
send an updated announcement to this newsgroup.


---

Stephen Thomas (sat@tridom.com)
AT&T Tridom (404-426-4261)
Newsgroups: comp.dcom.sys.cisco
From: Rex Mammel <rexm@advtech.uswest.com>
Subject: Re:  Token-Ring not reset after beaconing
Date: 21 Aug 92 09:18:07 MDT

we are also seeing this same problem on an AGS+ 2E2T
card on the ethernet interfaces also running 9.0(1).

Is this a known bug?

	  I believe I have seen this problem mentioned before and I am
	wondering if there is a fix yet.
	  I am running GS3-BFX 9.0(1) in an AGS+. On several occasions
	a beaconing condition on the token-ring has caused the token-ring
	interface on the cisco to go down. The interface does not reset
	automatically, but must be manually reset via software
	(shutdown, no shutdown).
	Thanks,
	  Bill

	Bill Rippon         Phone: 914-784-7479
	IBM Watson Research Center     Email: bjripp@watson.ibm.com

Newsgroups: comp.dcom.sys.cisco
From: warlick@theophilus.msfc.nasa.gov (Chuck Warlick)
Subject: DDR vs Dedicated bandwidth
Date: 27 Aug 92 09:39:14 CDT

I have been doing some testing with version 9.0-1 of the routing
software and have come up with something that I can't explain.
I was comparing an ISDN link running DDR through a terminal adapter (Ascend)
and a dedicated link running through a DSU/CSU (Larse).  Both are 384k
but the terminal adapter gives much better performance.  When we put
an analyzer on the link we see periodic delays on the dedicated link but
no delays on the terminal adapter link.  Both are running V.35 on a MCI
card and are simularly configured.  Can anyone explain why these are giving
a large difference in performance ?

Thanks

Chuck Warlick
warlick@theophilus.msfc.nasa.gov
Newsgroups: comp.dcom.sys.cisco,comp.sys.novell
From: merdian@rus.uni-stuttgart.dbp.de (Peter Merdian)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Subnetting and class B nets
Date: 27 Aug 92 14:36:57 GMT
X400-Received: by /PRMD=uni-stuttgart/ADMD=dbp/C=de/;
	Relayed; 27 Aug 92 16:36:57+0200


 
>               But  for some reason  (perhaps some subnetting  rule),
> the cisco will  to not accept  two *different* subnet  masks for the
> same class B  network.  The cisco  automatically changes the  subnet
> mask for all interfaces with the same class B network address to the
> last subnet mask of the last interface set.

According to RFC 950 only one subnetmask is allowed for an IP network:

      For example, the Internet address might be interpreted as:

         <network-number><subnet-number><host-number>

      where the <network-number> field is as defined by IP [3], the
      <host-number> field is at least 1-bit wide, and the width of the
      <subnet-number> field is constant for a given network.  No further
                               ----------------------------
      structure is required for the <subnet-number> or <host-number>
      fields.  If the width of the <subnet-number> field is zero, then
      the network is not subnetted (i.e., the interpretation of [3] is
      used).

We have the same problem as you and waste a lot of our Class B
address space because of this. I have heard some rumors that new
routing protocols (OSPF ?) could solve this problem by carrying a 
variable subnet mask information with them.

-- Peter

Peter Merdian, BelWue Coordination, University of Stuttgart, merdian@belwue.de
Newsgroups: comp.dcom.sys.cisco
From: David Hampton <hampton@cisco.com>
Subject: Re: Cisco gateway software level and Vines 5 
Date: 03 Sep 92 19:35:32 PDT

> Is there a minimum gateway software level that you should be running on
> your cisco's to support Banyan Vines version 5 (versus earlier versions
> of Vines) - other than the level that added Vines routing?  :-)

Nope, the current router software should support Vines 5.0.  It is
missing support for new features added in Vines 5.0, e.g. Banyan's
traceroute, but everything else should work.

David
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Newsgroups: comp.dcom.sys.cisco
Subject: speed capabilities of cisco terminal servers
Date: 2 Sep 92 02:12:12 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

We're beginning to start setting up some fast modems.  Apparently
Telebit Trailblazers can go fast enough to use 115Kbps ports, when
using their proprietary encoding and compression.  This isn't a major
concern to me, but even with v.32bis and v.42bis it looks like we'll
be able to keep 57.6Kbps busy.

Our dialups are mostly connected to 96-line terminal servers, which
will shortly be using CSC3 processors.  (I have a feeling we should
have gotten CSC4's...)  We make use of most of the features of
terminal server, including X.remote, compressed SLIP, PPP (shortly),
TN3270, etc.  Obviously we don't expect to see 96 people
simultaneously doing 57.6K file transfers.  (Among other things, it
would come close to saturating the Ethernet.)  But as people start
using some of these newer features, we do expect to see more data
going through these boxes than we've had in the past.  Does anyone
(including Cisco) know what the limits of a single box are for the
normal telnet, SLIP, and X.remote?
Newsgroups: comp.dcom.sys.cisco
From: C.Chaundy@its.unimelb.edu.au
Subject: Banyan services on non-serverless networks
Content-Transfer-Encoding: 7BIT
Mime-Version: 1.0
Date: 02 Sep 1992 17:59:49 +1000
X-Vms-To: IN%"cisco@spot.colorado.edu"

If you have a network connected to a cisco system with Vines routing
enabled with PCs and a Banyan server on this network, but you do *not*
flag the network serverless, can the PCs obtain services such as getting
the time from other servers across the cisco, or are they restricted to
obtaining these services from the local server (this is what we want)?

Thanks, Chris Chaundy (Technical Manager, Networks)

Information Technology Services, Thomas Cherry Building,
The University of Melbourne, Parkville, Victoria 3052 Australia
Phone:    +61 3 344 7045                Fax:   +61 3 347 4803
Internet: C.Chaundy@its.unimelb.EDU.AU 	(X.121 505233430003)
From: tli@skat.usc.edu (Tony Li)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Router Problem Caused by Errant Host
Date: 28 Aug 1992 17:31:20 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: skat.usc.edu

In article <9vdnx8#.badboy@netcom.com> badboy@netcom.com (Jay Keller) writes:
     
    We recently experienced a failure of our Cisco router due to the following
    scenario:
    
    One of our workstations, running IBM TCP/IP for OS/2, was improperly
    configured.  The file that controls the IP address and the default routing
    was typo'ed such that the machine was accidentally assigned the same IP address
    as the Cisco router.  This brought down a major part of our network as the
    Cisco stopped routing.  Several hours were spent finding the problem.
    
    First of all, what troubleshooting techniques would have led our team to
    discover the exact nature of the problem more quickly?
    
The router will note this and issue a warning message to the console
and to its syslog host when this occurs.  This message will include
the MAC address of the station that it thinks is misconfigured:

%IP-4-DUPADDR: Duplicate address 160.89.32.8 on Ethernet0, sourced by 
	0000.0c00.aecc

It will also work to defend its address by generating a gratuitous ARP
reply and it will continue to route packets.  Unfortunately, if the
hosts ARP cache is still confused, there is not too much that the
router can do. 

    Secondly, is there any way to protect against this sort of thing?
    
The only way that I know of is to hard wire the ARP entry of the
router in all hosts.

Tony
-- 
Tony Li - Escapee from the USC Computer Science Department          tli@usc.edu
		       The net is not what it seems.
Newsgroups: comp.dcom.sys.cisco