Conference help::decnet-osi_for_vms

3953.0. "Unable to change MAC address for CSMA-CD station" by AIRAT::CHAINIKOV (Kirill Chainikov - IS Moscow) Mon May 05 1997 10:10

Hi folks,

    I am unable to see router adjacency on VAX/VMS V6.1 node with DECnet 
    V6.3 ECO 6 (and DNS V7.0) - no any ways to perform DEC DNS skulks
    (this is a primary DNS server for my geography).

    No any other events since normal operation except required 
    upgrade to this level of DECnet and DEC DNS.
    
 o  According the advice to eliminate driver control from other protocols
    prio to DECnet starts up (in some notes here) I reduced number of
    supported protocols to DECnet and TCP/IP (IP works just fine,
    DECNET starts First) but this did not help;


 o  $ show device EZA4 (which supposed to be DECNETV device)
    does not indicate that it is SGEC device:

    Device EZA4: is online, network device.

    Error count                    0    Operations completed                  0
    Owner process                 ""    Owner UIC                      [SYSTEM]
    Owner process ID        00000000    Dev Prot              S:RWPL,O:RWPL,G,W
    Reference count                1    Default buffer size                1492
 

 o  In SDA output below I could not find
    identification of DECNETV protocol.


 Can anybody advice me what to do next?

 Thanks a lot in advice.

 Kirill.



$ anal/system

SDA> show lan
LAN Data Structures
-------------------
LSB address  = 82E34F80
Device state = 0017 Inited,Run,Frk_Pnd,Timer

                 -- EZA Unit Summary  5-MAY-1997 16:58:22 --

UCB     UCB Addr  Fmt   Value           Client     State
---     --------  ---   -----           ------  -----------
EZA0    82E34900
EZA1    82E4BE40  Eth   60-07           SCA     0017 Strtn,Len,Uniq,Strtd
EZA2    82FD36C0  802E  08-00-2B-80-3C  DNAME   0017 Strtn,Len,Uniq,Strtd
EZA3    82FD3940  Eth   80-3C           DNAME   0017 Strtn,Len,Uniq,Strtd
EZA4    82FD3E40  802   FE                      0017 Strtn,Len,Uniq,Strtd
EZA5    82FD40C0  Eth   60-03           DECNET  0017 Strtn,Len,Uniq,Strtd
EZA6    82FD8940  802E  08-00-2B-80-3E  DTIME   0017 Strtn,Len,Uniq,Strtd
EZA8    82FD2540  802E  08-00-2B-80-48          0017 Strtn,Len,Uniq,Strtd
EZA9    82FD5240  Eth   08-00           TCPIP   0015 Strtn,Uniq,Strtd
EZA10   82FD54C0  Eth   08-06           ARP     0015 Strtn,Uniq,Strtd

SDA>


    


Extracts from NCL commands follow:


NCL>disable csma-cd station csmacd-0

Node 0 CSMA-CD Station CSMACD-0
at 1997-05-05-16:47:27.281+04:00I1.676


NCL>show csma-cd station csmacd-0 all stat

Node 0 CSMA-CD Station CSMACD-0
at 1997-05-05-16:47:33.461+04:00I1.676

Status

    UID                               = D7B5BA60-C150-11D0-8015-AA000400F1D1
    Communication Port                = EZA
    Hardware Address                  = 08-00-2B-31-70-0B
    State                             = Off
    MAC Address                       = 08-00-2B-31-70-0B
    Address Filters                   =
       {
       }
    Receive Mode                      = Normal

NCL>enable csma-cd station csmacd-0

Node 0 CSMA-CD Station CSMACD-0
at 1997-05-05-16:48:06.951+04:00I1.680


NCL>show csma-cd station csmacd-0 all stat

Node 0 CSMA-CD Station CSMACD-0
at 1997-05-05-16:48:10.761+04:00I1.680

Status

    UID                               = D7B5BA60-C150-11D0-8015-AA000400F1D1
    Communication Port                = EZA
    Hardware Address                  = 08-00-2B-31-70-0B
    State                             = On
.........
***
*** Here we hangup endlessly ***
***

        try 
        
        $ define ncl$environment "NoBackTrans"
        
        and then do
        
        $ mc ncl show routing circuit csmacd-0 adj * all
        $ mc ncl show csma-cd station * all
        
        Also, try doing 
        
        $ mc cdi$trace
        
        and then repeat the other commands above. I strongly suspect
        that you are a victim of certain feature of ECO 6. I've twice
        already backed out from ECO 6 because my DNS server starts to
        misbehave. In that case you would see in the cdi$$trace lots of
        "adding child" messages.
        
        _veli

 Thanks, Veli
 for fast-as-usual response.

  Results:
  Yes, ncl$environment = NoBackTrans helps to see that MAC address is o'kay.
  Tracing CDI showed few 'adding child' events when trying to resolve
  behind-router decnetV names. Except "Clerk timeout occurred before any
  modifications" because of no connections to master replicas/clearinghouses,
  a lot of DNS errors like "nodename not a valid synonym too long)",
  "Error converting name "DEC:.MOW.DEC:.VBE.ENOC" to DECdns" are observed.

  I tried to downgrade yesterday to DECnet 6.3 without any ecos, problem
  remained:

  There is no adjacency on csmacd circuit. When compared routing, routing
  circuit scripts/parameters with ones from the working system, I did not find
  differences:

   MOSDNS/System> mc ncl
   NCL>show routing circuit csmacd-0 adja * al

   Node 0 Routing Circuit csmacd-0 Adjacency *
    at 1997-05-07-14:03:39.657+04:00I1.454

   command failed due to:
    no such object instance

  Local DECnet nodes are reachable, I can see adjacency to this node on
  DECNIS LAN circuit:

   MOSDNS/System> mc ncl show node DEC:.mow.mosnis"system password" -
   _MOSDNS/System> routing circuit mow-lan adjacency RTG$0131 all

       Node MOSNIS Routing Circuit MOW-LAN Adjacency RTG$0131
       at 1997-05-07-12:53:56.450+04:00Iinf

       Identifiers

           Name                              = RTG$0131

       Status

           Type                              = Autoconfigured
           State                             = Up
            State                             = Up
           LAN Address                       = AA-00-04-00-F1-D1
           Neighbor Node Type                = Phase V Endnode
           Endnode IDs                       =
              {
                 AA-00-04-00-F1-D1
              }
           Endnode NETs                      =
              {
                 49::00-34:AA-00-04-00-F1-D1:00
              }


 Can  VAXPHV04_061 NET$CSMACD/NET$FDDI patch kit help in this situation?

 Thanks again,
 Kirill.

    NET$CSMACD/NET$FDDI is not part of Routing.

        
        NET$ROUTING_FILTER in action maybe? $SHO LOGI NET$ROUTING_FILTER
        and maybe just to make it sure
        
	$ net$ishfilter = "$sys$update:net_ishfilter"
	$ net$ishfilter STATUS
	$ net$ishfilter disable	!if approriarite
        
        _veli
        
        

Great Thanks, Veli,

  that's exactly the reason..
  I partly solved it manually defining router address.

  As always as you consider something terrible, 
  the answer is easy.. Somebody installing MTA/MTS was playing
  with network startup files. NET$LOGICALS.COM was modified 
  and as a result among others - net$routing_filter was true.

Again,
wishing you success,
Thanks for the help.

 Kirill.

        Pleasure to help. And too bad you had such a bad luck against
        Canada today.
        
        _veli