Conference netcad::hub_mgnt

136.0. "DECbridge 90 not filtering 802.3 if I forward 60-04" by UTOPIE::ROBERT (Robert Windisch TSSC-Vienna/Austria @AUI x2563) Thu Jan 28 1993 15:29

Is it the expected behaviour of the DECbridge 90 to forward 802.3 packets if 
I set the bridge to forward only ethernet protocol 60-04 (lat).

Is there anything, I have to change in the forward database or is this a
feature of the DECbridge 90.

Here is a logfile of my bridge setup and a sample of the packets which
I can monitor on the workgroup side of the bridge.


Robert Windisch

DECbridge> SHOW BRIDGE
DECbridge 90 V1.14  08-00-2B-26-A7-26 � 1991 Digital Equipment Corp
FPROM V1.5 �1991 Digital Equipment Corp. 19-APR-1991
Bridge states:
        Console owner: AA-00-04-00-64-C0        Uptime: 273,248.86 seconds
        Bridge state: 37                        Work group size: 2
        Hub management enable: 1                Spanning tree enable: 1
        Flash EPROM erasures:  0                Address lifetime: 450*2 sec.

Event counters:
        System buffer unavailable errors: 0
        Work group size exceeded errors: 143,960

Spanning tree parameters:
        Bridge id:       FF-FF-08-00-2B-26-A7-26        Root port: 1
        Designated_root: 00-14-08-00-7C-00-4F-D6        Root path cost: 216
        Current Forward delay: 15, Hello interval: 1, Listen time: 15
        Default Forward delay: 15, Hello interval: 1, Listen time: 15
        Topology change flag: 0         Topology change timer: 30
        Bad hello limit: 15             Bad hello reset interval: 5
        Epoch_mode: 1   Epoch1 who: 00-00-00-00-00-00   Mode changes: 30
        Epoch 1 poll time: 18 seconds   Epoch 1 response time: 15 seconds

DECbridge>


DECbridge> SHOW PROTO
Protocol 1: forward all ethernet protocol 60-04
Protocol 2: unused protocol
Protocol 3: unused protocol
Protocol 4: unused protocol
Protocol 5: unused protocol
Protocol 6: unused protocol
Protocol 7: unused protocol
Protocol 8: unused protocol
Protocol 9: unused protocol
Protocol 10: unused protocol
Protocol 11: unused protocol
Protocol 12: unused protocol
Protocol 13: unused protocol
Protocol 14: unused protocol
Protocol 15: unused protocol
Protocol 16: unused protocol

DECbridge>

-----------------------------------------------------------------------------
LAN-Anlayzer run at the workgroup side of the decbridge 90.


    IEEE 802.3 packet received at 28-JAN-1993 21:17:27.59    (   0usec.)
    Destination address    Source address         Length
    09-00-2B-00-00-04      02-07-01-07-C8-72      21
    IS9542_ALL_ES
     FE FE 03 82 12 01 00 04 00 19 00 00 08 49 10 00    ...........I..
     06 00 01 00 01                                     .....

    **** 11 lost packets ****


    IEEE 802.3 packet received at 28-JAN-1993 21:17:33.29    (   0usec.)
    Destination address    Source address         Length
    09-00-2B-00-00-05      AA-00-04-00-A9-C3      35
    IS9542_ALL_IS
     FE FE 03 82 20 01 00 02 00 1E 00 00 02 0A 49 00    .. .........I.
     30 AA 00 04 00 A9 C3 20 0A 49 00 30 AA 00 04 00    0�...�� .I.0�...
     A9 C3 21                                           ��!
                                                                                

    This has been discussed in the Ethernet Notes file.
    
    What you have is a incomplete implementation of an 802.3 packet.
    It has no 802.2 header.  Novell is a prime example of a company
    that has an incomplete 802.3 implementation.  Maybe someone should
    tell them that they aren't the only ones on a LAN today.  8^)
    
    Anyways, rather than cutoff communication thru the DB90 for all
    those vendors that haven't done things right, the engineers decided
    to let those packets thru.  Whether or not its right to let those
    packets thru in inverse mode is a rathole that I'm not going to
    go down.  They should and do go thru when you are in normal mode.
    To change this means a gate array change if I'm not mistaken.
    
    dave

.re:       <<< Note 136.1 by CGOS01::DMARLOWE "dsk dsk dsk (tsk tsk tsk)" >>>
�                           -< Nasty 802.3 packets. >-

�    What you have is a incomplete implementation of an 802.3 packet.
�    It has no 802.2 header.

Huh?
I do have Novell Nodes on our LAN (Digital internal Network), but
the packets in question has been generated by Phase V Nodes (IS/ES Systems)
The trace has been produced by a software lan analyzer  (� John Weir - UK)

If our own Bridge can't correctly filter our own implementation of OSI (aka
DECnet/OSI for OpenVMS), then either

  - our Phase V implementation is wrong
  - the DECbridge90 filter algorithm is wrong

what case should we pick now  :-(

And the bridge behaves wrong, if she forwards other packets then LAT, if I set
the bridge to inverse node, forwarding only 60-04   -  ok RATHOLE ALERT!

Robert

    Well, I think, I hope LeNAC engineering can answer this one.
    
    dave