🚀 go-pugleaf

> On 6 Aug 92 14:54:17 GMT, smee@bristol.ac.uk (Paul Smee) said:
> 
> > I'm aware that we could block it through all interfaces of the AGS+ by
> > using 'Administrative Filtering by Protocol Type', but somewhere in the
> > manual is a line suggesting that there is a performance hit on this,
> > 'proportional to the number of entries in the type code access list'.
> > Cisco don't say what the constant of proportionality is, though.  If an
> > entry cost, say .001% of throughput, who cares?  If it costs 50% per
> > entry, ouch.
> 
> I haven't the performance data sitting at hand at the moment. I'm
> sure however we're not costing you 50% per entry.

Would be handy if you could provide some sort of rough numbers just for
guidance.  I have had one piece of mail from another using site, where
they claim a 20% performance degradation for a 35-entry list.  (Don't
know how that compares with official figures, since I haven't seen any,
but it does make me feel better insofar as it makes me believe that
I've now got some sort of clue. :-)

Thanks for your response.

> > It looks, though, like it might be possible to win by telling the AGS+
> > to route Appletalk, and then setting 'no appletalk address' on all the
> > interfaces.  
> 
> This will work, as long as you aren't doing encapsulation bridging. If
> you are encapsulating, (ie, over FDDI or HDLC serial lines) this
> configuration will not work. And when it doesn't work, you will see very
> rude (albeit entertaining) things happen to your network. Overall, I
> would say that it is safer to set up the input type & input lsap filters
> rather than depending on not doing encapsulation bridging at some later
> time.

Just a mention in passing, in case it influences the thinking of your
developers -- I also had a bit of mail from someone who is using this
technique for isolating Novell IPX.  Also, a personal comment which may
be obvious (but I'll make it anyway), it would be nice if your
developers could keep in mind that it is very handy if encapsulation
interfaces (FDDI, HDLC, whatever next year's flavor is, ...) could be
made to work as much like the straight-ether ones as possible, as far
as routing access controls go.  (They may already do this.  I certainly
don't have a wide-enough range of low-level protocol knowledge to know,
so don't take this as a criticism, just as an observation.)

Thanks again...

-- 
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
 P.Smee@bristol.ac.uk - ..!uunet!uknet!bsmail!p.smee - Tel +44 272 303132