QUESTION:
We have a 6611 Frame Relay network of about 40 remote sites.
We had a problem with NV/6000 V1 in that it would periodically
show a remote 6611 as being down (red), but it really was not.
There wasn't even temp errors on the link at the time. We played
with timers in NV/6000, but never fixed the problem.
Now we have upgraded to NV/6000 V2.1. We still have the problem.
Questions:
1. What is NV/6000 sending out to the router interfaces to periodically
check statuses.
2. Is there an NV/6000 timer that we can adjust to allow for a
longer response time to the status poll?
---------- ---------- ---------- --------- ---------- ----------
A: Netview is pinging machines on the network to determine if they are
down. It is possible that you either have a very slow response time
from these routers (determine this by pinging them from the command
line an looking at the 'time=' field) or performance problems with
netview due to lack of memory or paging space. The timeout wait for the
pings and ping retries is only adjusted under: Options -> SNMP
Configuration (which you may have already adjusted). Try very high
values of timeout and retries for the routers and see if this solves
your problems. If not, please reply.
Thank you.
---------- ---------- ---------- --------- ---------- ----------
QUESTION:
I have looked at the AIX machine NV/6000 is running on.
It has 64 Meg of real memory. There are 2 paging spaces defined,
"paging00" and "hd6". They were both set at 48Meg. I increased
them both (I didn't know which NV/6000 ran in) to 100 Meg.
As for the TIMEOUT and RETRIES parameters, I increased them
from .8 seconds to 8.0 seconds and from 3 to 7 retris respectively.
No chance in the problem. I will go back out and measures ping
times myself. Any more suggestions?
---------- ---------- ---------- --------- ---------- ----------
QUESTION:
I have find PMR 3E236, which is the exact fit for our problem.
It is still open. It sounds like this is really a 6611 problem.
What do you think?
---------- ---------- ---------- --------- ---------- ----------
A: Please send me the information you get when you ping the routers.
You also need to bring netmon down after you made the changes. The
best and most complete way to do this is bringing netview down with
ovstop and starting back up with nv6000.
Thank you
---------- ---------- ---------- --------- ---------- ----------
QUESTION:
We stopped netmon and restarted it. We still have the same
problem. The customer pinged 6611s that showed red. The
slowest response was about 130ms. The average was 80ms.
What do you think?
---------- ---------- ---------- --------- ---------- ----------
A: In reading the PMR you mentioned, I found others with similar
problems: PMRs 0117X and 0436X. Please reference these for more
information. In them I found some key problems. One or all of these
may solve your problem. However, PMR 3E236 is still open and unsolved.
If these do not solve your problem, reply and we can possibly forward
this to the 6611 group for further action.
Make sure you have the following PTFs installed on your 6611s depending
on the level:
1.1.0.0 -> NP00293
1.1.0.1 -> NP00294
1.1.1.2 -> NP00287
Make sure you have the following PTFs installed on the NV/6000 machine:
U428927 and U429307
The PTFs must be installed and committed. After you apply the PTFs you
need to:
1) Bring down NV6k.
2) Bring up all daemons except netmon
3) Run ovtopofix -a
4) Bring up the graphical interface
5) Show all hidden objects.
6) Go into all location symbols. Find ALL symbols in the user
plane, and delete them from all submaps (use delete object function).
7) exit graphical interface.
8) run ovtopofix -a
9 start netmon
10) bring up graphical interface
11) as nodes discovered, drag them to IP Internet submap.
12) After all symbols have been moved to IP Internet submap, use
cut and paste functions to move gateway and network symbols
to the proper location submaps. Do NOT use the copy function.
If symbols are in the user plane after cutting and pasting,
then something was done incorrectly, and the symbols
need to be deleted and rediscovered again.
13) After customization is complete, bring down graphical interface
one last time and run ovtopofix -a.
14) All meta-connections should be fine after this.
15) One note: T1 lines are not treated by NetView/6000 as serial
(they can be used as non-Point to Point in some cases), so
the network submaps of some serial nets will look a little
strange.
Please try and let us know if it helps. and don't forget to do a backup
of the openview database before you started above steps. Thanks.
Some of the PMRs even stated clearing the openview database and
rediscovering the network as a last resort. Do this if the above does
not work. Call 1-800-CALLAIX or use fixdist to obtain the PTFs if they
are not installed.
Thank you.
---------- ---------- ---------- --------- ---------- ----------
This item was created from library item Q674117 FDNSW
Additional search words:
ADJUST AIX ALTERNATE AUTO AUTOMATIC COMMUNICATIO DOWN FDNSW INDEX IX
NETVIEW NON NOV94 NV OZIBM OZNEW REALLY REMOTE RISCNETV RISCSYSTEM
RJE ROUTERS SHOWING SOFTWARE STOP 6000 6611
WWQA: ITEM: RTA000050705 ITEM: RTA000050705
Dated: 10/1996 Category: RISCNETV
This HTML file was generated 99/06/24~12:43:19
Comments or suggestions?
Contact us