home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / dcom / sys / cisco / 1082 < prev    next >
Encoding:
Text File  |  1992-08-12  |  2.9 KB  |  65 lines
  1. Newsgroups: comp.dcom.sys.cisco
  2. Path: sparky!uunet!boulder!recnews
  3. From: Paul Smee <P.Smee@bristol.ac.uk>
  4. Subject: Re: Blocking protocols
  5. In-Reply-To: <9208070820.AA19630@wolf.cisco.com>; from "David S.A. Stine" at Aug 7, 92 1:20 am
  6. Message-ID: <11162.9208101104@bristol.ac.uk>
  7. Sender: news@colorado.edu
  8. Reply-To: P.Smee@bristol.ac.uk
  9. Date: 10 Aug 92 12:04:41 BST
  10. X-Mailer: ELM [version 2.3 PL11]
  11. Via: uk.ac.bristol; Mon, 10 Aug 1992 12:05:53 +0100
  12. Lines: 51
  13.  
  14. > On 6 Aug 92 14:54:17 GMT, smee@bristol.ac.uk (Paul Smee) said:
  15. > 
  16. > > I'm aware that we could block it through all interfaces of the AGS+ by
  17. > > using 'Administrative Filtering by Protocol Type', but somewhere in the
  18. > > manual is a line suggesting that there is a performance hit on this,
  19. > > 'proportional to the number of entries in the type code access list'.
  20. > > Cisco don't say what the constant of proportionality is, though.  If an
  21. > > entry cost, say .001% of throughput, who cares?  If it costs 50% per
  22. > > entry, ouch.
  23. > 
  24. > I haven't the performance data sitting at hand at the moment. I'm
  25. > sure however we're not costing you 50% per entry.
  26.  
  27. Would be handy if you could provide some sort of rough numbers just for
  28. guidance.  I have had one piece of mail from another using site, where
  29. they claim a 20% performance degradation for a 35-entry list.  (Don't
  30. know how that compares with official figures, since I haven't seen any,
  31. but it does make me feel better insofar as it makes me believe that
  32. I've now got some sort of clue. :-)
  33.  
  34. Thanks for your response.
  35.  
  36. > > It looks, though, like it might be possible to win by telling the AGS+
  37. > > to route Appletalk, and then setting 'no appletalk address' on all the
  38. > > interfaces.  
  39. > 
  40. > This will work, as long as you aren't doing encapsulation bridging. If
  41. > you are encapsulating, (ie, over FDDI or HDLC serial lines) this
  42. > configuration will not work. And when it doesn't work, you will see very
  43. > rude (albeit entertaining) things happen to your network. Overall, I
  44. > would say that it is safer to set up the input type & input lsap filters
  45. > rather than depending on not doing encapsulation bridging at some later
  46. > time.
  47.  
  48. Just a mention in passing, in case it influences the thinking of your
  49. developers -- I also had a bit of mail from someone who is using this
  50. technique for isolating Novell IPX.  Also, a personal comment which may
  51. be obvious (but I'll make it anyway), it would be nice if your
  52. developers could keep in mind that it is very handy if encapsulation
  53. interfaces (FDDI, HDLC, whatever next year's flavor is, ...) could be
  54. made to work as much like the straight-ether ones as possible, as far
  55. as routing access controls go.  (They may already do this.  I certainly
  56. don't have a wide-enough range of low-level protocol knowledge to know,
  57. so don't take this as a criticism, just as an observation.)
  58.  
  59. Thanks again...
  60.  
  61. -- 
  62. Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
  63.  P.Smee@bristol.ac.uk - ..!uunet!uknet!bsmail!p.smee - Tel +44 272 303132
  64.  
  65.