🚀 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.

> 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 sounds more elegant, and also would be more flexible
> if we do need to handle inter-departmental Appletalk later.  Anyone
> have any comments on this possibility?

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.

Please note that should you choose to put in protocol-type bridge packet
filtering that AppleTalk consists of two protocol types: AppleTalk
($809B) and AARP, ($80F3). You must filter both. And also when definint
bridging filters, you must take into account that Phase I packets are
"classic" ARPA encapsulation (ie, like IP) whereas Phase II packets are
802.3. For ARPA encapsulations, you would use an input type list; for
Phase II/802.3, you would use an input LSAP type list.

dsa