HP3000-L Archives

November 2013, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Gary Stephens <[log in to unmask]>
Reply To:
Gary Stephens <[log in to unmask]>
Date:
Wed, 13 Nov 2013 09:01:33 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (200 lines)
Thanks Craig,
that was the one: Getting old is not fun, all the 1's and 0's start getting in the wrong order ;-)

Jeff: Good call, on a cisco device you can do a clear mac address-table dynamic 
that would clear the aforesaid table, if its a busy switch you would potentially see some degradation of traffic I guess, for a second or to whilst arp sorts things out but not something that should cause concern, 
would be interesting to see if that worked, have never tried it myself, its always been the internet;update command.
interesting...

On 13 Nov 2013, at 02:44, Craig Lalley <[log in to unmask]> wrote:

> NETCONTROL NET=lan1;UPDATE=INTERNET
> 
> from my aging memory, I will try it out tomorrow.
> 
> -Craig
> 
> Sent from my iPad
> 
>> On Nov 12, 2013, at 2:02 PM, John Maclerran <[log in to unmask]> wrote:
>> 
>> Hmmm. I don't see anything in either NSCONTROL or LINKCONTROL that has an
>> INTERNET= type parameter.
>> 
>> NSCONTROL [ start, stop, abort, autologon, loadkeys, log=, server=, status,
>> mod ]
>> NSCONTROL STATUS shows info about people currently logged in via NS/VT, as
>> well as other ns service status items, but nothing about gateways or MAC
>> addresses.
>> 
>> LINKCONTROL has STATUS= and TRACE= options, and if I do a
>> 
>> LINKCONTROL @;STATUS=ALL, I get
>> 
>> Linkname: LANLINK   Linktype: PCI 100BT        Linkstate:
>> CONNECTED
>> Physical Path:              0/0/0/0
>> Current Station Address:    00-30-6E-0C-4C-49
>> Default Station Address:    00-30-6E-0C-4C-49
>> Current Multicast Addresses:
>> 09-00-09-00-00-01  09-00-09-00-00-03  09-00-09-00-00-04
>> 09-00-09-00-00-06
>> 
>> Transmit bytes            61628547519    Receive bytes
>> 3867900143
>> Transmits                    51716332    Receives unicast
>> 27168338
>> Transmits no error           51716332    Receives broadcast
>> 4241358
>> Transmits dropped                   0    Receives multicast
>> 68732
>> Transmits deferred                  0    Receives no error
>> 31426928
>> Transmits 1 retry                   0    Recv CRC
>> error                      0
>> Transmits >1 retry                  0    Recv Maxsize
>> error                  0
>> Trans 16 collisions                 0    Recv dropped: addr
>> 21426
>> Trans late collision                0    Recv dropped: buffer
>> 30074
>> Trans underruns                     0    Recv dropped:
>> descr                 0
>> Carrier losses                      0    Recv dropped:
>> other                 0
>> Trans jabber timeout                0    Recv watchdg
>> timeout                0
>> Link disconnects                    0    Recv
>> collisions                     0
>> Link speed                        100    Recv
>> overruns                       0
>> Link duplex                      Full    Link auto sensed
>> No
>> Link mode             100Base-TX Core    Secs since clear
>> 4317947
>> 
>> 
>> The section under 'Current Multicast Addresses:' look like MAC addresses,
>> but I can't see anything in LINKCONTROL to be able to refresh that list.
>> 
>> 
>> 
>> 
>> On Tue, Nov 12, 2013 at 11:46 AM, Howard Hoxsie <[log in to unmask]>wrote:
>> 
>>> I seem to recall (like Gary Stephens) that MPE caches the MAC for the
>>> gateway, and that there is a LINKCONTROL or NSCONTROL command that updates
>>> with an "INTERNET=@" or "INTERNET=ALL" clause.  It's been a few years
>>> though...
>>> 
>>> Good luck!
>>> 
>>> Howard
>>> 
>>> 
>>>> On Tue, Nov 12, 2013 at 10:36 AM, John Maclerran <[log in to unmask]> wrote:
>>>> 
>>>> Thanks Donna that clarifies a lot.
>>>> 
>>>> We have a shutdown command file that basically stops all jobs, aborts all
>>>> sessions, ups the jobfence so nobody can log in, and brings down the
>>>> network interface. It doesn't do an MPE shutdown (i.e. no SHUT x
>>>> messages),
>>>> it leaves the system up, but with only operator.sys logged in on the
>>>> master
>>>> console.  A corresponding startup command file restarts the network,
>>>> restreams the background jobs and returns the fence to normal for users to
>>>> log in.
>>>> 
>>>> It sounds like we should do the shutdown just prior to the maintenance,
>>>> and
>>>> then a startup afterward.  No need to physically restart the system though
>>>> (i.e. ctrl-a SHUTDOWN, ctrl-b RS)
>>>> 
>>>> 
>>>> 
>>>> On Tue, Nov 12, 2013 at 11:06 AM, Donna Hofmeister <[log in to unmask]
>>>>> wrote:
>>>> 
>>>>> On Tue, Nov 12, 2013 at 9:59 AM, Gary Stephens
>>>>> <[log in to unmask]>wrote:
>>>>> 
>>>>>> wasnt there a gateway reset command, as I recall you could either do
>>>> an
>>>>>> nscontrol xxx internet;reset alternatively shut and restart the
>>>> network,
>>>>> or
>>>>>> something similar?
>>>>>> I am sure Donna will remember though!
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 12 Nov 2013, at 17:17, Jack Connor <[log in to unmask]
>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> If you're taking it off the air for the network changes, John, I'd
>>>> go
>>>>>> ahead and close the network down until the work has completed and then
>>>>>> reopen it.
>>>>>>> 
>>>>>>> MPE will be looking for the IPs as it opens up.  I know you can see
>>>> the
>>>>>> MAC addresses in NETTOOL, but I don't think they're of any import
>>>> other
>>>>>> than informational and for DTC traffic.
>>>>> 
>>>>> I agree with what Jack said -- halt the network (even the system if
>>>>> possible -- because it's almost the same thing...) while the larger
>>>> network
>>>>> work is being done.  When the new gear is in place and seems stable
>>>> "wake
>>>>> up" the 3000 and watch to what happens.
>>>>> 
>>>>> When you halt the network (presuming you're not taking the box down) be
>>>>> sure to halt/quiesce network-dependent things (like jobs/listeners) just
>>>>> prior.  I'd suggest doing an 'openq' on your network printers as well
>>>> (keep
>>>>> the input side of printing open, but not the output side).   (And if
>>>> you're
>>>>> thinking "gee, it's almost like shutting down the system" see the
>>>> paragraph
>>>>> before this one :-)            - d
>>>>> 
>>>>> --
>>>>> Donna Hofmeister
>>>>> Allegro Consultants, Inc.
>>>>> 408-252-2330
>>>>> 
>>>>> * To join/leave the list, search archives, change list settings, *
>>>>> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>>>> 
>>>> 
>>>> 
>>>> --
>>>> John MacLerran, IT Analyst, Senior ([log in to unmask])
>>>> Idaho State University <http://www.isu.edu> -- Leading in opportunity and
>>>> innovation
>>>> (208)282-2954
>>>> http://picasaweb.google.com/jmaclerran
>>>> 
>>>> * To join/leave the list, search archives, change list settings, *
>>>> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>> 
>> 
>> -- 
>> John MacLerran, IT Analyst, Senior ([log in to unmask])
>> Idaho State University <http://www.isu.edu> -- Leading in opportunity and
>> innovation
>> (208)282-2954
>> http://picasaweb.google.com/jmaclerran
>> 
>> * To join/leave the list, search archives, change list settings, *
>> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> 
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2