Subject: (usr-tc) WTB: USR Hiper ARC

From: "Steve Rivera -www.wrca.net" <[email-masked]>
Date: Mon, 07 Aug 2000 23:06:46 +0000

I am in the market for USR Hiper ARC's w/ nics.
Please email qty and price off list.

Thanks in advance.

Steve Rivera (VP) - w-732-833-2111 /  c-732-433-5890 24Hr
www.isp-networkhardware.com
ICQ# 75229638
Email: [email-masked]
Mobile Email: [email-masked]

Worldwide Provider of Network Hardware Since 1981.
Cisco, Ascend,USR,Adtran, Kentrox,Livingston, Microcom,Computone,Verilink,
IBM,Motorola,UDS,Codex,ATT,Paradyne,Hayes,Racal,GDC,Telebit,MultiTech,
Sync/Tylink,Wellfleet,,Black Box,Micom, APC Batteries & More

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Ken Kirchner <[email-masked]>
Date: Tue, 08 Aug 2000 03:54:38 +0000

We've had several incidents here in the past few months where our MPIP
serving HARC somehow thinks it's about 20 years in the future. Even though
the NTP server is set, it manages to get the wrong date and time and keep
it for hours.  Only after it is manually reset does it seem to function
normally.  This HARC doesnt differ from our other 13 HARCs by much (2 of
the others are MPIP servers as well and do not exhibit this problem, but
they do not serve nearly as many other HARCs).  We have swapped out the
HARC but this has not solved the problem.  Has anyone ran into this
before? 

-- 
Ken Kirchner                   :  [email-masked]
Assitant System Administrator  :  Tel (318)222-2638
ShreveNet, Inc.                :  Fax (318)213-2650

ShreveNet - Your Premium Internet Service Provider!

-

---

From: Marcelo Souza <[email-masked]>
Date: Tue, 08 Aug 2000 04:08:33 +0000

My ISDN users are claiming that that could not send e-mail
attachments when connected to my ISDN lines. It is the same chassis that I
have another DSP with v.90 that works well.
	My log says nothing. 
	My hiper Arc is v.4.1.59 and the DSP is 2.0.60.

- Marcelo

-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 08 Aug 2000 04:15:11 +0000

Also sprach Ken Kirchner
>serving HARC somehow thinks it's about 20 years in the future. Even
>though the NTP server is set, it manages to get the wrong date and time
>and keep it for hours.  Only after it is manually reset does it seem to
>function normally.  This HARC doesnt differ from our other 13 HARCs by
>much (2 of the others are MPIP servers as well and do not exhibit this
>problem, but they do not serve nearly as many other HARCs).  We have
>swapped out the HARC but this has not solved the problem.  Has anyone
>ran into this before? 

I've never run into that...but I think I'd be turning off the MPIP
server_state on that one.  Keeping in mind, of course, that MPIP is
rather dependant on having the time synchronized between systems, having
an MPIP server with the wrong idea of what time it is can be a very big
problem.  While that Arc may still go all wiggy as to what time it
thinks it is, if its only an MPIP client, at least it'll only be
affecting calls that it takes, and not calls that are on other Arcs that
are using it as an MPIP server as well.

Oh...and I wouldn't worry about the MPIP clients, as long as they have
another MPIP server configured, they'll fail-over to it without any
significant problems.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: [email-masked]
Date: Tue, 08 Aug 2000 14:01:54 +0000

Quoting Ken Kirchner <[email-masked]>:

> though
What does the syslog say? If there is a NTP issue you should see corresponding 
syslog entries

-V

-

---

From: [email-masked]
Date: Tue, 08 Aug 2000 14:04:43 +0000

> 	My hiper Arc is v.4.1.59 and the DSP is 2.0.60.

I do remember an issue with MTU with 2.0.60 code.  setting the default user 
with MTU of 576 usually resolved the issue.  The correct way to fix this
is to use the latest code.

The workaround for this is 

set user default mtu 576

-V

-