HDTenEightyP/NetNews huggingface dataset:
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Virtual Token Ring
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Mon, 9 Nov 92 20:31:40 GMT

Token Based Flow Control

In this application a single server is being pounded by multiple
clients clustered around two or three hubs connected to the server
across some single physical link.  These clients are using old
style transport layer without rate based control.  Since the server
knows what the current load in number of connections, and knows the
rate at which it can accept cell streams, the server would like
to manage flow control for the 10-30 clients located at the remote
site.  The server would like to manage the bandwidth at the data link
level, not requiring a new technology transport layer.

Solution:

Token passing systems have an inherent, though dumb flow control
since no stations can transmit until it control of the token.  Thus,
a natural flow control mechanism would have the server send over 
a token to be passed around to each client in turn, which when received
allows the client to transmit a fixed quota of cells.  The token could
tally up the number of cells ready for release at each client, and
when its quota of cells have been accounted for, or a fixed timeout has
occurred, the token would cause itself to expire.

The server would continue to release tokens as needed to keep its IO
busy.

Of course, with the self routing capability of the wave system, along
with its inherent intelligence to carry and manipulate variables, the
creation of a virtual token ring is simply accomplished.  Additionally,
the interpretable wave can handle more complex multi-priority flow control,
simulating a dual priority token ring.

Just like a token ring, the whole procedure takes place at the data link
level.
Newsgroups: comp.dcom.cell-relay
From: craig@sics.se (Craig Partridge)
Subject: SSCOP better than TCP?
Organization: Swedish Institute of Computer Science, Kista
Date: Mon, 9 Nov 1992 18:17:08 GMT

goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes:

> Just in case anyone's wondering, SSCOP (service-specific
> connection-oriented protocol) is the service-specific sublayer that sits
> above AAL3/4 OR  AAL 5 to create a connection-oriented data link
> service.
> ...
> Or if you want "end-to-end ATM", it can be used to deliver
> a transport-like service.
 
Sigh... I thought everyone had learned about the end-to-end argument by
now.  The link layer (ATM) has no business providing a function that higher
layers also have to provide.  If this synopsis is accurate, SSCOP sounds like
a remarkably dumb idea.
 
> Personally, I think datagramme services can use it too:  If you have a
> lot of loss in the ATM layer, then TCP recovery (single selective
> recovery, at best) will not be  very effective at high speeds over
> multi-hop (or other long delay) links.  For pure local use, it might be
> overkill, but it's not so hard to build so why not?
 
TCP will run just fine over multihop gigabit links.  There's some
misunderstanding here.

Most TCPs currently rexmit one segment per rtt for two reasons: (1) the
receiving TCP doesn't use selective acks, so all that is known is that a segmentat the edge of the window was lost.  So the only segment that the sending
TCP knows needs retransmission is the first segment, so that's the one to send;
(2) the usual cause of loss right now is congestion, which makes it all the
more important to only launch segments known to be missing (to avoid
overloading the network further with useless duplicates).
 
Another problem for TCP with high-bandwidth paths is that the window size
is too small.
 
However, there are standard TCP extensions for high-bandwidth paths that
extend the window size and provide for selective acks and better RTT timing.
(See RFC 1323 -- which is a proposed standard and note these extensions are
deployed in some implementations, like Cray's).  Testing to date shows that
this TCP (which interoperates with older versions) runs at gigabit speeds
just fine.
 
Craig
Newsgroups: comp.dcom.sys.cisco
From: GUELLEC@FRILL.BITNET
Subject: Cisco IGS problems
X-Organization: Institut Laue-Langevin. Grenoble
X-Envelope-To: cisco@spot.colorado.edu
Content-Transfer-Encoding: 7BIT
Date: 6 Nov 1992 10:18 GMT+1
X-Vms-To: IN%"cisco@spot.colorado.edu"
X-Note1: mail msgid was <01GQTTA5RPCW9EDILC@frill.BITNET>
X-Note2: message-id generated by recnews

First question
 
We have upgrdated an IGS/2L from:
        V8.2(3) to V9.0
        0.5Mb to 4Mb memory
After the modification we sometimes have the following error message:
 
%SYS-3-INVMEMINT: Invalid memory action (malloc) at interrupt level
-Process= "Sched*" , ipl= 4
-Traceback= 100CFF4 105B8FA 116DF54 107EE62 107D39A 100C140 100BD92 100B066
 
Inside the upgrade kit there were two chips:
                - one 17-0728a to replace U55 (no problem).
                - one 17-0930-0137DE which we did'nt use because there was no
                  informations in the kit. Our french support (Racal-Datacom)
                  could not help either.
 
Second question
 
We also have another IGS/2L with V8.2 soft version.
Does the Appletalk Phase II discovery mode work well ?.
On our network (interface E 0 side) we have ten Shiva V Fastpaths (phase II).
On the other network ( interface E 1 side) there are Shiva and Gator ( both
phase I and Phase II).
To operate correctly in Appletalk routing, we were obliged to:
        - force E 0 cable range and address (apple cable-range 100-110 100.50)
          so that the Cisco understands the RTPM packets from other routers
          which all had addresses type 100.x.
          In discovery mode ( on int E 0) the interface got an address type
          103.x and did not understand RTPM from other routers.
 
        - force E 1 address 0.0 to have Phase I discovery mode.
          The command 'apple discovery' forces the Cisco to get a Phase II
          address but we want to have a Phase I address.
 
Thanks.
 
A.Guellec
Institut Laue-Langevin
Departement Informatique
38042 Grenoble
France
 
Guellec@frill.bitnet
Guellec@ill.fr
 
Newsgroups: comp.dcom.sys.cisco
From: dyer@spdcc.com (Steve Dyer)
Subject: Re: Any New Products from Cisco
Organization: S.P. Dyer Computer Consulting, Cambridge MA
Date: Thu, 5 Nov 1992 18:27:47 GMT

In article <CH-Cheng.17@CSC.mgate1.cuhk.hk> CH-Cheng@CSC.mgate1.cuhk.hk (CH Cheng) writes:
>I didn't have chance to go the Interop this year but I'm very curious to 
>know whether there are any thing new from Cisco.  Could anyone tell us?

Ha!  Unless you were interested in SNA and "APPI" you wouldn't have found
out anything about new products from Cisco.  Frankly, as a source of
new product information (as opposed to a schmoozing booth for a bunch
of suits) the Cisco booth at Interop really sucked.  There was no product
literature evident anywhere, there was some bozo who knew nothing about
their new 3000 routers other than being able to open and close the chassis,
and mostly it was a bunch of power suits of both sexes networking and
making dates for later in the week.  I saw no info available on terminal
servers or their entire line of stuff.  It was as if you were supposed to
_know_ what Cisco selled already, and only be interested in SNA networks
anyway.  If not, tough.

The only redeeming quality was that if you might have been lucky to find
and speak to a technical person there (they were obvious from their clothes),
you'd have gleaned a little info.  I walked away thinking "if I wanted to
call my Cisco sales rep for info on their new products, I'd have done so
and avoided this mob scene."  Believe me, the individuals staffing the IBM
booth were more relaxed and had fewer broomsticks up their butts than the
crowd at the Cisco booth.  With their new capital letter, they only seem
intersted in Capital and making deals.

Yes, you may distribute this to the individuals within Cisco who were
responsible for this debacle (whom I sure wouldn't see it thru USENET.)

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
Newsgroups: comp.dcom.sys.cisco
From: tfallon@oit.gatech.edu (Tom Fallon)
Subject: OSPF
Date: 10 Nov 1992 10:45:19 -0500
X-Note1: mail msgid was <199211101545.AA15282@>
X-Note2: message-id generated by recnews


We at Georgia Tech are interested in implementing OSPF on our 
campus backbone. Our backbone is comprised of an FDDI ring of
3 AGS+s with 8.3(5) ucode. I'm trying to make an assessment
of OSPF (what the users think about it) and determine the best
way to implement it (i.e. microde level needed, any tricks in
configuring it, etc.). I would appreciate any and all suggestions
from the OSPF community.

Thank you,

Tom Fallon

tom.fallon@oit.gatech.edu 

Newsgroups: comp.dcom.sys.cisco
From: sgvax.dnet%sgvax%"a1::limmg".dnet@mrgate.dnet
Subject: cisco lat filtering
Date: 4 Nov 92 04:39:38 -0500
X-Note1: mail msgid was <9211040939.AA29286@esds01.es.dupont.com>
X-Note2: message-id generated by recnews

From:	NAME: MARGARET LIM                  
	FUNC: REGIONAL TECHNICAL SUPPORT      
	TEL: 770-7157                         <LIMMG AT A1 AT SGVAX>
To:	"BOONMARK@CISCO.COM"@ESDS01@MRGATE,
	"TAC@CISCO.COM"@ESDS01@MRGATE
CC:	"CISCO@SPOT.COLORADO.EDU"@ESDS01@MRGATE


Hi Boonmark,
How are you? Wondering if you can me with this, can the cisco rel 
ver 8.3.5 support lat bridge filtering by specific services. I 
understand that we can do it today if we implement group codes 
but all our networks implement 0 group codes . Hence to change 
the group code of some of the vaxes may be a tedious thing to do 
as changes need to be made at the terminal servers end too. I 
wonder if there is an easier way or an alternative to group codes 
for setting up lat filtering of services if I were to bring up 
lat bridging between lan A and lan B?


   -----------cisco A  ------/________ cisco B ------------
	|					    |
     Lan A					LAn B

Regards,
Mag

Newsgroups: comp.dcom.sys.cisco
From: vsg%tron!plaza.dnet@uunet.UU.NET (Marty Adkins, (W) ESG Distributed Systems, MS 1615, WIN 285-1479)
Subject: MEC 2.4 microcode
Date: 5 Nov 1992 19:37:15 -0500
X-Note1: mail msgid was <9211060407.AA06191@relay1.UU.NET>
X-Note2: message-id generated by recnews

>Article 2839 of comp.dcom.sys.cisco:
>Path: tron!uunet!uunet!nntp1.radiomail.net!csl.sri.com!cisco.com!tsiang
>From: tsiang@cisco.com (David Tsiang)
>Newsgroups: comp.dcom.sys.cisco
>Subject: Re: Weird Ethernet Behavior
>Date: 7 Oct 1992 23:27:37 GMT
>Organization: cisco Systems, Incorporated
>Lines: 66
>Distribution: world
>Message-ID: <1avrp9INNgp@roche.csl.sri.com>
>References: <BvF94p.9CA@usenet.ucs.indiana.edu> <1aee3aINNfgk@early-bird.think.com> <BvG405.Jp0@usenet.ucs.indiana.edu> <1ahhtcINNma4@moe.ksu.ksu.edu>
>NNTP-Posting-Host: tsiang-ss2.cisco.com
> 
> 
>-- 
> 
>What interface cards are you using?  I know that for the MEC (an AGS+ card) there is 
>a small window where the interface chip will not automatically flush bad CRC'd 
>packets like it should.  This only seems to occur on 'bad' networks and seems
>to occur most often when fiber repeaters are involved.  The good news is that
>although the interface chip does not flush the packet, it does mark the CRC bad
>status bit.  With the latest and greatest MEC microcode (Ver 2.4), we no longer 
>rely on the interface chip to flush a packet and we do an explicit check of
>the CRC status bit.
> 
>So if you have an MEC and are seeing this problem, I would upgrade the microcode
>to Ver 2.4.
> 
> 
> 
>David Tsiang
>High End Systems Development
>cisco Systems - HW engineering
>Menlo Park, California
>email:  tsiang@cisco.com

David,

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)?

Thank you,
Marty Adkins
Distributed Systems
Westinghouse Electronic Systems Group
Internet: Adkins@plaza.wec.com
Newsgroups: comp.dcom.sys.cisco
From: mhump@sparky.msfc.nasa.gov (Mark Humphries)
Subject: Re: priority queing
Date: 4 Nov 92 08:47:11 CST
X-Note1: mail msgid was <9211041447.AA00956@sparky.msfc.nasa.gov>
X-Note2: message-id generated by recnews


I understand that guaranteed bandwidth is not the inteneded purpose of 
priority queuing but rather guaranteed throughput or priority throughput.
I know you can't configure the router (with priority queuing or any other
commands) to guarantee 20% of BW to #1 nets or 80% of BW for certain 
protocols.  However, my theory was that if two groups of nets are assigned
the same priority, the router should equally balance it's queue dropping
between them. This would effectively give the two groups of networks equal
time or resources (or each 50% of BW, or 33.333% of BW for 3 groups).

Let's assume their is a heavy traffic load (which is causing packet queues to
fill up) through Router A to Router B (or the reverse).  Router A must make a 
decision concerning which queue to drop packets from.  The group of nets who 
have the lowest priority will have their packets dropped first.  However, what
about the case where there is equal priority.  If they DO have equal priority,
it seems that the Cisco should balance queue dropping equally between them.  If 
this is the case, this would be a way to guarantee two groups of networks (or
traffic from two interfaces) equal resources i.e. equal througput i.e. equal
bandwidth. 

I guess my questions should be: 

 1) Does the configuration below assign the same priority to the two groups
    of networks in the access lists?

	priority-list 1 protocol ip high ip list 100
	priority-list 2 protocol ip high ip list 200

	access-list 100
	 (#1 Nets behind Router 1)
	 .
	 .

	access-list 200
	 (#2 Nets behind Router 2)
	 .
	 .



 2) If it does mean equal priority, how would the Cisco drop packets from 
    these priority queues in the scenario described above?


Mark Humphries
Boeing Computer S. S.
Marshall Space Flight Center
Huntsville, AL


----- Begin Included Message -----

Mark,

I don't think there is any way of achieving this, but maybe someone else has a 
suggestion.

Priority queuing lets you configure which packets are *discarded first* when the 
link starts getting saturated. You'd probably want to configure both sides the
same way for it to work well.

Maybe this is good enough?

Regards,

David.

----- End Included Message -----

----- Begin Included Message -----
> 
> 
>    Is there any way to use priority queing on the Ciscos to guarantee
>    bandwidth to two seperate groups of networks sharing one serial
>    link to their corresponding networks on the other side of the link?
> 
> Sorry, there is no way to do that with priority queueing.  Thank you
> for the suggestion.
> 
> Tony
> 
> 
----- End Included Message -----
Newsgroups: comp.dcom.sys.cisco
From: trstan%trew@dot.ca.gov ( )
Subject: Re:  RIP and cisco
Date: 4 Nov 92 13:33:36 PST
Return-Path: <trstan@trew ( )>
X-Note1: mail msgid was <9211042138.AA01089@dot.ca.gov>
X-Note2: message-id generated by recnews



We have a bunch of ciscos where RIP is the local protocol.
We use ROUTER IGRP and REDISTRIBUTE RIP and it works fine, 
just set passive-interface commands for the local ethernets.
We use ROUTER RIP and REDISTRIBUTE IGRP on the ethernets and
set passive-interface commands for the serial lines.

Newsgroups: comp.dcom.sys.cisco
From: Pasvorn Boonmark <boonmark@cisco.com>
Subject: OSPF
Date: 10 Nov 92 22:41:50 -0800
X-Note1: mail msgid was <9211110641.AA29339@last-call.cisco.com>
X-Note2: message-id generated by recnews

Tom,

To run OSPF, you would need 9.0(2) software.  For the microcode, there
should not be any problem.  The best released FDDI microcode would be
1.0, but this means that you also have to upgrade your cBus controller
to 2.0. 

-Pasvorn
Newsgroups: comp.dcom.sys.cisco
From: wrl@wdl1.wdl.loral.com
Subject: CSC-4 & Token Ring Problems
X-Sender: wrl@wdl50.wdl.loral.com (Unverified)
Date: 13 Nov 92 14:15:23 PST
X-Note1: mail msgid was <9211132215.AA24251@wdl50.wdl.loral.com>
X-Note2: message-id generated by recnews

Hi,

We have an AGS+ with 9.0(2.1) GS3-BF and a CSC-R16 card and ever since we
have upgraded to CSC/4 our Token ring has gone crazy.

We even installed a "new" router today from Cisco. When the problem could
not be isolated, Cisco shipped us a new AGS+ Chassis, ENV, CCTL, CSC/4 CPU,
2 MEC-6's and a CSC-R16. The previous router before the upgrade was a CSC/3
and 8.3.3 and no problems (We still have it as a fallback router at this
time). We switch to old router, things work, new router, blah. Whenever we
use the CSC/4, we die (I have 3 CSC-4 CPU's from Cisco so thats not it).

The CSC-R16 Token Ring is connected to a 16MB "Campus" Ring with IBM PS2's
as Token Ring Bridges to 4MB sub-rings. The 16MB ring is OK but the
problems are on the 4MB rings behind the bridges. On one ring I have a MS
LAN MAN Server and PC Clients with NETBIOS. Whenever the CSC/4 is in use,
the clients netbios fails. We can not figure it out, the Cisco is behind a
bridge and should not effect anything on the 4MB ring.

Anyone else having problems with 9.0(*) and CSC/4 with a CSC-R16 card ???

PS. The CSC-R16 card is up to date with Rev 3.1 firmware.

Thanks.

Bill

=================================================================
Bill Lewandowski                 Loral Western Development Labs
ATT:(408) 473-4362               Internet: wrl@wdl1.wdl.loral.com
Fax:(408) 473-4440               UUCP: wdl1!wrl

Newsgroups: comp.dcom.sys.cisco
From: CH-Cheng@CSC.mgate1.cuhk.hk (CH Cheng)
Subject: Any New Products from Cisco
Organization: Computer Services Centre, C.U.H.K.
Date: Thu, 5 Nov 1992 07:36:12 GMT

Hi,

I didn't have chance to go the Interop this year but I'm very curious to 
know whether there are any thing new from Cisco.  Could anyone tell us?

Thanks in advance.

Che-Hoo Cheng
Computer Services Center
The Chinese University of Hong Kong
Newsgroups: comp.dcom.sys.cisco
From: Dave Katz <dkatz@cisco.com>
Subject: Cisco-FDDI<->Sun-FDDI/S help
Date: 13 Nov 92 14:09:51 -0800
X-Note1: mail msgid was <9211132209.AA14568@regal.cisco.com>
X-Note2: message-id generated by recnews

In the configuration you describe, you shouldn't have to do anything
special--just plug the Sun in.  The AGS+ will recognize that it is
connected to an S port and do the right thing.  Note that you should
not plug anything into the second PHY on the AGS+ (it will automatically
disconnect).

The FDDI CMT spec allows any combination of ports to be connected, except
for M to M (but does not require it).

If the Sun implementation insists on seeing an M port before it is willing
to allow the connection, you could then try playing with the signal bits,
but I doubt that this is necessary.

Note that you can't really build a "single ring" network in the sense that
an 802.5 token ring network has a single ring;  single attach stations
can only be attached to concentrators if anything bigger than a two-station
network is desired.
Path: nntp1.radiomail.net!uunet!ogicse!uwm.edu!linac!att!cbnewse!cbnewsd!elel
   From: elel@cbnewsd.cb.att.com (eric.edberg)
   Newsgroups: comp.dcom.sys.cisco
   Keywords: configuration questions
   Date: 2 Nov 92 21:03:32 GMT
   Article-I.D.: cbnewsd.1992Nov2.210332.18843
   Organization: AT&T
   Lines: 44

   Hello,

   I am a new CISCO AGS+ user.  We are using the routers to
   perform IP routing and protocol conversion between Suns with
   FDDI/S cards using a SMDS (802.6 switch).

   We ordered FDDI cards from Sun, and were delivered Sun-FDDI/S 
   cards (single ring fddi cards).  Stupid me, I believed FDDI was
   always dual-ring........

   The short questions is:

	   What procedure must be used to configure the CISCO AGS+
	   to be setup as a single-ring router using the S and M
	   physical interfaces ?

   Reading Cisco documentation, I think it should be possible to do
   something with the:

	   fddi cmt-signal-bits 'bits' [phy-a,phy-b]

		   and

	   cmt disconnect phy-b

   commands to tell it to change the physical type and disconnect
   the unused phy-b ring.

   ** Am I on the right track ?

   The first simple test we plan on implementing is:


   Sun (FDDI/S)<->(FDDI/M Phys-A Cisco <-> Hssi(0) (SMDS) <-> DSU/CSU ---\
									  |
									  |
   Sun (FDDI/S)<->(FDDI/M) Phys-A Cisco <-> Hssi(0) (SMDS) <-> DSU/CSU ---/


   ** Has anyone configured the Cisco FDDI for a single ring network ?

   Eric Edberg
   att!iexist!elel
   708-713-5231

Newsgroups: comp.dcom.sys.cisco
From: JIMWW@SACUSR.MP.USBR.GOV
Subject: Re: 39461 - DECnet Phase IV to Phase V redistrobution
X-Vms-Original-To: SMTP%"cisco@spot.colorado.edu"
Date: 13 Nov 1992 12:35:30 PST
X-Note1: mail msgid was <199211132036.AA10432@spot.Colorado.EDU>
X-Note2: message-id generated by recnews


Howdy,

  I am having problems with DECnet Phase IV to V address distrobution.

We have an IGS connected to an AGS with a 56kb serial link. Both routers are in 
the same area (12) with other decnet nodes some of which are remote through 
a DECnet router, off of the respective ethernets.


   +------+           56k             +-------+
   | IGS  |---------------------------|  AGS  |
   +------+                           +-------+
      |                                   |
  -----------                 --------------------------------------------
    |                             |               |              |
  +-----+                     +-----+          +-----+          etc
  | VAX |                     | VAX |        --| RTR |--
  +-----+                     +-----+          +-----+
                                                 |  |
AGS config:

decnet routing 12.253
decnet node-type area
clns routing
clns router igrp MP NET 47.0005.80.0600.0000.00.0000.000c.aa00.0400.fd30.00
decnet conversion igrp MP

interface ethernet 0
decnet cost 1

interface serial 3
clns router igrp MP


IGS config:
decnet routing 12.252
decnet node-type routing-iv
clns routing
clns router igrp MP NET 47.0005.80.0600.0000.00.0000.000c.aa00.0400.fb30.00
decnet conversion igrp MP

interface ethernet 0
decnet cost 1

interface serial 0
clns router igrp MP

When I bring up the clns with all clns debugging on it shows some of the nodes
being advertized (not many 3/15),  however they do not make it to DECnet 
routing tables. The cisco's are DECnet isolated.  HELP!!!!

The routers have been successfully routing phase iv for years and will in the 
future, but so little DECnet traffic goes over that link I can play with it.
We are attempting to setup using a single pipe for two fed agencies to save us
both some money (your tax dollars). Neither agency is concerned with what
areas or nodes are in the other agency but using phase iv to v conversion it
looked like no problem since our respective gosip addresses were different.

What am I overlooking

Thanks

   jimww

================================================================================
#  James W. Wheeler                 #                                          #
#  Regional Systems Manager         #   voice: 916 978-5089  fax: 916-978-5284 #
#  Mid Pacific Region               #                                          #
#  U.S. Bureau of Reclamation       #    inet: jimww@sacmgr.mp.usbr.gov        #
#  2800 Cottage Way    MP1101       #                                          #
#  Sacramento, CA 95825             #                                          #
#===============================================================================

Newsgroups: comp.dcom.sys.cisco