| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
Hello,
Recently I ran into a combination inconsistency/DNS data base
corruption problem.
A node4 recenlty had an area address change which was made from NCP from
another machine other than the DECmcc machine. Every evening the NCP
database is updated to contain the current node and address information. So
this node4 had it's address both locally and in the local NCP database changed
via NCP not MCC. Obviously this has led to MCC database corruption.
Following is a log file for this node4 showing that it is now only
accessible by using the Node Synonym and not the full DNS database name.
Is this the inconsistent data that I can expect when I manage my
network with both MCC and NCP?( In the manual there is a warning
that says "Manae your network with DECmcc, in preference to NCP, as much as
possible. DECmcc has many features that help it maintain a consistent view
of the network. NCP does not use these features. If you manage with NCP
sporadically, you may subsequently receive inconsistent or incorrect
information from DECmcc.")
Is the inconsistency with how the PHASE IV access module handles a command
when the node synonym and the full DNS name is used normal? I am assuming
because of this inconsistency, that is why I can only access this node via
the Node Synomym after the address change.(The inconsistency can be seen
in the log below by looking at the line directly after the given command.
MCC translates Node Synonyms to DECnect addresses, but not complete DNS
names. Why is this ?)
How can I avoid this problem in the future? From reading this Warning and
my now corrupt database, it seems the only way, if DECmcc is to be usefull,
is that EVERY system manager use DECmcc to do any network management of
their local node. Which would mean logging into another machine in order
to change their own DECnet address or parameters, because not every machine
has DECmcc installed. In the case of routers, etc, this would be
possible, but not every node on the network. What exactly for inconsistencies
or inccorrect data can I expect from a mixed (DECmcc and NCP) managed network?
Is this a problem that other network managers are running into and how
do they handle this? Do they manage all nodes centrally, or?
Thanks in advance,
Julie Ann
DECmcc (T1.2.4)
>MCC SHOW NODE4 BYFR01 ALL ATTRIBUTES
Node4 15.26
AT 20-MAR-1992 12:40:28 All Attributes
Name = BYFR01
Address = 15.26
State = On
Physical Address = AA-00-04-00-1A-3C
Active Links = 2
nmfoperationalState = Enabled
Seconds Since Last Zeroed = 23694 Seconds
User Bytes Received = 1020 Bytes
User Bytes Sent = 9046 Bytes
Total Messages Received = 568 Messages
Total Messages Sent = 620 Messages
Connects Received = 27 Connects
Connects Sent = 34 Connects
Response Timeouts = 0 Timeouts
Received Connect Resource Errors = 0
Maximum Logical Links Active = 3 Links
Aged Packet Loss = 2 Packets
Node Unreachable Packet Loss = 0 Packets
Node Out-of-Range Packet Loss = 0 Packets
Oversized Packet Loss = 0 Packets
Packet Format Error = 22
Partial Routing Update Loss = 0
Verification Reject = 0
Counter Creation Time = 20-MAR-1992 06:05:38.13
Identification = "DECrouter 2000 V1.2 BL12"
Management Version = V4.2.0
Delay Factor = 80
Delay Weight = 5
Inactivity Timer = 60 Seconds
Maximum Links = 1024 Links
NSP Version = V4.1.0
Retransmit Factor = 10
Maximum Area Cost = 1022
Maximum Area Hops = 30
Broadcast Routing Timer = 40 Seconds
Buffer Size = 576 Bytes
Maximum Address = 1023
Maximum Area = 63
Maximum Broadcast NonRouters = 1022
Maximum Broadcast Routers = 32
Maximum Buffers = 500
Maximum Cost = 1022
Maximum Hops = 30
Maximum Visits = 63
Routing Timer = 600 Seconds
Routing Version = V2.0.0
Segment Buffer Size = 576
Type = AreaIV
Host Address = 1.5
Host Name = BYLV01
Location = "BYF 460 F3 RRECHNERRAUM"
Implementation Desc = -- Attribute Not Available
Responsible Person = "KRETSCHMER"
Phone Number = "31412"
MAIL Account = -- Attribute Not Available
Remarks = -- Attribute Not Available
Text File = -- Attribute Not Available
Node does not support requested directive.
MCC>SHOW NODE4 .EU.BY.BYF.BYFR01 ALL ATTRIBUTES
Node4 DECNOS_NS:.EU.BY.BYF.BYFR01
AT 20-MAR-1992 12:41:10 All Attributes
Node not currently accessible.
Location = "BYF 460 F3 RRECHNERRAUM"
Implementation Desc = -- Attribute Not Available
Responsible Person = "KRETSCHMER"
Phone Number = "31412"
MAIL Account = -- Attribute Not Available
Remarks = -- Attribute Not Available
Text File = -- Attribute Not Available
MCC>SHOW NDOE 0 REMOTE NODE BYFR01
Using default ALL IDENTIFIERS
Node4 1.82 Remote Node 15.26
AT 20-MAR-1992 12:41:30 Identifiers
Examination of Attributes shows:
Address = 15.26
Name = BYFR01
MCC> SHOW NODE4 0 REMOTE NODE .EU.BY.BYF.BYFR01
%MCC-W-ATTRUNKNOWN, unknown attribute REMOTE
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2603.1 | You must use MCC to ensure MCC & NCP are in synch. | CUJO::HILL | Dan Hill-Net.Mgt.-Customer Resident | Sun Mar 22 1992 01:10 | 18 |
To answer your question, there is no mechanism in place for DECmcc to
allow for changes to be made via NCP and then have those changes
propogated to DNS so that MCC and NCP databases are synchronized. You
must use MCC for all changes.
There really is no way around it. If you want the benefits of MCC,
you have to be willing to make a sacrifice or two. Becoming a DNS mutant
is one. Enforcing certain network management procedures (e.g.,
everyone use MCC instead of NCP to make changes) is another.
You could really become a "network Nazi" and force everyone to go to
one person, as we do for our network management.
As with everything, there are trade-offs. Quick and uncontrolled
changes to network databases get you running in the short term, but
you'll pay the price in extended trouble-shooting sessions later.
-Dan
| |||||
| 2603.2 | really everything centrally managed | COL01::LUNT | Mon Mar 23 1992 13:10 | 13 | |
Hi again,
Does this mean, that in order for DECmcc to be consistent I have
to manage all the remote nodes in my network from my DECmcc machine?
You said that there you manage all centrally. I always thought within
Digital that
only the node names and addresses were given out centrally, but
each person then manages their own nodes. Isn't there a way to only
update my MCC machine without having to perform remote management for
every node registered in DECmcc?
Julie Ann
| |||||
| 2603.3 | Depends on what you really need to manage | CUJO::HILL | Dan Hill-Net.Mgt.-Customer Resident | Thu Mar 26 1992 01:51 | 36 |
My customer (not a Digital site) requires very tight control on our
network. Node name changes are coordinated and managed from a central
point. This makes it easier (though still not perfect) as far as
management is concerned.
On a corporate level, it would be next to impossible to force everyone
to comply with such rules, especially in dynamic environments with no
configuration management controls in place. This is even more true if
more than one group, or worse yet, if every user, can change his node
name, type, location, etc. without coordinating with network management
personnel. In a case like this, you would spend more time managing the
changes than you would spend fixing (or anticipating) problems.
Central management is part of gaining control and being able to track
down and fix (or prevent) problems more readily. Problem is, users
HATE control. They don't like to comply, yet they want problems fixed
immediately.
You and your customer must determine what works best for your speicific
environment.
There is nothing in place that allows MCC to be updated based on user
changes. It would make life simpler, but it doesn't exist.
There is something that may help you validate your configuration,
though. It is AUTOCONFIGURATION/AUTOTOPOLOGY. This would allow you to
match the bridge/router view of the network with what you have layed
out. Think about it and you'll see what I mean. If you really
stretched it, I supposed with a lot of work you could develop
procedures that validated the network topology and updated your
configuration to match what was really there. This would be a LOT of
work though.
-Dan
-dan
| |||||