MCGUIRE@GRIN1.BITNET ("McGuire,Ed") (11/17/87)
I have a DECnet problem between a VAX 8600, running VMS V4.5 and DECnet Phase IV routing, and two Sun 3/280s, running Sun DNA (Sun DECnet). These systems are connected via Ethernet. The performance of remote login and file transfer between the VAX and a Sun is horrible. The Ethernet: The VAX 8600's UNA-0 interface attaches to a DELNI. The Sun 3/280s' ie1 interfaces both attach to a second DELNI in a different building. There is a LAN Bridge on each DELNI. Fiber optic cable between the two Bridges connects the two buildings' LANs. The symptom: Data transmission is intermittent, not continuous. During a file transfer (or even during a mirror loop), packets fly for less than a second, and then there is dead time for about ten seconds. This behavior is repeated until the file is transferred (or the requested number of loop iterations are completed). The link does not go down. On the VAX end, a counter called `unrecognized frame destination' is incremented regularly, seemingly each time transmission is interrupted but I'm not sure of that. Plea for help 1: Any ideas in general about what's happening and how we could fix it? Plea for help 2: What is `unrecognized frame destination' telling me? Plea for help 3: Sun provides software that puts the Sun's Ethernet interface card into promiscuous mode and logs all packets that fly by. We have done this on the Suns to watch packets on the Suns' DELNI. We'd like to do the same thing on the VAX's DELNI, comparing output from each during a mirror loop. We attached a spare Sun workstation to the VAX's DELNI, but it would not boot, so we want to try to log packets from the VAX. Do we need to write a program to do this ourselves? Has anyone already done this? Thanks in advance for your help!! ---- Ed McGuire, Systems Coordinator, Grinnell College, MCGUIRE@GRIN2.BITNET
klb@philabs.Philips.Com (Ken Bourque) (11/24/87)
>Plea for help 2: What is `unrecognized frame destination' telling me?
This is a normal condition when running DECnet and TCP over the same Ethernet.
The VMS system is receiving multicast and (maybe) broadcast TCP datagrams.
However, the "packet type" is TCP rather than DECnet, so the driver throws it
on the floor. I don't think this is the source of your problem.
--
Ken Bourque klb@philabs.philips.com ...!{uunet,ihnp4,decvax}!philabs!klb