cja@flamingo.nersc.gov (Cathy Aronson) (10/02/90)
I was wondering if anyone else besides us has been having trouble
using static subnet defaults with versions 8.1(14) and/or 8.1(19)?
It is a very strange problem. Everything works fine until the
box reloads. Then the network is known via "static" instead of
just the subnet being known via "static" and the network itself
being known via "connected".
When this happens the network itself is no longer distributed
into the appropriate routing processes (even if you try using
redistribute static). Our set up worked just fine til
8.1.
Here is the kicker. The only way to make the problem go away,
is to configure the box from memory. I have tried everything else
and conf from mem is the only thing that makes the network known
again via "connected". I can reproduce this problem over and over
whenever I want. There is no difference between what is in the
volitile mem, and what is in non-volitile memory at the time
that I config it from memory.
The problem happens on two of the three routers that we are using
static default subnet on.
If anyone has any ideas, or if anyone else has seen this,
please let me know.
Thanks a lot!
Cathy Aronson
National Energy Research Supercomputer Center
Lawrence Livermore National Laboratory
cja@marmot.nersc.gov
415-422-4016fortinp@bwdls56.bnr.ca (Pierre Fortin) (10/03/90)
In article <27385@boulder.Colorado.EDU>, cja@flamingo.nersc.gov (Cathy Aronson) writes: [stuff deleted] > I can reproduce this problem over and over > whenever I want. There is no difference between what is in the > volitile mem, and what is in non-volitile memory at the time > that I config it from memory. > We've also run across a problem related to non-volatile memory (my coleague should have reported it directly to cisco by now). At any rate, my conclusion was that the NV memory actually contained lots of stuff which is *not* displayed with "show config". To cisco (avoided using caps... :^) ): Can you provide an optional parameter to allow showing *all* contents of the NV memory? Something like "show config all"; and why not "write term all" while you're at it? In our case, a "write erase" quickly followed by "write memory" was required to get rid of a persistent "no ip route-cache" statement which would disappear with "no ip address" and reappear when an IP address was coded. > > Cathy Aronson > National Energy Research Supercomputer Center > Lawrence Livermore National Laboratory > cja@marmot.nersc.gov > 415-422-4016 Cheers, Pierre Pierre Fortin Bell-Northern Research I know, my postings are Internet Systems P.O.Box 3511, Stn C terse and humourless. So? (613)763-2598 Ottawa, Ontario RIP: aptly named protocol Canada K1Y 4H7 AppleTalk: Adam&Eve's design
lougheed@cisco.com (10/04/90)
When you do a "show configuration" you do indeed see the entire contents of NVRAM, except for a "magic number" indicating the memory was written, a byte count, and a checksum. We store the configuration commands in NVRAM as ASCII text. To avoid consuming too much memory, only the non-default configuration settings are entered into the NVRAM when you do a "write" command. In the case you mention, I suspect entering the command "ip route-cache" would have done the trick. Kirk Lougheed cisco >> We've also run across a problem related to non-volatile memory (my coleague >> should have reported it directly to cisco by now). At any rate, my >> conclusion was that the NV memory actually contained lots of stuff which >> is *not* displayed with "show config". >> >> To cisco (avoided using caps... :^) ): Can you provide an optional >> parameter to allow showing *all* contents of the NV memory? >> Something like "show config all"; and why not "write term all" while you're >> at it? >> >> In our case, a "write erase" quickly followed by "write memory" was required >> to get rid of a persistent "no ip route-cache" statement which would >> disappear with "no ip address" and reappear when an IP address was coded.