Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!csn!boulder!daemon
From: C.Chaundy@its.unimelb.edu.au
Newsgroups: comp.dcom.sys.cisco
Subject: Problems with LAT bridging (repost)
Message-ID: <33876@boulder.Colorado.EDU>
Date: 3 Apr 91 13:16:19 GMT
Sender: daemon@boulder.Colorado.EDU
Lines: 46

The following message was posted some time ago, but I have had no response
(apart from a message that these sort of filters work OK when you used with
input-type-list, which is *not* how I want to use them).  BTW, the AGS+ is
running 8.1(21).

Date: Thu, 28 Feb 1991 21:03 +1100
From: C.Chaundy@its.unimelb.EDU.AU
Subject: Problems with LAT bridging

We have a network in which DECnet, TCP/IP and AppleTalk are routed, and
the following protocols are bridged:

	DEC remote console	type = 0x6002
	DEC LAT			type = 0x6004
	DEC bridge		type = 0x8038 (we use ELMS)
	DEC LTM			type = 0x803F
	Banyan VINES		type = 0x0BAD (we don't run 8.2 yet)

The access list we use on our AGS+ is:

	access-list 201 permit 0x6002 0x0000
	access-list 201 permit 0x6004 0x0000
	access-list 201 permit 0x8038 0x0000
	access-list 201 permit 0x803F 0x0000
	access-list 201 permit 0x0BAD 0x0000
	access-list 201 deny   0x0000 0xFFFF

When we enable this on interfaces with:

	bridge-group 1 output-type-list 201

everything seems to work OK until a host tries to access a LAT printer across
the cisco.  For some reason, the multicast packets requesting the terminal
server response for a given server name seem to be filtered, despite the fact
that the protocol type is 0x6004 (LAT units = 09-00-2B-00-00-0F).  Other LAT
sessions seem to work fine across the cisco.  What am I doing wrong (or is
there a bug lurking here)?

Chris Chaundy

Technical Manager, Networks,
Information Technology Services, The University of Melbourne
Internet: C.Chaundy@its.unimelb.EDU.AU	(DTE 505233430003)
Phone:    +61 3 344 7045  Cables Unimelb
Fax:      +61 3 347 4803  Telex AA35185
Post:     Parkville, Victoria 3052 Australia