home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.xmission.com
/
2014.06.ftp.xmission.com.tar
/
ftp.xmission.com
/
pub
/
lists
/
usr-tc
/
archive
/
usr-tc.199909
< prev
next >
Wrap
Internet Message Format
|
1999-09-30
|
964KB
From: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) TC and Cistron
Date: 01 Sep 1999 11:57:15 -0400 (EDT)
On Tue, 31 Aug 1999, Tavis Morse wrote:
> Hello,
> I'm trying to set up cistron radius to work with the HiperArc,
> does anyone have this working? If so, I'm wondering what typical clients
> and users file entries might look like.
Works great here. The clients file is easy enough -- hostname of your
ARC's and NMC's in the left column, then the Radius shared secret in the
right column, with a tab in between.
The shared secret is case sensitive, so you might want to put it in quotes
on the ARC -- not sure if that's necessary, but doesn't hurt to be sure.
Our default users entry is:
DEFAULT Auth-Type = System
Port-Limit = 1,
USR-Max-Channels = 1,
USR-IP-SAA-Filter = 1,
Session-Timeout = 43200,
Idle-Timeout = 1800,
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 255.255.255.254,
Framed-IP-Netmask = 255.255.255.255,
Framed-Routing = None,
Framed-Compression = Van-Jacobson-TCP-IP,
Framed-MTU = 1500,
Filter-Id = "dialup"
> I have been trying to get it working unsuccessfully for 2 days.,
> so far I can't even get the radius.log to show any activity at all with the
> -y flag. TCPdump shows 'datametrics' packets coming in.
try tcpdump -n so you get actual port numbers, or grep /etc/services and
see what "datametrics" maps to...
One thing that can trip you up is that some Radius servers (definitely
Livingston, maybe Cistron too) look in /etc/services for "radius" and
"radacct" to figure out what port to listen on. On FreeBSD at least,
/etc/services shows ports 1812 and 1813. The ARC defaults to 1645 and
1646. You can either fix the ARC or fix /etc/services, but you'll have to
fix one of them to make things work. We decided to fix /etc/services, but
one of these days I may switch to the newer port numbers...
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) SNMP OID to reset card
Date: 01 Sep 1999 12:12:12 -0400 (EDT)
On Mon, 30 Aug 1999, Paul Farber wrote:
> What OID can I send to reset a DSP?
It's a set of OIDs, and then there's yet another OID you have to poll for
the result code. (tcpdumping a TCM session makes more sense out of it)
You should be able to Hardware reset any card with:
1.3.6.1.4.1.429.1.1.7.1.1.4.slotno = integer 4
1.3.6.1.4.1.429.1.1.7.1.1.6.slotno = string "00"
then keep checking 1.3.6.1.4.1.429.1.1.7.1.1.7 til you get a 2, and
..1.1.7.1.1.8 until you get a 1. You'll get that when the command goes
through, though, not when the card is done resetting...
(I hope I don't have that backwards, I'm going off of some source code to
a Perl script I never finished...)
> Where can I get a good, up to date reference of the SNMP OID's for the
> DSP's?
ftp://totalservice.3com.com/pub/.docs/24100003.pdf
ftp://totalservice.3com.com/pub/.docs/24166100.pdf
> Is there a LINUX version of TCM yet? I remember a list post to mail a guy
> at 3Com... and luck yet?
No, but several people have gotten pretty big chunks of it re-implemented
in Perl...
> Has anyone got TCM to run under X w/Wine?
That's a scary thought. :)
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) RE: IP Spoofing
Date: 01 Sep 1999 12:40:45 -0500
HiPer>> SET NET USER DEFAULT PPP_SOURCE_IP_FILTER ENABLED
CLI - Request SET NETWORK USER failed because item is not in table
Do I need some kind of default user to take advantage of this?
SMT
-----Original Message-----
Sent: Tuesday, August 31, 1999 10:52 AM
Cc: Totalcontrol
It is wrong.. the command is
"SET NET USER DEFAULT PPP_SOURCE_IP_FILTER_ENABLED"
-M
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
|Sent: Monday, August 30, 1999 5:08 PM
|To: usr-tc@lists.xmission.com
|Subject: Re: (usr-tc) IP Spoofing
|
|
|
|I'm almost sure that's wrong. I think it's something like...
|
|set net user default ppp_source_ip_filter enable
|
|although there might be a global switch you can flip. The
|radius attribute does not work.
|
|
|Jamie Orzechowski writes...
|>set nework user default spoofing enable/disable
|>
|>----- Original Message -----
|>From: Russ Miescke <russm@powerweb.net>
|>To: <usr-tc@lists.xmission.com>
|>Sent: Monday, August 30, 1999 5:02 PM
|>Subject: (usr-tc) IP Spoofing
|>
|>
|>> How do I keep people from spoofing an IP address on the TC hub.
|>> I know there is an option, but can't find it for the life of me.
|>>
|>> Russ Miescke
|>> Power Web Connect
|
|--
|Aaron Nabil
|
|-
| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
| 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.
|
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) RE: IP Spoofing
Date: 01 Sep 1999 13:45:30 -0400
Thus spake Scott Trautman
>HiPer>> SET NET USER DEFAULT PPP_SOURCE_IP_FILTER ENABLED
>CLI - Request SET NETWORK USER failed because item is not in table
>Do I need some kind of default user to take advantage of this?
I'm pretty sure usernames are case-sensitive...try default in
lower-case.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) RE: IP Spoofing
Date: 01 Sep 1999 12:55:58 -0500
set net user default ppp_source_ip_filter enabled
...you are correct sir, 'default' needs to be in lower case...!
SMT
-----Original Message-----
Sent: Wednesday, September 01, 1999 12:46 PM
Thus spake Scott Trautman
>HiPer>> SET NET USER DEFAULT PPP_SOURCE_IP_FILTER ENABLED
>CLI - Request SET NETWORK USER failed because item is not in table
>Do I need some kind of default user to take advantage of this?
I'm pretty sure usernames are case-sensitive...try default in
lower-case.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "C Thompson" <cthompson@wingnet.net>
Subject: (usr-tc) HARC Chassis sold
Date: 01 Sep 1999 14:31:51 -0500
For all who were asking about the Hiper ARC chassis with DSP modems, we have sold it.
Thanks. I received far more calls and e-mails than I anticipated and do not have the time
to return all of them personally.
Craig Thompson, Manager
WingNET Internet Services,
P.O. Box 3000 // Cleveland, TN 37320-3000
423-559-LINK (v) 423-559-5444 (f)
http://www.wingnet.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: (usr-tc) Packet filtering strategies/netbus et al
Date: 01 Sep 1999 14:35:56 -0500
Hi--
I'm reviewing my filtering strategies and wondering about the wisdom of
putting filters a) on TC unit ethernets b) on individual dialin users c)
border routers to combat netbus et al types of attacks. I've got a pretty
good list of the ports typically used (yeah, I know, can use other ports
too, but could cut down by 95%).
Assumptions/questions:
-our own users most likely will not attack each other (? assumption) support
b,c approach
-load/user performance on ARC or Netserver get to be an issue with too much
filtering?
-how big a problem is it anyway?
-how big a filter is too big? I've got about 30 lines in one already, could
easily double+ that. Limits on Netserver filters? ARC's?
We use Cisco 3640's on our borders, 2501's in smaller pops, TC units for
dialup & a couple PM3's for ISDN. Sure wish the netserver filters had a
'log' item on 'em. Really makes debugging a lot easier...as well as more
than less proactively tracking down filter problems/attacks w/syslog entries
to show....
I'm currently using some pretty modest filtering already.
..and finally...anyone doing a lot with the ARC filters? Anyone interested
in making some bucks converting a couple Netserver filters to an ARC filter?
Easy way to do it? Trying to get a set of filters I'm happy with then port
them to the ARC's. The new format, albeit "improved" and I'm sure more
"flexible" is giving me dread...
SMT
Scott Trautman 608-240-4638,4637fax
Global Dialog Internet www.gdinet.com
2810 Crossroads, STE LL2
Madison WI 53718
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike Wilker" <mikew@LL.NET>
Subject: (usr-tc) HiperDSP T-1/E-1
Date: 01 Sep 1999 14:52:14 -0500
Are the T-1 and E-1 cards the same with different code, or do you have to
get different cards to go from T-1 to E-1? Thanks.
Mike Wilker
Operations Manager
Local Link, Inc.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Marty Elliott <marty@2assetrecovery.com>
Subject: Re: (usr-tc) HiperDSP T-1/E-1
Date: 01 Sep 1999 13:17:15 -0700
At 02:52 PM 09/01/1999 -0500, you wrote:
>Are the T-1 and E-1 cards the same with different code, or do you have to
>get different cards to go from T-1 to E-1? Thanks.
>
>Mike Wilker
Mike -- don't get me going on this issue!
Same cards -- basically. The E1 version has a daughter card (35-001914-0x)
that plugs into the standard DSP NAC (p/n 69-001914-0x). It contains the
extra six ports. 3Com refuses to sell them (the daughter cards) separately
and insists you buy the card set (p/n 992267-00) for about $2000 more than
the danged T1 version.
Have been fighting over this for weeks with 3Com from Australia to
Singapore to California to Illinois to Europe.
Good luck.
Marty
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Marty Elliott
MARS, Inc.
2105 South 48th Street
Suite 104
Tempe, AZ 85282
602-426-8272
602-454-0770 fax
www.2assetrecovery.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Eric J Merkel <merkel@defnet.com>
Subject: (usr-tc) Quad Modem problem (Need help!) :)
Date: 01 Sep 1999 16:18:12 -0400
We had a major fiber cut here locally today and it knocked out several of
our T1's, one of which is coming into our TCH into a bank of 6 Quad 4
modems. When the T1 was finally restored to those modems, serveral of them
would not takes calls. FWIW we have another 6 quads and 2 hiper dsp's on 3
other T1's in this box that are working ok so it seems to be limited to the
first T1 only.
They (ports 7,8,9,10,11,12,21,22,23,24) would do one of the following:
1) call and get click, orange light, carrier, light goes dark, click
carrier, orange light, disconnect
2) call and get dead silence but orange light comes on
I've tried the following to bring these modems back to working condition:
1) Hard and soft reset of the DS0 for those modems
2) Reset the entire T1 coming into those channels
3) Did a hard and soft hardware reset on the quad cards themselves
4) Hard and soft busy and restore on those DS0's
5) Pulled the darn quad cards and reset them
6) Yank the T1 cable out and reset it
None of these worked, so I have all of these modems soft busied out until I
can think of something else to try. This T1 has been in operation a couple
of years but occasionally if it goes down, it starts doing funky things like
this. Somehow last time it happened it automagically fixed itself.
Unfortunately, it does not look like that is going to happen at this point.
Any ideas would be much appreciated. :)
Eric
Eric Merkel / MetaLink Technologies, Inc
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Email: merkel@metalink.net
Phone: 419-782-3472 X304
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Aaron Nabil <nabil@spiritone.com>
Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
Date: 01 Sep 1999 13:36:45 -0700 (PDT)
Scott Trautman writes...
>..and finally...anyone doing a lot with the ARC filters? Anyone interested
>in making some bucks converting a couple Netserver filters to an ARC filter?
Easy money, considering the ARC supports netserver syntax filters.
--
Aaron Nabil
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
Date: 01 Sep 1999 17:38:42 -0400 (EDT)
But from previous list discussions the filters were prone to not working.
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Wed, 1 Sep 1999, Aaron Nabil wrote:
> Scott Trautman writes...
> >..and finally...anyone doing a lot with the ARC filters? Anyone interested
> >in making some bucks converting a couple Netserver filters to an ARC filter?
>
> Easy money, considering the ARC supports netserver syntax filters.
>
>
> --
> Aaron Nabil
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
Date: 01 Sep 1999 18:15:01 -0400 (EDT)
On Wed, 1 Sep 1999, Scott Trautman wrote:
> I'm reviewing my filtering strategies and wondering about the wisdom of
> putting filters a) on TC unit ethernets b) on individual dialin users c)
> border routers to combat netbus et al types of attacks. I've got a pretty
> good list of the ports typically used (yeah, I know, can use other ports
> too, but could cut down by 95%).
> Assumptions/questions:
> -our own users most likely will not attack each other (? assumption) support
> b,c approach
Depends on how big you are. If you're small like us and only have 2000
customers, this is a mostly-reasonable assumption. If you're AOL or
Mindspring or even ExecPC-sized, this is a really bad assumption. :)
> -load/user performance on ARC or Netserver get to be an issue with too much
> filtering?
Hasn't been, but most of our filters are on our border.
Filter syntax on the ARC is very difficult for me to grasp -- whether it's
counterintuitive, whether I'm stupid, or whether I'm just too used to
Cisco, I don't know yet. ;) And as Paul Farber just pointed out, filters
were completely broken in some older ARC releases...
So my approach is to use the border Cisco to filter things that I want to
apply to absolutely everybody... but where there are cases where I may
want to toggle them on/off on a per-user basis, use ARC filters.
> -how big a problem is it anyway?
Depends on how many script kiddies ya got. Usually you know about them
really fast because of the questions they ask, or the filters they
trigger. For us, it depends more on how many outside script kiddies our
own users manage to piss off, which is usually directly proportional to
the number of them that use IRC... :)
> We use Cisco 3640's on our borders, 2501's in smaller pops, TC units for
> dialup & a couple PM3's for ISDN. Sure wish the netserver filters had a
> 'log' item on 'em. Really makes debugging a lot easier...as well as more
> than less proactively tracking down filter problems/attacks w/syslog entries
> to show....
The ARC has a "log" on it -- sort of. You can have it log a specified
number of bytes of each packet trapped to syslog. Unfortunately, it does
exactly that and nothing more -- dumps the *raw* packet, in hex. It's up
to you to parse the packet manually to figure out if it's a TCP/IP packet
or not, and then get the source/destination address, protocol, and port
numbers or which ICMP message it is. Ugh...
Anyway.
What I'm doing on the ARC:
- Filter TCP port 139 going to and from the user, because of both Winnuke
and because of customers doing stupid things with file sharing.
- Filter TCP port 25 going to anywhere except our own mail server for
customers less than a month old. The idea is to thwart hit-and-run
spammers that sign up with a fake address, abuse some offsite open SMTP
relay, and never call back when you cancel them. This happened to us
twice recently. Twice too many.
- In Radius, provide a knob to disable either of these for the few people
that legitimately need it -- we just put these people in a particular Unix
group and have an alternate default entry pick 'em up. (You'd be
surprised how many NT servers at State Government offices are open for
file sharing across the Internet...)
- In Radius, use the USR-IP-SAA-Filter VSA to prevent IP spoofing, unless
the user has a subnet routed to them. We don't use the global switch on
the ARC; we'd rather do it in Radius so it can be turned off on a per-user
basis.
That's all we do on the ARC. The filters are well under 10 lines... so no
major CPU impact... and if they cause problems for particular people, we
just add 'em to a Unix group and they go away.
On our border Cisco 3620, we are a little more facist... :)
- Block spoofed and RFC1918 addresses. (10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16... and also 127.0.0.0/8) Should be obvious.
- "no ip directed-broadcast" on every interface, to prevent smurf amping.
"no ip redirects" on the serial interfaces to the Internet.
- Block telnet to our ARCs because of the DoS attack mentioned a few weeks
ago, at least until a fix is available from 3Com...
- Block UDP port 31337 -- first version of Back Orifice. Don't know what
BO2K defaults to, if anything.
- Block TCP ports 12345, 12346, 20034 -- netbus
- Block internal services like SNMP, RIPv2 (hm, I can remove that now that
we're all OSPF), Sun RPC, nfs, tftp, MySQL, lpr, Radius, and other
oddities like port 0 that occasionally get used by script kiddie
attacks... Some of these are only blocked to/from the subnet with our
servers, and are open to dialups (just in case someone really does have to
use SNMP on a remote system, for example). Some of them are blocked for
everyone.
(I'm open to suggestions on additions/removals here, by the way. It just
now occured to me that echo and chargen might be good candidates to
block...)
- Log, but do not block, outgoing SMTP connections (syn packets only) from
our dialup IP pools.
We don't get a lot of hits on too many of these... aside from the
occasional port scan and the scan of whole subnets for old Back Orifice
setups... and we've got enough CPU left over on the 3620 to handle it.
(It's only taking two full BGP views)
But surprisingly, the *SMTP* logging actually helped me catch a Netbus
install or two that I otherwise wouldn't have noticed. Newer versions can
have the infected machine email a message to the attacker saying "hi, I'm
awake now, my IP address today is <x.x.x.x>" when the infected machine
dials in. When I first put the SMTP logging in, I found one long-time
customer was trying to send a ridiculous amount of email to a *.k12.ca.us
address. When I ran tcpdump on 'em, the word "netbus" popped up in it a
lot. We emailed a pointer to McAfee's web site to the user, and the SMTP
attempts stopped a day or two later.
Non-3Com-but-somewhat-related-question:
Has anyone tried rate limiting ICMP on a Cisco? What's the best way
(read: minimal CPU impact) to do it on IOS 11.3?
I was considering doing something like generic traffic shaping down to
256K, on an access list that matched all ICMP -- or at least ICMP echo
request/reply. (Probably wouldn't shape the one that makes MTU path
discovery work. :)
The idea would be to reduce -- slightly -- the effect of a smurf attack.
It'd still saturate our border router (unless our backbone providers did
the same), but at least it wouldn't melt down the customer's router (or
modem) as well, and they'd at least be able to use our own network during
the attack.
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Dan Hollis <goemon@sasami.anime.net>
Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
Date: 01 Sep 1999 15:21:19 -0700 (PDT)
On Wed, 1 Sep 1999, Mike Andrews wrote:
> The ARC has a "log" on it -- sort of. You can have it log a specified
> number of bytes of each packet trapped to syslog.
What id like to see is some filter rule 'if xyz then dump connection'.
Would be a real deterrence to script kiddies if they get disconnected
every time they try to backorifice or smurf someone.
-Dan
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
Date: 01 Sep 1999 19:05:47 -0400
Thus spake Mike Andrews
>Depends on how big you are. If you're small like us and only have 2000
>customers, this is a mostly-reasonable assumption. If you're AOL or
>Mindspring or even ExecPC-sized, this is a really bad assumption. :)
Perhaps, if you don't want to get into putting filters on your Arcs, and
are more comfortable with ciscos, you can put the filters at the next
hop cisco rather than on the arc directly. Doesn't get the filter quite
to the edge, but limits the damage a script kiddie can do within your
network. We don't do this, but I probably could. :)
>Filter syntax on the ARC is very difficult for me to grasp -- whether it's
>counterintuitive, whether I'm stupid, or whether I'm just too used to
>Cisco, I don't know yet. ;)
Maybe all three? ;) No...there are some aspects of the Arc's filtering
language that is a bit on the bizarre side. Putting multiple
qualifications for the same check on multiple filter rules is a bit
counter-intuitive for me.
>For us, it depends more on how many outside script kiddies our own
>users manage to piss off, which is usually directly proportional to the
>number of them that use IRC... :)
Preach it brother.
>(You'd be surprised how many NT servers at State Government offices are
>open for file sharing across the Internet...)
Oh, lovely...I already was whelmed by our state gov. Mostly from
popping up at the top of netscan.org when that first came out. You're
not inspiring much confidence here. :)
>- In Radius, use the USR-IP-SAA-Filter VSA to prevent IP spoofing, unless
>the user has a subnet routed to them. We don't use the global switch on
>the ARC; we'd rather do it in Radius so it can be turned off on a per-user
>basis.
How well does the global switch work? Does it account for network
blocks being routed to the customer? How does the mechanism actually
work internally? I'm curious as I'm considering using this, but am a
little unsure of it at the moment.
>On our border Cisco 3620, we are a little more facist... :)
>- Block telnet to our ARCs because of the DoS attack mentioned a few weeks
>ago, at least until a fix is available from 3Com...
We've talked about this before...but turning on the telnet access
limitations on the Arc's works like a charm and is safer.
>(I'm open to suggestions on additions/removals here, by the way. It just
>now occured to me that echo and chargen might be good candidates to
>block...)
We tend to not block anything going to customers. We're kinda of the
thought that they're wanting Internet Access...they get it...warts and
all. :) Obviously, if they're getting a flood type of DoS we'll put
filters on our side and stuff...but typically their gonna get a lecture
about IRC in the process. :)
>(It's only taking two full BGP views)
BGP isn't very CPU intensive except when its initially syncing up...it
*is* memory intensive, but it doesn't hit the CPU very hard (a *whole*
lot less than RIP does)
>Non-3Com-but-somewhat-related-question:
>Has anyone tried rate limiting ICMP on a Cisco? What's the best way
>(read: minimal CPU impact) to do it on IOS 11.3?
>I was considering doing something like generic traffic shaping down to
>256K, on an access list that matched all ICMP -- or at least ICMP echo
>request/reply.
I wouldn't traffic shape that, but would rate-limit it instead (the
difference being traffic-shaping buffers...rate limiting drops)
>(Probably wouldn't shape the one that makes MTU path discovery work. :)
Host Unreachable: fragmentation needed, but DF (do not fragment) set
>The idea would be to reduce -- slightly -- the effect of a smurf attack.
>It'd still saturate our border router (unless our backbone providers did
>the same), but at least it wouldn't melt down the customer's router (or
>modem) as well, and they'd at least be able to use our own network during
>the attack.
Possibly you're looking for something like priority queueing as well?
Let whatever get through, but push the ICMP stuff down to lower priority
so web/email/whatever traffic gets through in preference to the ICMP
crap.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
Date: 01 Sep 1999 19:17:07 -0400 (EDT)
On Wed, 1 Sep 1999, Dan Hollis wrote:
> On Wed, 1 Sep 1999, Mike Andrews wrote:
> > The ARC has a "log" on it -- sort of. You can have it log a specified
> > number of bytes of each packet trapped to syslog.
>
> What id like to see is some filter rule 'if xyz then dump connection'.
>
> Would be a real deterrence to script kiddies if they get disconnected
> every time they try to backorifice or smurf someone.
hahaha... that would be kinda funny, though false positives would really
suck. :)
(And of course you can't be sure they're not going to change the
port number, and you can't filter on the packet contents...)
but it is actually possible though -- just have a script "tail -f" the
syslog output, or set up an entry in syslog.conf that sends the output to
"|scriptname"... have the program fork off a telnet session to the ARC to
"disconnect user blah" when it sees a denied packet come into the log.
I've got something similar already that watches for PPP/POP3/FTP logins
and logouts, both successful and failed, and throws it into a MySQL
database, so we can quickly find out (for example) who's never even tried
to read their email.
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Aaron Nabil <nabil@spiritone.com>
Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
Date: 01 Sep 1999 17:51:14 -0700 (PDT)
Mike Andrews writes...
>- In Radius, use the USR-IP-SAA-Filter VSA to prevent IP spoofing, unless
>the user has a subnet routed to them. We don't use the global switch on
>the ARC; we'd rather do it in Radius so it can be turned off on a per-user
>basis.
This works for you? It doesn't on my V4.2.29 - 1.
--
Aaron Nabil
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Greg owens" <gowens@magnolia-net.com>
Subject: (usr-tc) DSP card needed
Date: 01 Sep 1999 19:57:53 -0500
This is a multi-part message in MIME format.
------=_NextPart_000_0035_01BEF4B4.472EE9A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
If anyone has a used (or new if the price is right) DSP card they would =
like to sell. I would surely love to buy! Need both nic & nac and card =
be guarenteed to work. You may email privately if you like. Thanks
Greg Owens
Magnolia Internet Services
http://www.magnolia-net.com=20
gowens@magnolia-net.com=20
------=_NextPart_000_0035_01BEF4B4.472EE9A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>If anyone has a used (or new if the =
price is right)=20
DSP card they would like to sell. I would surely love to buy! Need both =
nic=20
& nac and card be guarenteed to work. You may email privately =
if you=20
like. Thanks</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Greg Owens<BR>Magnolia Internet =
Services<BR><A=20
href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A> =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"mailto:gowens@magnolia-net.com">gowens@magnolia-net.com</A>=20
</FONT></DIV></BODY></HTML>
------=_NextPart_000_0035_01BEF4B4.472EE9A0--
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Grzegorz Paszka <Grzegorz.Paszka@pik-net.pl>
Subject: Re: (usr-tc) TCM under X/Wine
Date: 02 Sep 1999 11:01:28 +0200
On Mon, Aug 30, 1999 at 01:54:30PM -0400, Paul Farber wrote:
> Do you have a link to Vmware???
http://www.vmware.com
--
Grzegorz Paszka, System Administrator, Gliwice ul. Toszecka 102
e-mail: Grzegorz.Paszka@pik-net.pl tel. 48-32-2799600 wew 333
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: (usr-tc) strange DS0 states
Date: 02 Sep 1999 09:21:50 -0300
Does anyone have any idea why this is happening? It's got me baffled...
01 Idle N/A REMOTE OOS 0x00000000 NONE 0x00000000
02 Conn In 002 REMOTE OOS 0x004E0100 NONE 0x000091EB
03 Conn In 003 REMOTE OOS 0x00400200 NONE 0x00009958
04 Conn In 004 REMOTE OOS 0x00270300 NONE 0x000081CC
05 Conn In 005 REMOTE OOS 0x00310400 NONE 0x000095E7
06 Conn In 006 IS 0x00400500 NONE 0x00009860
07 Conn In 007 REMOTE OOS 0x00240600 NONE 0x00009184
08 Conn In 008 REMOTE OOS 0x004D0700 NONE 0x000084F8
09 Conn In 009 REMOTE OOS 0x00500800 NONE 0x00008D34
10 Conn In 010 REMOTE OOS 0x003F0900 NONE 0x00008955
11 Conn In 011 IS 0x00490A00 NONE 0x00008677
12 Conn In 012 IS 0x00270B00 NONE 0x000096A9
13 Conn In 013 REMOTE OOS 0x00280C00 NONE 0x00008BEF
14 Conn In 014 IS 0x00140D00 NONE 0x00009A27
15 Conn In 015 IS 0x00650E00 NONE 0x00009CF5
16 Conn In 016 IS 0x001F0F00 NONE 0x000086E9
17 Conn In 017 IS 0x00481000 NONE 0x00009A28
18 Conn In 018 REMOTE OOS 0x006B1100 NONE 0x000095E2
19 Conn In 019 IS 0x00351200 NONE 0x00008D41
20 Conn In 020 IS 0x00391300 NONE 0x000098F2
21 Conn In 021 REMOTE OOS 0x003A1400 NONE 0x00009F40
22 Conn In 022 IS 0x002C1500 NONE 0x00008E30
23 Conn In 023 IS 0x00391600 NONE 0x00009AA6
24 Dchan N/A IS 0x00000000 NONE 0x00000000
The trunk members are up and taking calls but some of them are showing out
of service. All members appear to be in service as far as the switch guys
are concerned looking at it from the DMS100 side. Any ideas?
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jim Johnson <jim@perigee.net>
Subject: Re: (usr-tc) RE: IP Spoofing
Date: 02 Sep 1999 09:45:09 -0400
What is the command to show all the settings for the default net user?
JJ
Scott Trautman wrote:
>
> set net user default ppp_source_ip_filter enabled
>
> ...you are correct sir, 'default' needs to be in lower case...!
>
> SMT
>
> -----Original Message-----
> From: Jeff Mcadams [mailto:jeffm@iglou.com]
> Sent: Wednesday, September 01, 1999 12:46 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) RE: IP Spoofing
>
> Thus spake Scott Trautman
> >HiPer>> SET NET USER DEFAULT PPP_SOURCE_IP_FILTER ENABLED
> >CLI - Request SET NETWORK USER failed because item is not in table
>
> >Do I need some kind of default user to take advantage of this?
>
> I'm pretty sure usernames are case-sensitive...try default in
> lower-case.
> --
> Jeff McAdams Email: jeffm@iglou.com
> Head Network Administrator Voice: (502) 966-3848
> IgLou Internet Services (800) 436-4456
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: RE: (usr-tc) RE: IP Spoofing
Date: 02 Sep 1999 10:49:01 -0300
"show user default" should list all the settings for the default user and
default net user.
On Thursday, September 02, 1999 10:45 AM, Jim Johnson [SMTP:jim@perigee.net]
wrote:
>
> What is the command to show all the settings for the default net user?
>
> JJ
>
> Scott Trautman wrote:
> >
> > set net user default ppp_source_ip_filter enabled
> >
> > ...you are correct sir, 'default' needs to be in lower case...!
> >
> > SMT
> >
> > -----Original Message-----
> > From: Jeff Mcadams [mailto:jeffm@iglou.com]
> > Sent: Wednesday, September 01, 1999 12:46 PM
> > To: usr-tc@lists.xmission.com
> > Subject: Re: (usr-tc) RE: IP Spoofing
> >
> > Thus spake Scott Trautman
> > >HiPer>> SET NET USER DEFAULT PPP_SOURCE_IP_FILTER ENABLED
> > >CLI - Request SET NETWORK USER failed because item is not in table
> >
> > >Do I need some kind of default user to take advantage of this?
> >
> > I'm pretty sure usernames are case-sensitive...try default in
> > lower-case.
> > --
> > Jeff McAdams Email: jeffm@iglou.com
> > Head Network Administrator Voice: (502) 966-3848
> > IgLou Internet Services (800) 436-4456
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike Wronski" <mike@coredump.ae.usr.com>
Subject: RE: (usr-tc) RE: IP Spoofing
Date: 02 Sep 1999 09:36:37 -0500
There is the global switch "ENABLE IP SOURCE_ADDRESS_FILTER" that would be the
best method of turning on this feature..
-M
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew
|Sent: Thursday, September 02, 1999 8:49 AM
|To: 'usr-tc@lists.xmission.com'
|Subject: RE: (usr-tc) RE: IP Spoofing
|
|
|
|"show user default" should list all the settings for the default user and
|default net user.
|
|On Thursday, September 02, 1999 10:45 AM, Jim Johnson [SMTP:jim@perigee.net]
|wrote:
|>
|> What is the command to show all the settings for the default net user?
|>
|> JJ
|>
|> Scott Trautman wrote:
|> >
|> > set net user default ppp_source_ip_filter enabled
|> >
|> > ...you are correct sir, 'default' needs to be in lower case...!
|> >
|> > SMT
|> >
|> > -----Original Message-----
|> > From: Jeff Mcadams [mailto:jeffm@iglou.com]
|> > Sent: Wednesday, September 01, 1999 12:46 PM
|> > To: usr-tc@lists.xmission.com
|> > Subject: Re: (usr-tc) RE: IP Spoofing
|> >
|> > Thus spake Scott Trautman
|> > >HiPer>> SET NET USER DEFAULT PPP_SOURCE_IP_FILTER ENABLED
|> > >CLI - Request SET NETWORK USER failed because item is not in table
|> >
|> > >Do I need some kind of default user to take advantage of this?
|> >
|> > I'm pretty sure usernames are case-sensitive...try default in
|> > lower-case.
|> > --
|> > Jeff McAdams Email: jeffm@iglou.com
|> > Head Network Administrator Voice: (502) 966-3848
|> > IgLou Internet Services (800) 436-4456
|> >
|> > -
|> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
|> > 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.
|>
|> -
|> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
|> 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.
|
|
|
|-
| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
| 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.
|
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
Date: 02 Sep 1999 10:46:19 -0400 (EDT)
On Wed, 1 Sep 1999, Aaron Nabil wrote:
> Mike Andrews writes...
> >- In Radius, use the USR-IP-SAA-Filter VSA to prevent IP spoofing, unless
> >the user has a subnet routed to them. We don't use the global switch on
> >the ARC; we'd rather do it in Radius so it can be turned off on a per-user
> >basis.
>
> This works for you? It doesn't on my V4.2.29 - 1.
It does appear to work here, on 4.2.29. (At least syslog is recording the
denied packets.)
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Greg Coffey <gcoffey@vcn.com>
Subject: (usr-tc) Couple of Questions
Date: 02 Sep 1999 10:09:42 -0600
I have two questions that maybe you can help with.
1. I had a 386 NMC that was x2 enabled that I took out of service due to
getting some hiperdsp's installed. This was several weeks ago. I had to
build a temporary chassis in a hurry yesterday and used the nmc card with
12 quads. It now shows that x2 is not enabled. I know its the right card
but I may have swapped the flash and/or ram with another card during the
upgrade. Does the key reside in the flash, the ram or somewhere else on
the card? Could we lose the key because the card was not in use for
several weeks?
2. All of the quads used to take calls in order. Now it is showing calls
in the middle of the group or more or less on a random or rotating
basis. Is there a setting to get them back where the first call goes to
the 1st modem, etc?
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "C Thompson" <cthompson@wingnet.net>
Subject: (usr-tc) info on aggregating ISDN lines
Date: 02 Sep 1999 12:17:09 -0500
We have a customer who wants to aggregate 2 or more ISDN lines for one
large bandwidth channel. How can they do this with a standard dialup?
I know that I can give them, say, two login names, have them login as
login1 and login2 which can both be set for a 128K login and make it the
responsibility of the equipment to provide the aggregation of 256K total,
but I wanted to check with you guys and see if this is the only way, the
best way, etc. Any equipment you know of or recommend to do this?
Please reply asap, as we are working on a project with a due date coming
up very soon.
Craig Thompson, Manager
WingNET Internet Services,
P.O. Box 3000 // Cleveland, TN 37320-3000
423-559-LINK (v) 423-559-5444 (f)
http://www.wingnet.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: RE: (usr-tc) Couple of Questions
Date: 02 Sep 1999 13:24:21 -0300
1. My impression is that it's stored on the NMC's NVRAM/EEPROM, not the
flash. I could be wrong though.
2. Your dual pri card is probably set to do round-robin modem assignment.
If you want your modems used in order and the telco has not set the LTC to
round-robin the calls on the trunk group, you can set it to fixed
assignment. Otherwise you can set it to route to the first available modem.
On Thursday, September 02, 1999 1:10 PM, Greg Coffey [SMTP:gcoffey@vcn.com]
wrote:
> I have two questions that maybe you can help with.
>
> 1. I had a 386 NMC that was x2 enabled that I took out of service due to
> getting some hiperdsp's installed. This was several weeks ago. I had to
> build a temporary chassis in a hurry yesterday and used the nmc card with
> 12 quads. It now shows that x2 is not enabled. I know its the right card
> but I may have swapped the flash and/or ram with another card during the
> upgrade. Does the key reside in the flash, the ram or somewhere else on
> the card? Could we lose the key because the card was not in use for
> several weeks?
>
> 2. All of the quads used to take calls in order. Now it is showing calls
> in the middle of the group or more or less on a random or rotating
> basis. Is there a setting to get them back where the first call goes to
> the 1st modem, etc?
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) info on aggregating ISDN lines
Date: 02 Sep 1999 12:30:54 -0400
Thus spake C Thompson
>We have a customer who wants to aggregate 2 or more ISDN lines for one
>large bandwidth channel. How can they do this with a standard dialup?
>I know that I can give them, say, two login names, have them login as
>login1 and login2 which can both be set for a 128K login and make it the
>responsibility of the equipment to provide the aggregation of 256K total,
>but I wanted to check with you guys and see if this is the only way, the
>best way, etc. Any equipment you know of or recommend to do this?
>Please reply asap, as we are working on a project with a due date coming
>up very soon.
Uhm...you can multi-link as many channels together as you want with MP.
Why not just set his Port-Limit or Max-Channels or whatever it is to 4.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: (usr-tc) Errors on PRI line
Date: 02 Sep 1999 15:18:09 -0300
I'm getting some errors on a PRI line which I reported to the telco.
They've been scoping it for a few hours now and don't see anything but I'm
still getting these errors:
span1> disp near total
Span1 Near Total Line Index is: 0
Span1 Near Total Errored Seconds is: 25
Span1 Near Total Severely Errored Seconds is: 0
Span1 Near Total Severely Errored Framing Seconds is: 0
Span1 Near Total Unavailable or Failed Seconds is: 0
Span1 Near Total Controlled Slip Seconds is: 0
Span1 Near Total Path Coding Violations is: 301
Span1 Near Total Line Errored Seconds is: 0
Span1 Near Total Bursty Errored Seconds is: 18
Span1 Near Total Degraded Minutes is: 0
Span1 Near Total Line Code Violations is: 0
Does anyone have any idea what might be causing these? And why wouldn't the
telco be able to pick these up from a scope?
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: matthew de Jongh <matthew.de.jongh@the-spa.com>
Subject: Re: (usr-tc) Telepath Modem Woes
Date: 02 Sep 1999 16:13:35 -0400
we have had consistent problems with telepath modems for years.
i'm sure about specific models but there is definitely a problem.
a customer gave us one and we couldn't make it connect no matter what we did.
matthew
At 04:19 PM 8/23/99 -0500, you wrote:
>
>I have been getting reports from techs saying that Telepath modems (model
>6000905) are having problems connecting to our USR TC chassis. I believe
>Gateway packages this modem with their pc's.
>
>Has anyone else seen problems with this modem? fix?
>
>
>-----------------------------------------------------
>Brian Feeny (BF304) signal@shreve.net
>318-222-2638 x 109 http://www.shreve.net/~signal
>Network Administrator ShreveNet Inc. (ASN 11881)
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
Date: 02 Sep 1999 19:02:29 -0400 (EDT)
On Wed, 1 Sep 1999, Jeff Mcadams wrote:
> Perhaps, if you don't want to get into putting filters on your Arcs, and
> are more comfortable with ciscos, you can put the filters at the next
> hop cisco rather than on the arc directly. Doesn't get the filter quite
> to the edge, but limits the damage a script kiddie can do within your
> network. We don't do this, but I probably could. :)
For most of our ARCs (Frankfort), the next hop Cisco *is* the border. I
know, probably not a great network design, and I could fix it nowadays,
but it's one of those evolved vs designed things...
> >- In Radius, use the USR-IP-SAA-Filter VSA to prevent IP spoofing, unless
> >the user has a subnet routed to them. We don't use the global switch on
> >the ARC; we'd rather do it in Radius so it can be turned off on a per-user
> >basis.
>
> How well does the global switch work? Does it account for network
> blocks being routed to the customer? How does the mechanism actually
> work internally? I'm curious as I'm considering using this, but am a
> little unsure of it at the moment.
Don't know because I never tried the global switch, because I didn't know
if it could be turned off with Radius. I knew it could be turned on with
Radius, so I just did that. It's been said here that it does NOT account
for customers with subnets routed to them -- which is why I wanted to be
able to turn it off in Radius. But for your average joe dialup guy, it
seems to work fine.
> >(I'm open to suggestions on additions/removals here, by the way. It just
> >now occured to me that echo and chargen might be good candidates to
> >block...)
>
> We tend to not block anything going to customers. We're kinda of the
> thought that they're wanting Internet Access...they get it...warts and
> all. :) Obviously, if they're getting a flood type of DoS we'll put
> filters on our side and stuff...but typically their gonna get a lecture
> about IRC in the process. :)
Yeah, and that's one thing I try to keep in mind before adding any more
filters -- too easy to screw up legitimate use. (Especially with the port
139 one... there are some mp3 leeching programs that use that to make the
file transfers harder to track.) But for some of the DoS-prevention ones,
I'd rather spend time on the phone explaining filters than time on the
phone explaining how to remove Back Orifice from their PC. :) (Been
there, done that, wasn't fun)
You can get into the same religious argument with spam, and liability for
attacks/spam/whatever that do get through (if you don't filter, you're not
liable; if you do, you might be) and all the other fun policy crap I got
to learn by working at an .edu site for 3 years... :) But we won't get
into that here...
The trick is to try to find a balance between convenience and security.
You always end up having to compromise something on both sides.
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Aaron Nabil <nabil@spiritone.com>
Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
Date: 02 Sep 1999 16:19:12 -0700 (PDT)
Mike Andrews writes...
>On Wed, 1 Sep 1999, Aaron Nabil wrote:
>
>> Mike Andrews writes...
>> >- In Radius, use the USR-IP-SAA-Filter VSA to prevent IP spoofing, unless
>> >the user has a subnet routed to them. We don't use the global switch on
>> >the ARC; we'd rather do it in Radius so it can be turned off on a per-user
>> >basis.
>>
>> This works for you? It doesn't on my V4.2.29 - 1.
>
>It does appear to work here, on 4.2.29.
I get this...
Jul 4 10:35:57 us8a At 17:35:56, Facility "User Manager", Level
"UNUSUAL":: AUTH: Unknown attribute passed back from RADIUS Server: 9870
in my syslog, I didn't think to check if it was actually filtering
packets (I'm guessing not). Is it 0x9870 that you are using?
>(At least syslog is recording the denied packets.)
Yeah, any way to turn that off that you've found? It ignores the
Log-Filter-Packet attribute for SAA filtering. I had one user with
a broken wingate-ish program that ended up sysloging almost every
other packet, ouch.
--
Aaron Nabil
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
Date: 03 Sep 1999 00:25:30 -0400 (EDT)
On Thu, 2 Sep 1999, Aaron Nabil wrote:
> Mike Andrews writes...
> >On Wed, 1 Sep 1999, Aaron Nabil wrote:
> >
> >> Mike Andrews writes...
> >> >- In Radius, use the USR-IP-SAA-Filter VSA to prevent IP spoofing, unless
> >> >the user has a subnet routed to them. We don't use the global switch on
> >> >the ARC; we'd rather do it in Radius so it can be turned off on a per-user
> >> >basis.
> >>
> >> This works for you? It doesn't on my V4.2.29 - 1.
> >
> >It does appear to work here, on 4.2.29.
>
> I get this...
>
> Jul 4 10:35:57 us8a At 17:35:56, Facility "User Manager", Level
> "UNUSUAL":: AUTH: Unknown attribute passed back from RADIUS Server: 9870
>
> in my syslog, I didn't think to check if it was actually filtering
> packets (I'm guessing not). Is it 0x9870 that you are using?
Yup. Don't suppose you've got 9870 instead of 0x9870? You'd think the
ARC would put the leading 0x on it...
> >(At least syslog is recording the denied packets.)
>
> Yeah, any way to turn that off that you've found? It ignores the
> Log-Filter-Packet attribute for SAA filtering. I had one user with
> a broken wingate-ish program that ended up sysloging almost every
> other packet, ouch.
Haven't tried. But we syslog every damn thing at debug level anyway --
disk is cheap. (28 gig IDE for $250 now -- it's a shame I hate IDE :)
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Aaron Nabil <nabil@spiritone.com>
Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
Date: 02 Sep 1999 22:56:26 -0700 (PDT)
Mike Andrews writes...
>On Thu, 2 Sep 1999, Aaron Nabil wrote:
>
>> Mike Andrews writes...
>> >On Wed, 1 Sep 1999, Aaron Nabil wrote:
>> >
>> >> Mike Andrews writes...
>> >> >- In Radius, use the USR-IP-SAA-Filter VSA to prevent IP spoofing, unless
>> >> >the user has a subnet routed to them. We don't use the global switch on
>> >> >the ARC; we'd rather do it in Radius so it can be turned off on a per-user
>> >> >basis.
>> >>
>> >> This works for you? It doesn't on my V4.2.29 - 1.
>> >
>> >It does appear to work here, on 4.2.29.
>>
>> I get this...
>>
>> Jul 4 10:35:57 us8a At 17:35:56, Facility "User Manager", Level
>> "UNUSUAL":: AUTH: Unknown attribute passed back from RADIUS Server: 9870
>>
>> in my syslog, I didn't think to check if it was actually filtering
>> packets (I'm guessing not). Is it 0x9870 that you are using?
>
>Yup. Don't suppose you've got 9870 instead of 0x9870? You'd think the
>ARC would put the leading 0x on it...
VENDORATTR 429 USR-IP-SAA-FILTER 39024 integer
VALUE USR-IP-SAA-FILTER USR-IP-SAA-FILTER-No 0
VALUE USR-IP-SAA-FILTER USR-IP-SAA-FILTER-Yes 1
Look like what you've got? (Radiator uses decimal).
--
Aaron Nabil
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Boggs <sboggs@unitedbank.net>
Subject: (usr-tc) Connect-Speed attribute
Date: 03 Sep 1999 13:09:15 -0400
The RADIUS section of the HARC docs describes a RADIUS attribute
Connect-Speed (0x9023)
It is described as a "32-bit integer".
When I capture this attribute, it appears as a number usually between 20-49.
Does anyone know how to translate this "32-bit integer"?
TIA.
Scott Boggs
Network Admin.
AccessUnited
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Luke Parrish <lparrish@inet-resources.com>
Subject: (usr-tc) Re: info on aggregating ISDN lines
Date: 02 Sep 1999 12:08:46 -0500
They won't have to have 2 logins, just assign them one RADIUS profile with
their max channels set to 4. This way their router can request 4 channels
and the access server will allow the customer to bond 4 channels. I have
done this several times using an Ascend MAX200.
At 12:17 PM 9/2/99 -0500, C Thompson wrote:
>We have a customer who wants to aggregate 2 or more ISDN lines for one
>large bandwidth channel. How can they do this with a standard dialup?
>
>I know that I can give them, say, two login names, have them login as
>login1 and login2 which can both be set for a 128K login and make it the
>responsibility of the equipment to provide the aggregation of 256K total,
>but I wanted to check with you guys and see if this is the only way, the
>best way, etc. Any equipment you know of or recommend to do this?
>
>Please reply asap, as we are working on a project with a due date coming
>up very soon.
>
>
>
>Craig Thompson, Manager
>WingNET Internet Services,
>P.O. Box 3000 // Cleveland, TN 37320-3000
>423-559-LINK (v) 423-559-5444 (f)
>http://www.wingnet.net
>-
>Send 'unsubscribe' in the body to 'list-request@inet-access.net' to leave.
>Eat sushi frequently. inet@inet-access.net is the human contact address.
Luke Parrish
Internetworking Resources
Independent Internet Consultant
lparrish@inet-resources.com
cell 318.348.7906
fax 815.377.5239
pager 1.800.443.7243 pin# 080765
http://www.inet-resources.com/
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: David Ernst <drernst@bloomington.in.us>
Subject: Re: (usr-tc) TC and Cistron
Date: 31 Aug 1999 13:46:27 -0500 (EST)
Your /etc/services is listing ports 1645 & 1646 as "Datametrics". I
don't know much about this but apparently datametrics had that port
number reserved before RADIUS started using it. Meanwhile Radius is
probably being listed as 1812/1813 (did you just upgrade to RedHat 6.0
by any chance?). See RFC 2138 for more information about the
history.
We fixed this problem just by editing our /etc/services file. Here
are the key lines:
radius 1645/tcp # datametrics / old radius entry
radius 1645/udp # datametrics / old radius entry
radacct 1646/tcp # sa-msg-port / old radacct entry
radacct 1646/udp # sa-msg-port / old radacct entry
#radius 1812/tcp # Radius
#radius 1812/udp # Radius
#radacct 1813/tcp # Radius Accounting
#radacct 1813/udp # Radius Accounting
This should bring you back up. I'm sure there's a way to tell the
HiperArc to use the "real" radius ports, but I didn't know what that
was, and I did know how to do this, and I needed to get it fixed FAST.
So, although it thumbs its nose at the Internet Number Assigning
Authorities, we did it anyway.
David
--
David Ernst
HoosierNet, Inc.
On Tue, 31 Aug 1999, Tavis Morse wrote:
>Hello,
>I'm trying to set up cistron radius to work with the HiperArc,
>does anyone have this working? If so, I'm wondering what typical clients
>and users file entries might look like.
>I have been trying to get it working unsuccessfully for 2 days.,
>so far I can't even get the radius.log to show any activity at all with the
>-y flag. TCPdump shows 'datametrics' packets coming in.
>TIA
>Tavis Morse
>Norfolk County Internet
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: David Ernst <drernst@bloomington.in.us>
Subject: Re: (usr-tc) TC and Cistron
Date: 31 Aug 1999 13:46:27 -0500 (EST)
Your /etc/services is listing ports 1645 & 1646 as "Datametrics". I
don't know much about this but apparently datametrics had that port
number reserved before RADIUS started using it. Meanwhile Radius is
probably being listed as 1812/1813 (did you just upgrade to RedHat 6.0
by any chance?). See RFC 2138 for more information about the
history.
We fixed this problem just by editing our /etc/services file. Here
are the key lines:
radius 1645/tcp # datametrics / old radius entry
radius 1645/udp # datametrics / old radius entry
radacct 1646/tcp # sa-msg-port / old radacct entry
radacct 1646/udp # sa-msg-port / old radacct entry
#radius 1812/tcp # Radius
#radius 1812/udp # Radius
#radacct 1813/tcp # Radius Accounting
#radacct 1813/udp # Radius Accounting
This should bring you back up. I'm sure there's a way to tell the
HiperArc to use the "real" radius ports, but I didn't know what that
was, and I did know how to do this, and I needed to get it fixed FAST.
So, although it thumbs its nose at the Internet Number Assigning
Authorities, we did it anyway.
David
--
David Ernst
HoosierNet, Inc.
On Tue, 31 Aug 1999, Tavis Morse wrote:
>Hello,
>I'm trying to set up cistron radius to work with the HiperArc,
>does anyone have this working? If so, I'm wondering what typical clients
>and users file entries might look like.
>I have been trying to get it working unsuccessfully for 2 days.,
>so far I can't even get the radius.log to show any activity at all with the
>-y flag. TCPdump shows 'datametrics' packets coming in.
>TIA
>Tavis Morse
>Norfolk County Internet
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Pete Ashdown <pashdown@xmission.com>
Subject: Re: (usr-tc) RE: IP Spoofing
Date: 03 Sep 1999 11:22:25 -0600 (MDT)
Mike Wronski said once upon a time:
>
>There is the global switch "ENABLE IP SOURCE_ADDRESS_FILTER" that would be the
>best method of turning on this feature..
Mike, does this still not take into account framed-routes? Will it ever?
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike Wronski" <mike@coredump.ae.usr.com>
Subject: RE: (usr-tc) RE: IP Spoofing
Date: 03 Sep 1999 13:07:15 -0500
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown
|Sent: Friday, September 03, 1999 12:22 PM
|To: usr-tc@lists.xmission.com
|Subject: Re: (usr-tc) RE: IP Spoofing
|
|
|Mike Wronski said once upon a time:
|>
|>There is the global switch "ENABLE IP SOURCE_ADDRESS_FILTER" that would be the
|>best method of turning on this feature..
|
|Mike, does this still not take into account framed-routes? Will it ever?
Yes, and eventually.
-M
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Clint R. Sparks" <csparks@cqc.com>
Subject: (usr-tc) Problems with Connect Speeds going down
Date: 03 Sep 1999 13:16:14 -0500
Looking for any help with a new problem that started about a week ago where
customers that connect at 50,666k or 52k are now connecting at 31,2k or
33.6k. We have changed nothing on our Total Control. We use the Hiper DSP
cards with PRI's and Hiper Arc card and we are running Hiper DSP code 1.2.43
and Hiper Arc 4.1.59-6. We have had absolutely no problems up until a week
ago, we have rebooted our Hiper DSP cards and Hiper Arc card to see if that
would help but it has not. Our PRI's come from GTE and they say they cannot
find anything wrong on their lines. I have seen this myself from my home and
it does not make sense.
Any help would be appreciated.
Thank you,
Clint R. Sparks
ComQuest Internet Services
csparks@cqc.com
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Greg Coffey <gcoffey@vcn.com>
Subject: Re: (usr-tc) Problems with Connect Speeds going down
Date: 03 Sep 1999 12:37:19 -0600
Can anyone connect at a higher rate? Or are we talking about a few customers?
At 01:16 PM 9/3/99 -0500, you wrote:
>Looking for any help with a new problem that started about a week ago where
>customers that connect at 50,666k or 52k are now connecting at 31,2k or
>33.6k. We have changed nothing on our Total Control. We use the Hiper DSP
>cards with PRI's and Hiper Arc card and we are running Hiper DSP code 1.2.43
>and Hiper Arc 4.1.59-6. We have had absolutely no problems up until a week
>ago, we have rebooted our Hiper DSP cards and Hiper Arc card to see if that
>would help but it has not. Our PRI's come from GTE and they say they cannot
>find anything wrong on their lines. I have seen this myself from my home and
>it does not make sense.
>
>Any help would be appreciated.
>
>Thank you,
>
>Clint R. Sparks
>ComQuest Internet Services
>csparks@cqc.com
>
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
Thanks, Greg Coffey <gcoffey@vcn.com>
Visionary Communications V 307-234-5443 F 307-234-5446
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Clint R. Sparks" <csparks@cqc.com>
Subject: Re: (usr-tc) Problems with Connect Speeds going down
Date: 03 Sep 1999 13:58:20 -0500
Yes, we are seeing about 55% connecting at 56k speeds, the rest at 33.6k or
lower. The odd thing is people that always connected at 50k will now connect
at 31,2k 8 times and then 49,333k or 45,333k then the next time 31,2k again.
I just received a call from GTE saying they checked all the spans and they
see nothing wrong, no errors of any kind. It is affecting numerous customers
from all over the city and county. I have another identical setup Total
Control in another city which is Ameritech and no problems, speeds are great
and no complaints.
----- Original Message -----
Sent: Friday, September 03, 1999 1:37 PM
> Can anyone connect at a higher rate? Or are we talking about a few
customers?
>
> At 01:16 PM 9/3/99 -0500, you wrote:
> >Looking for any help with a new problem that started about a week ago
where
> >customers that connect at 50,666k or 52k are now connecting at 31,2k or
> >33.6k. We have changed nothing on our Total Control. We use the Hiper DSP
> >cards with PRI's and Hiper Arc card and we are running Hiper DSP code
1.2.43
> >and Hiper Arc 4.1.59-6. We have had absolutely no problems up until a
week
> >ago, we have rebooted our Hiper DSP cards and Hiper Arc card to see if
that
> >would help but it has not. Our PRI's come from GTE and they say they
cannot
> >find anything wrong on their lines. I have seen this myself from my home
and
> >it does not make sense.
> >
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) Connect-Speed attribute
Date: 03 Sep 1999 15:01:21 -0400 (EDT)
On Fri, 3 Sep 1999, Scott Boggs wrote:
> The RADIUS section of the HARC docs describes a RADIUS attribute
> Connect-Speed (0x9023)
> It is described as a "32-bit integer".
> When I capture this attribute, it appears as a number usually between 20-49.
> Does anyone know how to translate this "32-bit integer"?
Yeah. It should be in your dictionary file. Here's a chunk of ours
(from Cistron radius):
VALUE USR-Initial-Tx-Link-Data-Rate 110-BPS 1
VALUE USR-Initial-Tx-Link-Data-Rate 300-BPS 2
VALUE USR-Initial-Tx-Link-Data-Rate 600-BPS 3
VALUE USR-Initial-Tx-Link-Data-Rate 1200-BPS 4
VALUE USR-Initial-Tx-Link-Data-Rate 2400-BPS 5
VALUE USR-Initial-Tx-Link-Data-Rate 4800-BPS 6
VALUE USR-Initial-Tx-Link-Data-Rate 7200-BPS 7
VALUE USR-Initial-Tx-Link-Data-Rate 9600-BPS 8
VALUE USR-Initial-Tx-Link-Data-Rate 12000-BPS 9
VALUE USR-Initial-Tx-Link-Data-Rate 14400-BPS 10
VALUE USR-Initial-Tx-Link-Data-Rate 16800-BPS 11
VALUE USR-Initial-Tx-Link-Data-Rate 19200-BPS 12
VALUE USR-Initial-Tx-Link-Data-Rate 38400-BPS 13
VALUE USR-Initial-Tx-Link-Data-Rate 75-BPS 14
VALUE USR-Initial-Tx-Link-Data-Rate 450-BPS 15
VALUE USR-Initial-Tx-Link-Data-Rate UNKNOWN-BPS 16
VALUE USR-Initial-Tx-Link-Data-Rate 57600-BPS 17
VALUE USR-Initial-Tx-Link-Data-Rate 21600-BPS 18
VALUE USR-Initial-Tx-Link-Data-Rate 24000-BPS 19
VALUE USR-Initial-Tx-Link-Data-Rate 26400-BPS 20
VALUE USR-Initial-Tx-Link-Data-Rate 28800-BPS 21
VALUE USR-Initial-Tx-Link-Data-Rate 115200-BPS 22
VALUE USR-Initial-Tx-Link-Data-Rate 31200-BPS 23
VALUE USR-Initial-Tx-Link-Data-Rate 33600-BPS 24
VALUE USR-Initial-Tx-Link-Data-Rate 25333-BPS 25
VALUE USR-Initial-Tx-Link-Data-Rate 26666-BPS 26
VALUE USR-Initial-Tx-Link-Data-Rate 28000-BPS 27
VALUE USR-Initial-Tx-Link-Data-Rate 29333-BPS 28
VALUE USR-Initial-Tx-Link-Data-Rate 30666-BPS 29
VALUE USR-Initial-Tx-Link-Data-Rate 32000-BPS 30
VALUE USR-Initial-Tx-Link-Data-Rate 33333-BPS 31
VALUE USR-Initial-Tx-Link-Data-Rate 34666-BPS 32
VALUE USR-Initial-Tx-Link-Data-Rate 36000-BPS 33
VALUE USR-Initial-Tx-Link-Data-Rate 37333-BPS 34
VALUE USR-Initial-Tx-Link-Data-Rate 38666-BPS 35
VALUE USR-Initial-Tx-Link-Data-Rate 40000-BPS 36
VALUE USR-Initial-Tx-Link-Data-Rate 41333-BPS 37
VALUE USR-Initial-Tx-Link-Data-Rate 42666-BPS 38
VALUE USR-Initial-Tx-Link-Data-Rate 44000-BPS 39
VALUE USR-Initial-Tx-Link-Data-Rate 45333-BPS 40
VALUE USR-Initial-Tx-Link-Data-Rate 46666-BPS 41
VALUE USR-Initial-Tx-Link-Data-Rate 48000-BPS 42
VALUE USR-Initial-Tx-Link-Data-Rate 49333-BPS 43
VALUE USR-Initial-Tx-Link-Data-Rate 50666-BPS 44
VALUE USR-Initial-Tx-Link-Data-Rate 52000-BPS 45
VALUE USR-Initial-Tx-Link-Data-Rate 53333-BPS 46
VALUE USR-Initial-Tx-Link-Data-Rate 54666-BPS 47
VALUE USR-Initial-Tx-Link-Data-Rate 56000-BPS 48
VALUE USR-Initial-Tx-Link-Data-Rate 57333-BPS 49
VALUE USR-Initial-Tx-Link-Data-Rate 58666-BPS 50
VALUE USR-Initial-Tx-Link-Data-Rate 60000-BPS 51
VALUE USR-Initial-Tx-Link-Data-Rate 61333-BPS 52
VALUE USR-Initial-Tx-Link-Data-Rate 62666-BPS 53
VALUE USR-Initial-Tx-Link-Data-Rate 64000-BPS 54
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Scot Desort" <scot@njaccess.net>
Subject: Re: (usr-tc) Problems with Connect Speeds going down
Date: 03 Sep 1999 15:29:10 -0400
I have a bunch of customers who were served from a Bell Atlantic central
office equipped with a Lucent 1A switch. A week ago, BA upgraded the switch
to a 5ESS. Connect speeds from half of the people served by that switch
dropped from 47-50K to below 40.
GTE would have had to replace a bunch of switches on the user side all at
once for it to have such a sweeping effect as you have described.
Also, ask them about their tandems. Buggers, they are. May be a whole
geographical section of your customers served by a single tandem switch that
is on the fritz. There are 2 that serve our area, and one of them is ALWAYS
having problems.
...Scot
----- Original Message -----
Sent: Friday, September 03, 1999 2:16 PM
> Looking for any help with a new problem that started about a week ago
where
> customers that connect at 50,666k or 52k are now connecting at 31,2k or
> 33.6k. We have changed nothing on our Total Control. We use the Hiper DSP
> cards with PRI's and Hiper Arc card and we are running Hiper DSP code
1.2.43
> and Hiper Arc 4.1.59-6. We have had absolutely no problems up until a week
> ago, we have rebooted our Hiper DSP cards and Hiper Arc card to see if
that
> would help but it has not. Our PRI's come from GTE and they say they
cannot
> find anything wrong on their lines. I have seen this myself from my home
and
> it does not make sense.
>
> Any help would be appreciated.
>
> Thank you,
>
> Clint R. Sparks
> ComQuest Internet Services
> csparks@cqc.com
>
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Brian Becker" <brian@semo.net>
Subject: (usr-tc) Date: Fri, 3 Sep 1999 15:04:50 -0500
Date: 03 Sep 1999 14:10:18 -0600
We have a web tv that can authenticate in one area but not in another. Both
circuits are built the same and in the same TELCO.
Area that does work---
DSP - 1.2.5
ARC - 4.1.78
NMC - 5.6.2
New PPP Call received on interface slot:1/mod:23
Unexpected (LCP) Layer Down, ID 1, Restarting Link 28814384, to .
PPP - Authentication Complete to rhack56.
PPP - IP Link UP to rhack56 (199.217.238.231)
Local IP Address (199.217.238.227) was configured.
Peer PPP at rhack56 Does NOT support AUTO compression, DISABLING.
Area that doesn't work---
DSP - 2.0.81
ARC - 4.1.11
NMC - 6.1.17
New PPP Call received on interface slot:1/mod:11
....Tracing of Call Events; Escape to stop...
Unexpected (LCP) Layer Down, ID 1, Restarting Link 28043864, to .
Peer has not requested Auth, PPP link down to .
PPP connection down to .
Brian Becker
President, Poplar Bluff Internet
http://www.semo.net
TotallyFabricated.com Software
http://www.TotallyFabricated.com
Home of JerusalemPerspective.com
http://www.JerusalemPerspective.com
Personal Page
http://Tonionio.com / http://BenjaminBecker.com
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Greg Coffey <gcoffey@vcn.com>
Subject: Re: (usr-tc) Problems with Connect Speeds going down
Date: 03 Sep 1999 14:22:53 -0600
Could be that the local telco recently installed a SLC due to growth. That
would explain losing it in a certain area but not all over town. A SLC
takes out a whole area but they also install pairgain in certain locations
that will strip out 56k. That is usually at a residence or business. Much
smaller scale.
At 01:58 PM 9/3/99 -0500, you wrote:
>Yes, we are seeing about 55% connecting at 56k speeds, the rest at 33.6k or
>lower. The odd thing is people that always connected at 50k will now connect
>at 31,2k 8 times and then 49,333k or 45,333k then the next time 31,2k again.
>I just received a call from GTE saying they checked all the spans and they
>see nothing wrong, no errors of any kind. It is affecting numerous customers
>from all over the city and county. I have another identical setup Total
>Control in another city which is Ameritech and no problems, speeds are great
>and no complaints.
>
>
>----- Original Message -----
>From: Greg Coffey <gcoffey@vcn.com>
>To: <usr-tc@lists.xmission.com>
>Sent: Friday, September 03, 1999 1:37 PM
>Subject: Re: (usr-tc) Problems with Connect Speeds going down
>
>
> > Can anyone connect at a higher rate? Or are we talking about a few
>customers?
> >
> > At 01:16 PM 9/3/99 -0500, you wrote:
> > >Looking for any help with a new problem that started about a week ago
>where
> > >customers that connect at 50,666k or 52k are now connecting at 31,2k or
> > >33.6k. We have changed nothing on our Total Control. We use the Hiper DSP
> > >cards with PRI's and Hiper Arc card and we are running Hiper DSP code
>1.2.43
> > >and Hiper Arc 4.1.59-6. We have had absolutely no problems up until a
>week
> > >ago, we have rebooted our Hiper DSP cards and Hiper Arc card to see if
>that
> > >would help but it has not. Our PRI's come from GTE and they say they
>cannot
> > >find anything wrong on their lines. I have seen this myself from my home
>and
> > >it does not make sense.
> > >
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
Thanks, Greg Coffey <gcoffey@vcn.com>
Visionary Communications V 307-234-5443 F 307-234-5446
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Greg Coffey <gcoffey@vcn.com>
Subject: (usr-tc) Need Some Quad Modems
Date: 03 Sep 1999 14:45:42 -0600
I'm in the market for some digital quads. Email me if you have some to
sell. I could use 1-2 dozen of them.
Thanks, Greg Coffey <gcoffey@vcn.com>
Visionary Communications V 307-234-5443 F 307-234-5446
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Andrew:PC Global, Inc." <andrew@pcglobal.net>
Subject: Re: (usr-tc) Need Some Quad Modems
Date: 03 Sep 1999 13:57:20 -0700
I have about 25 in stock... about 8 NICS . These are the V.34
analog/Digital.
We have been selling them at $175 each with a 90 day warranty
We take all credit cards,
Best Regards,
Andrew Shlensky
****************************
PC Global, Inc.
(602) 438-6200 office (NEW TEL NUMBER!)
(602) 438-1119 fax
(305) 216-8638 mobile
New!e-mail my mobile http://www.nextel.com/paging
URL: http://www.pcglobal.net
E-MAIL: andrew@pcglobal.net
ICQ: 21219089
Computer Service Parts SpEciaLiSts!
Leader in New/Used PCs,Laptops
Communication & Networking,Monitors
Printers, Hard Drives, Midrange/Mainframe.
Hard to Get Parts. We buy and sell all
types of GEAR-
****************************
----- Original Message -----
Sent: Friday, September 03, 1999 1:45 PM
I'm in the market for some digital quads. Email me if you have some to
sell. I could use 1-2 dozen of them.
Thanks, Greg Coffey <gcoffey@vcn.com>
Visionary Communications V 307-234-5443 F 307-234-5446
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Andrew:PC Global, Inc." <andrew@pcglobal.net>
Subject: Re: (usr-tc) Need Some Quad Modems
Date: 03 Sep 1999 13:58:03 -0700
sorry that was supposed to be a private reply.
Andrew Shlensky
****************************
PC Global, Inc.
(602) 438-6200 office (NEW TEL NUMBER!)
(602) 438-1119 fax
(305) 216-8638 mobile
New!e-mail my mobile http://www.nextel.com/paging
URL: http://www.pcglobal.net
E-MAIL: andrew@pcglobal.net
ICQ: 21219089
Computer Service Parts SpEciaLiSts!
Leader in New/Used PCs,Laptops
Communication & Networking,Monitors
Printers, Hard Drives, Midrange/Mainframe.
Hard to Get Parts. We buy and sell all
types of GEAR-
****************************
----- Original Message -----
Sent: Friday, September 03, 1999 1:45 PM
I'm in the market for some digital quads. Email me if you have some to
sell. I could use 1-2 dozen of them.
Thanks, Greg Coffey <gcoffey@vcn.com>
Visionary Communications V 307-234-5443 F 307-234-5446
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike Wronski" <mike@coredump.ae.usr.com>
Subject: RE: (usr-tc) Date: Fri, 3 Sep 1999 15:04:50 -0500
Date: 03 Sep 1999 16:57:19 -0500
Change the code on the HARCs to Match.. You have a strange code combination..
Working area has newer arc code and
old DSP code. Non working area has new DSP and very old HARC code..
I would sugest that you use 4.1.59-6 for HARC and 2.0.81 for the DSPs everywhere.
-M
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Becker
|Sent: Friday, September 03, 1999 3:10 PM
|To: usr-tc@lists.xmission.com
|Subject: (usr-tc) Date: Fri, 3 Sep 1999 15:04:50 -0500
|
|
|We have a web tv that can authenticate in one area but not in another. Both
|circuits are built the same and in the same TELCO.
|
|Area that does work---
|DSP - 1.2.5
|ARC - 4.1.78
|NMC - 5.6.2
|New PPP Call received on interface slot:1/mod:23
|Unexpected (LCP) Layer Down, ID 1, Restarting Link 28814384, to .
|PPP - Authentication Complete to rhack56.
|PPP - IP Link UP to rhack56 (199.217.238.231)
|Local IP Address (199.217.238.227) was configured.
|Peer PPP at rhack56 Does NOT support AUTO compression, DISABLING.
|
|Area that doesn't work---
|DSP - 2.0.81
|ARC - 4.1.11
|NMC - 6.1.17
|New PPP Call received on interface slot:1/mod:11
|....Tracing of Call Events; Escape to stop...
|Unexpected (LCP) Layer Down, ID 1, Restarting Link 28043864, to .
|Peer has not requested Auth, PPP link down to .
|PPP connection down to .
|
|Brian Becker
|President, Poplar Bluff Internet
| http://www.semo.net
|TotallyFabricated.com Software
| http://www.TotallyFabricated.com
|Home of JerusalemPerspective.com
| http://www.JerusalemPerspective.com
|Personal Page
| http://Tonionio.com / http://BenjaminBecker.com
|
|
|-
| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
| 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.
|
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Clint R. Sparks" <csparks@cqc.com>
Subject: Re: (usr-tc) Problems with Connect Speeds going down
Date: 03 Sep 1999 17:56:05 -0500
As it happens, GTE in my area has just one switch GTD 5 I believe and it
covers all the customers in my area of service. They just recently upgraded
the switch to handle more PRI's which is what we use as they were out of
capacity to fill PRI orders. Of course if it is because of the recent
upgrade to their switch I will have a heck of a time getting them to believe
it is something that started when they upgraded and that it has to be
related.
> I have a bunch of customers who were served from a Bell Atlantic central
> office equipped with a Lucent 1A switch. A week ago, BA upgraded the
switch
> to a 5ESS. Connect speeds from half of the people served by that switch
> dropped from 47-50K to below 40.
>
> GTE would have had to replace a bunch of switches on the user side all at
> once for it to have such a sweeping effect as you have described.
>
> Also, ask them about their tandems. Buggers, they are. May be a whole
> geographical section of your customers served by a single tandem switch
that
> is on the fritz. There are 2 that serve our area, and one of them is
ALWAYS
> having problems.
>
>
> ...Scot
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Eric Billeter" <ebilleter@cableone.net>
Subject: RE: (usr-tc) Date: Fri, 3 Sep 1999 15:04:50 -0500
Date: 03 Sep 1999 15:55:00 -0700
Something else to verify..
From my experience i have found the following
webtv units require pap authentication be the default for the chassis
they also require vj header compression set in radius
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Wronski
Sent: Friday, September 03, 1999 2:57 PM
Cc: brian@semo.net
Change the code on the HARCs to Match.. You have a strange code
combination..
Working area has newer arc code and
old DSP code. Non working area has new DSP and very old HARC code..
I would sugest that you use 4.1.59-6 for HARC and 2.0.81 for the DSPs
everywhere.
-M
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Becker
|Sent: Friday, September 03, 1999 3:10 PM
|To: usr-tc@lists.xmission.com
|Subject: (usr-tc) Date: Fri, 3 Sep 1999 15:04:50 -0500
|
|
|We have a web tv that can authenticate in one area but not in another. Both
|circuits are built the same and in the same TELCO.
|
|Area that does work---
|DSP - 1.2.5
|ARC - 4.1.78
|NMC - 5.6.2
|New PPP Call received on interface slot:1/mod:23
|Unexpected (LCP) Layer Down, ID 1, Restarting Link 28814384, to .
|PPP - Authentication Complete to rhack56.
|PPP - IP Link UP to rhack56 (199.217.238.231)
|Local IP Address (199.217.238.227) was configured.
|Peer PPP at rhack56 Does NOT support AUTO compression, DISABLING.
|
|Area that doesn't work---
|DSP - 2.0.81
|ARC - 4.1.11
|NMC - 6.1.17
|New PPP Call received on interface slot:1/mod:11
|....Tracing of Call Events; Escape to stop...
|Unexpected (LCP) Layer Down, ID 1, Restarting Link 28043864, to .
|Peer has not requested Auth, PPP link down to .
|PPP connection down to .
|
|Brian Becker
|President, Poplar Bluff Internet
| http://www.semo.net
|TotallyFabricated.com Software
| http://www.TotallyFabricated.com
|Home of JerusalemPerspective.com
| http://www.JerusalemPerspective.com
|Personal Page
| http://Tonionio.com / http://BenjaminBecker.com
|
|
|-
| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
| 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.
|
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Ed" <ed@taylors.com>
Subject: Re: (usr-tc) Problems with Connect Speeds going down
Date: 02 Sep 1999 21:41:22 -0400
Have any of you tried using Ascends to see if it happens with them? I know
there is an issue with crossing switches that 3com has and are currently
working on. We cross between Bell Atlantic and Ameritech and have this
issue.
For some reason it seems to not affect the Ascends as much...
Ed
----- Original Message -----
Sent: Friday, September 03, 1999 6:56 PM
As it happens, GTE in my area has just one switch GTD 5 I believe and it
covers all the customers in my area of service. They just recently upgraded
the switch to handle more PRI's which is what we use as they were out of
capacity to fill PRI orders. Of course if it is because of the recent
upgrade to their switch I will have a heck of a time getting them to believe
it is something that started when they upgraded and that it has to be
related.
> I have a bunch of customers who were served from a Bell Atlantic central
> office equipped with a Lucent 1A switch. A week ago, BA upgraded the
switch
> to a 5ESS. Connect speeds from half of the people served by that switch
> dropped from 47-50K to below 40.
>
> GTE would have had to replace a bunch of switches on the user side all at
> once for it to have such a sweeping effect as you have described.
>
> Also, ask them about their tandems. Buggers, they are. May be a whole
> geographical section of your customers served by a single tandem switch
that
> is on the fritz. There are 2 that serve our area, and one of them is
ALWAYS
> having problems.
>
>
> ...Scot
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: D Mayer <dmayer@netwalk.com>
Subject: (usr-tc) ARC rebooting over and over...
Date: 04 Sep 1999 19:30:20 -0400
I've got an ARC that's been working normally on 4.1.59-6 since it was
installed about 2 weeks ago, and it suddenly started rebooting itself in the
middle of the night last night. From console I'm getting the crash dumps
included below just after the boot prom menu exits. The first two are what
it was getting when I first checked it, it was trying to load normally from
flash. I then tried having it boot from TFTP and captured the second two
crash dumps (somewhat different).
I figure this is a flash corruption or something, but I don't know how to
fix it. At one point it did actually boot, and I re-uploaded netserve.dmf
(4.1.59-6), but when I rebooted again it started the reboot cycle over
again. Any suggestions?
TIA,
Peter D. Mayer
NetWalk System Administrator
dmayer@netwalk.com
Here are the crash dumps:
Attempting auto-load from Flash ...
EXCEPTION 0300 CRASH DUMP:
GPRs:
R0: 0x0009EE18 R1: 0x07FCFF28 R2: 0x000B50A4 R3: 0x8BB552DA
R4: 0x00000400 R5: 0x00176591 R6: 0x45D8C3FF R7: 0x00168140
R8: 0x00168220 R9: 0x8BB10000 R10: 0x00000000 R11: 0x000000E9
R12: 0x000000A0 R13: 0x000BD2AC R14: 0x00000000 R15: 0x0011EEB0
R16: 0x00000000 R17: 0x00000000 R18: 0x001CF27A R19: 0x07FD0148
R20: 0x0011EEB0 R21: 0x0000823F R22: 0x0011EEB0 R23: 0x0000FFFF
R24: 0x00139AB8 R25: 0x00000001 R26: 0x00000001 : 0x00000400
R28: 0x000000B1 R29: 0x00172280 R30: 0x0004B0A8 R31: 0x307D3FA0
SPRs:
CR: 0x24000000 XER: 0x20000001 LR: 0x0006B254 CTR: 0x45D6DE92
SRR0: 0x0006B26C SRR1: 0x00003930 DSISR: 0x40000000 DAR: 0x307D3FA3
DMISS: 0x307D3FA4 DCMP: 0x80000001 HASH1: 0x0001F4C0 HASH2: 0x00010B00
IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000
82660 Registers:
Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06
CPU/PCI Addr: 0x00050CC0, Sys Error Addr: 0x000607E0
Call Stack:
0x0006B26C (Exception return address - SRR0)
0x0006B254
0x0009EE18
0x000967D4
0x00096890
0x0009912C
0x000A1258
0x0009F29C
0x000A0708
0x00046994
0x00045FC8
0x000462A8
0x00045B28
Attempting auto-load from Flash ...
EXCEPTION 0300 CRASH DUMP:
GPRs:
R0: 0x0009EE18 R1: 0x07FCFF28 R2: 0x000B50A4 R3: 0x8BFD3DE2
R4: 0x00000400 R5: 0x0017255D R6: 0x00000000 R7: 0x00168140
R8: 0x00168220 R9: 0x8BF80000 R10: 0x00000000 R11: 0x000000F6
R12: 0x00000037 R13: 0x000BD2AC R14: 0x00000000 R15: 0x0011EEB0
R16: 0x00000000 R17: 0x00000000 R18: 0x001CF27A R19: 0x07FD0148
R20: 0x0011EEB0 R21: 0x0000823F R22: 0x0011EEB0 R23: 0x0000FFFF
R24: 0x0012837C R25: 0x00000001 R26: 0x00000001 R27: 0x00000400
R28: 0x000000F8 R29: 0x00172280 R30: 0x0004B0A8 R31: 0x95ADCDCB
SPRs:
CR: 0x24000000 XER: 0x20000001 LR: 0x0006B254 CTR: 0xFFFDAF0F
SRR0: 0x0006B26C SRR1: 0x00003930 DSISR: 0x40000000 DAR: 0x95ADCDC8
DMISS: 0x95ADCDCF DCMP: 0x80000016 HASH1: 0x0001B700 HASH2: 0x000148C0
IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000
82660 Registers:
Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06
CPU/PCI Addr: 0x80050CC0, Sys Error Addr: 0x000607E0
Call Stack:
0x0006B26C (Exception return address - SRR0)
0x0006B254
0x0009EE18
0x000967D4
0x00096890
0x0009912C
0x000A1258
0x0009F29C
0x000A0708
0x00046994
0x00045FC8
0x000462A8
0x00045B28
Attempting auto-load from Network ...
Initializing Flash Filesystem ... OK
No Change in kernel.dmi (Flash not Updated)
Reinitializing decompression module.
In : 303800 bytes
--10--20--30--40--50--60--70--80--90--100
.
EXCEPTION 0200 CRASH DUMP:
GPRs:
R0: 0x00F0E980 R1: 0x010FFD58 R2: 0x00F1F748 R3: 0x00000000
R4: 0x00F1788C R5: 0x00FB6DD0 R6: 0x00FB6DD0 R7: 0x00000124
R8: 0x0000012A R9: 0x0000012A R10: 0x00000129 R11: 0x0000001F
R12: 0x0CBA9E40 R13: 0x00F1FDB0 R14: 0x00000000 R15: 0x00000000
R16: 0x00000000 R17: 0x00F17E74 R18: 0x00F17E70 R19: 0x0000FDB3
R20: 0x00F17DE0 R21: 0x00001DAB R22: 0x00F17DE8 R23: 0x00FB6510
R24: 0x00000000 R25: 0x0004A2B8 R26: 0x00000000 R27: 0x00010000
R28: 0x00000000 R29: 0x00000002 R30: 0x00000000 R31: 0x00000000
SPRs:
CR: 0x44000000 XER: 0x20000018 LR: 0x00F0E980 CTR: 0x00F10EC8
SRR0: 0x00F10094 SRR1: 0x0008B930 DSISR: 0x40000000 DAR: 0x38634C4F
DMISS: 0x38634C48 DCMP: 0x80000021 HASH1: 0x00018D00 HASH2: 0x000172C0
IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000
82660 Registers:
Err Status 1: 0x20, Err Status 2: 0x00, CPU Err: 0x72, PCI Err: 0x06
CPU/PCI Addr: 0x0CBA9E40, Sys Error Addr: 0x0CBA9E40
Call Stack:
0x00F10094 (Exception return address - SRR0)
0x00F0E980
0x00F0F4F0
0x00F005A0
0x00F009F0
0x00F00390
0x00F00028
Attempting auto-load from Network ...
Initializing Flash Filesystem ... OK
No Change in kernel.dmi (Flash not Updated)
Reinitializing decompression module.
In : 303800 bytes
--10--20--30--40--50--60--70--80--90--100
.
Can't write.
EXCEPTION 0200 CRASH DUMP:
GPRs:
R0: 0x00F0E980 R1: 0x010FFD58 R2: 0x00F1F748 R3: 0x00000000
R4: 0x00F1788C R5: 0x00FB6DD0 R6: 0x00FB6DD0 R7: 0x00000208
R8: 0x000001D1 R9: 0x000001D1 R10: 0x0000010A R11: 0x0000001F
R12: 0x0CBA9E40 R13: 0x00F1FDB0 R14: 0x00000000 R15: 0x00000000
R16: 0x00000000 R17: 0x00F17E74 R18: 0x00F17E70 R19: 0x0000FDB3
R20: 0x00F17DE0 R21: 0x00001DAB R22: 0x00F17DE8 R23: 0x00FB6510
R24: 0x00000000 R25: 0x00000035 R26: 0x00FAE748 R27: 0x00000008
R28: 0x00000000 R29: 0x00000101 R30: 0x00000072 R31: 0x00000002
SPRs:
CR: 0x44000000 XER: 0x20000018 LR: 0x00F0E980 CTR: 0x00F10F80
SRR0: 0x00F10094 SRR1: 0x0008B930 DSISR: 0x40000000 DAR: 0x38634C4F
DMISS: 0x38634C48 DCMP: 0x80000021 HASH1: 0x00018D00 HASH2: 0x000172C0
IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000
82660 Registers:
Err Status 1: 0x20, Err Status 2: 0x00, CPU Err: 0x72, PCI Err: 0x06
CPU/PCI Addr: 0x0CBA9E40, Sys Error Addr: 0x0CBA9E40
Call Stack:
0x00F10094 (Exception return address - SRR0)
0x00F0E980
0x00F0F57C
0x00F005A0
0x00F009F0
0x00F00390
0x00F00028
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: <pferraro@wna-linknet.com>
Subject: (usr-tc) Power requirements
Date: 04 Sep 1999 22:20:40 -0400 (EDT)
Can anyone tell me what the power requirements are for a HIPER Hub
with 1 70amp A/C power supply, built in fan tray, 3 Hiper DSPs, HiperArc
and NMC card? I have this unit plugged into a TrippLite UPS (the only
thing plugged into it) and occassionally when we get some power
fluctuations the hub shuts down! We have to actually turn it OFF and then
back ON again!
How do I figure out the power requirements? Should we move up to a
large UPS? Any and all comments appreciated!
==============================================================================
Phillip Ferraro WorldNet Access, Inc
pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
Voice (910) 346-0835 824 Gumbranch Square, Suite R3
FAX (910) 455-1933 Jacksonville, Nc 28540-6269
==============================================================================
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Marcelo Souza <mpsouza@centroin.com.br>
Subject: Re: (usr-tc) ARC rebooting over and over...
Date: 05 Sep 1999 10:39:48 -0300 (EST)
You should try to re-initialize and reload the flash code with the:
AT{ZF}
After reboot.
- Marcelo
On Sat, 4 Sep 1999, D Mayer wrote:
|I've got an ARC that's been working normally on 4.1.59-6 since it was
|installed about 2 weeks ago, and it suddenly started rebooting itself in the
|middle of the night last night. From console I'm getting the crash dumps
|included below just after the boot prom menu exits. The first two are what
|it was getting when I first checked it, it was trying to load normally from
|flash. I then tried having it boot from TFTP and captured the second two
|crash dumps (somewhat different).
|
|I figure this is a flash corruption or something, but I don't know how to
|fix it. At one point it did actually boot, and I re-uploaded netserve.dmf
|(4.1.59-6), but when I rebooted again it started the reboot cycle over
|again. Any suggestions?
|
|TIA,
|Peter D. Mayer
|NetWalk System Administrator
|dmayer@netwalk.com
|
|
|Here are the crash dumps:
|
|Attempting auto-load from Flash ...
|
|
|EXCEPTION 0300 CRASH DUMP:
|
|GPRs:
|R0: 0x0009EE18 R1: 0x07FCFF28 R2: 0x000B50A4 R3: 0x8BB552DA
|R4: 0x00000400 R5: 0x00176591 R6: 0x45D8C3FF R7: 0x00168140
|R8: 0x00168220 R9: 0x8BB10000 R10: 0x00000000 R11: 0x000000E9
|R12: 0x000000A0 R13: 0x000BD2AC R14: 0x00000000 R15: 0x0011EEB0
|R16: 0x00000000 R17: 0x00000000 R18: 0x001CF27A R19: 0x07FD0148
|R20: 0x0011EEB0 R21: 0x0000823F R22: 0x0011EEB0 R23: 0x0000FFFF
|R24: 0x00139AB8 R25: 0x00000001 R26: 0x00000001 : 0x00000400
|R28: 0x000000B1 R29: 0x00172280 R30: 0x0004B0A8 R31: 0x307D3FA0
|
|SPRs:
|CR: 0x24000000 XER: 0x20000001 LR: 0x0006B254 CTR: 0x45D6DE92
|SRR0: 0x0006B26C SRR1: 0x00003930 DSISR: 0x40000000 DAR: 0x307D3FA3
|DMISS: 0x307D3FA4 DCMP: 0x80000001 HASH1: 0x0001F4C0 HASH2: 0x00010B00
|IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000
|
|82660 Registers:
|Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06
|CPU/PCI Addr: 0x00050CC0, Sys Error Addr: 0x000607E0
|
|Call Stack:
| 0x0006B26C (Exception return address - SRR0)
| 0x0006B254
| 0x0009EE18
| 0x000967D4
| 0x00096890
| 0x0009912C
| 0x000A1258
| 0x0009F29C
| 0x000A0708
| 0x00046994
| 0x00045FC8
| 0x000462A8
| 0x00045B28
|
|
|
|
|Attempting auto-load from Flash ...
|
|
|EXCEPTION 0300 CRASH DUMP:
|
|GPRs:
|R0: 0x0009EE18 R1: 0x07FCFF28 R2: 0x000B50A4 R3: 0x8BFD3DE2
|R4: 0x00000400 R5: 0x0017255D R6: 0x00000000 R7: 0x00168140
|R8: 0x00168220 R9: 0x8BF80000 R10: 0x00000000 R11: 0x000000F6
|R12: 0x00000037 R13: 0x000BD2AC R14: 0x00000000 R15: 0x0011EEB0
|R16: 0x00000000 R17: 0x00000000 R18: 0x001CF27A R19: 0x07FD0148
|R20: 0x0011EEB0 R21: 0x0000823F R22: 0x0011EEB0 R23: 0x0000FFFF
|R24: 0x0012837C R25: 0x00000001 R26: 0x00000001 R27: 0x00000400
|R28: 0x000000F8 R29: 0x00172280 R30: 0x0004B0A8 R31: 0x95ADCDCB
|
|SPRs:
|CR: 0x24000000 XER: 0x20000001 LR: 0x0006B254 CTR: 0xFFFDAF0F
|SRR0: 0x0006B26C SRR1: 0x00003930 DSISR: 0x40000000 DAR: 0x95ADCDC8
|DMISS: 0x95ADCDCF DCMP: 0x80000016 HASH1: 0x0001B700 HASH2: 0x000148C0
|IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000
|
|82660 Registers:
|Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06
|CPU/PCI Addr: 0x80050CC0, Sys Error Addr: 0x000607E0
|
|Call Stack:
| 0x0006B26C (Exception return address - SRR0)
| 0x0006B254
| 0x0009EE18
| 0x000967D4
| 0x00096890
| 0x0009912C
| 0x000A1258
| 0x0009F29C
| 0x000A0708
| 0x00046994
| 0x00045FC8
| 0x000462A8
| 0x00045B28
|
|
|
|
|
|Attempting auto-load from Network ...
|
|Initializing Flash Filesystem ... OK
|No Change in kernel.dmi (Flash not Updated)
|
|Reinitializing decompression module.
|In : 303800 bytes
|--10--20--30--40--50--60--70--80--90--100
|.
|
|EXCEPTION 0200 CRASH DUMP:
|
|GPRs:
|R0: 0x00F0E980 R1: 0x010FFD58 R2: 0x00F1F748 R3: 0x00000000
|R4: 0x00F1788C R5: 0x00FB6DD0 R6: 0x00FB6DD0 R7: 0x00000124
|R8: 0x0000012A R9: 0x0000012A R10: 0x00000129 R11: 0x0000001F
|R12: 0x0CBA9E40 R13: 0x00F1FDB0 R14: 0x00000000 R15: 0x00000000
|R16: 0x00000000 R17: 0x00F17E74 R18: 0x00F17E70 R19: 0x0000FDB3
|R20: 0x00F17DE0 R21: 0x00001DAB R22: 0x00F17DE8 R23: 0x00FB6510
|R24: 0x00000000 R25: 0x0004A2B8 R26: 0x00000000 R27: 0x00010000
|R28: 0x00000000 R29: 0x00000002 R30: 0x00000000 R31: 0x00000000
|
|SPRs:
|CR: 0x44000000 XER: 0x20000018 LR: 0x00F0E980 CTR: 0x00F10EC8
|SRR0: 0x00F10094 SRR1: 0x0008B930 DSISR: 0x40000000 DAR: 0x38634C4F
|DMISS: 0x38634C48 DCMP: 0x80000021 HASH1: 0x00018D00 HASH2: 0x000172C0
|IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000
|
|82660 Registers:
|Err Status 1: 0x20, Err Status 2: 0x00, CPU Err: 0x72, PCI Err: 0x06
|CPU/PCI Addr: 0x0CBA9E40, Sys Error Addr: 0x0CBA9E40
|
|Call Stack:
| 0x00F10094 (Exception return address - SRR0)
| 0x00F0E980
| 0x00F0F4F0
| 0x00F005A0
| 0x00F009F0
| 0x00F00390
| 0x00F00028
|
|
|
|
|
|Attempting auto-load from Network ...
|
|Initializing Flash Filesystem ... OK
|No Change in kernel.dmi (Flash not Updated)
|
|Reinitializing decompression module.
|In : 303800 bytes
|--10--20--30--40--50--60--70--80--90--100
|.
|Can't write.
|
|
|
|EXCEPTION 0200 CRASH DUMP:
|
|GPRs:
|R0: 0x00F0E980 R1: 0x010FFD58 R2: 0x00F1F748 R3: 0x00000000
|R4: 0x00F1788C R5: 0x00FB6DD0 R6: 0x00FB6DD0 R7: 0x00000208
|R8: 0x000001D1 R9: 0x000001D1 R10: 0x0000010A R11: 0x0000001F
|R12: 0x0CBA9E40 R13: 0x00F1FDB0 R14: 0x00000000 R15: 0x00000000
|R16: 0x00000000 R17: 0x00F17E74 R18: 0x00F17E70 R19: 0x0000FDB3
|R20: 0x00F17DE0 R21: 0x00001DAB R22: 0x00F17DE8 R23: 0x00FB6510
|R24: 0x00000000 R25: 0x00000035 R26: 0x00FAE748 R27: 0x00000008
|R28: 0x00000000 R29: 0x00000101 R30: 0x00000072 R31: 0x00000002
|
|SPRs:
|CR: 0x44000000 XER: 0x20000018 LR: 0x00F0E980 CTR: 0x00F10F80
|SRR0: 0x00F10094 SRR1: 0x0008B930 DSISR: 0x40000000 DAR: 0x38634C4F
|DMISS: 0x38634C48 DCMP: 0x80000021 HASH1: 0x00018D00 HASH2: 0x000172C0
|IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000
|
|82660 Registers:
|Err Status 1: 0x20, Err Status 2: 0x00, CPU Err: 0x72, PCI Err: 0x06
|CPU/PCI Addr: 0x0CBA9E40, Sys Error Addr: 0x0CBA9E40
|
|Call Stack:
| 0x00F10094 (Exception return address - SRR0)
| 0x00F0E980
| 0x00F0F57C
| 0x00F005A0
| 0x00F009F0
| 0x00F00390
| 0x00F00028
|
|-
| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
| 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.
|
- Marcelo
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Michael DeMan" <michael@prf.org>
Subject: Re: (usr-tc) ARC rebooting over and over...
Date: 05 Sep 1999 14:08:03 -0700
We had a similar problem. We had to initialize and reload the flash from
the command console. It started up again a couple days later, and
eventually became non-recoverable - the entire card had to be replaced.
----------
>From: Marcelo Souza <mpsouza@centroin.com.br>
>To: "'usr-tc@lists.xmission.com'" <usr-tc@lists.xmission.com>
>Subject: Re: (usr-tc) ARC rebooting over and over...
>Date: Sun, Sep 5, 1999, 6:39 AM
>
>
>You should try to re-initialize and reload the flash code with the:
>
> AT{ZF}
>
> After reboot.
>
>- Marcelo
>
>On Sat, 4 Sep 1999, D Mayer wrote:
>
>|I've got an ARC that's been working normally on 4.1.59-6 since it was
>|installed about 2 weeks ago, and it suddenly started rebooting itself in the
>|middle of the night last night. From console I'm getting the crash dumps
>|included below just after the boot prom menu exits. The first two are what
>|it was getting when I first checked it, it was trying to load normally from
>|flash. I then tried having it boot from TFTP and captured the second two
>|crash dumps (somewhat different).
>|
>|I figure this is a flash corruption or something, but I don't know how to
>|fix it. At one point it did actually boot, and I re-uploaded netserve.dmf
>|(4.1.59-6), but when I rebooted again it started the reboot cycle over
>|again. Any suggestions?
>|
>|TIA,
>|Peter D. Mayer
>|NetWalk System Administrator
>|dmayer@netwalk.com
>|
>|
>|Here are the crash dumps:
>|
>|Attempting auto-load from Flash ...
>|
>|
>|EXCEPTION 0300 CRASH DUMP:
>|
>|GPRs:
>|R0: 0x0009EE18 R1: 0x07FCFF28 R2: 0x000B50A4 R3: 0x8BB552DA
>|R4: 0x00000400 R5: 0x00176591 R6: 0x45D8C3FF R7: 0x00168140
>|R8: 0x00168220 R9: 0x8BB10000 R10: 0x00000000 R11: 0x000000E9
>|R12: 0x000000A0 R13: 0x000BD2AC R14: 0x00000000 R15: 0x0011EEB0
>|R16: 0x00000000 R17: 0x00000000 R18: 0x001CF27A R19: 0x07FD0148
>|R20: 0x0011EEB0 R21: 0x0000823F R22: 0x0011EEB0 R23: 0x0000FFFF
>|R24: 0x00139AB8 R25: 0x00000001 R26: 0x00000001 : 0x00000400
>|R28: 0x000000B1 R29: 0x00172280 R30: 0x0004B0A8 R31: 0x307D3FA0
>|
>|SPRs:
>|CR: 0x24000000 XER: 0x20000001 LR: 0x0006B254 CTR: 0x45D6DE92
>|SRR0: 0x0006B26C SRR1: 0x00003930 DSISR: 0x40000000 DAR: 0x307D3FA3
>|DMISS: 0x307D3FA4 DCMP: 0x80000001 HASH1: 0x0001F4C0 HASH2: 0x00010B00
>|IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000
>|
>|82660 Registers:
>|Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06
>|CPU/PCI Addr: 0x00050CC0, Sys Error Addr: 0x000607E0
>|
>|Call Stack:
>| 0x0006B26C (Exception return address - SRR0)
>| 0x0006B254
>| 0x0009EE18
>| 0x000967D4
>| 0x00096890
>| 0x0009912C
>| 0x000A1258
>| 0x0009F29C
>| 0x000A0708
>| 0x00046994
>| 0x00045FC8
>| 0x000462A8
>| 0x00045B28
>|
>|
>|
>|
>|Attempting auto-load from Flash ...
>|
>|
>|EXCEPTION 0300 CRASH DUMP:
>|
>|GPRs:
>|R0: 0x0009EE18 R1: 0x07FCFF28 R2: 0x000B50A4 R3: 0x8BFD3DE2
>|R4: 0x00000400 R5: 0x0017255D R6: 0x00000000 R7: 0x00168140
>|R8: 0x00168220 R9: 0x8BF80000 R10: 0x00000000 R11: 0x000000F6
>|R12: 0x00000037 R13: 0x000BD2AC R14: 0x00000000 R15: 0x0011EEB0
>|R16: 0x00000000 R17: 0x00000000 R18: 0x001CF27A R19: 0x07FD0148
>|R20: 0x0011EEB0 R21: 0x0000823F R22: 0x0011EEB0 R23: 0x0000FFFF
>|R24: 0x0012837C R25: 0x00000001 R26: 0x00000001 R27: 0x00000400
>|R28: 0x000000F8 R29: 0x00172280 R30: 0x0004B0A8 R31: 0x95ADCDCB
>|
>|SPRs:
>|CR: 0x24000000 XER: 0x20000001 LR: 0x0006B254 CTR: 0xFFFDAF0F
>|SRR0: 0x0006B26C SRR1: 0x00003930 DSISR: 0x40000000 DAR: 0x95ADCDC8
>|DMISS: 0x95ADCDCF DCMP: 0x80000016 HASH1: 0x0001B700 HASH2: 0x000148C0
>|IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000
>|
>|82660 Registers:
>|Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06
>|CPU/PCI Addr: 0x80050CC0, Sys Error Addr: 0x000607E0
>|
>|Call Stack:
>| 0x0006B26C (Exception return address - SRR0)
>| 0x0006B254
>| 0x0009EE18
>| 0x000967D4
>| 0x00096890
>| 0x0009912C
>| 0x000A1258
>| 0x0009F29C
>| 0x000A0708
>| 0x00046994
>| 0x00045FC8
>| 0x000462A8
>| 0x00045B28
>|
>|
>|
>|
>|
>|Attempting auto-load from Network ...
>|
>|Initializing Flash Filesystem ... OK
>|No Change in kernel.dmi (Flash not Updated)
>|
>|Reinitializing decompression module.
>|In : 303800 bytes
>|--10--20--30--40--50--60--70--80--90--100
>|.
>|
>|EXCEPTION 0200 CRASH DUMP:
>|
>|GPRs:
>|R0: 0x00F0E980 R1: 0x010FFD58 R2: 0x00F1F748 R3: 0x00000000
>|R4: 0x00F1788C R5: 0x00FB6DD0 R6: 0x00FB6DD0 R7: 0x00000124
>|R8: 0x0000012A R9: 0x0000012A R10: 0x00000129 R11: 0x0000001F
>|R12: 0x0CBA9E40 R13: 0x00F1FDB0 R14: 0x00000000 R15: 0x00000000
>|R16: 0x00000000 R17: 0x00F17E74 R18: 0x00F17E70 R19: 0x0000FDB3
>|R20: 0x00F17DE0 R21: 0x00001DAB R22: 0x00F17DE8 R23: 0x00FB6510
>|R24: 0x00000000 R25: 0x0004A2B8 R26: 0x00000000 R27: 0x00010000
>|R28: 0x00000000 R29: 0x00000002 R30: 0x00000000 R31: 0x00000000
>|
>|SPRs:
>|CR: 0x44000000 XER: 0x20000018 LR: 0x00F0E980 CTR: 0x00F10EC8
>|SRR0: 0x00F10094 SRR1: 0x0008B930 DSISR: 0x40000000 DAR: 0x38634C4F
>|DMISS: 0x38634C48 DCMP: 0x80000021 HASH1: 0x00018D00 HASH2: 0x000172C0
>|IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000
>|
>|82660 Registers:
>|Err Status 1: 0x20, Err Status 2: 0x00, CPU Err: 0x72, PCI Err: 0x06
>|CPU/PCI Addr: 0x0CBA9E40, Sys Error Addr: 0x0CBA9E40
>|
>|Call Stack:
>| 0x00F10094 (Exception return address - SRR0)
>| 0x00F0E980
>| 0x00F0F4F0
>| 0x00F005A0
>| 0x00F009F0
>| 0x00F00390
>| 0x00F00028
>|
>|
>|
>|
>|
>|Attempting auto-load from Network ...
>|
>|Initializing Flash Filesystem ... OK
>|No Change in kernel.dmi (Flash not Updated)
>|
>|Reinitializing decompression module.
>|In : 303800 bytes
>|--10--20--30--40--50--60--70--80--90--100
>|.
>|Can't write.
>|
>|
>|
>|EXCEPTION 0200 CRASH DUMP:
>|
>|GPRs:
>|R0: 0x00F0E980 R1: 0x010FFD58 R2: 0x00F1F748 R3: 0x00000000
>|R4: 0x00F1788C R5: 0x00FB6DD0 R6: 0x00FB6DD0 R7: 0x00000208
>|R8: 0x000001D1 R9: 0x000001D1 R10: 0x0000010A R11: 0x0000001F
>|R12: 0x0CBA9E40 R13: 0x00F1FDB0 R14: 0x00000000 R15: 0x00000000
>|R16: 0x00000000 R17: 0x00F17E74 R18: 0x00F17E70 R19: 0x0000FDB3
>|R20: 0x00F17DE0 R21: 0x00001DAB R22: 0x00F17DE8 R23: 0x00FB6510
>|R24: 0x00000000 R25: 0x00000035 R26: 0x00FAE748 R27: 0x00000008
>|R28: 0x00000000 R29: 0x00000101 R30: 0x00000072 R31: 0x00000002
>|
>|SPRs:
>|CR: 0x44000000 XER: 0x20000018 LR: 0x00F0E980 CTR: 0x00F10F80
>|SRR0: 0x00F10094 SRR1: 0x0008B930 DSISR: 0x40000000 DAR: 0x38634C4F
>|DMISS: 0x38634C48 DCMP: 0x80000021 HASH1: 0x00018D00 HASH2: 0x000172C0
>|IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000
>|
>|82660 Registers:
>|Err Status 1: 0x20, Err Status 2: 0x00, CPU Err: 0x72, PCI Err: 0x06
>|CPU/PCI Addr: 0x0CBA9E40, Sys Error Addr: 0x0CBA9E40
>|
>|Call Stack:
>| 0x00F10094 (Exception return address - SRR0)
>| 0x00F0E980
>| 0x00F0F57C
>| 0x00F005A0
>| 0x00F009F0
>| 0x00F00390
>| 0x00F00028
>|
>|-
>| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>| 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.
>|
>
>- Marcelo
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Robert von Bismarck <rvb@petrel.ch>
Subject: RE: (usr-tc) Mr. PC Global and his Spam
Date: 06 Sep 1999 17:12:59 +0200
Yep, got it too and find it bad, as we didn't get anough spam =
already...
-----Original Message-----
From: Phil Le Clercq [SMTP:phil.le.clercq@cinergy.net]
Sent: mardi, 31. ao=FBt 1999 10:21
To: 'usr-tc@lists.xmission.com'; 'andrew@pcglobal.net'
Subject: (usr-tc) Mr. PC Global and his Spam
Has anyone else on the TCH list received the below spam from
pcglobal? The
only way my email address would have been nabbed would be from this
TCH
list. I am formally asking pcglobal to refrain from using these
mailing
techniques, this was not the reason for which I joined this list and
believe
it to be bang out of order. Please don't do it again.
Phil Le Clercq
"Dear Subscriber,
You have been asked to be added to our Huge Inventory list. This
list will
be updated to alert you as we receive in the quantites of computer
hardware
we notified you of.
We just received in the following- We wish to move the lots of
equipment as
specified in the category:
Please submit your offer. Our decision to sell will be made by 3:00
Tuesday
Aug, 30 1999
As always, all items are in stock, in OUR inventory. No middlemen,
brokers
involved.
All items FOB Phoenix, AZ
PRINTERS:
(2) Lexmark Optra R+ W/Duplexer.......more crap
........(15) HP Vectra VL90=20
(20) ATT Globalyst 520
(30) assorted 486 notebooks color/mono
PC Global, Inc=20
(602) 438-6200 Tel
(602) 438-1119 Fax
Customer relations=20
Inventory logistics"
-----Original Message-----
From: Jack Singer [mailto:jsinger@aaacars.com]
Sent: Tuesday, August 31, 1999 2:53 AM
To: usr-tc@lists.xmission.com
Subject: Re: (usr-tc) Need used TC Units
If it is cheap enough....
Jack
"Andrew:PC Global, Inc." wrote:
> Can you use v.34 token ring chassis?
>
> Andrew Shlensky
> ****************************
> PC Global, Inc.
> (602) 438-6200 office (NEW TEL NUMBER!)
> (602) 438-1119 fax
> (305) 216-8638 mobile
> New!e-mail my mobile http://www.nextel.com/paging
> URL: http://www.pcglobal.net
> E-MAIL: andrew@pcglobal.net
> ICQ: 21219089
> Computer Service Parts SpEciaLiSts!
> Leader in New/Used PCs,Laptops
> Communication & Networking,Monitors
> Printers, Hard Drives, Midrange/Mainframe.
> Hard to Get Parts. We buy and sell all
> types of GEAR-
> ****************************
> ----- Original Message -----
> From: Jack Singer <jsinger@aaacars.com>
> To: <usr-tc@lists.xmission.com>
> Sent: Monday, August 30, 1999 12:56 PM
> Subject: (usr-tc) Need used TC Units
>
> Wanted to buy, used Total Control units, prefer X2 or V.90
upgraded. I
need
> eight or more units, so if you have one or more, please email or
call me
> directly.
>
> Internet Connections
> 6008 Hermitage Road
> Richmond, VA 23228
> (800) 664-5270
> jsinger@i-c.net
>
> -
> To unsubscribe to usr-tc, send an email to
"majordomo@xmission.com"
> 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.
>
> -
> To unsubscribe to usr-tc, send an email to
"majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "jamie dolan" <jamie@powernetonline.com>
Subject: (usr-tc) QUAD USR
Date: 06 Sep 1999 20:38:42 -0500
This is a multi-part message in MIME format.
------=_NextPart_000_0280_01BEF8A7.CEFB5FC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,
One of my old 2 PRI's quad units has been giving us problems for some =
time now. I want to get rid of it. I already have several Hyper =
chasies, so I can either use DSP cards or a whole new DSP chassie with =
cards in it. I am wondering what someone can suggest, in terms of trade =
in programs and how well the programs have or have not worked for you. =
If any one has a web site with a current list of all USR and vendor =
promos, please let me know.
Thanks.
PowerNet
------=_NextPart_000_0280_01BEF8A7.CEFB5FC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Hello,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>One of my old 2 PRI's quad units has been giving us =
problems=20
for some time now. I want to get rid of it. I already have =
several=20
Hyper chasies, so I can either use DSP cards or a whole new DSP chassie =
with=20
cards in it. I am wondering what someone can suggest, in terms of =
trade in=20
programs and how well the programs have or have not worked for =
you. If any=20
one has a web site with a current list of all USR and vendor promos, =
please let=20
me know.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Thanks.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>PowerNet</FONT></DIV></BODY></HTML>
------=_NextPart_000_0280_01BEF8A7.CEFB5FC0--
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
Date: 07 Sep 1999 08:00:20 -0400
Thus spake Mike Andrews
>On Wed, 1 Sep 1999, Jeff Mcadams wrote:
>> Perhaps, if you don't want to get into putting filters on your Arcs, and
>> are more comfortable with ciscos, you can put the filters at the next
>> hop cisco rather than on the arc directly. Doesn't get the filter quite
>> to the edge, but limits the damage a script kiddie can do within your
>> network. We don't do this, but I probably could. :)
>For most of our ARCs (Frankfort), the next hop Cisco *is* the border. I
>know, probably not a great network design, and I could fix it nowadays,
>but it's one of those evolved vs designed things...
And we're the same way in Louisville, what I was trying to get at was
that if your Arc's are spread across multiple networks (ours are, even
in Louisville), you can filter on the ethernet leading to the arcs, so,
for example, this would keep someone on Arc 1 from killing someone on
Arc 5 in our situation by putting the filters on the ethernets rather
than the serial interfaces out to our upstream.
>Yeah, and that's one thing I try to keep in mind before adding any more
>filters -- too easy to screw up legitimate use. (Especially with the port
>139 one... there are some mp3 leeching programs that use that to make the
>file transfers harder to track.) But for some of the DoS-prevention ones,
>I'd rather spend time on the phone explaining filters than time on the
>phone explaining how to remove Back Orifice from their PC. :) (Been
>there, done that, wasn't fun)
We just point them at some of the anti-virus vendors web sites and tell
them to go read. :)
>You can get into the same religious argument with spam, and liability for
>attacks/spam/whatever that do get through (if you don't filter, you're not
>liable; if you do, you might be) and all the other fun policy crap I got
>to learn by working at an .edu site for 3 years... :) But we won't get
>into that here...
No doubt...we don't do it so much from a liability point of view, but a
bit more practical...I just don't want to have to keep the extra filters
up to date. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Alex Bernal" <alex@chiriqui.com>
Subject: (usr-tc) WTB: USR Total Control
Date: 07 Sep 1999 08:11:11 -0600
This is a multi-part message in MIME format.
------=_NextPart_000_0085_01BEF908.8BD80FC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi:
I need to buy used in good working conditions:
US Robotics Total Control chassis equipped as follows:
Dual PRI card.
NetServer card (It have to be with ethernet nic).
Net management card (It have to be with ethernet nic).
12 digital/analog quad modems cards WITH analog/rs-232 NICs.
Two 45A AC power supplies.
1 Fan tray.
=20
Will pay 3,000.00 to 3,500.00
=20
Please respond privately to
alex@chiriqui.com =20
=20
Alexander Bernal 011-507-774-2512
------=_NextPart_000_0085_01BEF908.8BD80FC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Hi:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I need to buy used in good working=20
conditions:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>US Robotics Total Control chassis =
equipped=20
as follows:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Dual PRI card.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>NetServer card (It have to be with=20
ethernet nic).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Net management card (It have to be with =
ethernet=20
nic).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>12 digital/analog quad modems cards =
WITH=20
analog/rs-232 NICs.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Two 45A AC power =
supplies.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>1 Fan tray.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Will pay 3,000.00 to =
3,500.00</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Please respond privately to<BR><A=20
href=3D"mailto:alex@chiriqui.com">alex@chiriqui.com</A> </FONT=
></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Alexander Bernal=20
011-507-774-2512<BR></DIV></FONT></BODY></HTML>
------=_NextPart_000_0085_01BEF908.8BD80FC0--
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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 <kenk@shreve.net>
Subject: (usr-tc) Modem product codes
Date: 07 Sep 1999 10:22:23 -0500 (CDT)
Anyone know a good way of identifying the product code of a USR 56K Int
modem with out having the user rip apart their machine or installing Modem
Update Wizard? The ultimate goal is to determine if they have the latest
firmware revision.
___ ___
(___) Kenneth Kirchner .o. mailto:kenk@shreve.net (___)
(__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__)
(_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_)
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Andy Berkvam <aberkvam@coredcs.com>
Subject: Re: (usr-tc) Modem product codes
Date: 07 Sep 1999 12:18:07 -0500 (CDT)
On Tue, 7 Sep 1999, Ken Kirchner wrote:
> Anyone know a good way of identifying the product code of a USR 56K Int
> modem with out having the user rip apart their machine or installing Modem
> Update Wizard? The ultimate goal is to determine if they have the latest
> firmware revision.
>
An ATI command (ATI7, I believe) should give you both the Device ID
(product code) and the firmware dates and/or versions. You can usually
either have the customer use the Diagnostics in the Modem control panel or
use HyperTerminal to get the ATI commands (assuming they have Windows 9x).
Andy
--
===========================================================================
Andy Berkvam | "Only two things are infinite, the universe
| and human stupidity, and I'm not sure about
Email: | the former."
aberkvam@coredcs.com | - Albert Einstein
(MIME Attachments OK)|-WWW Pages: <http://www.coredcs.com/~aberkvam/>
===========================================================================
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: jlf@montrose-colo.com (Jim Faulkner)
Subject: (usr-tc) simultanious radius crashes
Date: 07 Sep 1999 11:46:23 -0600
Hello,
I have TC security and accounting version 5.5.3 running on three NT systems.
When one crashes the other 2 follow suit. It used to happen a couple times a
year now it's been 6 times in three days. Any Ideas?
Thanks,
Jim Faulkner
GWE.NET
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Marius Strom <marius@alpha1.net>
Subject: (usr-tc) SNMP OID
Date: 07 Sep 1999 19:38:25 -0500 (CDT)
Forgive me for asking, as I'm sure it's been asked before, however:
I'm looking for an SNMP OID to list how many users are online throughout
an entire TC system. I know Livingston has one on their PM3
(.1.3.6.1.2.1.2.1.0)..
Would appreciate it greatly!
--
Marius Strom <marius@alpha1.net>
Professional Geek/Unix System Administrator
Alpha1 Internet <http://www.alpha1.net>
http://www.marius.org/marius.pgp 0x5645C228
In theory, there is no difference between theory and practice...
...In practice, there is a big difference.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: das <das@gol.com>
Subject: (usr-tc) HARC 4.1.59 and 4.1.11 won't accept ISDN
Date: 08 Sep 1999 15:49:38 +0900
A bit of an emergency...
I thought that I would upgrade my hipers this morning. I upgraded both to
4.1.59 and once they were rebooted they stopped authenticating ISDN calls.
I flashed one to 4.1.11 and it lost various parts of it's configuration (ex.
it lost its ip network settings but retained pool settings) I reconfigured
it, but it still is having the same problems with ISDN. Analog calls
authenticate happily. I have tried flashing the second HARC back to 4.1.59, but
now it keeps failing the tftp upload.
Also, when I look in the logs, it repeatedly logs:
--syslog capture: 2b110903 slot:4/mod:10 --syslog capture:stop
each time for the same interface (slot and modem) and then it moves to a different
interface.
If anyone can offer any insight into this, I'm sure that my customers will be happily
and I will be extremely grateful.
das
--
____________________________________________
Alex Substanley Global OnLine Japan
Engineering Department
Das Man TEL: 81-3-5334-1700
Systems Engineer FAX: 81-3-5334-1711
The Highest Quality Service, Bar None
____________________________________________
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: das <das@gol.com>
Subject: (usr-tc) HARC 4.1.59 and 4.1.11 won't accept ISDN
Date: 08 Sep 1999 15:49:38 +0900
A bit of an emergency...
I thought that I would upgrade my hipers this morning. I upgraded both to
4.1.59 and once they were rebooted they stopped authenticating ISDN calls.
I flashed one to 4.1.11 and it lost various parts of it's configuration (ex.
it lost its ip network settings but retained pool settings) I reconfigured
it, but it still is having the same problems with ISDN. Analog calls
authenticate happily. I have tried flashing the second HARC back to 4.1.59, but
now it keeps failing the tftp upload.
Also, when I look in the logs, it repeatedly logs:
--syslog capture: 2b110903 slot:4/mod:10 --syslog capture:stop
each time for the same interface (slot and modem) and then it moves to a different
interface.
If anyone can offer any insight into this, I'm sure that my customers will be happily
and I will be extremely grateful.
das
--
____________________________________________
Alex Substanley Global OnLine Japan
Engineering Department
Das Man TEL: 81-3-5334-1700
Systems Engineer FAX: 81-3-5334-1711
The Highest Quality Service, Bar None
____________________________________________
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: das <das@gol.com>
Subject: Re: (usr-tc) HARC 4.1.59 and 4.1.11 won't accept ISDN
Date: 08 Sep 1999 17:58:12 +0900
Arigatou, Kobayashi-san.
I am in Japan as well. I seem to have fixed the problem. I had to power cycle the
chassis to get rid of it. I put a new HARC in the chassis, reconfigured it and I got
the same results. I decided to power cycle the chassis, and it is now happy. Much
stress for me though.
Thank you for your suggestions. I had tried those steps at earlier stages as well, so it
is good to see that I was on the right track.
das
Yuichi_Kobayashi@jp.3com.com (Yuichi_Kobayashi@jp.3com.com) spake:
>
>
> Das,
>
> We don't have the similer problem in Japan though , so I am not sure but
> Disableing or enabling PPP offloading may cure the problem . In case 'enable PPP
> offloading ' then need to set 'DISABLE PPP RECEIVE_ACCM ' as the release note of
> 4.1.59-6 .
>
> Regards,
> Kobayashi.
>
--
____________________________________________
Alex Substanley Global OnLine Japan
Engineering Department
Das Man TEL: 81-3-5334-1700
Systems Engineer FAX: 81-3-5334-1711
The Highest Quality Service, Bar None
____________________________________________
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Steve Valiunas" <Steve_Valiunas@mw.3com.com>
Subject: Re: (usr-tc) simultanious radius crashes
Date: 08 Sep 1999 09:41:54 -0500
If you enable debug on the servers and watch for the last received packet, is
it the same on more than one server? What was the authentication type-
pap/chap/ms-chap?
STeve
jlf@montrose-colo.com (Jim Faulkner) on 09/07/99 12:46:23 PM
Please respond to usr-tc@lists.xmission.com
Sent by: jlf@montrose-colo.com (Jim Faulkner)
cc: (Steve Valiunas/MW/US/3Com)
Hello,
I have TC security and accounting version 5.5.3 running on three NT systems.
When one crashes the other 2 follow suit. It used to happen a couple times a
year now it's been 6 times in three days. Any Ideas?
Thanks,
Jim Faulkner
GWE.NET
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Aaron Nabil <nabil@spiritone.com>
Subject: (usr-tc) found some users logged in as "default"
Date: 08 Sep 1999 02:21:59 -0700 (PDT)
I found a couple users logged into a chassis as "default". They
were not authenticated by (not was any request made to) my
radius server.
Anyone seen this happening before? Any clues?
config info:
us8a> _sh ver
V4.2.29 - 1
us8a> show authen
RADIUS AUTHENTICATION SETTINGS
Local Authentication is: DISABLED
Remote Authentication is: ENABLED
Hint Assigned is: DISABLED
Primary Server is: 205.139.108.2
Primary Destination Port is: 1645
Secondary Server is: 0.0.0.0
Secondary Destination Port is: 1645
Tertiary Server is: 0.0.0.0
Tertiary Destination Port is: 1645
Source Port is: 1645
Retransmission Timeout: 3 seconds
Max Retranmissions: 10
Vendor Specific Attribute: ENABLED
Active Authentication Server: 205.139.108.2
us8a> show user default
INFORMATION FOR USER: default
Status: INACTIVE
Type: NETWORK
Expiration: NONE
Message:
DNIS Re Authentication: DISABLED
Phone Number:
Alternate Phone Number:
Input Filter:
Output Filter:
Modem Group: all
Session Timeout in seconds: 0
Idle Timeout in seconds: 0
Tap Status: DISABLED
Tap Format: ASCII
Tap Output: SYSLOG
Tap Facility: LOG_AUTH
Tap Loglevel: VERBOSE
Tap Address: 0.0.0.0
Chat Script Name:
accounting radius entries for the call:
Code: Accounting-Request
Identifier: 143
Attributes:
User-Name = "default"
NAS-IP-Address = 192.168.0.224
Acct-Status-Type = Start
Acct-Session-Id = "34603054"
Acct-Delay-Time = 0
Acct-Authentic = Local
Service-Type = Framed-User
NAS-Port-Type = Async
NAS-Port = 65
USR-Modem-Training-Time = 18
USR-Interface-Index = 1785
USR-Chassis-Call-Slot = 3
USR-Chassis-Call-Span = 1
USR-Chassis-Call-Channel = 17
USR-Unauthenticated-Time = 22
Calling-Station-Id = ""
Called-Station-Id = "5034262600"
USR-Modulation-Type = v90Digital
USR-Simplified-MNP-Levels = ccittV42
USR-Simplified-V42bis-Usage = ccittV42bis
USR-Connect-Speed = 50666_BPS
Framed-Protocol = PPP
Framed-IP-Address = 206.98.121.68
Code: Accounting-Request
Identifier: 117
Authentic: <207>7<18><251><S<252><201><220><170>MV}Wg}
Attributes:
User-Name = "default"
NAS-IP-Address = 192.168.0.224
Acct-Status-Type = Stop
Acct-Session-Id = "34603054"
Acct-Delay-Time = 0
Acct-Authentic = Local
Service-Type = Framed-User
NAS-Port-Type = Async
NAS-Port = 65
USR-Modem-Training-Time = 18
USR-Interface-Index = 1785
USR-Chassis-Call-Slot = 3
USR-Chassis-Call-Span = 1
USR-Chassis-Call-Channel = 17
USR-Unauthenticated-Time = 22
Calling-Station-Id = ""
Called-Station-Id = "5034262600"
USR-Modulation-Type = v90Digital
USR-Simplified-MNP-Levels = ccittV42
USR-Simplified-V42bis-Usage = ccittV42bis
USR-Connect-Speed = 50666_BPS
Framed-Protocol = PPP
Framed-IP-Address = 206.98.121.68
Acct-Session-Time = 6123
Acct-Terminate-Cause = User-Request
Acct-Input-Octets = 266748
Acct-Output-Octets = 2667718
Acct-Input-Packets = 4445
Acct-Output-Packets = 6035
--
Aaron Nabil
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Robert von Bismarck <rvb@petrel.ch>
Subject: RE: (usr-tc) SNMP OID to reset card
Date: 06 Sep 1999 17:11:18 +0200
Yeah, but the solaris version is only compatible to 2.5.1 on SPARC. =
This
sucks bad as my network management station is an ultra-1 running 2.6 =
because
of HP OpenView... okay I do have an old HP 9000 lying around somehwere =
which
I could use for TCM (yet another 20" screen on my desktop ;-)
Does anyone have any experience with the HPUX version ? is it =
good/bad/same
as solaris ?
Robert von BISMARCK
Systems Engineer
_________________________
SPAN* / Petrel Communications SA=20
T=E9l : + 41 22 304 47 47
Fax : + 41 21 304 47 99
e-mail : rvb@petrel.ch
Web : http://ww.span.ch/
-----Original Message-----
From: Pete Ashdown [SMTP:pashdown@xmission.com]
Sent: lundi, 30. ao=FBt 1999 19:55
To: usr-tc@lists.xmission.com
Subject: Re: (usr-tc) SNMP OID to reset card
Paul Farber said once upon a time:
>Is there a LINUX version of TCM yet? I remember a list post to
mail a guy
>at 3Com... and luck yet?
I had a long discussion with the person in charge of development.
He
placed a survey on the list that polled interest in regards to a
Linux
version. He didn't get a strong response, and was put off by the
fact that
people think TCM would be a better product if it was open source.
Based on
this, I don't think TCM Linux is a strong bet. 3com appears to be
happy to
stick their head in the sand for a few more years based on an
informal
poll.
What baffles me is that they insist on still making the HPUX
version. Do
they honestly believe that more ISPs/sysadmins are using HPUX than
Linux?
>Has anyone got TCM to run under X w/Wine?
No, but I use it under Solaris and X. The Solaris version is
significantly
better than the Windoze version. Its worth buying a cheap IPX for
the sole
purpose of running TCM.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "jamie dolan" <jamie@powernetonline.com>
Subject: (usr-tc) Network Management
Date: 08 Sep 1999 11:53:11 -0500
This is a multi-part message in MIME format.
------=_NextPart_000_0532_01BEF9F0.B9863440
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Anyone have a command referance for setting up the new Network Managment =
Cards. Working on some special projects, and hoping for a complete =
command referance. I can not seem to find one online.
Thanks.
Jamie
------=_NextPart_000_0532_01BEF9F0.B9863440
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Anyone have a command referance for =
setting up=20
the new Network Managment Cards. Working on some special projects, =
and=20
hoping for a complete command referance. I can not seem to find =
one=20
online.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Thanks.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Jamie</FONT></DIV></BODY></HTML>
------=_NextPart_000_0532_01BEF9F0.B9863440--
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: <pferraro@wna-linknet.com>
Subject: (usr-tc) Checking DSP CRC errors
Date: 08 Sep 1999 13:04:40 -0400 (EDT)
Anyone know how to check the DSPs to see how many CRC, etc type
errors are received down a span? I assume you can do it at the CLI
level, but I don't know the command?
==============================================================================
Phillip Ferraro WorldNet Access, Inc
pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
Voice (910) 346-0835 824 Gumbranch Square, Suite R3
FAX (910) 455-1933 Jacksonville, Nc 28540-6269
==============================================================================
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: RE: (usr-tc) Checking DSP CRC errors
Date: 08 Sep 1999 14:19:43 -0300
On Wednesday, September 08, 1999 2:05 PM, pferraro@wna-linknet.com
[SMTP:pferraro@wna-linknet.com] wrote:
>
> Anyone know how to check the DSPs to see how many CRC, etc type
> errors are received down a span? I assume you can do it at the CLI
> level, but I don't know the command?
>
at the DSP CLI you would do "disp near total" in order to see the cumulative
errors. "Disp near current" gives you the current interval and "disp near
interval a" gives you all the 15 minute intervals in the last 24 hours.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: <pferraro@wna-linknet.com>
Subject: RE: (usr-tc) Checking DSP CRC errors
Date: 08 Sep 1999 13:25:46 -0400 (EDT)
Matt,
Is there a command to CLEAR the totals?
Thanks Again!
==============================================================================
Phillip Ferraro WorldNet Access, Inc
pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
Voice (910) 346-0835 824 Gumbranch Square, Suite R3
FAX (910) 455-1933 Jacksonville, Nc 28540-6269
==============================================================================
On Wed, 8 Sep 1999, Stainforth, Matthew wrote:
> On Wednesday, September 08, 1999 2:05 PM, pferraro@wna-linknet.com
> [SMTP:pferraro@wna-linknet.com] wrote:
> >
> > Anyone know how to check the DSPs to see how many CRC, etc type
> > errors are received down a span? I assume you can do it at the CLI
> > level, but I don't know the command?
> >
>
> at the DSP CLI you would do "disp near total" in order to see the cumulative
> errors. "Disp near current" gives you the current interval and "disp near
> interval a" gives you all the 15 minute intervals in the last 24 hours.
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: RE: (usr-tc) Checking DSP CRC errors
Date: 08 Sep 1999 14:34:03 -0300
Not the cumulative totals, at last I have never found one. The only error
clearing function I found was "clear near" which clears the error count for
the current interval only.
On Wednesday, September 08, 1999 2:26 PM, pferraro@wna-linknet.com
[SMTP:pferraro@wna-linknet.com] wrote:
>
> Matt,
>
> Is there a command to CLEAR the totals?
> Thanks Again!
>
============================================================================
==
>
> Phillip Ferraro WorldNet Access, Inc
> pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
> Voice (910) 346-0835 824 Gumbranch Square, Suite R3
> FAX (910) 455-1933 Jacksonville, Nc 28540-6269
>
============================================================================
==
>
>
> On Wed, 8 Sep 1999, Stainforth, Matthew wrote:
>
> > On Wednesday, September 08, 1999 2:05 PM, pferraro@wna-linknet.com
> > [SMTP:pferraro@wna-linknet.com] wrote:
> > >
> > > Anyone know how to check the DSPs to see how many CRC, etc type
> > > errors are received down a span? I assume you can do it at the CLI
> > > level, but I don't know the command?
> > >
> >
> > at the DSP CLI you would do "disp near total" in order to see the
> > cumulative
> > errors. "Disp near current" gives you the current interval and "disp
near
> > interval a" gives you all the 15 minute intervals in the last 24 hours.
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: jeff.binkley@asacomp.com (Jeff Binkley)
Subject: (usr-tc) (USR-TC) SIMULTANIOUS RAD
Date: 08 Sep 1999 10:51:00 -0500
Jim,
We run 6.0.8 and it does the same thing. I am assuming you are pointing
them all at the same MS Access database ? We get an NT access violation
when they crash.
Jeff Binkley
ASA Network Computing
U>Hello,
U>I have TC security and accounting version 5.5.3 running on three NT
U>systems. When one crashes the other 2 follow suit. It used to happen a
U>couple times a year now it's been 6 times in three days. Any Ideas?
U>Thanks,
U>Jim Faulkner
U>GWE.NET
CMPQwk 1.42 9999
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: jlf@montrose-colo.com (Jim Faulkner)
Subject: Re: (usr-tc) (USR-TC) SIMULTANIOUS RAD
Date: 08 Sep 1999 17:14:01 -0600
Thanks Jeff,
Actually I have a separate copy of the same database on each machine. I have
a batch file that backs up the origonal dbase to each machine when I make
changes.
I get Dr Watson error warnings on the NT's and an Illegal Program operation
on a W98 machine.
Jim
----- Original Message -----
Sent: Wednesday, September 08, 1999 9:51 AM
>
>
>
> Jim,
>
> We run 6.0.8 and it does the same thing. I am assuming you are pointing
> them all at the same MS Access database ? We get an NT access violation
> when they crash.
>
>
> Jeff Binkley
> ASA Network Computing
>
>
>
> U>Hello,
>
> U>I have TC security and accounting version 5.5.3 running on three NT
> U>systems. When one crashes the other 2 follow suit. It used to happen a
> U>couple times a year now it's been 6 times in three days. Any Ideas?
>
> U>Thanks,
> U>Jim Faulkner
> U>GWE.NET
>
> CMPQwk 1.42 9999
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: eric@dol.net
Subject: (usr-tc) cisco vs tc
Date: 08 Sep 1999 19:04:29 -0600
How does the Cisco remote access servers compare to the TC with
regards to customer satisfaction and connect speeds for those
who have experience with both products? Most of the discussions
here have been on the Ascend vs TC. We wanted to evaluate the
current cisco solution as well.
At what stage in the life cycle is the Cisco product at?
thanks
eric
Delaware Online!.........The SMART Choice!
With 56K V.90 & X2 & Flex Modems
Phone : 302-762-0375
Fax: 302-762-3462
Failure is NOT an option...
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: jeff.binkley@asacomp.com (Jeff Binkley)
Subject: Re: (usr-tc) simultanious
Date: 09 Sep 1999 07:13:00 -0500
Steve,
Maybe Jim can do this. However for me it happens so infrequently that I
can't affored to leave debug running and creating huge log files. I am
not sure if it related to the version of HiPerArc code we are running or
not. For the record we are on 4.1.64 (due to 4.1.56 killing off our
WebRamp customers).
Jeff Binkley
ASA Network Computing
u>If you enable debug on the servers and watch for the last received
u>packet, is it the same on more than one server? What was the
u>authentication type- pap/chap/ms-chap?
u> STeve
u>jlf@montrose-colo.com (Jim Faulkner) on 09/07/99 12:46:23 PM
u>Please respond to usr-tc@lists.xmission.com
u>Sent by: jlf@montrose-colo.com (Jim Faulkner)
u>To: usr-tc@lists.xmission.com
u>cc: (Steve Valiunas/MW/US/3Com)
u>Subject: (usr-tc) simultanious radius crashes
u>Hello,
u>I have TC security and accounting version 5.5.3 running on three NT
u>systems. When one crashes the other 2 follow suit. It used to happen a
u>couple times a year now it's been 6 times in three days. Any Ideas?
u>Thanks,
u>Jim Faulkner
u>GWE.NET
u>-
u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
u> with "unsubscribe usr-tc" in the body of the message.
u> For information on digests or retrieving files and old messages send
u> "help" to the same address. Do not use quotes in your message.
u>-
u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
u> with "unsubscribe usr-tc" in the body of the message.
u> For information on digests or retrieving files and old messages send
u> "help" to the same address. Do not use quotes in your message.
CMPQwk 1.42 9999
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: jeff.binkley@asacomp.com (Jeff Binkley)
Subject: (usr-tc) Soundblaster Modems
Date: 09 Sep 1999 07:13:00 -0500
Is anyone else haviong problems with Soundblaster modems and their TC
hubs ? We've had 2 customers so far with them that we've had major
problems with. One customer we lost because they never were able to get
the modem to train with our TC hub and the other experiences frequent
disconnects. In both cases they never got into V.90 territory (i.e.
26.4 - 31.2kbs). We've had the one with the frequent disconnects
download the latest modem software from their website to no avail.
Anyone else seen the same thing ? Folks are buying these based on name
and low price. For our TC we are running both Quads and DSPs and we've
seen it happen on both.
Jeff Binkley
ASA Network Computing
CMPQwk 1.42 9999
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Martin Lathoud <nytral@enDirect.qc.ca>
Subject: (usr-tc) preventing netserver crash
Date: 09 Sep 1999 10:12:34 -0400 (EDT)
Hello,
I am using a TC with a Netserver (standart packet bus circuit) code
3.8.71. I never got an uptime over a week, using it only for PPP dialin
purposes. Anyone has an idea of what I should track down to isolate and
resolve this quite annoying problem? 3Com once went to see the crash dump,
but did nothing with it.. And latest updates to Netserver code turn quite
old, when you look at all the releases for Hiper stuff. I was said it is
still supported.. where?
TIA,
Martin
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) preventing netserver crash
Date: 09 Sep 1999 10:25:17 -0400
Thus spake Martin Lathoud
>I am using a TC with a Netserver (standart packet bus circuit) code
>3.8.71. I never got an uptime over a week, using it only for PPP dialin
>purposes. Anyone has an idea of what I should track down to isolate and
>resolve this quite annoying problem? 3Com once went to see the crash dump,
>but did nothing with it.. And latest updates to Netserver code turn quite
>old, when you look at all the releases for Hiper stuff. I was said it is
>still supported.. where?
The NETServers are supported in hardware only. Attribute that to 3Com's
lame-brained decision to not port the pilgrim code to the NETServer
hardware. The NETServer code was based on the ComOS code from
Livingston (now a part of Lucent and basically killed off), when the
licensing ran out, 3Com basically just chopped any support for it.
Lovely customer service there. :/
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) preventing netserver crash
Date: 09 Sep 1999 09:31:29 -0500
I've had the same thing in the past. Isolated to one unit. Various uptime
from 48 hours to like 17 days, then crashola.
Things I would suggest:
1. try different memory in it. You have 16-20mb in it, right?
2. you have a spare Netserver? Good idea to keep one around. Swap it out
and see if the problem goes away. You can pick one up for ~$700. In fact
I have several to sell even.
3. Still a problem? Try swapping out the chassis.
4. Still a problem? Try a different dual-T1 card
5. Give up, get a day job :^)
Clues:
1. Happen under load?
2. Consistently happen after a certain amount of time?
Anaway, that's the process I've gone through several times before (1-4
anyway).
Each of the above has at one time or the other solved a "netserver" problem
for me.
SMT
-----Original Message-----
Sent: Thursday, September 09, 1999 9:13 AM
Hello,
I am using a TC with a Netserver (standart packet bus circuit) code
3.8.71. I never got an uptime over a week, using it only for PPP dialin
purposes. Anyone has an idea of what I should track down to isolate and
resolve this quite annoying problem? 3Com once went to see the crash dump,
but did nothing with it.. And latest updates to Netserver code turn quite
old, when you look at all the releases for Hiper stuff. I was said it is
still supported.. where?
TIA,
Martin
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Clayton Zekelman <clayton@MNSi.Net>
Subject: RE: (usr-tc) preventing netserver crash
Date: 09 Sep 1999 11:35:14 -0400
We used to have a bunch of netservers that crashed regularly. Older
hardware revs had
problems with crashing. USR (3Com now) had an engineering change which
appeared to clear up the problem.
At 09:31 AM 9/9/99 -0500, you wrote:
>I've had the same thing in the past. Isolated to one unit. Various uptime
>from 48 hours to like 17 days, then crashola.
>
>Things I would suggest:
>
>1. try different memory in it. You have 16-20mb in it, right?
>2. you have a spare Netserver? Good idea to keep one around. Swap it out
>and see if the problem goes away. You can pick one up for ~$700. In fact
>I have several to sell even.
>3. Still a problem? Try swapping out the chassis.
>4. Still a problem? Try a different dual-T1 card
>5. Give up, get a day job :^)
>
>Clues:
>
>1. Happen under load?
>2. Consistently happen after a certain amount of time?
>
>Anaway, that's the process I've gone through several times before (1-4
>anyway).
>Each of the above has at one time or the other solved a "netserver" problem
>for me.
>
>SMT
>
>
>-----Original Message-----
>From: Martin Lathoud [mailto:nytral@enDirect.qc.ca]
>Sent: Thursday, September 09, 1999 9:13 AM
>To: usr-tc@lists.xmission.com
>Subject: (usr-tc) preventing netserver crash
>
>
>Hello,
>I am using a TC with a Netserver (standart packet bus circuit) code
>3.8.71. I never got an uptime over a week, using it only for PPP dialin
>purposes. Anyone has an idea of what I should track down to isolate and
>resolve this quite annoying problem? 3Com once went to see the crash dump,
>but did nothing with it.. And latest updates to Netserver code turn quite
>old, when you look at all the releases for Hiper stuff. I was said it is
>still supported.. where?
>
>TIA,
>Martin
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6
tel. 519-985-8410
fax. 519-258-3009
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Martin Lathoud <nytral@enDirect.qc.ca>
Subject: RE: (usr-tc) preventing netserver crash
Date: 09 Sep 1999 13:54:04 -0400 (EDT)
The chassis is less than 1.5 years old.. I would have expected to get an
Netserver enhanced packet circuit version.. I've been told that it
depended on stock availability, and that it's not meaning much.. As far as
I can see, uptime is not 3Com priority :(. Since I only own one Netserver
(except modem code *!*, PM3 is the way to go), no way to do swap tests..
I'd better purchase a new spare NS card (cheaper than renewing the
contract support).
For the clues: reboot is purely random but always above a couple of days,
usage is often >40 ports (not only at crash time)
Later,
Martin
On Thu, 9 Sep 1999, Clayton Zekelman wrote:
> We used to have a bunch of netservers that crashed regularly. Older
> hardware revs had
> problems with crashing. USR (3Com now) had an engineering change which
> appeared to clear up the problem.
>
> At 09:31 AM 9/9/99 -0500, you wrote:
> >I've had the same thing in the past. Isolated to one unit. Various uptime
> >from 48 hours to like 17 days, then crashola.
> >
> >Things I would suggest:
> >
> >1. try different memory in it. You have 16-20mb in it, right?
> >2. you have a spare Netserver? Good idea to keep one around. Swap it out
> >and see if the problem goes away. You can pick one up for ~$700. In fact
> >I have several to sell even.
> >3. Still a problem? Try swapping out the chassis.
> >4. Still a problem? Try a different dual-T1 card
> >5. Give up, get a day job :^)
> >
> >Clues:
> >
> >1. Happen under load?
> >2. Consistently happen after a certain amount of time?
> >
> >Anaway, that's the process I've gone through several times before (1-4
> >anyway).
> >Each of the above has at one time or the other solved a "netserver" problem
> >for me.
> >
> >SMT
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "William Brien" <William_Brien@mw.3com.com>
Subject: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete)
Date: 09 Sep 1999 13:36:43 -0500
3Com Customers,
3Com would like to announce the release of HiPerARC v4.2.32-1 on the
TotalService website at:
http://totalservice.3com.com/
The HiPerARC v4.2.32-1 Maintenance Release replaces HiPerARC v4.2.29. This
version has fixes for the upgrade issues from v4.1.59-6, HiperBomb DoS (Denial
of Service) attack, and SNMP security issues. If you are using HiPerARC v4.2.29
on your Total Control chassis at this time, you are advised to upgrade to
v4.2.32-1 as soon as possible.
Download of this code requires a valid service contract. If you would like to
purchase a service contract, please contact your local reseller of 3Com services
for more information. To locate your local Value Added Reseller, as well as
3Com sales offices, please go to:
http://www.3com.com/products/shop/where2buy_2.html
If there are any questions or concerns regarding this release, please contact
3Com Technical Support toll-free at 1-800-231-8770. If you are calling from an
area not handled by this number, the TotalService website has contact
information for other countries and regions. Please go to the TotalService
website and click on 'Contacting Tech Support' for more information.
The Software Compatibility Matrix on TotalService will be updated later this
week to reflect compatibility with other releases of code.
Thank you,
Chuck Stace and Will Brien
Customer Service Product Planning
Chuck_Stace@3com.com
William_Brien@3com.com
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Brian Elfert <brian@citilink.com>
Subject: RE: (usr-tc) preventing netserver crash
Date: 09 Sep 1999 13:33:42 -0500 (CDT)
On Thu, 9 Sep 1999, Martin Lathoud wrote:
> The chassis is less than 1.5 years old.. I would have expected to get an
> Netserver enhanced packet circuit version.. I've been told that it
> depended on stock availability, and that it's not meaning much.. As far as
> I can see, uptime is not 3Com priority :(. Since I only own one Netserver
Just because your chassis reboots, that doesn't necessarily mean it's a
widespread problem.
My 5 Netserver cards have never rebooted even once that I remember, and
I've had them for at least 1.5 years.
Brian
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Clayton Zekelman <clayton@MNSi.Net>
Subject: RE: (usr-tc) preventing netserver crash
Date: 09 Sep 1999 14:55:33 -0400
When we were running Netserver, we had around 25 units installed, and more
than 3/4 of them were rock solid and reliable. The remaining units were
flaky.
At 01:33 PM 9/9/99 -0500, you wrote:
>
>
>On Thu, 9 Sep 1999, Martin Lathoud wrote:
>
>> The chassis is less than 1.5 years old.. I would have expected to get an
>> Netserver enhanced packet circuit version.. I've been told that it
>> depended on stock availability, and that it's not meaning much.. As far as
>> I can see, uptime is not 3Com priority :(. Since I only own one Netserver
>
>Just because your chassis reboots, that doesn't necessarily mean it's a
>widespread problem.
>
>My 5 Netserver cards have never rebooted even once that I remember, and
>I've had them for at least 1.5 years.
>
>Brian
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6
tel. 519-985-8410
fax. 519-258-3009
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Jack Singer" <jsinger@aaacars.com>
Subject: Re: (usr-tc) Quad card refurbishing
Date: 09 Sep 1999 15:23:31 -0400
Does anyone refurbish USR Quad cards? I have 4 cards with bad modems on them.
Internet Connections
jsinger@i-c.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: CyberPort Montana <netboss@cyberport.net>
Subject: Re: (usr-tc) Quad card refurbishing
Date: 09 Sep 1999 13:26:24 -0600
I'll second that. I have a number of cards that also need repairs.
Gary
At 03:23 PM 9/9/99 -0400, you wrote:
>Does anyone refurbish USR Quad cards? I have 4 cards with bad modems on
them.
>
>Internet Connections
>jsinger@i-c.net
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Christopher Arlis Hanes" <chanes@usacars.com>
Subject: (usr-tc) Static IPs with large dialin pools
Date: 09 Sep 1999 15:31:10 -0400
How does one handle static IPs when the pools used by a particular
dialin number span multiple class Cs? (i.e. a user dialing in has the
possibility of of dialing into a box whose router card is not on the
same network as the user's static IP.)
Thanks,
Chris Hanes
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) Static IPs with large dialin pools
Date: 09 Sep 1999 15:49:39 -0400
Thus spake Christopher Arlis Hanes
>How does one handle static IPs when the pools used by a particular
>dialin number span multiple class Cs? (i.e. a user dialing in has the
>possibility of of dialing into a box whose router card is not on the
>same network as the user's static IP.)
RIPv2
enable ip rip
and set ip network <blah> routing_protocol ripv2
should take care of the basics...you'll also need to turn on ripv2 on
most of the rest of your network....at least as far up as it might
change depending on which Arc they hit.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Lon R. Stockton, Jr." <lon@moonstar.com>
Subject: Re: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete)
Date: 09 Sep 1999 16:04:33 -0400 (EDT)
On Thu, 9 Sep 1999, William Brien wrote:
> The HiPerARC v4.2.32-1 Maintenance Release replaces HiPerARC v4.2.29. This
> version has fixes for the upgrade issues from v4.1.59-6, HiperBomb DoS (Denial
> of Service) attack, and SNMP security issues. If you are using HiPerARC v4.2.29
> on your Total Control chassis at this time, you are advised to upgrade to
> v4.2.32-1 as soon as possible.
>
> Download of this code requires a valid service contract.
Requiring service contracts to get fixes for well-known, easy to implement
exploits is certainlly a way to sell service contracts.
Before I purchased, I was told this was a 'best-of-breed' device. Now
I find that I gotta pay a couple thousand more just to get it fixed so
that any 14 year old with a program he got off a website can't crash it.
Either that, or turn off features that I was told I'd have in the
purchased product.
The mafia might not exist, but looks like protection rackets are alive
and well.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Brian <signal@shreve.net>
Subject: Re: (usr-tc) Static IPs with large dialin pools
Date: 09 Sep 1999 15:16:08 -0500 (CDT)
On Thu, 9 Sep 1999, Christopher Arlis Hanes wrote:
>
> How does one handle static IPs when the pools used by a particular
> dialin number span multiple class Cs? (i.e. a user dialing in has the
> possibility of of dialing into a box whose router card is not on the
> same network as the user's static IP.)
Static IP's do not have to be on the same "network" as their gateways.
In other words, if you had a router that was 192.168.1.1, and a hiper ARC
that was 192.168.5.1 and a static IP that was 208.242.79.4, that is
perfectly fine.
What *matters* is that you have established proper routing on your
network. *generally* interface ip's for terminal servers and routing
devices with ethernet interfaces are statically routed, perhaps you route
a /28 or /27 to your ethernet for use by your terminal servers (arcs,
netservers, etc). Dynamic IP pools are setup on these devices, and
aggregates for these pools can be announced via ripv2 (or ospf on the
newer arc code).
Static IP's are also announced via ripv2 (or ospf).........so long as you
have your interior routing protocol setup correctly, this is not a
problem.
>
> Thanks,
> Chris Hanes
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike Wronski" <mike@coredump.ae.usr.com>
Subject: RE: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete)
Date: 09 Sep 1999 15:22:50 -0500
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Lon R. Stockton,
|Jr.
|Sent: Thursday, September 09, 1999 3:05 PM
|To: usr-tc@lists.xmission.com
|Subject: Re: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete)
|
|
|
|On Thu, 9 Sep 1999, William Brien wrote:
|
|> The HiPerARC v4.2.32-1 Maintenance Release replaces HiPerARC v4.2.29. This
|> version has fixes for the upgrade issues from v4.1.59-6, HiperBomb DoS (Denial
|> of Service) attack, and SNMP security issues. If you are using
|HiPerARC v4.2.29
|> on your Total Control chassis at this time, you are advised to upgrade to
|> v4.2.32-1 as soon as possible.
|>
|> Download of this code requires a valid service contract.
|
|
|Requiring service contracts to get fixes for well-known, easy to implement
|exploits is certainlly a way to sell service contracts.
This release is not intended as the fix for the security issues. It replaces
4.2.29, which is a feature enhancement. It does however have the security issues
resolved.
There will be a 4.1.x service release for the security issues and other resolved
bugs shortly. This service release will be made available to everyone for 90
days, as was the previous service release.
-M
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Greg owens" <gowens@magnolia-net.com>
Subject: Re: (usr-tc) Soundblaster Modems
Date: 09 Sep 1999 19:57:14 -0500
Jeff...We have one customer (that we know of) that is experiencing very
frequent disconnects. We thought at first a phone line issue but after 3
trips SWB says all their stuff is OK. No we have not found a fix for the
problem and will probably lose customer very soon.... BTW we are running
DSP's.....Any one else seeing this
Greg Owens
Magnolia Internet Services
http://www.magnolia-net.com
----- Original Message -----
Sent: Thursday, September 09, 1999 7:13 AM
>
>
> Is anyone else haviong problems with Soundblaster modems and their TC
> hubs ? We've had 2 customers so far with them that we've had major
> problems with. One customer we lost because they never were able to get
> the modem to train with our TC hub and the other experiences frequent
> disconnects. In both cases they never got into V.90 territory (i.e.
> 26.4 - 31.2kbs). We've had the one with the frequent disconnects
> download the latest modem software from their website to no avail.
> Anyone else seen the same thing ? Folks are buying these based on name
> and low price. For our TC we are running both Quads and DSPs and we've
> seen it happen on both.
>
>
> Jeff Binkley
> ASA Network Computing
>
> CMPQwk 1.42 9999
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Brett Murphy" <me@murf.net>
Subject: Re: (usr-tc) Soundblaster Modems
Date: 10 Sep 1999 11:05:14 +1000
It amazes me that modem manufacturors whos product only works with a subset
of digital access servers considers this to be "OK"
All the best,
Brett Murphy
Technical Manager, Alphalink (Australia) PTY LTD
ph: +61 3 9486-8844 fax: +61 3 9486-6822
email: me@murf.net
The contents of this email message may not be quoted,
copied, reproduced or published in part or in whole,
without the written authorization of Brett Murphy,
Director, Alphalink (Australia) Pty Ltd.
-----Original Message-----
>Jeff...We have one customer (that we know of) that is experiencing very
>frequent disconnects. We thought at first a phone line issue but after 3
>trips SWB says all their stuff is OK. No we have not found a fix for the
>problem and will probably lose customer very soon.... BTW we are running
>DSP's.....Any one else seeing this
>Greg Owens
>Magnolia Internet Services
>http://www.magnolia-net.com
>----- Original Message -----
>From: Jeff Binkley <jeff.binkley@asacomp.com>
>To: <usr-tc@lists.xmission.com>
>Sent: Thursday, September 09, 1999 7:13 AM
>Subject: (usr-tc) Soundblaster Modems
>
>
>>
>>
>> Is anyone else haviong problems with Soundblaster modems and their TC
>> hubs ? We've had 2 customers so far with them that we've had major
>> problems with. One customer we lost because they never were able to get
>> the modem to train with our TC hub and the other experiences frequent
>> disconnects. In both cases they never got into V.90 territory (i.e.
>> 26.4 - 31.2kbs). We've had the one with the frequent disconnects
>> download the latest modem software from their website to no avail.
>> Anyone else seen the same thing ? Folks are buying these based on name
>> and low price. For our TC we are running both Quads and DSPs and we've
>> seen it happen on both.
>>
>>
>> Jeff Binkley
>> ASA Network Computing
>>
>> CMPQwk 1.42 9999
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> 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.
>>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jim Johnson <jim@perigee.net>
Subject: (usr-tc) [Fwd: Locating a bad HDSP port / Modems with 'highincomingconnections
Date: 10 Sep 1999 09:38:09 -0400
Is anyone else working with USR on this problem?
They had some testing code that reset the port after every call, that we
decided not to use on our production modems. Is anyone else using this
code and is it working?
Also, thanks to **Eric Billeter** for writing the script we are running
every day look for this automatically.
Regards,
Jim
Jim Johnson wrote:
>
> David,
>
> How is the new modem code coming? We are having a problem about once
> every two weeks. Haven't had one since last wednesday, and I am getting
> worried....
>
> Last week, we had two ports flake out at the beginning of the hunt
> group. All hell broke loose around here as people called to complain.
> :(
>
> Also, on another note, when will the modem code improve on the DSPs? We
> are losing customers right now because they are having disconnect and
> poor connect problems. Apparently, ISPs who use Ascend or PMs are
> having much better success in connecting these clients. I would suggest
> we quit worrying about the HiperARC code and work on the modem code
> right now!
>
> Thanks,
>
> Jim Johnson
>
> David Bachta wrote:
> >
> > Hi Jim,
> >
> > Thanks for your reply. I'll be sure to drop you a note as soon as we have a
> > released version of code to rectify the problem.
> >
> > Thank you for your comments regarding our support. I'm very sorry to hear your
> > past experiences with our support team have been less than favorable. We have
> > been striving to improve the quality of our support organization and I think we
> > have made some great progress, especially in the last year. If you haven't done
> > so already, you may want to check out some of our new support tools that don't
> > require a service contract (3KB, ISP Home Page, Totalservice Field Reported
> > Issues, 3Com Users forums, etc).
> >
> > Best Regards,
> > David
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Ralph Helfenberger <r.helfenberger@comlight.ch>
Subject: (usr-tc) Sawin for Windows silently died?
Date: 10 Sep 1999 16:19:11 +0200
Hi
When I went through the latest 3Com price list I could no longer find
the Security and Accounting Server for Windows. Did anybody of you
receive information about this product beeing discontinued?
Thanks.
Ralph
--
==========================================================================
R. Helfenberger Internet r.helfenberger@comlight.ch
Comlight AG Tel +41 31 740 40 40
Industriestr. 17 Fax +41 31 740 40 90
3178 Boesingen
Switzerland www.comlight.ch
==========================================================================
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: (usr-tc) HiPer Arc improvement thoughts...
Date: 10 Sep 1999 10:45:49 -0400
I mentioned earlier that I was going to email the list with some
thoughts of where I thought the HiPer Arc platform could/should go...
I have a little bit of time now, so maybe I can put some of these
thoughts down and maybe get some thoughts and discussion from the rest
of you about feasibility and maybe some other ideas...In any
case...these ideas are thrown out to maybe get some discussion going to
help give 3Com an idea of what we, as customers, would like to see out
of the Arc.
First off...a couple of specific feature requests...I may have mentioned
these before....if so, my apologies.
1) Bridging support...both over PPP, and over ethernet interfaces, and
any other interfaces that are supported (such as the new frame-relay
ones).
Imagine plugging your two ethernet interfaces into two different
switches in the same IP network...running spanning-tree between them
all...then your Arc isn't dependant on its switch being in one piece
to be able to communicate. Would require the use of a "virtual"
interface that participated in the bridging code as well...similar
in some ways to the internal interface that is available for use
with OSPF now. Basically, assign the IP address for the Arc to the
virtual interface, the Arc sends packets to the virtual interface,
when then goes into the bridging code to decide which physical
interface its sent out. This is very similar to Cisco's
bridge-groups with their integrated routing and bridging for those
of you who are familiar with that.
2) Support for a "packet bus interface". This one sounds bizarre...but
if you think about it for a bit it starts to make sense...if you have
multiple Arc's in a chassis...why make them communicate out their NIC's
onto an external network to talk to each other? Some benefits for
this...
With the first feature....you could have two Arcs, both running
briding code as well...each with a single ethernet+4t1 NIC and
support 8 frame-relay t1's, and still retain the dual-exit
capability described above with briding or routing over the packet
bus. You could also theoretically have an Arc handling modems that
has no NIC at all! Modem interfaces come in over the packet bus,
and that same data is then shipped back out over the packet bus
interface to another Arc with NIC card. This method could also be
used as a failover scenario if a NIC card failed, or a cable failed,
or a switch failed...you get the idea.
3) A larger variety of NIC interfaces. Particularly combined with the
packet bus interface, this frees you up to have a much greater variety
of NIC types...the Arc can then use the packet bus interface to get out
to the ethernet network (via another Arc most likely...either bridged or
routed), and allowing...oh....8 t1 NICs, or maybe a t3 nic, a
channelized t3 nic would be really sweet...the sky is the limit here
once you get the arcs using the packet bus as their ethernet
interface...
4) Similar to 3...the DSP cards have a crap-load of processing power in
them...could they be used for something more than just modems? It
seems...if you look at it in the abstract...that the DSP cards are
essentially interface extensions for the Arcs...let's take that
farther....this would mean basically totally revamping the code for the
DSP's for the new uses, or perhaps coming out with new code that's more
generalized. Then, with the possibility of new NICs for the DSP's you
could, again, extend the interface possibilities for the Arcs.
5) One that has bugged me for quite some time...PPP support on WAN
ports. I really don't particularly liked being restricted to
frame-relay encapsulation only...I can deal with it...but it'd be nice
to have the option of PPP encap as well. Many low end t1 routers don't
have frame-relay encap support, and it would be nice to be able to
interoperate with them.
In more abstract terms...I've been told by several 3Com folks that they
see the Pilgrim/Hiper Arc code as more full routing code rather than
just code for an Access Server. My understanding is that 3Com is moving
*all* of their routing products to eventually use the Pilgrim based
code.
With that thought in mind though...3Com seems (from a customer's
perspective) to still think of the HiPer Arc, specifically, as an access
server alone. I think the HiPer Arc and the Total Control platform as a
whole could become a quite capable router chassis product as a whole.
Personally speaking...I'd like to see that. In a similar vein...3Com
seems to think of the DSP cards as big powerful modem cards...and while
that's certainly a good use for them...let's break that paradigm (oh
man...a marketing cliche'...my apologies) and see them for more than
that...what they really are...a crapload of processing power on a card
that could theoretically, to the best of my knowledge, run just about
any arbitrary code with just about any arbitrary type of interface on
the NIC. That's a *very* powerful thought IMO.
Executive summary (I know, this should be at the top)...if you think of
the Total Control platform basically as a distributed processing router
platform...lot's of possibilities are opened up going forward. The
current code on there is getting to be pretty good and solid...but its
designed and written for a single specific function...limiting the
places where the TC platform could be used. This largely comes down to
be a business decision from 3Com (Lord help us there), but if they
decide that they don't want to limit the TC platform to being *only* an
access server (and personally, I think the distinction between access
server and router is a pretty thin line), then they need to start
thinking of the Arc as a router, not just an access server, and the
DSP's as generic interface cards, not modem/t1/pri cards.
These thoughts are probably not articulated very well...they're just
thoughts that I've had in the back of my head for a while that I want to
get out to some other people to see what you all have to say about the
ideas. I know some people wouldn't be interested in all at using some
of the features...but what I'm trying to get at here is the overall
direction for development of the Arcs/TC's, not specific feature
requests...although I have included some specific feature requests in my
message...try not to focus on those specifically...they are mostly there
as examples for the overall direction I was thinking of. Some of these
thoughts have been expressed in the past to some people at 3Com, but I
don't think any one person has ever heard the totality of what I was
thinking of (not having had time to sit down with anyone for long enough
time to fully hash these thoughts out).
So...there it is...let's hear what you think. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: (usr-tc) HiperARC Console yes/no
Date: 10 Sep 1999 09:48:10 -0500
HiPer>> list chassis
Slot Owner Description Ports Type
Console
1 YES --EMPTY-- 0 STATIC NO
2 YES --EMPTY-- 0 STATIC NO
3 YES --EMPTY-- 0 STATIC NO
4 YES --EMPTY-- 0 STATIC NO
5 YES --EMPTY-- 0 STATIC NO
6 YES --EMPTY-- 0 STATIC NO
7 YES --EMPTY-- 0 STATIC NO
8 YES --EMPTY-- 0 STATIC NO
9 YES --EMPTY-- 0 STATIC NO
10 YES --EMPTY-- 0 STATIC NO
11 YES --EMPTY-- 0 STATIC NO
12 YES 24 Channel High Density Modem 24 DYNAMIC YES
13 YES 24 Channel High Density Modem 24 DYNAMIC NO
14 YES 24 Channel High Density Modem 24 DYNAMIC YES
15 YES 24 Channel High Density Modem 24 DYNAMIC NO
#13, 15 weren't setup any different than #12, 14; it's all working just
fine, I'm just curious why Console is "NO" on 13,15. And how does one use
this "console" ability anyway???
SMT
Scott Trautman 608-240-4638,4637fax
Global Dialog Internet www.gdinet.com
2810 Crossroads, STE LL2
Madison WI 53718
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Horace Demmink <horace@pathwaynet.com>
Subject: RE: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete)
Date: 10 Sep 1999 10:57:25 -0400 (EDT)
On Thu, 9 Sep 1999, Mike Wronski wrote:
> |Requiring service contracts to get fixes for well-known, easy to implement
> |exploits is certainlly a way to sell service contracts.
>
> This release is not intended as the fix for the security issues. It replaces
> 4.2.29, which is a feature enhancement. It does however have the security issues
> resolved.
>
> There will be a 4.1.x service release for the security issues and other resolved
> bugs shortly. This service release will be made available to everyone for 90
> days, as was the previous service release.
>
Will there be a 4.2.x service release to solve these issues that will be
made available to everyone?
--
Horace Demmink
PathWay Computing
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike Wronski" <mike@coredump.ae.usr.com>
Subject: RE: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete)
Date: 10 Sep 1999 10:10:42 -0500
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Horace Demmink
|Sent: Friday, September 10, 1999 9:57 AM
|To: usr-tc@lists.xmission.com
|Subject: RE: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete)
|
|
|On Thu, 9 Sep 1999, Mike Wronski wrote:
|
|> |Requiring service contracts to get fixes for well-known, easy to implement
|> |exploits is certainlly a way to sell service contracts.
|>
|> This release is not intended as the fix for the security issues. It replaces
|> 4.2.29, which is a feature enhancement. It does however have the
|security issues
|> resolved.
|>
|> There will be a 4.1.x service release for the security issues and
|other resolved
|> bugs shortly. This service release will be made available to everyone for 90
|> days, as was the previous service release.
|>
|
|Will there be a 4.2.x service release to solve these issues that will be
|made available to everyone?
What issues? The 4.2.32-1 does resolve the security issues. (As stated above)
-M
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Brett Murphy" <me@murf.net>
Subject: Re: (usr-tc) HiPer Arc improvement thoughts...
Date: 11 Sep 1999 01:44:33 +1000
>4) Similar to 3...the DSP cards have a crap-load of processing power in
>them...could they be used for something more than just modems? It
>seems...if you look at it in the abstract...that the DSP cards are
>essentially interface extensions for the Arcs...let's take that
>farther....this would mean basically totally revamping the code for the
>DSP's for the new uses, or perhaps coming out with new code that's more
>generalized.
seti@home !!!!!!!!
All the best,
Brett Murphy
Technical Manager, Alphalink (Australia) PTY LTD
ph: +61 3 9486-8844 fax: +61 3 9486-6822
email: me@murf.net
The contents of this email message may not be quoted,
copied, reproduced or published in part or in whole,
without the written authorization of Brett Murphy,
Director, Alphalink (Australia) Pty Ltd.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: RE: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete)
Date: 10 Sep 1999 12:11:48 -0400 (EDT)
On Fri, 10 Sep 1999, Mike Wronski wrote:
> What issues? The 4.2.32-1 does resolve the security issues. (As stated above)
It doesn't, however, seem to fix the serious problem with route
aggregation I mentioned here twice. :(
(quick summary: if ARC eth:1 is 10.1.1.0/25, and another router sends
10.1.1.0/23 via OSPF, it puts the /23 route in the routing table instead
of the /25, and marks it 'local' instead of 'ospf'. Right route, wrong
mask.)
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: RE: (usr-tc) HiperARC Console yes/no
Date: 10 Sep 1999 13:24:40 -0300
You can set up a reverse telnet type service through the arc using these
console interfaces so that you can telnet to the DSP consoles.
On Friday, September 10, 1999 11:48 AM, Scott Trautman
[SMTP:scottt@corp.gdinet.com] wrote:
> HiPer>> list chassis
> Slot Owner Description Ports Type
> Console
> 1 YES --EMPTY-- 0 STATIC NO
> 2 YES --EMPTY-- 0 STATIC NO
> 3 YES --EMPTY-- 0 STATIC NO
> 4 YES --EMPTY-- 0 STATIC NO
> 5 YES --EMPTY-- 0 STATIC NO
> 6 YES --EMPTY-- 0 STATIC NO
> 7 YES --EMPTY-- 0 STATIC NO
> 8 YES --EMPTY-- 0 STATIC NO
> 9 YES --EMPTY-- 0 STATIC NO
> 10 YES --EMPTY-- 0 STATIC NO
> 11 YES --EMPTY-- 0 STATIC NO
> 12 YES 24 Channel High Density Modem 24 DYNAMIC YES
> 13 YES 24 Channel High Density Modem 24 DYNAMIC NO
> 14 YES 24 Channel High Density Modem 24 DYNAMIC YES
> 15 YES 24 Channel High Density Modem 24 DYNAMIC NO
>
> #13, 15 weren't setup any different than #12, 14; it's all working just
> fine, I'm just curious why Console is "NO" on 13,15. And how does one use
> this "console" ability anyway???
>
> SMT
>
>
> Scott Trautman 608-240-4638,4637fax
> Global Dialog Internet www.gdinet.com
> 2810 Crossroads, STE LL2
> Madison WI 53718
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) HiPer Arc improvement thoughts...
Date: 10 Sep 1999 12:43:18 -0400
Thus spake Brett Murphy
>>4) Similar to 3...the DSP cards have a crap-load of processing power in
>>them...could they be used for something more than just modems? It
>>seems...if you look at it in the abstract...that the DSP cards are
>>essentially interface extensions for the Arcs...let's take that
>>farther....this would mean basically totally revamping the code for the
>>DSP's for the new uses, or perhaps coming out with new code that's more
>>generalized.
>seti@home !!!!!!!!
Heh...well...really wasn't thinking along those lines, but it could
really add to your work-unit totals if you did that though. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Todd Keister" <Todd_Keister@mw.3com.com>
Subject: Re: (usr-tc) Static IPs with large dialin pools
Date: 10 Sep 1999 14:51:01 -0500
Chris:
An easy way to accomplish what Brian has suggested would be to set your
routing protocol:
set ip network [network name] routing_protocol [NONE-default, ripv1, or
ripv2]
enable ip rip
enable ip proxy_arp_all_dialin
save all
Ripv2 is recommended since it will allow for split horizon and poison
reverse (more efficient routing). After a protocol is set, you will still
need to enable rip. You will also need to enable proxy arp. This will allow
the Hiper Arc can act as a proxy agent, and inform the router about the ip
addresses of clients that have been given addresses. The Harc will then accept
these return packets from your router, and send them to the correct client.
Hope this helps.
Todd ;-}
Brian <signal@shreve.net> on 09/09/99 03:16:08 PM
Please respond to usr-tc@lists.xmission.com
Sent by: Brian <signal@shreve.net>
cc: (Todd Keister/MW/US/3Com)
On Thu, 9 Sep 1999, Christopher Arlis Hanes wrote:
>
> How does one handle static IPs when the pools used by a particular
> dialin number span multiple class Cs? (i.e. a user dialing in has the
> possibility of of dialing into a box whose router card is not on the
> same network as the user's static IP.)
Static IP's do not have to be on the same "network" as their gateways.
In other words, if you had a router that was 192.168.1.1, and a hiper ARC
that was 192.168.5.1 and a static IP that was 208.242.79.4, that is
perfectly fine.
What *matters* is that you have established proper routing on your
network. *generally* interface ip's for terminal servers and routing
devices with ethernet interfaces are statically routed, perhaps you route
a /28 or /27 to your ethernet for use by your terminal servers (arcs,
netservers, etc). Dynamic IP pools are setup on these devices, and
aggregates for these pools can be announced via ripv2 (or ospf on the
newer arc code).
Static IP's are also announced via ripv2 (or ospf).........so long as you
have your interior routing protocol setup correctly, this is not a
problem.
>
> Thanks,
> Chris Hanes
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Steve Rivera <sales@wrca.net>
Subject: Re: (usr-tc) Need Some Quad Modems
Date: 10 Sep 1999 15:48:24 -0400
would you be interested in trading 12 analog/digitals of yours, for
12 digital modems of mine? No nics just the nacs.
Let me know.
At 01:57 PM 09/03/1999 -0700, you wrote:
>I have about 25 in stock... about 8 NICS . These are the V.34
>analog/Digital.
>We have been selling them at $175 each with a 90 day warranty
>
>We take all credit cards,
>
>Best Regards,
>Andrew Shlensky
>****************************
>PC Global, Inc.
>(602) 438-6200 office (NEW TEL NUMBER!)
>(602) 438-1119 fax
>(305) 216-8638 mobile
>New!e-mail my mobile http://www.nextel.com/paging
>URL: http://www.pcglobal.net
>E-MAIL: andrew@pcglobal.net
>ICQ: 21219089
>Computer Service Parts SpEciaLiSts!
>Leader in New/Used PCs,Laptops
>Communication & Networking,Monitors
>Printers, Hard Drives, Midrange/Mainframe.
>Hard to Get Parts. We buy and sell all
>types of GEAR-
>****************************
>----- Original Message -----
>From: Greg Coffey <gcoffey@vcn.com>
>To: <usr-tc@lists.xmission.com>
>Sent: Friday, September 03, 1999 1:45 PM
>Subject: (usr-tc) Need Some Quad Modems
>
>
>I'm in the market for some digital quads. Email me if you have some to
>sell. I could use 1-2 dozen of them.
>
>
>
>Thanks, Greg Coffey <gcoffey@vcn.com>
>Visionary Communications V 307-234-5443 F 307-234-5446
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Andrew:PC Global, Inc." <andrew@pcglobal.net>
Subject: Re: (usr-tc) Need Some Quad Modems
Date: 10 Sep 1999 13:01:59 -0700
Steve,
Honestly, we get more requests for the an/dig than the digitals so I cant do
it.
we are selling the analog/digitals for $150 each currently.
Thanks Steve,
Andrew Shlensky
****************************
PC Global, Inc.
(602) 438-6200 office (NEW TEL NUMBER!)
(602) 438-1119 fax
(305) 216-8638 mobile
New!e-mail my mobile http://www.nextel.com/paging
URL: http://www.pcglobal.net
E-MAIL: andrew@pcglobal.net
ICQ: 21219089
Computer Service Parts SpEciaLiSts!
Leader in New/Used PCs,Laptops
Communication & Networking,Monitors
Printers, Hard Drives, Midrange/Mainframe.
Hard to Get Parts. We buy and sell all
types of GEAR-
****************************
----- Original Message -----
Sent: Friday, September 10, 1999 12:48 PM
would you be interested in trading 12 analog/digitals of yours, for
12 digital modems of mine? No nics just the nacs.
Let me know.
At 01:57 PM 09/03/1999 -0700, you wrote:
>I have about 25 in stock... about 8 NICS . These are the V.34
>analog/Digital.
>We have been selling them at $175 each with a 90 day warranty
>
>We take all credit cards,
>
>Best Regards,
>Andrew Shlensky
>****************************
>PC Global, Inc.
>(602) 438-6200 office (NEW TEL NUMBER!)
>(602) 438-1119 fax
>(305) 216-8638 mobile
>New!e-mail my mobile http://www.nextel.com/paging
>URL: http://www.pcglobal.net
>E-MAIL: andrew@pcglobal.net
>ICQ: 21219089
>Computer Service Parts SpEciaLiSts!
>Leader in New/Used PCs,Laptops
>Communication & Networking,Monitors
>Printers, Hard Drives, Midrange/Mainframe.
>Hard to Get Parts. We buy and sell all
>types of GEAR-
>****************************
>----- Original Message -----
>From: Greg Coffey <gcoffey@vcn.com>
>To: <usr-tc@lists.xmission.com>
>Sent: Friday, September 03, 1999 1:45 PM
>Subject: (usr-tc) Need Some Quad Modems
>
>
>I'm in the market for some digital quads. Email me if you have some to
>sell. I could use 1-2 dozen of them.
>
>
>
>Thanks, Greg Coffey <gcoffey@vcn.com>
>Visionary Communications V 307-234-5443 F 307-234-5446
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Andrew:PC Global, Inc." <andrew@pcglobal.net>
Subject: Sorry (usr-tc) Need Some Quad Modems
Date: 10 Sep 1999 13:09:11 -0700
sorry about the post.. hit reply accidentially
Have a good weekend USR-TC members!
Andrew Shlensky
****************************
PC Global, Inc.
(602) 438-6200 office (NEW TEL NUMBER!)
(602) 438-1119 fax
(305) 216-8638 mobile
New!e-mail my mobile http://www.nextel.com/paging
URL: http://www.pcglobal.net
E-MAIL: andrew@pcglobal.net
ICQ: 21219089
Computer Service Parts SpEciaLiSts!
Leader in New/Used PCs,Laptops
Communication & Networking,Monitors
Printers, Hard Drives, Midrange/Mainframe.
Hard to Get Parts. We buy and sell all
types of GEAR-
****************************
----- Original Message -----
Sent: Friday, September 10, 1999 1:01 PM
Steve,
Honestly, we get more requests for the an/dig than the digitals so I cant do
it.
we are selling the analog/digitals for $150 each currently.
Thanks Steve,
Andrew Shlensky
****************************
PC Global, Inc.
(602) 438-6200 office (NEW TEL NUMBER!)
(602) 438-1119 fax
(305) 216-8638 mobile
New!e-mail my mobile http://www.nextel.com/paging
URL: http://www.pcglobal.net
E-MAIL: andrew@pcglobal.net
ICQ: 21219089
Computer Service Parts SpEciaLiSts!
Leader in New/Used PCs,Laptops
Communication & Networking,Monitors
Printers, Hard Drives, Midrange/Mainframe.
Hard to Get Parts. We buy and sell all
types of GEAR-
****************************
----- Original Message -----
Sent: Friday, September 10, 1999 12:48 PM
would you be interested in trading 12 analog/digitals of yours, for
12 digital modems of mine? No nics just the nacs.
Let me know.
At 01:57 PM 09/03/1999 -0700, you wrote:
>I have about 25 in stock... about 8 NICS . These are the V.34
>analog/Digital.
>We have been selling them at $175 each with a 90 day warranty
>
>We take all credit cards,
>
>Best Regards,
>Andrew Shlensky
>****************************
>PC Global, Inc.
>(602) 438-6200 office (NEW TEL NUMBER!)
>(602) 438-1119 fax
>(305) 216-8638 mobile
>New!e-mail my mobile http://www.nextel.com/paging
>URL: http://www.pcglobal.net
>E-MAIL: andrew@pcglobal.net
>ICQ: 21219089
>Computer Service Parts SpEciaLiSts!
>Leader in New/Used PCs,Laptops
>Communication & Networking,Monitors
>Printers, Hard Drives, Midrange/Mainframe.
>Hard to Get Parts. We buy and sell all
>types of GEAR-
>****************************
>----- Original Message -----
>From: Greg Coffey <gcoffey@vcn.com>
>To: <usr-tc@lists.xmission.com>
>Sent: Friday, September 03, 1999 1:45 PM
>Subject: (usr-tc) Need Some Quad Modems
>
>
>I'm in the market for some digital quads. Email me if you have some to
>sell. I could use 1-2 dozen of them.
>
>
>
>Thanks, Greg Coffey <gcoffey@vcn.com>
>Visionary Communications V 307-234-5443 F 307-234-5446
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Horace Demmink <horace@pathwaynet.com>
Subject: RE: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete)
Date: 10 Sep 1999 16:31:21 -0400 (EDT)
On Fri, 10 Sep 1999, Mike Wronski wrote:
> |> There will be a 4.1.x service release for the security issues and
> |other resolved
> |> bugs shortly. This service release will be made available to everyone for 90
> |> days, as was the previous service release.
> |>
> |
> |Will there be a 4.2.x service release to solve these issues that will be
> |made available to everyone?
>
> What issues? The 4.2.32-1 does resolve the security issues. (As stated above)
>
Yes, but it is not publicly available. For example, my service contract
recently expired, leaving me with the 4.2.29 version. I need OSPF, but
also would like the critical bugs fixed. I guess it is a moot point as I
just registered another chassis. But what are you supposed to do if you do
not feel like cheating the system and are in the same boat?
--
Horace Demmink
PathWay Computing
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: D Mayer <dmayer@netwalk.com>
Subject: (usr-tc) Farewell!
Date: 10 Sep 1999 19:51:21 -0400
I've been on this list for close to two years, but now I'm leaving the
consumer level ISP biz to work in the R&D division at UUNET! I just wanted
to thank everbody who ever responded to my questions, and wish you all the
best of luck with your TC systems. This list has been 100 times better
support than 3Com could ever give.
Thanks!
Peter D. Mayer
NetWalk System Administrator
dmayer@netwalk.com
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Bob Purdon (Lists)" <lists@aussie.nu>
Subject: RE: (usr-tc) preventing netserver crash
Date: 11 Sep 1999 09:58:45 +1000 (EST)
> Just because your chassis reboots, that doesn't necessarily mean it's
> a widespread problem.
May well be - there is a revision of the NETserver that hates ISDN -
reboots almost daily. I *think* it's the release with the 'FC3' revision
IC on it. From memory, 'FC2' runs fine...
Bob Purdon, Ground Floor, Marine Board Building
Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000
Southern Internet Services. +61 (3) 6234 7444
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "T.J. Weber" <tjw-pop@ipmedia.net>
Subject: (usr-tc) PRI vs. C-T1
Date: 10 Sep 1999 19:01:40 -0500
We currently have several C-T1's and were wondering what the advantages
(disadvantages?) were for MX DID (Multi-Exchange, Direct Inbound
Dialing) lines were? I know that a C-T1 can only support ISDN DOV
connections (vs. true 64k BRI connections), but what other features or
advantages does a PRI have over a C-T1? The telco we are using has a
C5 switch for each exchange they provide to us and all calling features
should be enabled.
Thanks,
--t.j.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) preventing netserver crash
Date: 10 Sep 1999 20:37:02 -0400
Thus spake Bob Purdon (Lists)
>> Just because your chassis reboots, that doesn't necessarily mean it's
>> a widespread problem.
>May well be - there is a revision of the NETserver that hates ISDN -
>reboots almost daily. I *think* it's the release with the 'FC3' revision
>IC on it. From memory, 'FC2' runs fine...
Ah, yes...the infamous fc3 chip...didn't reboot the system...didn't even
lock it up...just froze the ethernet interface. If you had console
access...or !root dialup access, you could still login and do stuff
locally...just couldn't do anything with the ethernet.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Bob Purdon (Lists)" <lists@aussie.nu>
Subject: Re: (usr-tc) preventing netserver crash
Date: 11 Sep 1999 10:48:42 +1000 (EST)
> Ah, yes...the infamous fc3 chip...didn't reboot the system...didn't
> even lock it up...just froze the ethernet interface. If you had
> console access...or !root dialup access, you could still login and do
> stuff locally...just couldn't do anything with the ethernet.
Hmmm, ours rebooted. When replaced with an FC2 based NETserver, the
reboots went away. We don't do ISDN on these boxes these days anyway, so
it's a non-event, but still...
Bob Purdon, Ground Floor, Marine Board Building
Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000
Southern Internet Services. +61 (3) 6234 7444
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Clayton Zekelman <clayton@MNSi.Net>
Subject: RE: (usr-tc) preventing netserver crash
Date: 11 Sep 1999 11:33:34 -0400
Exactly right. All our FC3 rev IC Netservers rebooted, and the FC2's
didn't. Sometimes you have to peel back the sticker to read the chip rev...
At 09:58 AM 9/11/99 +1000, you wrote:
>
>> Just because your chassis reboots, that doesn't necessarily mean it's
>> a widespread problem.
>
>May well be - there is a revision of the NETserver that hates ISDN -
>reboots almost daily. I *think* it's the release with the 'FC3' revision
>IC on it. From memory, 'FC2' runs fine...
>
>------------------------------------------------------------------------
>Bob Purdon, Ground Floor, Marine Board Building
>Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000
>Southern Internet Services. +61 (3) 6234 7444
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6
tel. 519-985-8410
fax. 519-258-3009
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Aaron Nabil <nabil@spiritone.com>
Subject: (usr-tc) any way to hang up a user on a hiper arc?
Date: 13 Sep 1999 04:10:36 -0700 (PDT)
Short of writing an expect script to telnet into the arc, is there
any way via SNMP (or radius) to hang up a user on the arc?
I already know how to do this via hanging up the modem, but was
looking for a way to do it on the arc itself.
thx,
--
Aaron Nabil
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: John Campbell <sparky@roava.net>
Subject: (usr-tc) Unique problem - Just changed backbones...
Date: 13 Sep 1999 07:25:08 -0400
I have a unique problem, I just changed backbone providers, got everything
changed over.. I have verified all of my DNS numbers and everything..
However, even though most users are navigating and seeing things correctly,
other users are ping resolved to the old IP addresses of our old class C
for our web and mail servers. IP numbers work just fine, and it is not the
same on all users. Any ideas on this... Any help would be appreaciated.
John Campbell
mailto:sparky@roava.net
http://www.roava.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: d baud <dbaud@bigfoot.com>
Subject: (usr-tc) 4.2.32 and MLPPP broke on freebsd
Date: 13 Sep 1999 10:53:44 -0400
I just noticed that after upgrading to 4.2.32 the user implementation of
PPP on freebsd would not connect any more than one PPP link.
I flashed back to 4.2.29 (or any previous 4.1.xx) and the problem
disapears.
This issue only seem to happen with freebsd's PPP. I noticed that cisco
routers connects flawlessly, I also managed to connect a netserver 8i to
4.2.32 in MLPPP
I know this is probably not a problem relating to this upgrade, but I am
just curious on what setting have changed in this version ?
I am including a PPP log for the second PPP link that tries to connect
from a freebsd PPP system. The link gets disconnected immediately after
receiving an ACK from Hiper4.2.32
HiPer>> sho system
SYSTEM DESCRIPTION
System Descriptor:
3Com Corporation HiPer Access Router Card Built on Aug 16 1999
at 17:19:
37.
Object ID: 1.3.6.1.4.1.429.2.19
System UpTime: 2d 20:43:37
System Services: Internet EndToEnd Applications
System Transmit Authentication Name: HiPer
System Version: V4.2.32
Reset EEPROM Settings On Bootup: DISABLED
Outgoing PPP Data on interface: slot:7/mod:4
LCP CFG_REQ MRU 05 ea
ASYNC_MAP 00 00 00 00
AUTH_TYPE c0 23
MAGIC_NUM f4 3e 57 1e
PROTO_COMP
AC_COMP
MPP_MRRU 05 ea
MPP_ENDPTID 00
LCP CFG_REQ ASYNC_MAP 00 00 00 00
MRU 05 dc
MAGIC_NUM 68 ba c0 da
MPP_MRRU 05 dc
Outgoing PPP Data on interface: slot:7/mod:4
LCP CFG_ACK ASYNC_MAP 00 00 00 00
MRU 05 dc
MAGIC_NUM 68 ba c0 da
MPP_MRRU 05 dc
Outgoing PPP Data on interface: slot:7/mod:4
LCP CFG_REQ MRU 05 ea
ASYNC_MAP 00 00 00 00
AUTH_TYPE c0 23
MAGIC_NUM f4 3e 57 1e
PROTO_COMP
AC_COMP
MPP_MRRU 05 ea
MPP_ENDPTID 00
Incoming PPP Data on interface: slot:7/mod:4
LCP CFG_REJ PROTO_COMP
AC_COMP
Outgoing PPP Data on interface: slot:7/mod:4
LCP CFG_REQ MRU 05 ea
ASYNC_MAP 00 00 00 00
AUTH_TYPE c0 23
MAGIC_NUM f4 3e 57 1e
MPP_MRRU 05 ea
MPP_ENDPTID 00
Incoming PPP Data on interface: slot:7/mod:4
LCP CFG_ACK MRU 05 ea
ASYNC_MAP 00 00 00 00
AUTH_TYPE c0 23
MAGIC_NUM f4 3e 57 1e
MPP_MRRU 05 ea
MPP_ENDPTID 00
Incoming PPP Data on interface: slot:7/mod:4
PAP REQUEST USERNAME = pppuser
PASSWORD = ppppasse
Outgoing PPP Data on interface: slot:7/mod:4
PAP
ACK
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: (usr-tc) Seeing DSP
Date: 13 Sep 1999 14:27:06 -0400
I just installed a new DSP but the PRI isn't hooked into it yet. Getting;
HiPer>> list chassis
Slot Owner Description Ports Type Console
1 YES 24 Channel High Density Modem 23 DYNAMIC NO
2 YES 24 Channel High Density Modem 23 DYNAMIC NO
3 YES --EMPTY-- 0 STATIC NO
4 YES --EMPTY-- 0 STATIC NO
5 YES --EMPTY-- 0 STATIC NO
How do I get the ARC to recognize the new card(slot 3)? Is it possible w/o
rebooting?
Thanks,
Kirk
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Christopher Arlis Hanes" <chanes@usacars.com>
Subject: (usr-tc) Problems with NI2 and NFAS
Date: 13 Sep 1999 14:41:23 -0400
Is there anyone out there using NFAS to support 2 PRIs through a single
D channel on the dual pri cards. I've had no luck getting this to work
yet. From a configuration standpoint things look correct - 23B+1D on
the first span and 24B on the second; however, when I dial in, I get
fast busies. The telco techs have been on site and can dial in to their
test equipment successfully on the new PRIs. My chassis works fine when
I use old PRIs configured for dms100. When I change the switch settings
to NI2, set the NFAS id, and plug up the new PRIs - nothing but fast
busies. I'm running tcs 3.3 (i.e. 3.02 on the dual pri card). Any
help would be GREATLY appreciated.
Thanks,
Chris Hanes
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: John Campbell <sparky@roava.net>
Subject: (usr-tc) Thanks to all who replied
Date: 13 Sep 1999 15:05:07 -0400
Found my problem with the help of this list... Thanks to everyone who sent
me troubleshooting email.
John Campbell
mailto:sparky@roava.net
http://www.roava.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: Re: (usr-tc) Seeing DSP
Date: 13 Sep 1999 16:12:16 -0400
At 02:27 PM 9/13/99 -0400, I wrote:
>I just installed a new DSP but the PRI isn't hooked into it yet. Getting;
>HiPer>> list chassis
>Slot Owner Description Ports Type Console
>1 YES 24 Channel High Density Modem 23 DYNAMIC NO
>2 YES 24 Channel High Density Modem 23 DYNAMIC NO
>3 YES --EMPTY-- 0 STATIC NO
>4 YES --EMPTY-- 0 STATIC NO
>5 YES --EMPTY-- 0 STATIC NO
>
>How do I get the ARC to recognize the new card(slot 3)? Is it possible w/o
>rebooting?
Ok, I reseated the card and TCM sees it ok, but it still isn't apparently
responding on the D channel. I loaded the config from one of my working
cards and saved it, still no go. The only difference in them being that my
other DSPs are running 1.2.60 and the new one is showing 2.0.81. Is there
something different in 2.0.81 that I need to account for by a difference in
config?
Also, how do I set it to console: NO? Could that be my problem?
HiPer>> li chas
Slot Owner Description Ports Type Console
1 YES 24 Channel High Density Modem 23 DYNAMIC NO
2 YES 24 Channel High Density Modem 23 DYNAMIC NO
3 YES 24 Channel High Density Modem 23 DYNAMIC YES
4 YES --EMPTY-- 0 STATIC NO
Thanks,
Kirk
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) Seeing DSP
Date: 13 Sep 1999 15:33:45 -0500
You definately need to Hardware-Reboot the card (IE, not "software reset)
for the changes to take effect.
SMT
-----Original Message-----
Sent: Monday, September 13, 1999 3:12 PM
At 02:27 PM 9/13/99 -0400, I wrote:
>I just installed a new DSP but the PRI isn't hooked into it yet. Getting;
>HiPer>> list chassis
>Slot Owner Description Ports Type
Console
>1 YES 24 Channel High Density Modem 23 DYNAMIC NO
>2 YES 24 Channel High Density Modem 23 DYNAMIC NO
>3 YES --EMPTY-- 0 STATIC NO
>4 YES --EMPTY-- 0 STATIC NO
>5 YES --EMPTY-- 0 STATIC NO
>
>How do I get the ARC to recognize the new card(slot 3)? Is it possible w/o
>rebooting?
Ok, I reseated the card and TCM sees it ok, but it still isn't apparently
responding on the D channel. I loaded the config from one of my working
cards and saved it, still no go. The only difference in them being that my
other DSPs are running 1.2.60 and the new one is showing 2.0.81. Is there
something different in 2.0.81 that I need to account for by a difference in
config?
Also, how do I set it to console: NO? Could that be my problem?
HiPer>> li chas
Slot Owner Description Ports Type
Console
1 YES 24 Channel High Density Modem 23 DYNAMIC NO
2 YES 24 Channel High Density Modem 23 DYNAMIC NO
3 YES 24 Channel High Density Modem 23 DYNAMIC YES
4 YES --EMPTY-- 0 STATIC NO
Thanks,
Kirk
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: RE: (usr-tc) Seeing DSP
Date: 13 Sep 1999 16:56:28 -0400
At 03:33 PM 9/13/99 -0500, you wrote:
>You definately need to Hardware-Reboot the card (IE, not "software reset)
>for the changes to take effect.
Ok, I'm loading trunk settings from a working DSP, setting it, then
hardware resetting. One of the settings that's reverting back to default is
switch type. It should be priSwDMS100 but it keeps reverting to priSw5ESS
after the hardware reset. Other fields in trunk settings are changing back
also. Any ideas?
I'm guessing that I'm doing something wrong, but I don't know what :(
Thanks,
Kirk
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) Seeing DSP
Date: 13 Sep 1999 16:09:26 -0500
Be sure and do, in TCM, Configure->Actions Commands->Software->Save Modem/T1
settings
before you reboot. Highlight the DSP in question of course.
(thanks Jeff for lettin' me get an easy one answered in there :)
SMT
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) Seeing DSP
Date: 13 Sep 1999 21:07:25 -0400
Thus spake Scott Trautman
>Be sure and do, in TCM, Configure->Actions Commands->Software->Save
>Modem/T1 settings before you reboot. Highlight the DSP in question of
>course.
>(thanks Jeff for lettin' me get an easy one answered in there :)
Heh...I'm not quite as proficient in DSP's as in quads and the gateway
cards. :) Think that's largely from my coming from an IP background (I
hate dealing with modems, truth be known), and only having recently
introduced DSP's into our setup. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: RE: (usr-tc) Seeing DSP
Date: 13 Sep 1999 22:05:18 -0400
At 04:09 PM 9/13/99 -0500, you wrote:
>Be sure and do, in TCM, Configure->Actions Commands->Software->Save Modem/T1
>settings
>before you reboot. Highlight the DSP in question of course.
Ok, that seems to be holding the settings. Now, why is the new card saying
YES to console when none of the others are, and how do I change it?
HiPer>> li chas
Slot Owner Description Ports Type Console
1 YES 24 Channel High Density Modem 23 DYNAMIC NO
2 YES 24 Channel High Density Modem 23 DYNAMIC NO
3 YES 24 Channel High Density Modem 23 DYNAMIC YES
4 YES --EMPTY-- 0 STATIC NO
Thanks,
Kirk
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Marshall Morgan" <marshall@netdoor.com>
Subject: RE: (usr-tc) Seeing DSP
Date: 13 Sep 1999 21:14:01 -0500
set chASSIS slOT 3 coNSOLE nO
Marshall Morgan
Internet Doorway, Inc (aka NETDOOR)
http://www.netdoor.com
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell
> Sent: Monday, September 13, 1999 9:05 PM
> To: usr-tc@lists.xmission.com
> Subject: RE: (usr-tc) Seeing DSP
>
>
> At 04:09 PM 9/13/99 -0500, you wrote:
> >Be sure and do, in TCM, Configure->Actions Commands->Software->Save Modem/T1
> >settings
> >before you reboot. Highlight the DSP in question of course.
>
> Ok, that seems to be holding the settings. Now, why is the new card saying
> YES to console when none of the others are, and how do I change it?
> HiPer>> li chas
> Slot Owner Description Ports Type Console
> 1 YES 24 Channel High Density Modem 23 DYNAMIC NO
> 2 YES 24 Channel High Density Modem 23 DYNAMIC NO
> 3 YES 24 Channel High Density Modem 23 DYNAMIC YES
> 4 YES --EMPTY-- 0 STATIC NO
>
> Thanks,
> Kirk
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) Seeing DSP
Date: 13 Sep 1999 21:26:33 -0500
Interesting....this was what I was looking for a week or so ago,
I tried the opposite, set chassis slot 13 console yes, says
11 YES --EMPTY-- 0 STATIC NO
12 YES 24 Channel High Density Modem 24 DYNAMIC YES
13 YES 24 Channel High Density Modem 24 DYNAMIC NO
14 YES 24 Channel High Density Modem 24 DYNAMIC YES
15 YES 24 Channel High Density Modem 24 DYNAMIC NO
16 NO HiPer Access Router NAC 0 DYNAMIC NO
HiPer>> set chassis slot 13 console yes
ERROR - Cannot change console settings of a dynamic entry
...back to original question...why the two no when there wasn't any
difference
in setup? Anything to set on the DSP to "allow" console?
Anything I might have inadvertantly set on the chassis?
SMT
> -----Original Message-----
> From: Marshall Morgan [mailto:marshall@netdoor.com]
> Sent: Monday, September 13, 1999 9:14 PM
> To: usr-tc@lists.xmission.com
> Subject: RE: (usr-tc) Seeing DSP
>
>
> set chASSIS slOT 3 coNSOLE nO
>
> Marshall Morgan
>
> Internet Doorway, Inc (aka NETDOOR)
> http://www.netdoor.com
>
>
> > -----Original Message-----
> > From: owner-usr-tc@lists.xmission.com
> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell
> > Sent: Monday, September 13, 1999 9:05 PM
> > To: usr-tc@lists.xmission.com
> > Subject: RE: (usr-tc) Seeing DSP
> >
> >
> > At 04:09 PM 9/13/99 -0500, you wrote:
> > >Be sure and do, in TCM, Configure->Actions
> Commands->Software->Save Modem/T1
> > >settings
> > >before you reboot. Highlight the DSP in question of course.
> >
> > Ok, that seems to be holding the settings. Now, why is the
> new card saying
> > YES to console when none of the others are, and how do I change it?
> > HiPer>> li chas
> > Slot Owner Description Ports
> Type Console
> > 1 YES 24 Channel High Density Modem 23
> DYNAMIC NO
> > 2 YES 24 Channel High Density Modem 23
> DYNAMIC NO
> > 3 YES 24 Channel High Density Modem 23
> DYNAMIC YES
> > 4 YES --EMPTY-- 0
> STATIC NO
> >
> > Thanks,
> > Kirk
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: RE: (usr-tc) Seeing DSP
Date: 14 Sep 1999 00:03:16 -0400
At 09:14 PM 9/13/99 -0500, you wrote:
>set chASSIS slOT 3 coNSOLE nO
That didn't work, but I got there...almost;
HiPer>> set chassis slot 3 console no
ERROR - Cannot change console settings of a dynamic entry
HiPer>> set chassis slot 3 type static
HiPer>> set chassis slot 3 console no
HiPer>> set chassis slot 3 type dynamic
CLI - Invalid Argument: dynamic
This field is a KEYWORD LIST. The possible values are:
[ STATIC ]
So, now I got it set to NO, but;
HiPer>> li chas
Slot Owner Description Ports Type Console
1 YES 24 Channel High Density Modem 23 DYNAMIC NO
2 YES 24 Channel High Density Modem 23 DYNAMIC NO
3 YES 24 Channel High Density Modem 23 STATIC NO
Now, how do I get it back to dynamic? And what difference does YES or NO on
the console setting make anyway?
Thanks,
Kirk
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Scot Desort" <scot@njaccess.net>
Subject: (usr-tc) TC traffic pauses momentarily
Date: 14 Sep 1999 09:42:41 -0400
Running HiperARC 4.1.59 with DSP's. Occasionally, dialup connections will
stop receiving IP traffic, then anywhere from 15 seconds to 1 minute later
traffic resumes.
Customer is in the middle of receiving traffic, it suddenly stops, then
resumes. I have experienced this myself. It is not the host that they are
connecting to. They can be in the middle of receiving mail from our mail
server, and all traffic suddenly stops for a noticeable period of time. They
do not get disconnected.
I *thought* I saw some mention of this phenomenon on the list, but I'm not
sure. Anyone have any ideas? Is this a known issue?
...Scot
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: (usr-tc) modem that will not pick up
Date: 14 Sep 1999 11:11:48 -0300
I'm having a problem with one modem that refuses to pick up. When I watch
the status in performance monitor, I can see the call coming in (RingIn or
RingRcvd states), DNIS and ANI information comes up, but the modem never
picks up the call. I have replaced the DSP NAC and the problem didn't go
away. The only other place I can think to look is to the ARC itself but the
modem interface is UP/UP. I've also tried a full reconfig (restore from
default, save to nvram, reboot, reconfig, save to nvram, reboot) and no
luck. When a user happens to grab that line they hear a long pause of dead
air (maybe 5 seconds or more) and then it starts ringing endlessly. Any
ideas?
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) TC traffic pauses momentarily
Date: 14 Sep 1999 10:41:52 -0400 (EDT)
On Tue, 14 Sep 1999, Scot Desort wrote:
> Running HiperARC 4.1.59 with DSP's. Occasionally, dialup connections will
> stop receiving IP traffic, then anywhere from 15 seconds to 1 minute later
> traffic resumes.
>
> Customer is in the middle of receiving traffic, it suddenly stops, then
> resumes. I have experienced this myself. It is not the host that they are
> connecting to. They can be in the middle of receiving mail from our mail
> server, and all traffic suddenly stops for a noticeable period of time. They
> do not get disconnected.
>
> I *thought* I saw some mention of this phenomenon on the list, but I'm not
> sure. Anyone have any ideas? Is this a known issue?
Normal modem retraining, maybe? Check the retrain counts on the modem and
see if they go up...
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Ahmed Saeed <Ahmed.Saeed@widener.edu>
Subject: (usr-tc) HARC 4.1.59 and 4.1.11 won't accept ISDN (fwd)
Date: 14 Sep 1999 12:50:06 -0400 (EDT)
das,
you really dont need to reset config all over again, one can use the bulk
file command to save the config and tftp to arc again to relaod config.
tftp might not be working for several reasons. List network services
should show the tftpd demaon as enabled. If it is not enabled, enable
the service. Also, tftp time out may cause this .
Best solution is to do AT{ZF} on console of arc.
Ahmed
---------- Forwarded message ----------
A bit of an emergency...
I thought that I would upgrade my hipers this morning. I upgraded both to
4.1.59 and once they were rebooted they stopped authenticating ISDN calls.
I flashed one to 4.1.11 and it lost various parts of it's configuration (ex.
it lost its ip network settings but retained pool settings) I reconfigured
it, but it still is having the same problems with ISDN. Analog calls
authenticate happily. I have tried flashing the second HARC back to 4.1.59, but
now it keeps failing the tftp upload.
Also, when I look in the logs, it repeatedly logs:
--syslog capture: 2b110903 slot:4/mod:10 --syslog capture:stop
each time for the same interface (slot and modem) and then it moves to a different
interface.
If anyone can offer any insight into this, I'm sure that my customers will be happily
and I will be extremely grateful.
das
--
____________________________________________
Alex Substanley Global OnLine Japan
Engineering Department
Das Man TEL: 81-3-5334-1700
Systems Engineer FAX: 81-3-5334-1711
The Highest Quality Service, Bar None
____________________________________________
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: (usr-tc) More new DSP problems
Date: 14 Sep 1999 13:17:28 -0400
I finally got the card to retain it's trunk settings, but it's still
giving me problems. About every 2 hours it throws itself into a reboot and
locks up with all LEDs illuminated steady red. The only way to restore it
to service is to reseat the card. this DSp is running 2.0.81 while my other
DSP are running 1.2.60, ARC is 4.1.59
Also, I have no idea how to get the type set to dynamic.
Thanks,
Kirk
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: (usr-tc) Connect %'s
Date: 14 Sep 1999 15:04:00 -0400 (EDT)
Hello all...
Just throwing this out to see if it what others are getting:
ARC-I Total calls received: 51627 6 DSP's
Total calls failed : 2546
Connection average : 95.07
ARC-II Total calls received: 2318 6 Quad's
Total calls failed : 86
Connection average : 96.29
Total calls received: 53894
Total calls failed : 2631
Connection average : 95.12
System Date ( Time in GMT ) 14-SEP-1999 14:56:13
System UpTime: 34d 04:53:31
(Some cards have been rebooted to clear hung modems)
This is from a simple perl script that walk the inConnectAttemptFails and
inConnectEstablished OID's.
It's been hovering around 95% connection rate..... anyone seeing higher
than this?
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Clint R. Sparks" <csparks@cqc.com>
Subject: Re: (usr-tc) Connect %'s
Date: 14 Sep 1999 14:19:56 -0500
Paul,
What Hiper DSP and Hiper Arc code are you running?
Clint R. Sparks
ComQuest Internet Services
csparks@cqc.com
----- Original Message -----
Sent: Tuesday, September 14, 1999 2:04 PM
> Hello all...
>
> Just throwing this out to see if it what others are getting:
>
> ARC-I Total calls received: 51627 6 DSP's
> Total calls failed : 2546
> Connection average : 95.07
> ARC-II Total calls received: 2318 6 Quad's
> Total calls failed : 86
> Connection average : 96.29
>
> Total calls received: 53894
> Total calls failed : 2631
> Connection average : 95.12
>
> System Date ( Time in GMT ) 14-SEP-1999 14:56:13
> System UpTime: 34d 04:53:31
>
> (Some cards have been rebooted to clear hung modems)
>
> This is from a simple perl script that walk the inConnectAttemptFails and
> inConnectEstablished OID's.
>
> It's been hovering around 95% connection rate..... anyone seeing higher
> than this?
>
>
>
> Paul D. Farber II
> Farber Technology
> Ph. 570-628-5303
> Fax 570-628-5545
> farber@admin.f-tech.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: eric@dol.net
Subject: (usr-tc) PRI card needs to be constantly placed in service
Date: 14 Sep 1999 14:15:41 -0600
I have a pri card in a quad modem chassis software 3.0.2
It seems to go busy every few days and need to be placed
in service again with tcm. It gives no visible indication
that the pri is dead. Is this a hardware related issue
or a software issue?
thanks
eric
Delaware Online!.........The SMART Choice!
With 56K V.90 & X2 & Flex Modems
Phone : 302-762-0375
Fax: 302-762-3462
Failure is NOT an option...
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Scot Desort" <scot@njaccess.net>
Subject: Re: (usr-tc) TC traffic pauses momentarily
Date: 14 Sep 1999 16:29:58 -0400
Don't think so. Happens with ISDN also. That's how I've personally
experienced it....
...Scot
----- Original Message -----
Sent: Tuesday, September 14, 1999 10:41 AM
> On Tue, 14 Sep 1999, Scot Desort wrote:
>
> > Running HiperARC 4.1.59 with DSP's. Occasionally, dialup connections
will
> > stop receiving IP traffic, then anywhere from 15 seconds to 1 minute
later
> > traffic resumes.
> >
> > Customer is in the middle of receiving traffic, it suddenly stops, then
> > resumes. I have experienced this myself. It is not the host that they
are
> > connecting to. They can be in the middle of receiving mail from our mail
> > server, and all traffic suddenly stops for a noticeable period of time.
They
> > do not get disconnected.
> >
> > I *thought* I saw some mention of this phenomenon on the list, but I'm
not
> > sure. Anyone have any ideas? Is this a known issue?
>
>
> Normal modem retraining, maybe? Check the retrain counts on the modem and
> see if they go up...
>
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) TC traffic pauses momentarily
Date: 14 Sep 1999 16:41:42 -0400
Thus spake Scot Desort
>Don't think so. Happens with ISDN also. That's how I've personally
>experienced it....
The only cause I remember for something like this was when the user was
using bandwidth on demand with Multi-Link and MPIP wasn't functioning
correctly. The pause occured when their equipment started to bring up
the second line...it didn't get bundled in correctly...one side or the
other was trying to send data split across the two lines and because it
wasn't bundled correctly, the data was corrupted...eventually the second
channel hangs up because the usage has dropped below the threshold
level, and at the next resend, everything starts flowing again because
it only has the one link so the data is no longer being corrupted.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: Re: (usr-tc) More new DSP problems
Date: 14 Sep 1999 17:00:56 -0400
At 01:17 PM 9/14/99 -0400, I wrote:
> I finally got the card to retain it's trunk settings, but it's still
>giving me problems. About every 2 hours it throws itself into a reboot and
>locks up with all LEDs illuminated steady red. The only way to restore it
>to service is to reseat the card. this DSP is running 2.0.81 while my other
>DSP are running 1.2.60, ARC is 4.1.59
> Also, I have no idea how to get the type set to dynamic.
Yet more freaking joy with my new $4500 paperweight! Another condition
that throws it into a reboot is taking calls. Within 1-2 minutes of a call
authenticating on the DSP, it reboots. While testing though, the behavior
is inconstistant. About half of the time the reboot freezes with all lights
red and needs reseated, the rest of the time it reboots fully and returns
to service. Hardware version is 0.53.0
Anybody have any ideas?
Thanks again,
Kirk
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: USR TC Mailing list account <usrtc@fop.ns.ca>
Subject: Re: (usr-tc) Connect %'s
Date: 14 Sep 1999 18:16:19 -0300 (ADT)
For comparison, I've knocked up some software that dials out with 2
couriers and does testing. This setup is a "perfect" setup, ie, there are
no problems with it that would make it fail. According to that, the
cumulative logs for the last few days add up to:
Calls made: 23822
Calls succeeded: 23501
Calls failed: 327
Failure rate: 1.3%
Ring-No-answer fails: 6
Busies: 2
NoCarrier: 248
NoLoginPrompt: 70
NoPPP: 1
The number of failed calls from SNMP works out at 5.52% (93949
success/5492 failed).
Ergo, from this roughly 4% of failed calls are due to problems outside the
racks.
Hope this helps (and "Hi!" to JP, if yer still out there and didn't get
eaten in Canada, eh? :-)
Cheers, Steve
On Tue, 14 Sep 1999, Paul Farber wrote:
> Hello all...
>
> Just throwing this out to see if it what others are getting:
>
> ARC-I Total calls received: 51627 6 DSP's
> Total calls failed : 2546
> Connection average : 95.07
> ARC-II Total calls received: 2318 6 Quad's
> Total calls failed : 86
> Connection average : 96.29
>
> Total calls received: 53894
> Total calls failed : 2631
> Connection average : 95.12
>
> System Date ( Time in GMT ) 14-SEP-1999 14:56:13
> System UpTime: 34d 04:53:31
>
> (Some cards have been rebooted to clear hung modems)
>
> This is from a simple perl script that walk the inConnectAttemptFails and
> inConnectEstablished OID's.
>
> It's been hovering around 95% connection rate..... anyone seeing higher
> than this?
>
>
>
> Paul D. Farber II
> Farber Technology
> Ph. 570-628-5303
> Fax 570-628-5545
> farber@admin.f-tech.net
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Scot Desort" <scot@njaccess.net>
Subject: Re: (usr-tc) TC traffic pauses momentarily
Date: 14 Sep 1999 17:29:27 -0400
Hmmm. Can't be the case with the analog dialups -- they are definitely not
trying to do multilink. And when I use my 3COM Impact, I have to request 2
channels by entering the phone number twice. And I rarely do. Come to think
of it, it has also happened when I dialup analog. Honestly, I thought it was
my imagination until I had 2 customers call in a single day to "complain"
about the exact same thing.
I don't think it is very widespread. Or perhaps it is, and nobody noticed
but me and the other tech-heads that we have dialing in. I was going to
trying switching to the other ethernet port on the HARC, and then try
another port on the Cisco switch. Next time it happens, I'm going to run
some traceroutes and see exactly where the packets are dying -- at the HARC,
and our core, whatever. But other than that, I'm at a loss...
...Scot
----- Original Message -----
Sent: Tuesday, September 14, 1999 4:41 PM
> Thus spake Scot Desort
> >Don't think so. Happens with ISDN also. That's how I've personally
> >experienced it....
>
> The only cause I remember for something like this was when the user was
> using bandwidth on demand with Multi-Link and MPIP wasn't functioning
> correctly. The pause occured when their equipment started to bring up
> the second line...it didn't get bundled in correctly...one side or the
> other was trying to send data split across the two lines and because it
> wasn't bundled correctly, the data was corrupted...eventually the second
> channel hangs up because the usage has dropped below the threshold
> level, and at the next resend, everything starts flowing again because
> it only has the one link so the data is no longer being corrupted.
> --
> Jeff McAdams Email: jeffm@iglou.com
> Head Network Administrator Voice: (502) 966-3848
> IgLou Internet Services (800) 436-4456
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) Connect %'s
Date: 14 Sep 1999 17:58:11 -0400 (EDT)
DSP 2.0.19
ARC 4.1.59
NMC 6.1.17
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Tue, 14 Sep 1999, Clint R. Sparks wrote:
> Paul,
>
> What Hiper DSP and Hiper Arc code are you running?
>
> Clint R. Sparks
> ComQuest Internet Services
> csparks@cqc.com
>
>
> ----- Original Message -----
> From: Paul Farber <farber@admin.f-tech.net>
> To: <usr-tc@lists.xmission.com>
> Sent: Tuesday, September 14, 1999 2:04 PM
> Subject: (usr-tc) Connect %'s
>
>
> > Hello all...
> >
> > Just throwing this out to see if it what others are getting:
> >
> > ARC-I Total calls received: 51627 6 DSP's
> > Total calls failed : 2546
> > Connection average : 95.07
> > ARC-II Total calls received: 2318 6 Quad's
> > Total calls failed : 86
> > Connection average : 96.29
> >
> > Total calls received: 53894
> > Total calls failed : 2631
> > Connection average : 95.12
> >
> > System Date ( Time in GMT ) 14-SEP-1999 14:56:13
> > System UpTime: 34d 04:53:31
> >
> > (Some cards have been rebooted to clear hung modems)
> >
> > This is from a simple perl script that walk the inConnectAttemptFails and
> > inConnectEstablished OID's.
> >
> > It's been hovering around 95% connection rate..... anyone seeing higher
> > than this?
> >
> >
> >
> > Paul D. Farber II
> > Farber Technology
> > Ph. 570-628-5303
> > Fax 570-628-5545
> > farber@admin.f-tech.net
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Allen Marsalis <am@shreve.net>
Subject: Re: (usr-tc) Connect %'s
Date: 14 Sep 1999 16:55:26 -0500
At 03:04 PM 9/14/99 -0400, Paul Farber wrote:
>
>It's been hovering around 95% connection rate..... anyone seeing higher
>than this?
>
>
Nope, it hovers around 95% for us everyday..
Modem Health Check - file: shv1.1 - chassis: usr1
09/13/99 07:00:07
slot:x/mod:y Calls Calls Failed Percent
Arrived Established Attempts Success
------------ ------- ----------- -------- -------
slot:1/mod:1 7 7 0 100.00
slot:1/mod:10 21 20 1 95.24
slot:1/mod:11 17 15 2 88.24
slot:1/mod:12 13 13 0 100.00
slot:1/mod:13 6 6 0 100.00
slot:1/mod:14 24 23 1 95.83
slot:1/mod:15 22 19 3 86.36
slot:1/mod:16 12 11 1 91.67
slot:1/mod:17 30 29 1 96.67
slot:1/mod:18 18 17 1 94.44
slot:1/mod:19 25 22 3 88.00
slot:1/mod:2 28 25 3 89.29
slot:1/mod:20 26 23 3 88.46
slot:1/mod:21 26 26 0 100.00
slot:1/mod:22 24 22 2 91.67
slot:1/mod:23 35 34 1 97.14
slot:1/mod:3 25 25 0 100.00
slot:1/mod:4 32 30 2 93.75
slot:1/mod:5 26 25 1 96.15
slot:1/mod:6 38 37 1 97.37
slot:1/mod:7 28 24 4 85.71
slot:1/mod:8 23 23 0 100.00
slot:1/mod:9 31 29 2 93.55
slot:10/mod:1 28 27 1 96.43
slot:10/mod:10 34 33 1 97.06
slot:10/mod:11 34 34 0 100.00
slot:10/mod:12 29 28 1 96.55
slot:10/mod:13 26 26 0 100.00
slot:10/mod:15 29 28 1 96.55
slot:10/mod:16 27 26 1 96.30
slot:10/mod:17 26 26 0 100.00
slot:10/mod:18 15 15 0 100.00
slot:10/mod:21 27 25 2 92.59
slot:10/mod:22 32 28 4 87.50
slot:10/mod:23 16 15 1 93.75
slot:10/mod:3 27 26 1 96.30
slot:10/mod:4 23 22 1 95.65
slot:10/mod:5 29 27 2 93.10
slot:10/mod:6 18 18 0 100.00
slot:10/mod:7 27 24 3 88.89
slot:10/mod:8 9 9 0 100.00
slot:10/mod:9 14 14 0 100.00
slot:2/mod:1 21 19 2 90.48
slot:2/mod:10 26 24 2 92.31
slot:2/mod:11 40 35 5 87.50
slot:2/mod:12 30 30 0 100.00
slot:2/mod:13 31 27 4 87.10
slot:2/mod:14 32 32 0 100.00
slot:2/mod:16 5 4 1 80.00
slot:2/mod:18 31 29 2 93.55
slot:2/mod:19 32 30 2 93.75
Modem Health Check - file: shv1.1 - chassis: usr1
09/13/99 07:00:07
slot:x/mod:y Calls Calls Failed Percent
Arrived Established Attempts Success
------------ ------- ----------- -------- -------
slot:2/mod:2 33 32 1 96.97
slot:2/mod:20 22 21 1 95.45
slot:2/mod:21 34 32 2 94.12
slot:2/mod:22 25 25 0 100.00
slot:2/mod:23 5 5 0 100.00
slot:2/mod:3 25 23 2 92.00
slot:2/mod:4 15 15 0 100.00
slot:2/mod:5 18 17 1 94.44
slot:2/mod:6 28 25 3 89.29
slot:2/mod:7 24 24 0 100.00
slot:2/mod:8 30 28 2 93.33
slot:2/mod:9 30 28 2 93.33
slot:3/mod:1 30 29 1 96.67
slot:3/mod:10 29 28 1 96.55
slot:3/mod:11 20 19 1 95.00
slot:3/mod:13 30 30 0 100.00
slot:3/mod:15 31 28 3 90.32
slot:3/mod:18 6 6 0 100.00
slot:3/mod:19 19 19 0 100.00
slot:3/mod:2 21 20 1 95.24
slot:3/mod:20 25 25 0 100.00
slot:3/mod:21 28 27 1 96.43
slot:3/mod:22 29 28 1 96.55
slot:3/mod:3 18 18 0 100.00
slot:3/mod:4 32 31 1 96.88
slot:3/mod:5 23 22 1 95.65
slot:3/mod:6 20 20 0 100.00
slot:3/mod:7 25 23 2 92.00
slot:3/mod:8 27 26 1 96.30
slot:4/mod:1 26 25 1 96.15
slot:4/mod:10 21 21 0 100.00
slot:4/mod:11 33 32 1 96.97
slot:4/mod:12 25 23 2 92.00
slot:4/mod:13 14 13 1 92.86
slot:4/mod:14 36 34 2 94.44
slot:4/mod:15 22 19 3 86.36
slot:4/mod:16 29 29 0 100.00
slot:4/mod:17 27 26 1 96.30
slot:4/mod:18 17 16 1 94.12
slot:4/mod:19 24 22 2 91.67
slot:4/mod:2 29 28 1 96.55
slot:4/mod:20 35 34 1 97.14
slot:4/mod:21 22 22 0 100.00
slot:4/mod:22 18 17 1 94.44
slot:4/mod:23 30 28 2 93.33
slot:4/mod:3 30 27 3 90.00
slot:4/mod:4 17 17 0 100.00
slot:4/mod:7 23 22 1 95.65
slot:4/mod:8 21 21 0 100.00
slot:5/mod:1 13 12 1 92.31
slot:5/mod:10 17 14 3 82.35
Modem Health Check - file: shv1.1 - chassis: usr1
09/13/99 07:00:07
slot:x/mod:y Calls Calls Failed Percent
Arrived Established Attempts Success
------------ ------- ----------- -------- -------
slot:5/mod:11 23 21 2 91.30
slot:5/mod:12 27 25 2 92.59
slot:5/mod:13 29 26 3 89.66
slot:5/mod:15 36 35 1 97.22
slot:5/mod:16 11 11 0 100.00
slot:5/mod:18 19 19 0 100.00
slot:5/mod:19 19 19 0 100.00
slot:5/mod:2 7 7 0 100.00
slot:5/mod:20 24 24 0 100.00
slot:5/mod:21 29 28 1 96.55
slot:5/mod:22 25 24 1 96.00
slot:5/mod:23 28 26 2 92.86
slot:5/mod:3 23 22 1 95.65
slot:5/mod:4 15 13 2 86.67
slot:5/mod:5 19 19 0 100.00
slot:5/mod:6 16 15 1 93.75
slot:5/mod:7 30 30 0 100.00
slot:5/mod:8 18 15 3 83.33
slot:5/mod:9 24 21 3 87.50
slot:6/mod:1 34 31 3 91.18
slot:6/mod:10 9 9 0 100.00
slot:6/mod:11 30 24 6 80.00
slot:6/mod:12 15 15 0 100.00
slot:6/mod:13 30 28 2 93.33
slot:6/mod:15 32 31 1 96.88
slot:6/mod:16 23 22 1 95.65
slot:6/mod:17 29 28 1 96.55
slot:6/mod:18 21 20 1 95.24
slot:6/mod:19 16 16 0 100.00
slot:6/mod:2 29 27 2 93.10
slot:6/mod:20 6 6 0 100.00
slot:6/mod:21 24 24 0 100.00
slot:6/mod:22 35 33 2 94.29
slot:6/mod:23 29 28 1 96.55
slot:6/mod:3 28 28 0 100.00
slot:6/mod:4 17 15 2 88.24
slot:6/mod:5 27 25 2 92.59
slot:6/mod:6 11 11 0 100.00
slot:6/mod:7 19 18 1 94.74
slot:6/mod:8 27 26 1 96.30
slot:6/mod:9 13 13 0 100.00
slot:7/mod:1 24 22 2 91.67
slot:7/mod:10 29 27 2 93.10
slot:7/mod:11 25 22 3 88.00
slot:7/mod:12 29 28 1 96.55
slot:7/mod:13 24 22 2 91.67
slot:7/mod:14 24 21 3 87.50
slot:7/mod:15 23 21 2 91.30
slot:7/mod:18 31 29 2 93.55
slot:7/mod:19 24 24 0 100.00
slot:7/mod:2 26 25 1 96.15
Modem Health Check - file: shv1.1 - chassis: usr1
09/13/99 07:00:07
slot:x/mod:y Calls Calls Failed Percent
Arrived Established Attempts Success
------------ ------- ----------- -------- -------
slot:7/mod:20 30 28 2 93.33
slot:7/mod:21 5 5 0 100.00
slot:7/mod:22 25 24 1 96.00
slot:7/mod:23 28 28 0 100.00
slot:7/mod:5 14 13 1 92.86
slot:7/mod:6 8 8 0 100.00
slot:7/mod:7 21 20 1 95.24
slot:7/mod:8 29 27 2 93.10
slot:7/mod:9 10 10 0 100.00
slot:8/mod:1 38 35 3 92.11
slot:8/mod:11 19 19 0 100.00
slot:8/mod:12 36 33 3 91.67
slot:8/mod:13 21 21 0 100.00
slot:8/mod:14 27 25 2 92.59
slot:8/mod:15 20 19 1 95.00
slot:8/mod:16 30 29 1 96.67
slot:8/mod:17 32 31 1 96.88
slot:8/mod:18 27 26 1 96.30
slot:8/mod:19 29 28 1 96.55
slot:8/mod:2 32 30 2 93.75
slot:8/mod:20 10 10 0 100.00
slot:8/mod:21 17 17 0 100.00
slot:8/mod:22 27 26 1 96.30
slot:8/mod:23 27 24 3 88.89
slot:8/mod:3 27 25 2 92.59
slot:8/mod:5 29 28 1 96.55
slot:8/mod:6 20 19 1 95.00
slot:8/mod:7 32 28 4 87.50
slot:8/mod:8 31 31 0 100.00
slot:9/mod:1 32 29 3 90.62
slot:9/mod:10 10 10 0 100.00
slot:9/mod:11 21 21 0 100.00
slot:9/mod:12 5 5 0 100.00
slot:9/mod:13 33 33 0 100.00
slot:9/mod:14 9 9 0 100.00
slot:9/mod:15 11 11 0 100.00
slot:9/mod:16 27 23 4 85.19
slot:9/mod:17 27 26 1 96.30
slot:9/mod:18 23 22 1 95.65
slot:9/mod:19 27 24 3 88.89
slot:9/mod:2 25 23 2 92.00
slot:9/mod:20 30 27 3 90.00
slot:9/mod:21 29 29 0 100.00
slot:9/mod:22 34 29 5 85.29
slot:9/mod:23 3 3 0 100.00
slot:9/mod:3 24 20 4 83.33
slot:9/mod:4 3 3 0 100.00
slot:9/mod:5 31 29 2 93.55
slot:9/mod:6 25 23 2 92.00
slot:9/mod:7 19 19 0 100.00
slot:9/mod:8 26 24 2 92.31
Modem Health Check - file: shv1.1 - chassis: usr1
09/13/99 07:00:07
slot:x/mod:y Calls Calls Failed Percent
Arrived Established Attempts Success
------------ ------- ----------- -------- -------
slot:9/mod:9 19 18 1 94.74
=================================
95.12% average for chassis
=================================
am
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Eric Billeter" <ebilleter@cableone.net>
Subject: RE: (usr-tc) Connect %'s
Date: 14 Sep 1999 14:58:23 -0700
Total Calls Success 484124
Total calls Failed 24080
Call Failure Rate 4.74%
This is over 17 pops
Best rate is 2.39
Worst is 6.49
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of USR TC Mailing list
account
Sent: Tuesday, September 14, 1999 2:16 PM
For comparison, I've knocked up some software that dials out with 2
couriers and does testing. This setup is a "perfect" setup, ie, there are
no problems with it that would make it fail. According to that, the
cumulative logs for the last few days add up to:
Calls made: 23822
Calls succeeded: 23501
Calls failed: 327
Failure rate: 1.3%
Ring-No-answer fails: 6
Busies: 2
NoCarrier: 248
NoLoginPrompt: 70
NoPPP: 1
The number of failed calls from SNMP works out at 5.52% (93949
success/5492 failed).
Ergo, from this roughly 4% of failed calls are due to problems outside the
racks.
Hope this helps (and "Hi!" to JP, if yer still out there and didn't get
eaten in Canada, eh? :-)
Cheers, Steve
On Tue, 14 Sep 1999, Paul Farber wrote:
> Hello all...
>
> Just throwing this out to see if it what others are getting:
>
> ARC-I Total calls received: 51627 6 DSP's
> Total calls failed : 2546
> Connection average : 95.07
> ARC-II Total calls received: 2318 6 Quad's
> Total calls failed : 86
> Connection average : 96.29
>
> Total calls received: 53894
> Total calls failed : 2631
> Connection average : 95.12
>
> System Date ( Time in GMT ) 14-SEP-1999 14:56:13
> System UpTime: 34d 04:53:31
>
> (Some cards have been rebooted to clear hung modems)
>
> This is from a simple perl script that walk the inConnectAttemptFails and
> inConnectEstablished OID's.
>
> It's been hovering around 95% connection rate..... anyone seeing higher
> than this?
>
>
>
> Paul D. Farber II
> Farber Technology
> Ph. 570-628-5303
> Fax 570-628-5545
> farber@admin.f-tech.net
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) Connect %'s
Date: 14 Sep 1999 18:16:02 -0400 (EDT)
Was this into a dedicated slot/modem or did you just dial into a hunt
group?
Have you modified the default modem template at all???
Would have been nice if you used something other than a courier... kinda
loads up the test in favor of getting a connection... most customers get
a .v90 $20 win modem.
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Tue, 14 Sep 1999, USR TC Mailing list account wrote:
> For comparison, I've knocked up some software that dials out with 2
> couriers and does testing. This setup is a "perfect" setup, ie, there are
> no problems with it that would make it fail. According to that, the
> cumulative logs for the last few days add up to:
>
> Calls made: 23822
> Calls succeeded: 23501
> Calls failed: 327
> Failure rate: 1.3%
> Ring-No-answer fails: 6
> Busies: 2
> NoCarrier: 248
> NoLoginPrompt: 70
> NoPPP: 1
>
> The number of failed calls from SNMP works out at 5.52% (93949
> success/5492 failed).
>
> Ergo, from this roughly 4% of failed calls are due to problems outside the
> racks.
>
> Hope this helps (and "Hi!" to JP, if yer still out there and didn't get
> eaten in Canada, eh? :-)
>
> Cheers, Steve
>
> On Tue, 14 Sep 1999, Paul Farber wrote:
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: RE: (usr-tc) Connect %'s
Date: 14 Sep 1999 18:20:30 -0400 (EDT)
Feels good to be average!
Seems that we all have cobbled together our own failure scripts.... Anyone
gotten their script to busy out a modem that goes over a threshold
value (hung modem)? What OID or you using to set it to busy out??
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Tue, 14 Sep 1999, Eric Billeter wrote:
> Total Calls Success 484124
> Total calls Failed 24080
> Call Failure Rate 4.74%
>
> This is over 17 pops
> Best rate is 2.39
> Worst is 6.49
>
>
>
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of USR TC Mailing list
> account
> Sent: Tuesday, September 14, 1999 2:16 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) Connect %'s
>
>
> For comparison, I've knocked up some software that dials out with 2
> couriers and does testing. This setup is a "perfect" setup, ie, there are
> no problems with it that would make it fail. According to that, the
> cumulative logs for the last few days add up to:
>
> Calls made: 23822
> Calls succeeded: 23501
> Calls failed: 327
> Failure rate: 1.3%
> Ring-No-answer fails: 6
> Busies: 2
> NoCarrier: 248
> NoLoginPrompt: 70
> NoPPP: 1
>
> The number of failed calls from SNMP works out at 5.52% (93949
> success/5492 failed).
>
> Ergo, from this roughly 4% of failed calls are due to problems outside the
> racks.
>
> Hope this helps (and "Hi!" to JP, if yer still out there and didn't get
> eaten in Canada, eh? :-)
>
> Cheers, Steve
>
> On Tue, 14 Sep 1999, Paul Farber wrote:
>
> > Hello all...
> >
> > Just throwing this out to see if it what others are getting:
> >
> > ARC-I Total calls received: 51627 6 DSP's
> > Total calls failed : 2546
> > Connection average : 95.07
> > ARC-II Total calls received: 2318 6 Quad's
> > Total calls failed : 86
> > Connection average : 96.29
> >
> > Total calls received: 53894
> > Total calls failed : 2631
> > Connection average : 95.12
> >
> > System Date ( Time in GMT ) 14-SEP-1999 14:56:13
> > System UpTime: 34d 04:53:31
> >
> > (Some cards have been rebooted to clear hung modems)
> >
> > This is from a simple perl script that walk the inConnectAttemptFails and
> > inConnectEstablished OID's.
> >
> > It's been hovering around 95% connection rate..... anyone seeing higher
> > than this?
> >
> >
> >
> > Paul D. Farber II
> > Farber Technology
> > Ph. 570-628-5303
> > Fax 570-628-5545
> > farber@admin.f-tech.net
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Scot Desort" <scot@njaccess.net>
Subject: Re: (usr-tc) Connect %'s
Date: 14 Sep 1999 18:20:44 -0400
Haven't run any stats on my chassis yet since we really just started using
it not too long ago. But when we were shopping around, review after review I
read (for what they're worth in their "simulated real world environments")
consistently showed the top 4 players (Lucent, Ascend, 3COM, Bay/Nortel)
averaging between 94 and 97% connect rates. In the real world, 95% is
probably pretty good (I think). I can't see any NAS equipment with any true
diversity in the area it serves, and with a pretty high volume of calls,
getting much over 97-98% at most.
...Scot
----- Original Message -----
Sent: Tuesday, September 14, 1999 3:04 PM
> Hello all...
>
> Just throwing this out to see if it what others are getting:
>
> ARC-I Total calls received: 51627 6 DSP's
> Total calls failed : 2546
> Connection average : 95.07
> ARC-II Total calls received: 2318 6 Quad's
> Total calls failed : 86
> Connection average : 96.29
>
> Total calls received: 53894
> Total calls failed : 2631
> Connection average : 95.12
>
> System Date ( Time in GMT ) 14-SEP-1999 14:56:13
> System UpTime: 34d 04:53:31
>
> (Some cards have been rebooted to clear hung modems)
>
> This is from a simple perl script that walk the inConnectAttemptFails and
> inConnectEstablished OID's.
>
> It's been hovering around 95% connection rate..... anyone seeing higher
> than this?
>
>
>
> Paul D. Farber II
> Farber Technology
> Ph. 570-628-5303
> Fax 570-628-5545
> farber@admin.f-tech.net
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Scot Desort" <scot@njaccess.net>
Subject: Re: (usr-tc) Connect %'s
Date: 14 Sep 1999 18:24:02 -0400
Speaking of default modem templates, has anyone here made any changes to
theirs, and noticed significant improvements in successful calls or higher
speeds? Just curious....
...Scot
----- Original Message -----
Sent: Tuesday, September 14, 1999 6:16 PM
> Was this into a dedicated slot/modem or did you just dial into a hunt
> group?
>
> Have you modified the default modem template at all???
>
> Would have been nice if you used something other than a courier... kinda
> loads up the test in favor of getting a connection... most customers get
> a .v90 $20 win modem.
>
> Paul D. Farber II
> Farber Technology
> Ph. 570-628-5303
> Fax 570-628-5545
> farber@admin.f-tech.net
>
> On Tue, 14 Sep 1999, USR TC Mailing list account wrote:
>
> > For comparison, I've knocked up some software that dials out with 2
> > couriers and does testing. This setup is a "perfect" setup, ie, there
are
> > no problems with it that would make it fail. According to that, the
> > cumulative logs for the last few days add up to:
> >
> > Calls made: 23822
> > Calls succeeded: 23501
> > Calls failed: 327
> > Failure rate: 1.3%
> > Ring-No-answer fails: 6
> > Busies: 2
> > NoCarrier: 248
> > NoLoginPrompt: 70
> > NoPPP: 1
> >
> > The number of failed calls from SNMP works out at 5.52% (93949
> > success/5492 failed).
> >
> > Ergo, from this roughly 4% of failed calls are due to problems outside
the
> > racks.
> >
> > Hope this helps (and "Hi!" to JP, if yer still out there and didn't get
> > eaten in Canada, eh? :-)
> >
> > Cheers, Steve
> >
> > On Tue, 14 Sep 1999, Paul Farber wrote:
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Clint R. Sparks" <csparks@cqc.com>
Subject: Re: (usr-tc) Connect %'s
Date: 14 Sep 1999 17:28:04 -0500
Paul,
Have you tried Hiper DSP code 2.0.81?
If so what do you think of it?
Thank you,
Clint R. Sparks
ComQuest Internet Services
csparks@cqc.com
----- Original Message -----
Sent: Tuesday, September 14, 1999 4:58 PM
> DSP 2.0.19
> ARC 4.1.59
> NMC 6.1.17
>
> Paul D. Farber II
> Farber Technology
> Ph. 570-628-5303
> Fax 570-628-5545
> farber@admin.f-tech.net
>
> On Tue, 14 Sep 1999, Clint R. Sparks wrote:
>
> > Paul,
> >
> > What Hiper DSP and Hiper Arc code are you running?
> >
> > Clint R. Sparks
> > ComQuest Internet Services
> > csparks@cqc.com
> >
> >
> > ----- Original Message -----
> > From: Paul Farber <farber@admin.f-tech.net>
> > To: <usr-tc@lists.xmission.com>
> > Sent: Tuesday, September 14, 1999 2:04 PM
> > Subject: (usr-tc) Connect %'s
> >
> >
> > > Hello all...
> > >
> > > Just throwing this out to see if it what others are getting:
> > >
> > > ARC-I Total calls received: 51627 6 DSP's
> > > Total calls failed : 2546
> > > Connection average : 95.07
> > > ARC-II Total calls received: 2318 6 Quad's
> > > Total calls failed : 86
> > > Connection average : 96.29
> > >
> > > Total calls received: 53894
> > > Total calls failed : 2631
> > > Connection average : 95.12
> > >
> > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13
> > > System UpTime: 34d 04:53:31
> > >
> > > (Some cards have been rebooted to clear hung modems)
> > >
> > > This is from a simple perl script that walk the inConnectAttemptFails
and
> > > inConnectEstablished OID's.
> > >
> > > It's been hovering around 95% connection rate..... anyone seeing
higher
> > > than this?
> > >
> > >
> > >
> > > Paul D. Farber II
> > > Farber Technology
> > > Ph. 570-628-5303
> > > Fax 570-628-5545
> > > farber@admin.f-tech.net
> >
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) Connect %'s
Date: 14 Sep 1999 18:43:15 -0400 (EDT)
No, I haven't. From the release notes all it really did was add NFAS and
a few other things that I don't really use. Plus my support contract
expired, so I don't have access to the proper ARC/NMC software to make it
all TCS 3.5(?).
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Tue, 14 Sep 1999, Clint R. Sparks wrote:
> Paul,
>
> Have you tried Hiper DSP code 2.0.81?
>
> If so what do you think of it?
>
> Thank you,
>
> Clint R. Sparks
> ComQuest Internet Services
> csparks@cqc.com
>
>
> ----- Original Message -----
> From: Paul Farber <farber@admin.f-tech.net>
> To: <usr-tc@lists.xmission.com>
> Sent: Tuesday, September 14, 1999 4:58 PM
> Subject: Re: (usr-tc) Connect %'s
>
>
> > DSP 2.0.19
> > ARC 4.1.59
> > NMC 6.1.17
> >
> > Paul D. Farber II
> > Farber Technology
> > Ph. 570-628-5303
> > Fax 570-628-5545
> > farber@admin.f-tech.net
> >
> > On Tue, 14 Sep 1999, Clint R. Sparks wrote:
> >
> > > Paul,
> > >
> > > What Hiper DSP and Hiper Arc code are you running?
> > >
> > > Clint R. Sparks
> > > ComQuest Internet Services
> > > csparks@cqc.com
> > >
> > >
> > > ----- Original Message -----
> > > From: Paul Farber <farber@admin.f-tech.net>
> > > To: <usr-tc@lists.xmission.com>
> > > Sent: Tuesday, September 14, 1999 2:04 PM
> > > Subject: (usr-tc) Connect %'s
> > >
> > >
> > > > Hello all...
> > > >
> > > > Just throwing this out to see if it what others are getting:
> > > >
> > > > ARC-I Total calls received: 51627 6 DSP's
> > > > Total calls failed : 2546
> > > > Connection average : 95.07
> > > > ARC-II Total calls received: 2318 6 Quad's
> > > > Total calls failed : 86
> > > > Connection average : 96.29
> > > >
> > > > Total calls received: 53894
> > > > Total calls failed : 2631
> > > > Connection average : 95.12
> > > >
> > > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13
> > > > System UpTime: 34d 04:53:31
> > > >
> > > > (Some cards have been rebooted to clear hung modems)
> > > >
> > > > This is from a simple perl script that walk the inConnectAttemptFails
> and
> > > > inConnectEstablished OID's.
> > > >
> > > > It's been hovering around 95% connection rate..... anyone seeing
> higher
> > > > than this?
> > > >
> > > >
> > > >
> > > > Paul D. Farber II
> > > > Farber Technology
> > > > Ph. 570-628-5303
> > > > Fax 570-628-5545
> > > > farber@admin.f-tech.net
> > >
> > >
> > >
> > > -
> > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > > 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.
> > >
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: USR TC Mailing list account <usrtc@fop.ns.ca>
Subject: Re: (usr-tc) Connect %'s
Date: 14 Sep 1999 19:56:00 -0300 (ADT)
On Tue, 14 Sep 1999, Paul Farber wrote:
> Was this into a dedicated slot/modem or did you just dial into a hunt
> group?
Into the hunt groups. We've got several pools set up, and each rack has
calls from up to 5 different pools coming into it.
> Have you modified the default modem template at all???
Nothing of note that would affect the connection.
> Would have been nice if you used something other than a courier... kinda
> loads up the test in favor of getting a connection... most customers get
> a .v90 $20 win modem.
That's kinda the point. We want to go in and get an idea of how the racks
are performing giving a call coming in from a well set up modem. I can
then generate a graph showing what the call failure %age is, and what the
call failure %age is due to problems on the racks. This is all tied in
with SLA's (this is for an ISP that is part of a telco - very weird
reporting stuff goes on).
To answer your question in a later email as to what to do when I find a
bad modem, I have to call a manager who then calls a union supervisor who
then calls a union worker to go and reset the modem. I'm not allowed to
know the read/write snmp string. Told you it was weird.
Cheers, Steve
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Sam Lowe" <slowe@universalcom.net>
Subject: Re: (usr-tc) Connect %'s
Date: 14 Sep 1999 18:06:20 -0500
DSP 2.0.81
ARC 4.1.59
Total Connects: 46823
Total Fails: 1392
or about 3%
Worst modem is 7%.
Samuel S. Lowe
Director, Data Services
UniversalCom, Inc.
slowe@universalcom.net
----- Original Message -----
Sent: Tuesday, September 14, 1999 4:58 PM
> > > Hello all...
> > >
> > > Just throwing this out to see if it what others are getting:
> > >
> > > ARC-I Total calls received: 51627 6 DSP's
> > > Total calls failed : 2546
> > > Connection average : 95.07
> > > ARC-II Total calls received: 2318 6 Quad's
> > > Total calls failed : 86
> > > Connection average : 96.29
> > >
> > > Total calls received: 53894
> > > Total calls failed : 2631
> > > Connection average : 95.12
> > >
> > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13
> > > System UpTime: 34d 04:53:31
> > >
> > > (Some cards have been rebooted to clear hung modems)
> > >
> > > This is from a simple perl script that walk the inConnectAttemptFails
and
> > > inConnectEstablished OID's.
> > >
> > > It's been hovering around 95% connection rate..... anyone seeing
higher
> > > than this?
> > >
> > >
> > >
> > > Paul D. Farber II
> > > Farber Technology
> > > Ph. 570-628-5303
> > > Fax 570-628-5545
> > > farber@admin.f-tech.net
> >
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Clint R. Sparks" <csparks@cqc.com>
Subject: Re: (usr-tc) Connect %'s
Date: 14 Sep 1999 18:32:30 -0500
Sam,
3com is working with us right now on a connect speed problem and wants us to
go to Hiper DSP code 2.0.81, what do you think of it?
Have you had any problems with it?
Thank you,
Clint R. Sparks
ComQuest Internet Services
csparks@cqc.com
----- Original Message -----
Sent: Tuesday, September 14, 1999 6:06 PM
> DSP 2.0.81
> ARC 4.1.59
>
> Total Connects: 46823
> Total Fails: 1392
> or about 3%
>
> Worst modem is 7%.
>
> Samuel S. Lowe
> Director, Data Services
> UniversalCom, Inc.
> slowe@universalcom.net
>
> ----- Original Message -----
> From: Paul Farber <farber@admin.f-tech.net>
> To: <usr-tc@lists.xmission.com>
> Sent: Tuesday, September 14, 1999 4:58 PM
> Subject: Re: (usr-tc) Connect %'s
>
>
>
> > > > Hello all...
> > > >
> > > > Just throwing this out to see if it what others are getting:
> > > >
> > > > ARC-I Total calls received: 51627 6 DSP's
> > > > Total calls failed : 2546
> > > > Connection average : 95.07
> > > > ARC-II Total calls received: 2318 6 Quad's
> > > > Total calls failed : 86
> > > > Connection average : 96.29
> > > >
> > > > Total calls received: 53894
> > > > Total calls failed : 2631
> > > > Connection average : 95.12
> > > >
> > > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13
> > > > System UpTime: 34d 04:53:31
> > > >
> > > > (Some cards have been rebooted to clear hung modems)
> > > >
> > > > This is from a simple perl script that walk the
inConnectAttemptFails
> and
> > > > inConnectEstablished OID's.
> > > >
> > > > It's been hovering around 95% connection rate..... anyone seeing
> higher
> > > > than this?
> > > >
> > > >
> > > >
> > > > Paul D. Farber II
> > > > Farber Technology
> > > > Ph. 570-628-5303
> > > > Fax 570-628-5545
> > > > farber@admin.f-tech.net
> > >
> > >
> > >
> > > -
> > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > > 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.
> > >
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) Connect %'s
Date: 14 Sep 1999 19:38:34 -0400 (EDT)
On Tue, 14 Sep 1999, Paul Farber wrote:
> Hello all...
>
> Just throwing this out to see if it what others are getting:
>
> ARC-I Total calls received: 51627 6 DSP's
> Total calls failed : 2546
> Connection average : 95.07
> ARC-II Total calls received: 2318 6 Quad's
> Total calls failed : 86
> Connection average : 96.29
>
> Total calls received: 53894
> Total calls failed : 2631
> Connection average : 95.12
>
> System Date ( Time in GMT ) 14-SEP-1999 14:56:13
> System UpTime: 34d 04:53:31
>
> (Some cards have been rebooted to clear hung modems)
>
> This is from a simple perl script that walk the inConnectAttemptFails and
> inConnectEstablished OID's.
What's the exact OID's you're using? Those names don't exist in my MIB...
Is your script on a web page somewhere, or did you only post it here?
Guess I better dig through the list archives. :)
FWIW, I've found 4 different OIDs of interest:
* usrinCallmodemNotAvail [1.3.6.1.4.1.429.1.27.2.1.10]
PER-DSP-CARD (not per channel) counter of "modem unavailable" errors.
i.e. call comes in and the DSP refused to pick it up -- the old 'dead-air'
syndrome that was pretty much fixed a few releases back. This one seems
to stay at zero for me on DSP 2.0.81...
* mdmEvInConnectEstabs [1.3.6.1.4.1.429.1.6.10.1.1.4]
Successful connects.
* mdmEvConnectAttemptFails [1.3.6.1.4.1.429.1.6.10.1.1.8]
Failed connects.
* mdmEvInConnectAttemptFails [1.3.6.1.4.1.429.1.6.10.1.1.24]
Also failed connects!
For Quads, both of the failed connect OID's appear to be identical.
But for DSP's, they're a lot different.
It appears that on DSP's, the second OID includes things like a voice call
hitting the modem pool and hanging up on the answer tone, and the OID
above doesn't -- seems to be for DSP problems only.
For example, when a DSP card gets rebooted, the first OID counter shoots
up to about 50 (as people try to call while it's in the midst of
rebooting, even if you busied it out first?), then stays there and never
moves much past that. The second one grows for any call failure of any
type, whether it's a buggy v.90 modem or whether it's a voice call
(hopefully a telemarketer getting an earful of carrier).
Since things like voice calls make the failure counters go up, it doesn't
make a lot of sense to use this to judge the quality of 3Com's v.90 code.
Especially when nobody's doing a similar comparison on, say, Cisco or
Ascend servers.
Anyone else noticing any other patterns?
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: (usr-tc) DSP Core Dump
Date: 14 Sep 1999 20:39:34 -0400
Connecting to the DSP Console port shows the following shortly after any
call is connected to it;
*** CORE DUMP ***
At 19:43:48 07/02/96
Total Uptime: 00:02:23
S/W Rev. 2.0.81.0 built 04/27/99 12:56:12
Mail() error Task = IDL
Q_SEND Failed: ulStatus = 0x7
LAST MSG 214 5 4 IDL(018)=>DST(021) 000 00000000
BEAR FFFFFFFE BESR 00000000 BR0 FC580502 BR1 0C1C4202
BR2 08584202 BR3 1078C200 BR4 04594387 BR5 00594101
BR6 04590A0E BR7 00590A0E DCCR 80008000 DEAR FFFFFFFF
ESR 00000000 EVPR 80000000 EXIER 00800009 EXISR 0000000A
ICCR 80008001 IOCR 0000C001 MSR 00001200 PVR 00000020
PIT 00000000 SRR0 8000B920 SRR1 00001200 SRR2 3FFEFE00
SRR3 00000000 TBHI 00000002 TBLO 070844ED TCR FC000000
TSR 0C000000 LR 80006BFC
** Stack Trace **
80005444
80006BF8
80130C14
Does anybody have any ideas what the hell is wrong with my card???
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Sam Lowe" <slowe@universalcom.net>
Subject: Re: (usr-tc) Connect %'s
Date: 14 Sep 1999 19:44:00 -0500
Clint,
We have had no problems with this code release. We have had a continuing
problem with ISDN connections that seemingly lock up (can't route anything
but ICMP packets), but this problem was present before we did the last
software upgrade. We skipped over the 2.0.19 load entirely.
We have seen no decrease in general connect speeds.
Sam
----- Original Message -----
Sent: Tuesday, September 14, 1999 6:32 PM
> Sam,
>
> 3com is working with us right now on a connect speed problem and wants us
to
> go to Hiper DSP code 2.0.81, what do you think of it?
>
> Have you had any problems with it?
>
> Thank you,
>
> Clint R. Sparks
> ComQuest Internet Services
> csparks@cqc.com
>
>
> ----- Original Message -----
> From: Sam Lowe <slowe@universalcom.net>
> To: <usr-tc@lists.xmission.com>
> Sent: Tuesday, September 14, 1999 6:06 PM
> Subject: Re: (usr-tc) Connect %'s
>
>
> > DSP 2.0.81
> > ARC 4.1.59
> >
> > Total Connects: 46823
> > Total Fails: 1392
> > or about 3%
> >
> > Worst modem is 7%.
> >
> > Samuel S. Lowe
> > Director, Data Services
> > UniversalCom, Inc.
> > slowe@universalcom.net
> >
> > ----- Original Message -----
> > From: Paul Farber <farber@admin.f-tech.net>
> > To: <usr-tc@lists.xmission.com>
> > Sent: Tuesday, September 14, 1999 4:58 PM
> > Subject: Re: (usr-tc) Connect %'s
> >
> >
> >
> > > > > Hello all...
> > > > >
> > > > > Just throwing this out to see if it what others are getting:
> > > > >
> > > > > ARC-I Total calls received: 51627 6 DSP's
> > > > > Total calls failed : 2546
> > > > > Connection average : 95.07
> > > > > ARC-II Total calls received: 2318 6 Quad's
> > > > > Total calls failed : 86
> > > > > Connection average : 96.29
> > > > >
> > > > > Total calls received: 53894
> > > > > Total calls failed : 2631
> > > > > Connection average : 95.12
> > > > >
> > > > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13
> > > > > System UpTime: 34d 04:53:31
> > > > >
> > > > > (Some cards have been rebooted to clear hung modems)
> > > > >
> > > > > This is from a simple perl script that walk the
> inConnectAttemptFails
> > and
> > > > > inConnectEstablished OID's.
> > > > >
> > > > > It's been hovering around 95% connection rate..... anyone seeing
> > higher
> > > > > than this?
> > > > >
> > > > >
> > > > >
> > > > > Paul D. Farber II
> > > > > Farber Technology
> > > > > Ph. 570-628-5303
> > > > > Fax 570-628-5545
> > > > > farber@admin.f-tech.net
> > > >
> > > >
> > > >
> > > > -
> > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > > > 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.
> > > >
> > >
> > >
> > > -
> > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > > 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.
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) Connect %'s
Date: 14 Sep 1999 21:41:37 -0400 (EDT)
> What's the exact OID's you're using? Those names don't exist in my
MIB...
They are abbreviations the I used in a perl script. I use
> * mdmEvInConnectEstabs [1.3.6.1.4.1.429.1.6.10.1.1.4]
> Successful connects.
> * mdmEvInConnectAttemptFails [1.3.6.1.4.1.429.1.6.10.1.1.24]
> Also failed connects!
I didn't think of / see the mdmEvConnectAttemptFails MIB.... will have to
add that.
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Tue, 14 Sep 1999, Mike Andrews wrote:
> On Tue, 14 Sep 1999, Paul Farber wrote:
>
> > Hello all...
> >
> > Just throwing this out to see if it what others are getting:
> >
> > ARC-I Total calls received: 51627 6 DSP's
> > Total calls failed : 2546
> > Connection average : 95.07
> > ARC-II Total calls received: 2318 6 Quad's
> > Total calls failed : 86
> > Connection average : 96.29
> >
> > Total calls received: 53894
> > Total calls failed : 2631
> > Connection average : 95.12
> >
> > System Date ( Time in GMT ) 14-SEP-1999 14:56:13
> > System UpTime: 34d 04:53:31
> >
> > (Some cards have been rebooted to clear hung modems)
> >
> > This is from a simple perl script that walk the inConnectAttemptFails and
> > inConnectEstablished OID's.
>
>
> What's the exact OID's you're using? Those names don't exist in my MIB...
>
> Is your script on a web page somewhere, or did you only post it here?
> Guess I better dig through the list archives. :)
>
> FWIW, I've found 4 different OIDs of interest:
>
> * usrinCallmodemNotAvail [1.3.6.1.4.1.429.1.27.2.1.10]
> PER-DSP-CARD (not per channel) counter of "modem unavailable" errors.
> i.e. call comes in and the DSP refused to pick it up -- the old 'dead-air'
> syndrome that was pretty much fixed a few releases back. This one seems
> to stay at zero for me on DSP 2.0.81...
>
> * mdmEvInConnectEstabs [1.3.6.1.4.1.429.1.6.10.1.1.4]
> Successful connects.
>
> * mdmEvConnectAttemptFails [1.3.6.1.4.1.429.1.6.10.1.1.8]
> Failed connects.
>
> * mdmEvInConnectAttemptFails [1.3.6.1.4.1.429.1.6.10.1.1.24]
> Also failed connects!
>
> For Quads, both of the failed connect OID's appear to be identical.
>
> But for DSP's, they're a lot different.
>
> It appears that on DSP's, the second OID includes things like a voice call
> hitting the modem pool and hanging up on the answer tone, and the OID
> above doesn't -- seems to be for DSP problems only.
>
> For example, when a DSP card gets rebooted, the first OID counter shoots
> up to about 50 (as people try to call while it's in the midst of
> rebooting, even if you busied it out first?), then stays there and never
> moves much past that. The second one grows for any call failure of any
> type, whether it's a buggy v.90 modem or whether it's a voice call
> (hopefully a telemarketer getting an earful of carrier).
>
> Since things like voice calls make the failure counters go up, it doesn't
> make a lot of sense to use this to judge the quality of 3Com's v.90 code.
> Especially when nobody's doing a similar comparison on, say, Cisco or
> Ascend servers.
>
> Anyone else noticing any other patterns?
>
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Fred Williams" <fwilliams@gtnet.gov.uk>
Subject: Re: (usr-tc) Connect %'s
Date: 15 Sep 1999 09:26:06 +0100
My average is about the same. This is on the UK phone system.
On 14 Sep 99, at 15:04, Paul Farber wrote:
> Hello all...
>
> Just throwing this out to see if it what others are getting:
>
> ARC-I Total calls received: 51627 6 DSP's
> Total calls failed : 2546
> Connection average : 95.07
> ARC-II Total calls received: 2318 6 Quad's
> Total calls failed : 86
> Connection average : 96.29
>
> Total calls received: 53894
> Total calls failed : 2631
> Connection average : 95.12
>
> System Date ( Time in GMT ) 14-SEP-1999 14:56:13
> System UpTime: 34d 04:53:31
>
> (Some cards have been rebooted to clear hung modems)
>
> This is from a simple perl script that walk the inConnectAttemptFails
> and inConnectEstablished OID's.
>
> It's been hovering around 95% connection rate..... anyone seeing
> higher than this?
****************************************************************
* Fred Williams email fwilliams@gtnet.gov.uk *
* CCTA voice 01603 704706 *
* Rosebery Court GTN 3040 4706 *
* St Andrews Business Park fax 01603 704817 *
* NORWICH GTN fax 3040 4817 *
* NR7 0HS UK *
****************************************************************
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Steve Drees" <drees@the-bridge.net>
Subject: (usr-tc) HiperARC equivalent of portmaster show line0
Date: 15 Sep 1999 09:04:44 -0500
On a portmaster 3 I can issue a show line0 and get a nice table showing
alarms and violations on the PRI. What's the equivalent command on a
HiperARC?
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: jeff.binkley@asacomp.com (Jeff Binkley)
Subject: Re: (usr-tc) Connect %'s
Date: 15 Sep 1999 09:45:00 -0500
As long as your users aren't buying the Soundblaster 56 modems. We've
ended up switching out all of our users that have them. Either they
can't connect at all or get random disconnects. Their latest code is no
help. We are starting to tell customers that call in with them that
either they will need to buy a new modem or go elsewhere. I hate
telling customers that.
Jeff Binkley
ASA Network Computing
u>Haven't run any stats on my chassis yet since we really just started
u>using it not too long ago. But when we were shopping around, review
u>after review I read (for what they're worth in their "simulated real
u>world environments") consistently showed the top 4 players (Lucent,
u>Ascend, 3COM, Bay/Nortel) averaging between 94 and 97% connect rates.
u>In the real world, 95% is probably pretty good (I think). I can't see
u>any NAS equipment with any true diversity in the area it serves, and
u>with a pretty high volume of calls, getting much over 97-98% at most.
u>....Scot
u>----- Original Message -----
u>From: Paul Farber <farber@admin.f-tech.net>
u>To: <usr-tc@lists.xmission.com>
u>Sent: Tuesday, September 14, 1999 3:04 PM
u>Subject: (usr-tc) Connect %'s
u>> Hello all...
u>>
u>> Just throwing this out to see if it what others are getting:
u>>
u>> ARC-I Total calls received: 51627 6 DSP's
u>> Total calls failed : 2546
u>> Connection average : 95.07
u>> ARC-II Total calls received: 2318 6 Quad's
u>> Total calls failed : 86
u>> Connection average : 96.29
u>>
u>> Total calls received: 53894
u>> Total calls failed : 2631
u>> Connection average : 95.12
u>>
u>> System Date ( Time in GMT ) 14-SEP-1999 14:56:13
u>> System UpTime: 34d 04:53:31
u>>
u>> (Some cards have been rebooted to clear hung modems)
u>>
u>> This is from a simple perl script that walk the
u>> inConnectAttemptFails and inConnectEstablished OID's.
u>>
u>> It's been hovering around 95% connection rate..... anyone seeing
u>> higher than this?
u>>
u>>
u>>
u>> Paul D. Farber II
u>> Farber Technology
u>> Ph. 570-628-5303
u>> Fax 570-628-5545
u>> farber@admin.f-tech.net
u>>
u>>
u>> -
u>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
u>> with "unsubscribe usr-tc" in the body of the message.
u>> For information on digests or retrieving files and old messages
u>> send "help" to the same address. Do not use quotes in your
u>message. >
u>-
u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
u> with "unsubscribe usr-tc" in the body of the message.
u> For information on digests or retrieving files and old messages send
u> "help" to the same address. Do not use quotes in your message.
CMPQwk 1.42 9999
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) HiperARC equivalent of portmaster show line0
Date: 15 Sep 1999 10:18:18 -0400
Thus spake Steve Drees
>On a portmaster 3 I can issue a show line0 and get a nice table showing
>alarms and violations on the PRI. What's the equivalent command on a
>HiperARC?
I don't think there is. In the PM's, the whole system is a single
system image...meaning the same image that runs the IP stack, also runs
the modems, and PRI signaling, etc. In the TC, those are handled by
different cards running different software images. The HiPer Arc is
responsible for the IP stack, and DTE signaling, there are other cards
that have their own images running the modem code and PRI signaling. If
you're using DSP's, the modem code and PRI signaling is in one image,
but if you're using the old school quads and dual-pri cards, the modem
code is obviously on the quad cards and the pri signaling is on the
pri-card, so even those functions might be split between cards.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Clayton Zekelman <clayton@MNSi.Net>
Subject: Re: (usr-tc) HiperARC equivalent of portmaster show line0
Date: 15 Sep 1999 10:20:25 -0400
Alarms and Line Violations are tracked on your HiperDSP or Dual PRI card,
not the HiperARC. You would have to use TCM's performance monitor or the
CLI on the cards to find the information.
At 09:04 AM 9/15/99 -0500, you wrote:
>On a portmaster 3 I can issue a show line0 and get a nice table showing
>alarms and violations on the PRI. What's the equivalent command on a
>HiperARC?
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6
tel. 519-985-8410
fax. 519-258-3009
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: (usr-tc) HiPer Arc improvement thoughts followup :)
Date: 15 Sep 1999 11:12:23 -0400
OK...posted last week some of my thoughts on where I think the HiPer Arc
and Total Control platform(s) should go as far as further development.
I got exactly one serious response that was sent to me privately and was
requested that the post stay private (and I'm happy to honor that).
Part of my intentions in posting that message (which I've included
below) was to spark some discussion amongst memebers of the list about
what you all think on this subject. We're the people using this
equipment, we're the people that know best where we want it to go.
Let's let 3Com know about it. :)
3Com just posted drivers for their NICs for Linux (to be honest, I did a
double-take when I saw that, but think its tres cool!), so apparently
they are beginning to foster a corporate culture of listening to
customers and what they want (and I can't support this idea enough I
don't think).
Let's hear what you all think about my proposals...and let's hear some
of your own if you have different ideas. Honest folks, I don't care if
you don't agree with me, but let's give 3Com a basis for where to go
with the development of this stuff.
--------------------
I mentioned earlier that I was going to email the list with some
thoughts of where I thought the HiPer Arc platform could/should go...
I have a little bit of time now, so maybe I can put some of these
thoughts down and maybe get some thoughts and discussion from the rest
of you about feasibility and maybe some other ideas...In any
case...these ideas are thrown out to maybe get some discussion going to
help give 3Com an idea of what we, as customers, would like to see out
of the Arc.
First off...a couple of specific feature requests...I may have mentioned
these before....if so, my apologies.
1) Bridging support...both over PPP, and over ethernet interfaces, and
any other interfaces that are supported (such as the new frame-relay
ones).
Imagine plugging your two ethernet interfaces into two different
switches in the same IP network...running spanning-tree between
them all...then your Arc isn't dependant on its switch being in
one piece to be able to communicate. Would require the use of a
"virtual" interface that participated in the bridging code as
well...similar in some ways to the internal interface that is
available for use with OSPF now. Basically, assign the IP
address for the Arc to the virtual interface, the Arc sends
packets to the virtual interface, when then goes into the
bridging code to decide which physical interface its sent out.
This is very similar to Cisco's bridge-groups with their
integrated routing and bridging for those of you who are
familiar with that.
2) Support for a "packet bus interface". This one sounds bizarre...but
if you think about it for a bit it starts to make sense...if you have
multiple Arc's in a chassis...why make them communicate out their NIC's
onto an external network to talk to each other? Some benefits for
this...
With the first feature....you could have two Arcs, both running
briding code as well...each with a single ethernet+4t1 NIC and
support 8 frame-relay t1's, and still retain the dual-exit
capability described above with briding or routing over the
packet bus. You could also theoretically have an Arc handling
modems that has no NIC at all! Modem interfaces come in over
the packet bus, and that same data is then shipped back out over
the packet bus interface to another Arc with NIC card. This
method could also be used as a failover scenario if a NIC card
failed, or a cable failed, or a switch failed...you get the
idea.
3) A larger variety of NIC interfaces. Particularly combined with the
packet bus interface, this frees you up to have a much greater variety
of NIC types...the Arc can then use the packet bus interface to get out
to the ethernet network (via another Arc most likely...either bridged or
routed), and allowing...oh....8 t1 NICs, or maybe a t3 nic, a
channelized t3 nic would be really sweet...the sky is the limit here
once you get the arcs using the packet bus as their ethernet
interface...
4) Similar to 3...the DSP cards have a crap-load of processing power in
them...could they be used for something more than just modems? It
seems...if you look at it in the abstract...that the DSP cards are
essentially interface extensions for the Arcs...let's take that
farther....this would mean basically totally revamping the code for the
DSP's for the new uses, or perhaps coming out with new code that's more
generalized. Then, with the possibility of new NICs for the DSP's you
could, again, extend the interface possibilities for the Arcs.
5) One that has bugged me for quite some time...PPP support on WAN
ports. I really don't particularly liked being restricted to
frame-relay encapsulation only...I can deal with it...but it'd be nice
to have the option of PPP encap as well. Many low end t1 routers don't
have frame-relay encap support, and it would be nice to be able to
interoperate with them.
In more abstract terms...I've been told by several 3Com folks that they
see the Pilgrim/Hiper Arc code as more full routing code rather than
just code for an Access Server. My understanding is that 3Com is moving
*all* of their routing products to eventually use the Pilgrim based
code.
With that thought in mind though...3Com seems (from a customer's
perspective) to still think of the HiPer Arc, specifically, as an access
server alone. I think the HiPer Arc and the Total Control platform as a
whole could become a quite capable router chassis product as a whole.
Personally speaking...I'd like to see that. In a similar vein...3Com
seems to think of the DSP cards as big powerful modem cards...and while
that's certainly a good use for them...let's break that paradigm (oh
man...a marketing cliche'...my apologies) and see them for more than
that...what they really are...a crapload of processing power on a card
that could theoretically, to the best of my knowledge, run just about
any arbitrary code with just about any arbitrary type of interface on
the NIC. That's a *very* powerful thought IMO.
Executive summary (I know, this should be at the top)...if you think of
the Total Control platform basically as a distributed processing router
platform...lot's of possibilities are opened up going forward. The
current code on there is getting to be pretty good and solid...but its
designed and written for a single specific function...limiting the
places where the TC platform could be used. This largely comes down to
be a business decision from 3Com (Lord help us there), but if they
decide that they don't want to limit the TC platform to being *only* an
access server (and personally, I think the distinction between access
server and router is a pretty thin line), then they need to start
thinking of the Arc as a router, not just an access server, and the
DSP's as generic interface cards, not modem/t1/pri cards.
These thoughts are probably not articulated very well...they're just
thoughts that I've had in the back of my head for a while that I want to
get out to some other people to see what you all have to say about the
ideas. I know some people wouldn't be interested in all at using some
of the features...but what I'm trying to get at here is the overall
direction for development of the Arcs/TC's, not specific feature
requests...although I have included some specific feature requests in my
message...try not to focus on those specifically...they are mostly there
as examples for the overall direction I was thinking of. Some of these
thoughts have been expressed in the past to some people at 3Com, but I
don't think any one person has ever heard the totality of what I was
thinking of (not having had time to sit down with anyone for long enough
time to fully hash these thoughts out).
So...there it is...let's hear what you think. :)
---------------------------
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
Date: 15 Sep 1999 11:49:39 -0400 (EDT)
I don't really see the TC chassis being a jack of all trades. Doing that
means a compromise. I buy 3Com/TC for it's ability to answer phone calls
and put ppp on the line. If I want a really good router i'll build a
linux box and put some NIC's in it.. or spend the money and buy a router.
There are still many issues with the DSP code that need to be resolved...
ISDN reliability, v.90 compatibility, uptime, off by snmp 1 errors, etc.
Fix them first!
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
Date: 15 Sep 1999 12:46:15 -0400
[rearranging your post a bit...pardon me :)]
Thus spake Paul Farber
>There are still many issues with the DSP code that need to be resolved...
>ISDN reliability, v.90 compatibility, uptime, off by snmp 1 errors, etc.
>Fix them first!
Oh, *please* don't think I was talking about doing *any* of these things
at the expense of current development efforts. :) I'm looking more at
a strategic long term direction, compared to the things you're
mentioning which I would consider more of a tactical nature. :)
Sure...v.90 needs to continue to be improved, the DSP code needs to be
solidified more...I certainly don't want the DSP code to be thrown
out...its just getting the point of being decent...
>I don't really see the TC chassis being a jack of all trades. Doing that
>means a compromise. I buy 3Com/TC for it's ability to answer phone calls
>and put ppp on the line. If I want a really good router i'll build a
>linux box and put some NIC's in it.. or spend the money and buy a router.
This is a distinction that a lot of people make that I just don't think
is particularly valid. :) An access server *is* a router, although a
router isn't necessarily an access server. :) Basically, the HiPer
Arc, as an access server, is already doing everything that a router is
doing...and more...(well...ok...its a router with a rather limited
feature set at this point, but it *is* a router, nonetheless) it's
dealing with interfaces popping up and down all the time, and
authentication, and dynamic configuration...all stuff that plain jain
routers don't have to deal with nearly as much. Why not take advantage
of the fact that the HiPer Arc, as an access server, already has, (or
more accurately, needs to have) all the features of a router (plus the
rest that make it an access server as well).
Let me throw this out as a possible for instance. Let's assume that
3Com implements the packet bus interface proposal from my message.
Let's also assume that new NIC's have come up...say a channelized T3 NIC
(28 ports of t1 essentially). Now then...you've got a TC chassis with
14 Arcs that have a channelized T3 NICs (that's 392 ports of t1
service), then two Arcs each with...say...a fast ethernet port, and an
unchannelized t3 port. At approximately $3k/Arc, you've got dual-exit
output to your network as a whole, dual-t3 uplink capability to Internet
connections, and 392 t1 ports....that works out to about $48k dollars
for that capability...not anything to sneeze at! This is just one
example that I pulled off the top of my head with some fairly simple
assumptions (the only one assumption not mentioned would be
implementation of BGP in the Arc...something that I understand is
already planned).
Again...there are plenty of other possibilities here. The HiPer Arc
code is developing nicely actually...there's still plenty of things that
are on my wishlist for it in a tactical sense (BGP would be nice, but
not a huge one, the ability to do some rate-limiting/traffic-shaping
stuff would be nice, I'd like bridging/ethernet switching capabilities,
etc.), but these are all things that routers do...we're already moving
towards router functionality, why not take advantage of it. :)
Something that I was just discussing with my co-admin here...the HiPer
Arcs are *really* close to be useable for DSL aggregation in most of the
cities we serve. GTE does it over frame-relay - frame-relay is
supported in the 4.2.x code, BellSouth does it over ATM - ATM is
coming...indeed, the code is already in the Arc to do it, just don't
think the NICs are available yet, Cincinnati Bell does it over l2tp (I
know...I think its bizarre too, but that's how they do it) - l2tp server
is already in the Arc. About the only thing that's really missing from
the Arc that people might want/need to do DSL aggregation is some
traffic-shaping/rate-limiting features, and possibly PPPoE/PPPoA/PPPoF
options.
Just some more random thoughts.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Kevin Benton <s1kevin@tims.net>
Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
Date: 15 Sep 1999 12:58:58 -0400 (EDT)
On Wed, 15 Sep 1999, Jeff Mcadams wrote:
> OK...posted last week some of my thoughts on where I think the HiPer Arc
> and Total Control platform(s) should go as far as further development.
> I got exactly one serious response that was sent to me privately and was
> requested that the post stay private (and I'm happy to honor that).
Didn't have time to read or reply and at the moment, this is about all
you'll get from me though I'm sure there are things I could probably
comment on. Were in the middle of some huge projects and I'm a point man
so...
> Part of my intentions in posting that message (which I've included
> below) was to spark some discussion amongst memebers of the list about
> what you all think on this subject. We're the people using this
> equipment, we're the people that know best where we want it to go.
> Let's let 3Com know about it. :)
See above.
> 3Com just posted drivers for their NICs for Linux (to be honest, I did a
> double-take when I saw that, but think its tres cool!), so apparently
> they are beginning to foster a corporate culture of listening to
> customers and what they want (and I can't support this idea enough I
> don't think).
Great idea except that I don't see spending $10,000 just to get an ESP so
I can put Linux on it and run modems off it (even if they are digital). I
can spend a heck of a lot less, let an ARC run the dial-up and put a
stand-alone Linux box together to perform the rest of those functions...
Now... If EdgeServer PRO's were a tad bit more reasonably priced, say in
the $2,500 range, then we'd start talking about that potential. Still,
the HARC is an excellent dial-up platform and it does what we need it to
for the time being. I'm not much for breaking something that isn't broke.
> Let's hear what you all think about my proposals...and let's hear some
> of your own if you have different ideas. Honest folks, I don't care if
> you don't agree with me, but let's give 3Com a basis for where to go
> with the development of this stuff.
>
>
> --------------------
>
>
> I mentioned earlier that I was going to email the list with some
> thoughts of where I thought the HiPer Arc platform could/should go...
>
> I have a little bit of time now, so maybe I can put some of these
> thoughts down and maybe get some thoughts and discussion from the rest
> of you about feasibility and maybe some other ideas...In any
> case...these ideas are thrown out to maybe get some discussion going to
> help give 3Com an idea of what we, as customers, would like to see out
> of the Arc.
>
> First off...a couple of specific feature requests...I may have mentioned
> these before....if so, my apologies.
>
> 1) Bridging support...both over PPP, and over ethernet interfaces, and
> any other interfaces that are supported (such as the new frame-relay
> ones).
>
> Imagine plugging your two ethernet interfaces into two different
> switches in the same IP network...running spanning-tree between
> them all...then your Arc isn't dependant on its switch being in
> one piece to be able to communicate. Would require the use of a
> "virtual" interface that participated in the bridging code as
> well...similar in some ways to the internal interface that is
> available for use with OSPF now. Basically, assign the IP
> address for the Arc to the virtual interface, the Arc sends
> packets to the virtual interface, when then goes into the
> bridging code to decide which physical interface its sent out.
> This is very similar to Cisco's bridge-groups with their
> integrated routing and bridging for those of you who are
> familiar with that.
>
> 2) Support for a "packet bus interface". This one sounds bizarre...but
> if you think about it for a bit it starts to make sense...if you have
> multiple Arc's in a chassis...why make them communicate out their NIC's
> onto an external network to talk to each other? Some benefits for
> this...
>
> With the first feature....you could have two Arcs, both running
> briding code as well...each with a single ethernet+4t1 NIC and
> support 8 frame-relay t1's, and still retain the dual-exit
> capability described above with briding or routing over the
> packet bus. You could also theoretically have an Arc handling
> modems that has no NIC at all! Modem interfaces come in over
> the packet bus, and that same data is then shipped back out over
> the packet bus interface to another Arc with NIC card. This
> method could also be used as a failover scenario if a NIC card
> failed, or a cable failed, or a switch failed...you get the
> idea.
>
> 3) A larger variety of NIC interfaces. Particularly combined with the
> packet bus interface, this frees you up to have a much greater variety
> of NIC types...the Arc can then use the packet bus interface to get out
> to the ethernet network (via another Arc most likely...either bridged or
> routed), and allowing...oh....8 t1 NICs, or maybe a t3 nic, a
> channelized t3 nic would be really sweet...the sky is the limit here
> once you get the arcs using the packet bus as their ethernet
> interface...
>
> 4) Similar to 3...the DSP cards have a crap-load of processing power in
> them...could they be used for something more than just modems? It
> seems...if you look at it in the abstract...that the DSP cards are
> essentially interface extensions for the Arcs...let's take that
> farther....this would mean basically totally revamping the code for the
> DSP's for the new uses, or perhaps coming out with new code that's more
> generalized. Then, with the possibility of new NICs for the DSP's you
> could, again, extend the interface possibilities for the Arcs.
>
> 5) One that has bugged me for quite some time...PPP support on WAN
> ports. I really don't particularly liked being restricted to
> frame-relay encapsulation only...I can deal with it...but it'd be nice
> to have the option of PPP encap as well. Many low end t1 routers don't
> have frame-relay encap support, and it would be nice to be able to
> interoperate with them.
>
>
> In more abstract terms...I've been told by several 3Com folks that they
> see the Pilgrim/Hiper Arc code as more full routing code rather than
> just code for an Access Server. My understanding is that 3Com is moving
> *all* of their routing products to eventually use the Pilgrim based
> code.
>
> With that thought in mind though...3Com seems (from a customer's
> perspective) to still think of the HiPer Arc, specifically, as an access
> server alone. I think the HiPer Arc and the Total Control platform as a
> whole could become a quite capable router chassis product as a whole.
> Personally speaking...I'd like to see that. In a similar vein...3Com
> seems to think of the DSP cards as big powerful modem cards...and while
> that's certainly a good use for them...let's break that paradigm (oh
> man...a marketing cliche'...my apologies) and see them for more than
> that...what they really are...a crapload of processing power on a card
> that could theoretically, to the best of my knowledge, run just about
> any arbitrary code with just about any arbitrary type of interface on
> the NIC. That's a *very* powerful thought IMO.
>
> Executive summary (I know, this should be at the top)...if you think of
> the Total Control platform basically as a distributed processing router
> platform...lot's of possibilities are opened up going forward. The
> current code on there is getting to be pretty good and solid...but its
> designed and written for a single specific function...limiting the
> places where the TC platform could be used. This largely comes down to
> be a business decision from 3Com (Lord help us there), but if they
> decide that they don't want to limit the TC platform to being *only* an
> access server (and personally, I think the distinction between access
> server and router is a pretty thin line), then they need to start
> thinking of the Arc as a router, not just an access server, and the
> DSP's as generic interface cards, not modem/t1/pri cards.
>
> These thoughts are probably not articulated very well...they're just
> thoughts that I've had in the back of my head for a while that I want to
> get out to some other people to see what you all have to say about the
> ideas. I know some people wouldn't be interested in all at using some
> of the features...but what I'm trying to get at here is the overall
> direction for development of the Arcs/TC's, not specific feature
> requests...although I have included some specific feature requests in my
> message...try not to focus on those specifically...they are mostly there
> as examples for the overall direction I was thinking of. Some of these
> thoughts have been expressed in the past to some people at 3Com, but I
> don't think any one person has ever heard the totality of what I was
> thinking of (not having had time to sit down with anyone for long enough
> time to fully hash these thoughts out).
>
> So...there it is...let's hear what you think. :)
>
> ---------------------------
> --
> Jeff McAdams Email: jeffm@iglou.com
> Head Network Administrator Voice: (502) 966-3848
> IgLou Internet Services (800) 436-4456
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
E-Mail: s1kevin@tims.net
Web: http://users.sota-oh.com/~s1kevin/
Unsolicited advertisements processing fee: $50 subject to change without notice
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
Date: 15 Sep 1999 13:11:25 -0400
Thus spake Kevin Benton
>On Wed, 15 Sep 1999, Jeff Mcadams wrote:
>> 3Com just posted drivers for their NICs for Linux (to be honest, I did a
>> double-take when I saw that, but think its tres cool!), so apparently
>> they are beginning to foster a corporate culture of listening to
>> customers and what they want (and I can't support this idea enough I
>> don't think).
>Great idea except that I don't see spending $10,000 just to get an ESP so
>I can put Linux on it and run modems off it (even if they are digital). I
>can spend a heck of a lot less, let an ARC run the dial-up and put a
>stand-alone Linux box together to perform the rest of those functions...
No, no, no.... :) This was in reference to ethernet NICs for PC...like
3c509's etc. :) No real connection to TC's...just a comment about 3Com
in general. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
Date: 15 Sep 1999 13:33:54 -0400 (EDT)
Again, if I want a router that allow multiple eth or ser ports... I'll but
a cisco. Adding ARC's are expensive and limited compared to multi-slot
eth/ser chassis. A 2e-2w blade for my 3640 is much cheaper than a new ARC
or NIC for a TC (at this point).
Having a dedicated packet bus for connecting chassis may be a step
backward. 3Com *should* fix the multi-chassis MLPPP, not add circuit
traces or cards. USR/3Com has a bad history of supporting new technology
like OSPF (yeah.. thats a joke.. some 3Com humor)
With very high density alternatives like the PM-4, TC needs to do one
thing very well, like answer the phone and route to it.
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Wed, 15 Sep 1999, Jeff Mcadams wrote:
Snip
> router isn't necessarily an access server. :) Basically, the HiPer
> Arc, as an access server, is already doing everything that a router is
> doing...and more...(well...ok...its a router with a rather limited
> feature set at this point, but it *is* a router, nonetheless) it's
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
Date: 15 Sep 1999 13:45:47 -0400
Thus spake Paul Farber
>Again, if I want a router that allow multiple eth or ser ports... I'll but
>a cisco. Adding ARC's are expensive and limited compared to multi-slot
>eth/ser chassis. A 2e-2w blade for my 3640 is much cheaper than a new ARC
>or NIC for a TC (at this point).
Define "much." Last price list I got for cisco equip puts the 2e2w card
at $2500...not much more than a whole Arc NAC/NIC combo. And
besides...I'm not talking about having this within the next year or
so...this is long-term thinking.
>Having a dedicated packet bus for connecting chassis may be a step
>backward.
Who said anything about connecting chassis' together? I'm talking about
letting the Arc's see the packet bus that's already in all of the
chassis' that you own as a network interface to communicate between Arcs
in the same chassis.
>3Com *should* fix the multi-chassis MLPPP, not add circuit
>traces or cards.
What's wrong with multi-chassis MP? Works like a champ for me (once I
got rid of my NETServers).
>USR/3Com has a bad history of supporting new technology like OSPF
>(yeah.. thats a joke.. some 3Com humor)
Which is available and working in 4.2.x...yes it did take a while...but
to 3Com's credit, its there and it looks pretty solid.
>With very high density alternatives like the PM-4, TC needs to do one
>thing very well, like answer the phone and route to it.
Have you looked into buying a PM4 recently? You can't...they've been
discontinued. PM3's will be soon...PM2's will stick around, but...big
deal.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Marcelo Souza <mpsouza@centroin.com.br>
Subject: Re: (usr-tc) HiperARC equivalent of portmaster show line0
Date: 15 Sep 1999 15:22:08 -0300 (EST)
On Wed, 15 Sep 1999, Steve Drees wrote:
|On a portmaster 3 I can issue a show line0 and get a nice table showing
|alarms and violations on the PRI. What's the equivalent command on a
|HiperARC?
At DSP (not HARC) console you can use:
>chdev span
span>disp spns
- Marcelo
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
Date: 15 Sep 1999 14:44:25 -0400 (EDT)
> Define "much." Last price list I got for cisco equip puts the 2e2w card
> at $2500...not much more than a whole Arc NAC/NIC combo. And
> besides...I'm not talking about having this within the next year or
> so...this is long-term thinking.
That's a list price... who pays list price? A 2e-2w blade that can
support 2 T-1's and 2 10Base-T's is cheaper and performs better then the
arc.
I would like the TC chassis to be one hell of an ACCESS SERVER. 3Com has
routers and switches. Let THEM route and switch. Concentrate on answering
the phone and compatibility.
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Martin Lathoud <nytral@enDirect.qc.ca>
Subject: (usr-tc) ARC/quad/NMC compatibility
Date: 15 Sep 1999 15:06:30 -0400 (EDT)
Hi,
in my old TCH, I wonder if replacing the Netserver by an ARC is ok? Will
it be managed by the ol'NMC with no problems? What about Quad/PRI cards
compatibility with the ARC?
Regards,
Martin
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jim Johnson <jim@perigee.net>
Subject: (usr-tc) Default User Validation
Date: 15 Sep 1999 15:54:34 -0400
This might seem like a stupid question, but I am curious, is there a way
to validate a username of default using radius? It would never get sent
to radius since it would match the default user in the local user table.
Jim Johnson
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) ARC/quad/NMC compatibility
Date: 15 Sep 1999 15:25:29 -0400
Thus spake Martin Lathoud
>in my old TCH, I wonder if replacing the Netserver by an ARC is ok? Will
>it be managed by the ol'NMC with no problems? What about Quad/PRI cards
>compatibility with the ARC?
I run a bunch o quads with 5.9.9 and 5.10.9 with no problems with the
Arc.
Just make sure your NMC is the 16 meg (8 meg flash) version with the
appropriate code and you should be fine as far as the nmc being able to
handle the Arc.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) ARC/quad/NMC compatibility
Date: 15 Sep 1999 15:25:29 -0400
Thus spake Martin Lathoud
>in my old TCH, I wonder if replacing the Netserver by an ARC is ok? Will
>it be managed by the ol'NMC with no problems? What about Quad/PRI cards
>compatibility with the ARC?
I run a bunch o quads with 5.9.9 and 5.10.9 with no problems with the
Arc.
Just make sure your NMC is the 16 meg (8 meg flash) version with the
appropriate code and you should be fine as far as the nmc being able to
handle the Arc.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: Re: (usr-tc) HiperARC equivalent of portmaster show line0
Date: 15 Sep 1999 16:18:59 -0400
At 03:22 PM 9/15/99 -0300, you wrote:
> At DSP (not HARC) console you can use:
>
> >chdev span
> span>disp spns
Here's a question; One of the lines shown in
span1>dis spanst is
Span1 Modem Not Available Count is: 7
yet all of the modems on that card appear to be working fine.
Why's that?
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Clint R. Sparks" <csparks@cqc.com>
Subject: (usr-tc) Question on Hiper DSP Code 2.0.81
Date: 15 Sep 1999 15:40:31 -0500
Sometime back I remember seeing a post on the list that stated when using
Hiper DSP code 2.0.81 the LPBK/D-ALM light will stay on green, can anyone
please confirm this for me (we are not using NFAS right now)?
Thank you,
Clint R. Sparks
ComQuest Internet Services
csparks@cqc.com
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) Question on Hiper DSP Code 2.0.81
Date: 15 Sep 1999 16:45:58 -0400
Thus spake Clint R. Sparks
>Sometime back I remember seeing a post on the list that stated when using
>Hiper DSP code 2.0.81 the LPBK/D-ALM light will stay on green, can anyone
>please confirm this for me (we are not using NFAS right now)?
Yes, in 2.0.x, the LPBK/D-ALM light indicates the D-channel state.
Solid green indicates that there is a Primary D channel up on that span.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Clint R. Sparks" <csparks@cqc.com>
Subject: Re: (usr-tc) Question on Hiper DSP Code 2.0.81
Date: 15 Sep 1999 16:10:59 -0500
Thank you for your help and responding so quick.
Clint R. Sparks
ComQuest Internet Services
csparks@cqc.com
> Yes, in 2.0.x, the LPBK/D-ALM light indicates the D-channel state.
> Solid green indicates that there is a Primary D channel up on that span.
> --
> Jeff McAdams Email: jeffm@iglou.com
> Head Network Administrator Voice: (502) 966-3848
> IgLou Internet Services (800) 436-4456
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Scot Desort" <scot@njaccess.net>
Subject: (usr-tc) Weird traceroute problem on TC
Date: 15 Sep 1999 19:54:44 -0400
OK, first let me say that I am too new to the TC platform to have even a
small clue as to what the hell I'm doing.
That being said, here is the situation. Any user dialed into the TC can
traceroute out to any host on the net fine. If that same host tries to
traceroute back, responses make it back all the way to the HARC ethernet
port, then every other packet times out (well, it's the last hop, which is
the client modem).
In "playing" with different settings in the HARC, I _think_ I remember some
CLI command that has something to do with how (or IF) the HARC will allow
traces/pings to client modems.
If _I_ traceroute to the client modem from MY network (on a different subnet
from the HARC) I DO get a complete trace to the client. I can telnet to my
core router and that traces OK also. I temporarily removed all access lists
from my core to the world, in case I flubbed something up there. Nada.
I did implement the fix for the HiperBomb telnet problem mentioned here a
few weeks ago. But other than that, I can't think of anything I may have
done to cause this. I have NO filters enabled in the HARC.
My network with respect to the TC is as follows:
TC---->Cisco Switch----->Cisco 3640----->WORLD
No RIP. Simple static routing.
I stumbled across this situation in trying to troubleshoot my question I
posted a few days ago about IP traffic to client modems momentarily pausing
then re-starting. I had people off-network tracing back, and every single
one could not complete a trace to any connected client modem, yet I can, and
they can trace out. You can try to trace in to 207.202.83.106 and see what I
mean.
Anyone have any ideas? I think I probably touched something I shouldn't have
in HARM or the CLI.
TIA,
Scot
NJaccess
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
Date: 16 Sep 1999 17:31:24 -0400 (EDT)
On Wed, 15 Sep 1999, Paul Farber wrote:
> There are still many issues with the DSP code that need to be resolved...
> ISDN reliability, v.90 compatibility, uptime, off by snmp 1 errors, etc.
> Fix them first!
The off-by-one SNMP errors are finally fixed in the 6.x.x NMC releases --
at least all the off-by-ones that I found.
Never had any uptime problems.
ISDN's OK for us, mostly.
v.90 still needs work. (Be nice if all the Rockwell HCF chips disppeared
off the planet first though.) The Quads work a hell of a lot better for
this -- why are the code bases so different here? If it's all in
assembler I can understand, but if it's in something more portable, I
don't see why they have to behave so differently.
Multilink PPP got real slow in the last DSP releases and needs work again.
The ARC 4.2.x releases have a big problem with handling two routes with
the same network number and different netmasks... (NOT fixed in 4.2.32)
Other than that things seem to be working fine for us. (knock on plastic)
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Igor Brezac" <igor@ipass.net>
Subject: RE: (usr-tc) HiPer Arc improvement thoughts followup :)
Date: 16 Sep 1999 18:04:34 -0400
I'd like to add support for the standard RFC Radius VSAs and reiterate the
improvement of v90 and ISDN code on DSPs.
-Igor
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews
> Sent: Thursday, September 16, 1999 5:31 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
>
>
> On Wed, 15 Sep 1999, Paul Farber wrote:
>
> > There are still many issues with the DSP code that need to
> be resolved...
> > ISDN reliability, v.90 compatibility, uptime, off by snmp 1
> errors, etc.
> > Fix them first!
>
> The off-by-one SNMP errors are finally fixed in the 6.x.x NMC
> releases --
> at least all the off-by-ones that I found.
>
> Never had any uptime problems.
>
> ISDN's OK for us, mostly.
>
> v.90 still needs work. (Be nice if all the Rockwell HCF
> chips disppeared
> off the planet first though.) The Quads work a hell of a lot
> better for
> this -- why are the code bases so different here? If it's all in
> assembler I can understand, but if it's in something more portable, I
> don't see why they have to behave so differently.
>
> Multilink PPP got real slow in the last DSP releases and
> needs work again.
>
> The ARC 4.2.x releases have a big problem with handling two
> routes with
> the same network number and different netmasks... (NOT fixed
> in 4.2.32)
>
> Other than that things seem to be working fine for us.
> (knock on plastic)
>
>
> Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent,
> Frankfort KY
> mandrews@dcr.net -=--=- mandrews@bit0.com -=--=-
http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
Date: 16 Sep 1999 20:46:53 -0400 (EDT)
Thats still of long list of "not quite ready's".
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Thu, 16 Sep 1999, Mike Andrews wrote:
> On Wed, 15 Sep 1999, Paul Farber wrote:
>
> > There are still many issues with the DSP code that need to be resolved...
> > ISDN reliability, v.90 compatibility, uptime, off by snmp 1 errors, etc.
> > Fix them first!
>
> The off-by-one SNMP errors are finally fixed in the 6.x.x NMC releases --
> at least all the off-by-ones that I found.
>
> Never had any uptime problems.
>
> ISDN's OK for us, mostly.
>
> v.90 still needs work. (Be nice if all the Rockwell HCF chips disppeared
> off the planet first though.) The Quads work a hell of a lot better for
> this -- why are the code bases so different here? If it's all in
> assembler I can understand, but if it's in something more portable, I
> don't see why they have to behave so differently.
>
> Multilink PPP got real slow in the last DSP releases and needs work again.
>
> The ARC 4.2.x releases have a big problem with handling two routes with
> the same network number and different netmasks... (NOT fixed in 4.2.32)
>
> Other than that things seem to be working fine for us. (knock on plastic)
>
>
> Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
> mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
> "If you're not part of the solution.... you're part of the precipitate."
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Brian Elfert <brian@citilink.com>
Subject: RE: (usr-tc) HiPer Arc improvement thoughts followup :)
Date: 16 Sep 1999 20:10:46 -0500 (CDT)
On Thu, 16 Sep 1999, Igor Brezac wrote:
> I'd like to add support for the standard RFC Radius VSAs and reiterate the
> improvement of v90 and ISDN code on DSPs.
I've never heard of standard VSAs. VSAs are vendor specific attributes,
so I have no idea how they could be standardized really.
I'm sure there are some attributes the Total Control could support. For
instance, Connect-Rate appears to be a valid attribute not used.
Brian
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Brian Becker" <brian@semo.net>
Subject: (usr-tc) Radius Attribute IP_Pool_Name
Date: 17 Sep 1999 02:53:40 -0500
Reading the docs on the Total Control Radius server (I don't have it but was
just reading how it works), I ran across the ability for RADIUS to select
which ip pool is used when authenticating a user. This would solve a huge
problem.
According to 3com HiPerArc Docs - page E-473
Attributes
61 NAS-Port-Type F,L
62 Port-Limit
63 Login_LAT-Port NS
64 Prompt
.
.
217 Framed-IP-Addr-Pool-Name
250 Char-Noecho
And on page E-445 in the Vendor Specific Attributes it says:
0x9024 IP-Address-Pool
Sets the name of the IP address pool for Framed PPP/SLIP users.
Values: ASCII string. Limit: 16 bytes
User Types: Framed
Packet Types: Access-Accept
Default: None
Use the following global command to set this parameter locally:
add ip pool <pool_name>
I've tried editing my dictionary file (I'm using Livingston v1.16 running a
FreeBSD box) for attribute 217:
ATTRIBUTE Framed-IP-Addr-Pool-Name 217 string
and in my user file I've included the line:
Framed-IP-Addr-Pool-Name = "testippool",
which is the name of a pool. But I'm still getting the an ip from another
pool. I set the pool to private. But still can't get it to use those ips.
Also tried
ATTRIBUTE IP_Pool_Name 0x9024 string
But that hasn't worked either...
Any ideas?
Thanks,
Brian
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jim Johnson <jim@perigee.net>
Subject: (usr-tc) Current Consumption
Date: 17 Sep 1999 09:00:47 -0400
Can someone tell me the current consumption for:
Quad-NAC
Dual-PRI-NIC
Dual-PRI-NAC
Jim
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Robert von Bismarck <rvb@petrel.ch>
Subject: (usr-tc) MPIP performance
Date: 17 Sep 1999 17:46:33 +0200
Hello,
I have been trying unsuccessfully to make a MPIP connection to my TC =
pool
from a cisco 1603 for testing.
The links go up, everything is fine, until I begin a download, =
performance
is bad. I get something between 8KB/s and 10KB/s, while I get about 7 =
to
8KB/s with an ISDN TA hooked up to my PC.
Oh, yeah, we have 64k ISDN here, not some funky US-specific 56k stuff =
;-)=20
Here's the setup
I have 6 HiperARC's that are clients and one HiperARC that is server
Clients are : 111.222.333.1, 111.222.333.2, 111.222.333.3, =
111.222.333.4
111.222.333.5, 111.222.333.6
Server is : 111.222.333.10
The clients are set up like this :
Add mpip server 111.222.333.10 sharedsecret secret
Set mpip client_state on
Set mpip server_state off
Set ntp primary_server ntp.server.ip.address
The server is set up like this :
Add mpip client 111.222.333.1 sharedsecret secret
Add mpip client 111.222.333.2 sharedsecret secret
Add mpip client 111.222.333.3 sharedsecret secret
Add mpip client 111.222.333.4 sharedsecret secret
Add mpip client 111.222.333.5 sharedsecret secret
Add mpip client 111.222.333.6 sharedsecret secret
Set mpip server_state on
Set mpip client_state off
Set ntp primary_server ntp.server.ip.address
Everything goes through a 10/100Mb Switch (Cisco Catalyst 2924XL) and
default router for all those boards is a Cisco 7206 on the same subnet.
Robert von BISMARCK
Systems Engineer
_________________________
SPAN* / Petrel Communications SA=20
T=E9l : + 41 22 304 47 47
Fax : + 41 21 304 47 99
e-mail : rvb@petrel.ch
Web : http://ww.span.ch/
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike Wronski" <mike@coredump.ae.usr.com>
Subject: RE: (usr-tc) Radius Attribute IP_Pool_Name
Date: 17 Sep 1999 11:29:00 -0500
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Becker
|Sent: Friday, September 17, 1999 2:54 AM
|To: usr-tc@lists.xmission.com
|Subject: (usr-tc) Radius Attribute IP_Pool_Name
|
|
|Reading the docs on the Total Control Radius server (I don't have it but was
|just reading how it works), I ran across the ability for RADIUS to select
|which ip pool is used when authenticating a user. This would solve a huge
|problem.
|
|According to 3com HiPerArc Docs - page E-473
|Attributes
|61 NAS-Port-Type F,L
|62 Port-Limit
|63 Login_LAT-Port NS
|64 Prompt
|.
|.
|217 Framed-IP-Addr-Pool-Name
|250 Char-Noecho
|
|
|And on page E-445 in the Vendor Specific Attributes it says:
|0x9024 IP-Address-Pool
|Sets the name of the IP address pool for Framed PPP/SLIP users.
|Values: ASCII string. Limit: 16 bytes
|User Types: Framed
|Packet Types: Access-Accept
|Default: None
|Use the following global command to set this parameter locally:
|add ip pool <pool_name>
|
|I've tried editing my dictionary file (I'm using Livingston v1.16 running a
|FreeBSD box) for attribute 217:
|
|ATTRIBUTE Framed-IP-Addr-Pool-Name 217 string
|
|and in my user file I've included the line:
|Framed-IP-Addr-Pool-Name = "testippool",
|
|which is the name of a pool. But I'm still getting the an ip from another
|pool. I set the pool to private. But still can't get it to use those ips.
217 Is an ascend attribute. The HARC will accept (some of) these in the 4.2.x
code base. See the docs for a more complete list.
|Also tried
|ATTRIBUTE IP_Pool_Name 0x9024 string
|
The above will work with any HARC code. But your 1.1.6 Radius does not support
3com VSA's.
-M
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) MPIP performance
Date: 17 Sep 1999 12:34:59 -0400
Thus spake Robert von Bismarck
>I have been trying unsuccessfully to make a MPIP connection to my TC pool
>from a cisco 1603 for testing.
>The links go up, everything is fine, until I begin a download, performance
>is bad. I get something between 8KB/s and 10KB/s, while I get about 7 to
>8KB/s with an ISDN TA hooked up to my PC.
Hrmm...sounds like you're occasionally getting MP (note, not MPIP, MPIP
is the protocol used between the TC's to coordinate MP bundling), and
occasionally not. 10KB/s, while not fantastic, is in the range of
bundled traffic.
>The server is set up like this :
>Add mpip client 111.222.333.1 sharedsecret secret
>Add mpip client 111.222.333.2 sharedsecret secret
>Add mpip client 111.222.333.3 sharedsecret secret
>Add mpip client 111.222.333.4 sharedsecret secret
>Add mpip client 111.222.333.5 sharedsecret secret
>Add mpip client 111.222.333.6 sharedsecret secret
>Set mpip server_state on
>Set mpip client_state off
>Set ntp primary_server ntp.server.ip.address
Not sure if its the cause of your problems, but the MPIP server needs to
be set up as a client of itself, so you need another add mpip client
statement in there with the server's own IP address.
>Everything goes through a 10/100Mb Switch (Cisco Catalyst 2924XL) and
>default router for all those boards is a Cisco 7206 on the same subnet.
Unless there's a problem with something other than the bundling, this
really shouldn't matter. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jim Johnson <jim@perigee.net>
Subject: (usr-tc) TC Routing Question
Date: 17 Sep 1999 14:45:10 -0400
Several ARCs are set up in a single /22 network (CIDR block of 1024
addresses).
Dialup IP Address pools are out of this block and the ARC's ethernet
ports are also in this block.
Now, if I want to set up an account in radius which can route a /28
block, can I use a /28 block out of this /22 block?
When I tried it from the same block and the route showed up in the ARC
correctly, but the traffic was not routing down the connection for some
reason.
Radius - Entry is like:
test Password=route, Simultaneous-Use=1
Framed-IP-Address=xxx.xxx.62.3,
Framed-Route="xxx.xxx.63.8/30 xxx.xxx.62.3 1"
Relevant Pieces of the ARC's routing table:
0.0.0.0/0 NetMgr xxx.xxx.60.1 1 eth:1
127.0.0.1/H LOCAL 127.0.0.1 1 loopback
xxx.xxx.60.0/22 LOCAL xxx.xxx.60.6 1 eth:1
xxx.xxx.60.6/H LOCAL xxx.xxx.60.6 1 eth:1
xxx.xxx.62.3/H LOCAL xxx.xxx.62.3 1 slot:14/mod:18
xxx.xxx.63.8/30 NetMgr xxx.xxx.62.3 1 slot:14/mod:18
xxx.xxx.63.255/H LOCAL xxx.xxx.63.255 1 eth:1
It seems that it should be able to work. If not, I guess I'll just have
to get a completely different network block and break it up for the
routed network.
Thanks,
Jim
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) TC Routing Question
Date: 17 Sep 1999 15:02:08 -0400
Thus spake Jim Johnson
>Several ARCs are set up in a single /22 network (CIDR block of 1024
>addresses).
>Dialup IP Address pools are out of this block and the ARC's ethernet
>ports are also in this block.
>Now, if I want to set up an account in radius which can route a /28
>block, can I use a /28 block out of this /22 block?
Hrmm...you're wanting to depend on proxy arp to take care of this for
you then?
Not sure specifically how this works, but try:
enable ip proxy_arp_all_dialin
and see if that does what you need. If not, you'll need to use some
sort of active routing protocol (RIPv2 or newly available OSPF). The
active routing protocol is the cleaner solution IMHO (I'm not a terribly
big fan of proxy arp), but is a bit harder on the systems. FWIW, you
shouldn't have to grab a block from outside the /22 just because you're
using active routing...should be able to use the block inside the /22
with active routing just fine.
>When I tried it from the same block and the route showed up in the ARC
>correctly, but the traffic was not routing down the connection for some
>reason.
Because it never got to the Arc to be routed down the connection. Your
next hop router assumed, since the route wasn't advertised via some
active routing protocol, that the ip addresses within the /28 were local
to the ethernet (based on its interface ip address and mask), sent out
an arp request for the ip address it was trying to get to, but the Arc
didn't know to proxy arp for it.
>It seems that it should be able to work. If not, I guess I'll just have
>to get a completely different network block and break it up for the
>routed network.
I think you should be able to get this to work.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: (usr-tc) HiperARC/DSP console setup redux
Date: 17 Sep 1999 14:42:52 -0500
Hi--
I've still got one DSP card that refuses to grant me a console; there is
just a squeegum of doubt as to whether it was rebooted after upgrade to
2.0.81, but, I do notice one difference between it and the other DSP's; the
Hardware rev level is 0.49, vs. my others that are at 0.53 and 0.54.
Could the hardware rev have anything to do with anything?
I've got exactly 1 other .49 rev level DSP, but...it's in a chassis with a
Netserver so no help there....
12 YES 24 Channel High Density Modem 24 DYNAMIC YES
13 YES 24 Channel High Density Modem 24 DYNAMIC NO
14 YES 24 Channel High Density Modem 24 DYNAMIC YES
15 YES 24 Channel High Density Modem 24 DYNAMIC YES
Slot 13 is the one I'm concerned about.
Upgrading from 2.0.19 to 2.0.81 DID fix the DSP in slot 15, and I am quite
happily using the console feature now--
Anybody know?
Scott Trautman 608-240-4638,4637fax
Global Dialog Internet www.gdinet.com
2810 Crossroads, STE LL2
Madison WI 53718
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Igor Brezac" <igor@ipass.net>
Subject: RE: (usr-tc) HiPer Arc improvement thoughts followup :)
Date: 17 Sep 1999 15:53:37 -0400
> I've never heard of standard VSAs. VSAs are vendor specific
> attributes,
> so I have no idea how they could be standardized really.
>
Read http://www.cis.ohio-state.edu/htbin/rfc/rfc2138.html.
There are many vendors who conform to RFC style VSAs: Livingston, RedBack,
even Ascend has an option for VSAs, just to name a few. There are some
features specific to ARC which should be configurable via radius.
-Igor
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jim Johnson <jim@perigee.net>
Subject: Re: (usr-tc) TC Routing Question
Date: 17 Sep 1999 15:46:38 -0400
Thanks for the quick reply.
I was going to add a static route to the router once I got it working
rather than turn on RIP.
But the thing that is confusing me is that I was telnetted into the ARC
and trying to ping or traceroute to an IP on the routed network block
and it was not working. That seemed like am easy way to test it.
Oh well, I added the static route to the router now and now traffic is
dying the ARC board even from the outside. So I am still doing
something wrong here.
Does this have an effect on Framed-Routes?
ENABLE IP SOURCE_ADDRESS_FILTER
Jim
Jeff Mcadams wrote:
>
> Thus spake Jim Johnson
> >Several ARCs are set up in a single /22 network (CIDR block of 1024
> >addresses).
>
> >Dialup IP Address pools are out of this block and the ARC's ethernet
> >ports are also in this block.
>
> >Now, if I want to set up an account in radius which can route a /28
> >block, can I use a /28 block out of this /22 block?
>
> Hrmm...you're wanting to depend on proxy arp to take care of this for
> you then?
>
> Not sure specifically how this works, but try:
> enable ip proxy_arp_all_dialin
> and see if that does what you need. If not, you'll need to use some
> sort of active routing protocol (RIPv2 or newly available OSPF). The
> active routing protocol is the cleaner solution IMHO (I'm not a terribly
> big fan of proxy arp), but is a bit harder on the systems. FWIW, you
> shouldn't have to grab a block from outside the /22 just because you're
> using active routing...should be able to use the block inside the /22
> with active routing just fine.
>
> >When I tried it from the same block and the route showed up in the ARC
> >correctly, but the traffic was not routing down the connection for some
> >reason.
>
> Because it never got to the Arc to be routed down the connection. Your
> next hop router assumed, since the route wasn't advertised via some
> active routing protocol, that the ip addresses within the /28 were local
> to the ethernet (based on its interface ip address and mask), sent out
> an arp request for the ip address it was trying to get to, but the Arc
> didn't know to proxy arp for it.
>
> >It seems that it should be able to work. If not, I guess I'll just have
> >to get a completely different network block and break it up for the
> >routed network.
>
> I think you should be able to get this to work.
> --
> Jeff McAdams Email: jeffm@iglou.com
> Head Network Administrator Voice: (502) 966-3848
> IgLou Internet Services (800) 436-4456
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Brian Elfert <brian@citilink.com>
Subject: RE: (usr-tc) HiPer Arc improvement thoughts followup :)
Date: 17 Sep 1999 15:13:32 -0500 (CDT)
On Fri, 17 Sep 1999, Igor Brezac wrote:
> > I've never heard of standard VSAs. VSAs are vendor specific
> > attributes,
> > so I have no idea how they could be standardized really.
>
> Read http://www.cis.ohio-state.edu/htbin/rfc/rfc2138.html.
> There are many vendors who conform to RFC style VSAs: Livingston, RedBack,
> even Ascend has an option for VSAs, just to name a few. There are some
> features specific to ARC which should be configurable via radius.
I guess I was confused. You want the format of the VSA to be
standardized, not the VSAs themselves. I thought you wanted every product
to output the exact same set of VSAs.
Brian
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) TC Routing Question
Date: 17 Sep 1999 16:28:33 -0400 (EDT)
On Fri, 17 Sep 1999, Jim Johnson wrote:
> Does this have an effect on Framed-Routes?
>
> ENABLE IP SOURCE_ADDRESS_FILTER
Yes -- it makes 'em break, from what I've read. Don't use source address
filtering with customers getting subnets routed to them. You could
try disabling it on those users via Radius (there's a VSA for it, I
forget which one now).
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) TC Routing Question
Date: 17 Sep 1999 15:33:34 -0500
Interestingly enough I DID have it enabled and all but one of my customers
with routed subnets have been just fine; one on a compatible systems router
jus wouldna work until I turned it off. Shrug.
SMT
-----Original Message-----
Sent: Friday, September 17, 1999 3:29 PM
On Fri, 17 Sep 1999, Jim Johnson wrote:
> Does this have an effect on Framed-Routes?
>
> ENABLE IP SOURCE_ADDRESS_FILTER
Yes -- it makes 'em break, from what I've read. Don't use source address
filtering with customers getting subnets routed to them. You could
try disabling it on those users via Radius (there's a VSA for it, I
forget which one now).
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: (usr-tc) Filtering telnet access on HiPer ARC
Date: 17 Sep 1999 16:02:41 -0500
Hello all,
I would like to filter telnet access to the HiPer ARC cards on several of my
TC chassis. I have an example filter that does not appear work and is giving
me a "anonymous protocol" message when I attempt to verify the filter.
Example filter where 10.0.0.2/32 is the one machine which is allowed telnet
access to the ARC and 10.1.1.1 is the address of the ARC itself.
#filter
:IP
010 AND src-addr = 10.0.0.2/32;
011 AND dst-addr = 10.1.1.1/32;
012 ACCEPT tcp-dst-port = 23;
020 AND dst-addr = 10.1.1.1/32;
021 DENY tcp-dst-port = 23;
030 ACCEPT;
Any obvious problems with this? I have similar filters working on all of my
other equipment, I just don't know what the anonymous protocol message is
trying to tell me and I can't seem to find any mention of it in any of the
release notes or documentation. Running the latest HiperARC code, 4.2.??
Any suggestions would be appreciated, it is Friday and my brain is starting
to shut down for the weekend :)
Mike McHenry
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jim Johnson <jim@perigee.net>
Subject: Re: (usr-tc) TC Routing Question
Date: 17 Sep 1999 17:06:55 -0400
Hmmmm.
DISABLE IP SOURCE_ADDRESS_FILTER
The routing started working perfectly. Ummm, maybe I don't understand
what that setting does. Is that behavior broken?
Jim
Scott Trautman wrote:
>
> Interestingly enough I DID have it enabled and all but one of my customers
> with routed subnets have been just fine; one on a compatible systems router
> jus wouldna work until I turned it off. Shrug.
>
> SMT
>
> -----Original Message-----
> From: Mike Andrews [mailto:mandrews@bit0.com]
> Sent: Friday, September 17, 1999 3:29 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) TC Routing Question
>
> On Fri, 17 Sep 1999, Jim Johnson wrote:
>
> > Does this have an effect on Framed-Routes?
> >
> > ENABLE IP SOURCE_ADDRESS_FILTER
>
> Yes -- it makes 'em break, from what I've read. Don't use source address
> filtering with customers getting subnets routed to them. You could
> try disabling it on those users via Radius (there's a VSA for it, I
> forget which one now).
>
> Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
> mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
> "If you're not part of the solution.... you're part of the precipitate."
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: Re: (usr-tc) HiperARC/DSP console setup redux
Date: 17 Sep 1999 17:55:01 -0400
At 02:42 PM 9/17/99 -0500, Scott Trautman <scottt@corp.gdinet.com> wrote:
>Hi--
>
>I've still got one DSP card that refuses to grant me a console; there is
>just a squeegum of doubt as to whether it was rebooted after upgrade to
>2.0.81, but, I do notice one difference between it and the other DSP's; the
>Hardware rev level is 0.49, vs. my others that are at 0.53 and 0.54.
>
>Could the hardware rev have anything to do with anything?
>
>I've got exactly 1 other .49 rev level DSP, but...it's in a chassis with a
>Netserver so no help there....
>
>12 YES 24 Channel High Density Modem 24 DYNAMIC YES
>13 YES 24 Channel High Density Modem 24 DYNAMIC NO
>14 YES 24 Channel High Density Modem 24 DYNAMIC YES
>15 YES 24 Channel High Density Modem 24 DYNAMIC YES
I've got the opposite situation, I need 1 card changed to DYNAMIC(although
I'm not sure what the difference does). All of mine are set NO to console.
Should they be set to YES?
1 YES 24 Channel High Density Modem 23 DYNAMIC NO
2 YES 24 Channel High Density Modem 23 DYNAMIC NO
3 YES 24 Channel High Density Modem 23 STATIC NO
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) HiperARC/DSP console setup redux
Date: 17 Sep 1999 17:08:41 -0500
Dynamic is a function of a nmc_chassis awareness setting--
If not dynamic, you would have had to specify the type card in a given slot.
With it on, it'll figur' it out all by itself.
Console, the upgrade to 2.0.81 from 2.0.19 changed "no" to "yes" in all but
this one case.
Being able to get a console session without plugging in a physical console
cable is pretty nifty.
I'm running out of pm2 ports...:)
SMT
> -----Original Message-----
> From: K Mitchell [mailto:mitch@keyconn.net]
> Sent: Friday, September 17, 1999 4:55 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) HiperARC/DSP console setup redux
>
>
> At 02:42 PM 9/17/99 -0500, Scott Trautman
> <scottt@corp.gdinet.com> wrote:
> >Hi--
> >
> >I've still got one DSP card that refuses to grant me a
> console; there is
> >just a squeegum of doubt as to whether it was rebooted after
> upgrade to
> >2.0.81, but, I do notice one difference between it and the
> other DSP's; the
> >Hardware rev level is 0.49, vs. my others that are at 0.53 and 0.54.
> >
> >Could the hardware rev have anything to do with anything?
> >
> >I've got exactly 1 other .49 rev level DSP, but...it's in a
> chassis with a
> >Netserver so no help there....
> >
> >12 YES 24 Channel High Density Modem 24
> DYNAMIC YES
> >13 YES 24 Channel High Density Modem 24
> DYNAMIC NO
> >14 YES 24 Channel High Density Modem 24
> DYNAMIC YES
> >15 YES 24 Channel High Density Modem 24
> DYNAMIC YES
>
> I've got the opposite situation, I need 1 card changed to
> DYNAMIC(although
> I'm not sure what the difference does). All of mine are set
> NO to console.
> Should they be set to YES?
> 1 YES 24 Channel High Density Modem 23
> DYNAMIC NO
> 2 YES 24 Channel High Density Modem 23
> DYNAMIC NO
> 3 YES 24 Channel High Density Modem 23
> STATIC NO
>
> --
> Kirk Mitchell-General Manager mitch@keyconn.net
> Keystone Connect Unlock Your World
> Altoona, PA 814-941-5000 http://www.keyconn.net
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: (usr-tc) RE: Filtering telnet access on HiPer ARC
Date: 17 Sep 1999 17:21:31 -0500
Ack, call me stupid and laugh, it is definately time to go home and sleep...
For any interested parties the problem is :IP needs to be IP: in the filter
rules...
Mike McHenry
-----Original Message-----
Sent: Friday, September 17, 1999 4:03 PM
Hello all,
I would like to filter telnet access to the HiPer ARC cards on several of my
TC chassis. I have an example filter that does not appear work and is giving
me a "anonymous protocol" message when I attempt to verify the filter.
Example filter where 10.0.0.2/32 is the one machine which is allowed telnet
access to the ARC and 10.1.1.1 is the address of the ARC itself.
#filter
:IP
010 AND src-addr = 10.0.0.2/32;
011 AND dst-addr = 10.1.1.1/32;
012 ACCEPT tcp-dst-port = 23;
020 AND dst-addr = 10.1.1.1/32;
021 DENY tcp-dst-port = 23;
030 ACCEPT;
Any obvious problems with this? I have similar filters working on all of my
other equipment, I just don't know what the anonymous protocol message is
trying to tell me and I can't seem to find any mention of it in any of the
release notes or documentation. Running the latest HiperARC code, 4.2.??
Any suggestions would be appreciated, it is Friday and my brain is starting
to shut down for the weekend :)
Mike McHenry
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: RE: (usr-tc) HiperARC/DSP console setup redux
Date: 17 Sep 1999 18:32:52 -0400
At 05:08 PM 9/17/99 -0500, you wrote:
>Dynamic is a function of a nmc_chassis awareness setting--
>If not dynamic, you would have had to specify the type card in a given slot.
>With it on, it'll figur' it out all by itself.
Chassis awareness is on, shouldn't all of the cards match then, instead of
one showing STATIC?
Thanks,
Kirk
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) HiperARC/DSP console setup redux
Date: 17 Sep 1999 18:54:21 -0400
Thus spake K Mitchell
>At 05:08 PM 9/17/99 -0500, you wrote:
>>Dynamic is a function of a nmc_chassis awareness setting--
>>If not dynamic, you would have had to specify the type card in a given slot.
>>With it on, it'll figur' it out all by itself.
>Chassis awareness is on, shouldn't all of the cards match then, instead of
>one showing STATIC?
Static assignments override chassis awareness.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: Re: (usr-tc) HiperARC/DSP console setup redux
Date: 17 Sep 1999 19:06:10 -0400
At 06:54 PM 9/17/99 -0400, Jeff wrote:
>Thus spake K Mitchell
>
>>Chassis awareness is on, shouldn't all of the cards match then, instead of
>>one showing STATIC?
>
>Static assignments override chassis awareness.
How do I undo the static assignment? Also, how do I set the cards to
Console: YES?
Thanks,
Kirk
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) HiperARC/DSP console setup redux
Date: 17 Sep 1999 19:47:33 -0400
Thus spake K Mitchell
>At 06:54 PM 9/17/99 -0400, Jeff wrote:
>>Thus spake K Mitchell
>>>Chassis awareness is on, shouldn't all of the cards match then, instead of
>>>one showing STATIC?
>>Static assignments override chassis awareness.
>How do I undo the static assignment? Also, how do I set the cards to
>Console: YES?
Not sure about the console part as I'm still using 1.2.x code, but the
static assignment is undone by:
set chassis slot x owner no
Then if you have chassis_awareness disabled from the NMC, it'll pick up
ownership as dynamic (should...may not happen right away).
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) HiperARC/DSP console setup redux
Date: 17 Sep 1999 20:59:50 -0400 (EDT)
On Fri, 17 Sep 1999, K Mitchell wrote:
> Also, how do I set the cards to Console: YES?
set chas slot xx cons yes
I think you have to be on static assignment for this to work, though.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: Re: (usr-tc) HiperARC/DSP console setup redux
Date: 17 Sep 1999 21:03:19 -0400
At 07:47 PM 9/17/99 -0400, Jeff wrote:
>>How do I undo the static assignment? Also, how do I set the cards to
>>Console: YES?
>
>Not sure about the console part as I'm still using 1.2.x code, but the
>static assignment is undone by:
>set chassis slot x owner no
I'm still running 1.2.x also, BTW is 1.2.5 newer or 1.2.60? With 3Com's
version numbering scheme, I'm not sure.
>Then if you have chassis_awareness disabled from the NMC, it'll pick up
>ownership as dynamic (should...may not happen right away).
Once the change shows, I'd take ownership back?
Thanks,
Kirk
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) HiperARC/DSP console setup redux
Date: 17 Sep 1999 21:32:06 -0400 (EDT)
On Fri, 17 Sep 1999, K Mitchell wrote:
> At 07:47 PM 9/17/99 -0400, Jeff wrote:
> >>How do I undo the static assignment? Also, how do I set the cards to
> >>Console: YES?
> >
> >Not sure about the console part as I'm still using 1.2.x code, but the
> >static assignment is undone by:
> >set chassis slot x owner no
>
> I'm still running 1.2.x also, BTW is 1.2.5 newer or 1.2.60? With 3Com's
> version numbering scheme, I'm not sure.
1.2.x code doesn't support the remote console thing anyway, you need 2.x
for that... so the console setting is kinda useless there.
From oldest to newest:
1.2.5 (oldest)
1.2.68
1.2.60
1.2.59
1.2.43
1.2.37 (newest before 2.x)
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) HiperARC/DSP console setup redux
Date: 17 Sep 1999 21:39:04 -0400
Thus spake K Mitchell
>At 07:47 PM 9/17/99 -0400, Jeff wrote:
>I'm still running 1.2.x also, BTW is 1.2.5 newer or 1.2.60? With 3Com's
>version numbering scheme, I'm not sure.
As Mike mentioned, 1.2.5 is the oldest...not so's you'd know it from the
numbering.
>>Then if you have chassis_awareness disabled from the NMC, it'll pick up
>>ownership as dynamic (should...may not happen right away).
>Once the change shows, I'd take ownership back?
Well...you *can*, but that kinda defeats the purpuse. :) Once the
change shows, it would be just as if the Arc had ownership...actually it
*does* have ownership...just assigned by the NMC rather than assigned
manually by you the admin. Once the change shows, all the requesite
interfaces should be up.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: Re: (usr-tc) HiperARC/DSP console setup redux
Date: 17 Sep 1999 21:44:20 -0400
At 09:39 PM 9/17/99 -0400, Jeff wrote:
>Thus spake K Mitchell
>>At 07:47 PM 9/17/99 -0400, Jeff wrote:
>>I'm still running 1.2.x also, BTW is 1.2.5 newer or 1.2.60? With 3Com's
>>version numbering scheme, I'm not sure.
>
>As Mike mentioned, 1.2.5 is the oldest...not so's you'd know it from the
>numbering.
>
>>>Then if you have chassis_awareness disabled from the NMC, it'll pick up
>>>ownership as dynamic (should...may not happen right away).
>
>>Once the change shows, I'd take ownership back?
>
>Well...you *can*, but that kinda defeats the purpuse. :) Once the
>change shows, it would be just as if the Arc had ownership...actually it
>*does* have ownership...just assigned by the NMC rather than assigned
>manually by you the admin. Once the change shows, all the requesite
>interfaces should be up.
Slot Owner Description Ports Type Console
1 YES 24 Channel High Density Modem 23 DYNAMIC NO
2 YES 24 Channel High Density Modem 23 DYNAMIC NO
3 NO 24 Channel High Density Modem 23 STATIC NO
So I should be setting ownership of 1 and 2 to no also then?
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Aaron Nabil <nabil@spiritone.com>
Subject: Re: (usr-tc) MPIP performance
Date: 18 Sep 1999 05:17:53 -0700 (PDT)
Jeff Mcadams writes...
>Not sure if its the cause of your problems, but the MPIP server needs to
>be set up as a client of itself, so you need another add mpip client
>statement in there with the server's own IP address.
My MPIP server is not a client of itself, and it works fine.
--
Aaron Nabil
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) Packet filtering strategies/netbus et al
Date: 18 Sep 1999 10:48:20 -0500
Well, don't know about that "supports netserver syntax" as it didn't seem to
work for me,
but, I did get the filters to work just fine with the latest HiperARC
Manager and new ARC code. The old ARC manager was a problem with filters.
The ARC filters are actually pretty nifty and a lot more flexible than the
familiar Netserver/Livingston variety. The AND to do port ranges saves a lot
of tedium.
For all like me that struggled some with all this, a couple notes:
Might be all too obvious for many, but here you go anyway--
Most, I would assume, will want to apply filters per RADIUS authenticated
dialup user, rather than the examples they give in the ARC pdf manual about
interfaces and local ARC users.
RADIUS user filter entry:
Framed-Filter = "myfilter"
You must then have both a "myfilter.in" and a "myfilter.out" on your ARC.
The out generally is just a permit/accept is all, but it has to be there.
The .in and .out is assumed by the ARC to the Framed-Filter as was on the
Netserver. IE, having a filter on the arc of the name "myfilter" won't do
anything for you.
To turn on filter access, you'll need to, at the arc:
set modem_group all filter_access on
If you don't have the filters on the ARC that are being applied (in this
example, myfilter.in, out), your users will not be able to get online at
all. They'll be dropped right after authentication.
modem_group all as in all your interfaces.
I also used the
verify filter myfilter.in
Command on the ARC to get feedback about any errors I had as I edited. Used
the ARC Manager to edit them.
Chapter 12 in the latest ARC documentation is pretty decent on how the
filters work and has enough examples to get you going.
Also note that during testing I was trying to view a connection with "sh int
slot:x/mod:y", and it does not indicate an Input or Output filter, but there
definately is one there as determined by testing. It does show "Filter
Access: ON" after doing the set modem_group....command.
That's my little filtering brain dump. Wasn't that bad once I got over the
dread of doing it.
SMT
> -----Original Message-----
> From: Aaron Nabil [mailto:nabil@spiritone.com]
> Sent: Wednesday, September 01, 1999 3:37 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
>
>
> Scott Trautman writes...
> >..and finally...anyone doing a lot with the ARC filters?
> Anyone interested
> >in making some bucks converting a couple Netserver filters
> to an ARC filter?
>
> Easy money, considering the ARC supports netserver syntax filters.
>
>
> --
> Aaron Nabil>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: <pferraro@wna-linknet.com>
Subject: (usr-tc) FAILED Realm processing error...
Date: 18 Sep 1999 12:19:52 -0400 (EDT)
Does anyone know what this mans EXACTLY? We have seen a couple
of our users get this and it also makes the radiusd dump core. I have no
idea how to check out a radiusd.core file. THe radius we are using is
MERIT 3.6B Any help or comments appreciated!
==============================================================================
Phillip Ferraro WorldNet Access, Inc
pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
Voice (910) 346-0835 824 Gumbranch Square, Suite R3
FAX (910) 455-1933 Jacksonville, Nc 28540-6269
==============================================================================
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: (usr-tc) SNMP challenge: ARC username from IP address
Date: 18 Sep 1999 15:29:35 -0400 (EDT)
OK, got a little challenge for you all. :)
On a HiPer ARC... Given a dialup user's IP address, find their username.
As fast as possible. (Think CGI here.)
I've had code to do this, but it is slow, and it broke on ARC release
4.2.x... forcing me to use an even slower method. :p I'd like to speed
it up.
The best I can do right now is two snmpwalks, followed by a single
snmpget. I'd like to get rid of the snmpwalks, but for some reason the
ARC will not let you directly snmpget some variables -- you have to walk
the whole table it's contained in. (And this got worse in 4.2.x. A bug,
I would think.)
Can anyone get it down to just snmpgets?
(3Com?)
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 18 Sep 1999 15:46:30 -0400 (EDT)
Quickest way would be to telnet into the ARC.. and snmp solution would
involve interating through the entite OID tree till you got a match.
An expect scrript or perl script would be much quicker. Just do telnet
in, do a sho ip networks and grep the results.
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Sat, 18 Sep 1999, Mike Andrews wrote:
> OK, got a little challenge for you all. :)
>
> On a HiPer ARC... Given a dialup user's IP address, find their username.
> As fast as possible. (Think CGI here.)
>
> I've had code to do this, but it is slow, and it broke on ARC release
> 4.2.x... forcing me to use an even slower method. :p I'd like to speed
> it up.
>
> The best I can do right now is two snmpwalks, followed by a single
> snmpget. I'd like to get rid of the snmpwalks, but for some reason the
> ARC will not let you directly snmpget some variables -- you have to walk
> the whole table it's contained in. (And this got worse in 4.2.x. A bug,
> I would think.)
>
> Can anyone get it down to just snmpgets?
>
> (3Com?)
>
>
>
> Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
> mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
> "If you're not part of the solution.... you're part of the precipitate."
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 18 Sep 1999 20:44:32 -0400
Thus spake Mike Andrews
>OK, got a little challenge for you all. :)
>On a HiPer ARC... Given a dialup user's IP address, find their username.
>As fast as possible. (Think CGI here.)
OK...given my knowledge of the hiperarc.mib and snmp (both of which
aren't terribly complete). The quickest executing way of doing this
would be to snmpwalk usrCipPortIndex (Index'es tend to return
considerably faster than when you're actually pulling data), then do
gets (so you can have multiple OIDs in one request...again...faster than
a ping pong walk) on usrCipPortIpAddress.xxxx with "xxxx" being filled
in with the index values that you collected from the walk. When you
find the IP address you need, then you can just do a get on
usrCipUserName.xxxx, with "xxxx" this time being the specific index
found from the PortIpAddress. Sorta two walks...but one can be
implemented as a few gets which will go faster than ping-ponging the
walk if you're really pressed for speed.
Not sure how some of the perl modules deal with it, but it seems to me,
that theoretically you could put multiple getnext requests in an
individual SNMP packet to an agent. You would have to have the
application have the intelligence to do this, but perhaps some of the
perl modules do this? I haven't checked into them enough to know. If
they do...you could grab all the information that you need with,
essentially, a single walk...just a single walk with multiple SNMP
getnext requests.
>I've had code to do this, but it is slow, and it broke on ARC release
>4.2.x... forcing me to use an even slower method. :p I'd like to speed
>it up.
>The best I can do right now is two snmpwalks, followed by a single
>snmpget.
I suspect we're kinda thinkin' of the same way then...maybe I've given
you some hints on how you can actually code it (I know...makes the code
considerably more complex...but I think the SNMP ops will be
considerably quicker) that will help out.
>I'd like to get rid of the snmpwalks, but for some reason the
>ARC will not let you directly snmpget some variables -- you have to walk
>the whole table it's contained in. (And this got worse in 4.2.x. A bug,
>I would think.)
Eh? Like what?
>Can anyone get it down to just snmpgets?
Uhm...don't know that I can cleanly. I might be able to come up with a
kludge way to do it though. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Kevin Benton <s1kevin@tims.net>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 18 Sep 1999 22:40:28 -0400 (EDT)
On Sat, 18 Sep 1999, Jeff Mcadams wrote:
> >On a HiPer ARC... Given a dialup user's IP address, find their username.
> >As fast as possible. (Think CGI here.)
>
> OK...given my knowledge of the hiperarc.mib and snmp (both of which
> aren't terribly complete). The quickest executing way of doing this
> would be to snmpwalk usrCipPortIndex (Index'es tend to return
> considerably faster than when you're actually pulling data), then do
> gets (so you can have multiple OIDs in one request...again...faster than
> a ping pong walk) on usrCipPortIpAddress.xxxx with "xxxx" being filled
> in with the index values that you collected from the walk. When you
> find the IP address you need, then you can just do a get on
> usrCipUserName.xxxx, with "xxxx" this time being the specific index
> found from the PortIpAddress. Sorta two walks...but one can be
> implemented as a few gets which will go faster than ping-ponging the
> walk if you're really pressed for speed.
(rest deleted)
Can you give an example in code? (shell scripts?)
Actually, we do it by using an expect script to telnet to the host and get
the results back usually within 3-5 seconds no matter how many users are
logged on. Of course, it's up to you to parse out what you need vs what
you don't need...
Kevin
E-Mail: s1kevin@tims.net
Web: http://users.sota-oh.com/~s1kevin/
Unsolicited advertisements processing fee: $50 subject to change without notice
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Scot Desort" <scot@njaccess.net>
Subject: (usr-tc) A PERSONAL Thank You - A Hurricane Floyd Story
Date: 18 Sep 1999 22:40:27 -0400
We were severely impacted by Hurricane Floyd. A major regional Bell
Atlantic/AT&T switching facility in Rochelle Park, NJ was flooded out at 6AM
on Friday. The building was 4 feet under water. All of our upstream T's go
through this facility, so we were dead in the water. There was no power to
the building at all.
Our primary upstream feed comes from IDT. We were in contact with them, and
they indicated that the rest of their network was up. They have NO ISDN
POP's AT ALL, so I was unable to bring up any kind of dial backup. We were
still dead. And getting real info from BA support is almost impossible.
I drove to Rochelle Park myself this morning to assess the damage
first-hand. The flood waters had receeded. There were no less than 6 AT&T
trailers on site, over 200 people, 30 trucks, the National Guard, and local
law enforcement. AC power had been restored, but DC power was still out,
which obviously means the frame, all DAC's, fiber equipment and switches
were still down. An AT&T "Network Disaster Recovery" team member gave me a
little bit of info -- they were trucking in some special DC power equipment
and cabling from Southern NJ. Once that was patched into the building, they
would try to power the equipment back up. They believed that the damages
were limited to power, and that the equipment itself was OK. But they
wouldn't know for sure until they could light it up. This outage not only
effected all T's into and out of the area, but also the local BA switch,
AT&T toll, and cellular for many carriers. In addition, I've beed told that
it handles a lot of the AT&T long distance switching for the Northeast
corridor, including traffic from northern NJ into NYC, and some
international traffic destined for the main AT&T center in Bedminster NJ.
At 1PM today, I received a call from another local ISP, Net Access
Corporation in Denville, NJ. Their upstream bypasses Rochelle Park, so they
were unaffected by it. They offered to allow me to connect, via ISDN, to
their network, FREE OF CHARGE, and they would broadcast BGP routes for all
of our networks. This call came OUT OF THE BLUE. I hurried over to the ops
center, and began configuring a few BRI's on a Cisco 2600 for dial-out. A
half-hour later, we were hot, and our routes started propagating. Within an
hour, we were back up and online, although crippled, but better than dead.
I know that Net Access uses Ascend equipment, so they're probably not on
this list. But I wanted to take this opportunity to broadcast this thank you
to Alex Rubenstein, and Net Access in general, for extending a helping hand
to someone who would normally be considered a competitor. It is so
refreshing to see another ISP offer such assistance during a time of crisis.
If the need ever arises in the future, I will most certainly reciprocate.
And I urge eveyone else on this list to do the same should you ever see the
opportunity to help another ISP hit so hard.
As of 9:15 PM, the switching center is still out. Traffic is slowly moving
in and out of my network. I would have liked to configure the PRI's on my TC
to dial out to them, but because I am so new with the TC, it was easier for
me to do it with the 2600. If anyone knows how I can configure my TC to dial
out, I would appreciate any config tips. I would like to get an entire PRI
worth of traffic connected to them, should this problem not be corrected by
Monday morning.
And once again, thanks Net Access...
Regards,
Scot
NJ Internet Access
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Kevin Benton <s1kevin@tims.net>
Subject: (usr-tc) WARNING: HARC 4.2.32 Crashed after deleting QuickSetup.cfg !!!
Date: 18 Sep 1999 22:44:53 -0400 (EDT)
See above... After this situation, we could not get the ARC to take
4.2.32 code unless we deleted the router config, then started over with
older code. Even still, 4.2.32 would not run properly. We do have an
open ticket with 3Com on this.
BTW, this was not an isolated incident. I was able to reproduce it on
another working HARC which was in service till I hosed it. When I
re-loaded the code back to an older version, things went back to
semi-normal as usual. (What is normal anyway?)
Kevin
E-Mail: s1kevin@tims.net
Web: http://users.sota-oh.com/~s1kevin/
Unsolicited advertisements processing fee: $50 subject to change without notice
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 19 Sep 1999 16:20:44 -0400
Thus spake Kevin Benton
>On Sat, 18 Sep 1999, Jeff Mcadams wrote:
>> OK...given my knowledge of the hiperarc.mib and snmp (both of which
>> aren't terribly complete). The quickest executing way of doing this
>> would be to snmpwalk usrCipPortIndex (Index'es tend to return
>> considerably faster than when you're actually pulling data), then do
>> gets (so you can have multiple OIDs in one request...again...faster than
>> a ping pong walk) on usrCipPortIpAddress.xxxx with "xxxx" being filled
>> in with the index values that you collected from the walk. When you
>> find the IP address you need, then you can just do a get on
>> usrCipUserName.xxxx, with "xxxx" this time being the specific index
>> found from the PortIpAddress. Sorta two walks...but one can be
>> implemented as a few gets which will go faster than ping-ponging the
>> walk if you're really pressed for speed.
>Can you give an example in code? (shell scripts?)
Nope, 'cause I'm *seriously* not a programmer, and none of the snmp util
toolkits do this parallelization of snmpwalks that I'm aware of.
>Actually, we do it by using an expect script to telnet to the host and get
>the results back usually within 3-5 seconds no matter how many users are
>logged on. Of course, it's up to you to parse out what you need vs what
>you don't need...
That doesn't scale to a large number of chassis' well, and also breaks
easily on upgrades of code. SNMP should be a bit more robust to code
upgrades not breaking the algorithm. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Brett Murphy" <me@murf.net>
Subject: Re: (usr-tc) Radius Attribute IP_Pool_Name
Date: 20 Sep 1999 09:34:02 +1000
I hacked cistron radius 1.5.3 with something to the following effect
/* BM append the IP POOL name */
/*
vendor specific attribute for POOL_NAME is 0x9024
A summary of the Vendor-Specific Attribute format is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Vendor-Id
The high-order octet is 0 and the low-order 3 octets are the SMI
Network Management Private Enterprise Code of the Vendor in
network byte order, as defined in the Assigned Numbers RFC [2].
*/
if(ip_pool_name != (char *)NULL) {
len = strlen(ip_pool_name);
if(len > 0 && len < AUTH_STRING_LEN) {
*ptr++ = 26;
*ptr++ = len + 10;
*ptr++ = 0;
*ptr++ = 0;
*ptr++ = 1;
*ptr++ = 173;
*ptr++ = 0;
*ptr++ = 0;
*ptr++ = 144;
*ptr++ = 36;
memcpy(ptr, ip_pool_name, len);
ptr += len;
total_length += len + 10;
}
All the best,
Brett Murphy
Technical Manager, Alphalink (Australia) PTY LTD
ph: +61 3 9486-8844 fax: +61 3 9486-6822
email: me@murf.net
The contents of this email message may not be quoted,
copied, reproduced or published in part or in whole,
without the written authorization of Brett Murphy,
Director, Alphalink (Australia) Pty Ltd.
-----Original Message-----
>
>
>|-----Original Message-----
>|From: owner-usr-tc@lists.xmission.com
>|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Becker
>|Sent: Friday, September 17, 1999 2:54 AM
>|To: usr-tc@lists.xmission.com
>|Subject: (usr-tc) Radius Attribute IP_Pool_Name
>|
>|
>|Reading the docs on the Total Control Radius server (I don't have it but
was
>|just reading how it works), I ran across the ability for RADIUS to select
>|which ip pool is used when authenticating a user. This would solve a huge
>|problem.
>|
>|According to 3com HiPerArc Docs - page E-473
>|Attributes
>|61 NAS-Port-Type F,L
>|62 Port-Limit
>|63 Login_LAT-Port NS
>|64 Prompt
>|.
>|.
>|217 Framed-IP-Addr-Pool-Name
>|250 Char-Noecho
>|
>|
>|And on page E-445 in the Vendor Specific Attributes it says:
>|0x9024 IP-Address-Pool
>|Sets the name of the IP address pool for Framed PPP/SLIP users.
>|Values: ASCII string. Limit: 16 bytes
>|User Types: Framed
>|Packet Types: Access-Accept
>|Default: None
>|Use the following global command to set this parameter locally:
>|add ip pool <pool_name>
>|
>|I've tried editing my dictionary file (I'm using Livingston v1.16 running
a
>|FreeBSD box) for attribute 217:
>|
>|ATTRIBUTE Framed-IP-Addr-Pool-Name 217 string
>|
>|and in my user file I've included the line:
>|Framed-IP-Addr-Pool-Name = "testippool",
>|
>|which is the name of a pool. But I'm still getting the an ip from another
>|pool. I set the pool to private. But still can't get it to use those ips.
>217 Is an ascend attribute. The HARC will accept (some of) these in the
4.2.x
>code base. See the docs for a more complete list.
>
>|Also tried
>|ATTRIBUTE IP_Pool_Name 0x9024 string
>|
>
>The above will work with any HARC code. But your 1.1.6 Radius does not
support
>3com VSA's.
>
>-M
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: (usr-tc) Playing with OSPF
Date: 20 Sep 1999 06:14:55 -0500
I have recently upgraded most of my HiperARC cards to 4.2.32-1 and have
started looking at switching them from RIP to OSPF. Everything is working as
I would expect for host dialins, HOWEVER it seems that the ARC is not
advertising any Framed-Routes setup through radius.
For example, an entry like the following in radius:
username Auth-Type=System
Service-Type=Framed-User,
Framed-IP-Address = 192.168.0.1,
Framed-Route = "10.0.0.1/24 192.168.0.1 1",
Framed-Routing = None,
Once username dials into the TC the host route for 192.168.0.1 is correctly
broadcast through OSPF but the 10.0.0.1/24 route is not. Am I missing a
setting here or is this the normal behavior for the ARC card? Every other
piece of equipment I have recognizes this route added in through radius and
correctly advertise the route through OSPF.
Mike
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: kenny@millar-bryce.com (Kenny Petrie)
Subject: (usr-tc) Assistance Required
Date: 20 Sep 1999 13:25:02 +0100
I am looking for some advice, I inherited a U.S. Robotics NetServer/8I and
wish to configure the box for 2 purposes:-
1) IP Terminal Server, I've managed to get this to work, so the modems
connected to ISDN pri are OK
2) Network Dial In PPP - this is proving to be more difficult, I am unable
to get this to work at all
I have had to config everything via the CLI as I am unable to connect to the
box via the n/work and the GUI tools due to the fact that the box balks at
the root! password ?
I have the Total Control NETServer 3.1 Windows Management Software as
supplied with the box.
Another problem seems to be that the commands published with the manuals are
out of step with the CLI
Can anyone assist with some pointers to a config approach for Network Dial
IN via PPP ?
TIA
regards
kenny
SYSTEM DESCRIPTION
System Descriptor:
U.S. Robotics NetServer/8I, Version: V4.1.7, Built on Mar 16 1998 at
21:29:52.
Object ID: 1.3.6.1.4.1.429.2.14
System UpTime: 63d 08:25:50
System Contact:
System Name: ras1
System Location:
System Services: Internet EndToEnd Applications
System Transmit Authentication Name: Netserver
System Version: V4.1.7
"Any opinions expressed in the email are those of the individual and not
necessarily the company. This email and any files transmitted with it are
confidential and solely for the use of the intended recipient. It may
contain material protected by attorney-client privilege. If you are not the
intended recipient or the person responsible for delivering to the intended
recipient, be advised that you have received this email in error and that
any use is strictly prohibited. If you have received this email in error
please notify the IT Manager by telephone on 44 (0) 131 556 1313."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 09:54:45 -0400 (EDT)
SNIP
> >Actually, we do it by using an expect script to telnet to the host and
get
> >the results back usually within 3-5 seconds no matter how many users
are
> >logged on. Of course, it's up to you to parse out what you need vs
what
> >you don't need...
>
> That doesn't scale to a large number of chassis' well, and also breaks
> easily on upgrades of code. SNMP should be a bit more robust to code
> upgrades not breaking the algorithm. :)
SNIP
Telnet will not break on code upgrades... list ip networks worked on
netserver and ARC. Place a common telnet account on every ARC and use
that. I have 3 ARC's that use this telnet setup to get user info...
hasn't broke with any of the upgrades I've done.
Perl's Net:Telnet is pretty damed good and very easy to modify.
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 09:52:35 -0400
Thus spake Paul Farber
>> >Actually, we do it by using an expect script to telnet to the host
>> >and get the results back usually within 3-5 seconds no matter how
>> >many users are logged on. Of course, it's up to you to parse out
>> >what you need vs what you don't need...
>> That doesn't scale to a large number of chassis' well, and also breaks
>> easily on upgrades of code. SNMP should be a bit more robust to code
>> upgrades not breaking the algorithm. :)
>Telnet will not break on code upgrades... list ip networks worked on
>netserver and ARC. Place a common telnet account on every ARC and use
>that. I have 3 ARC's that use this telnet setup to get user info...
>hasn't broke with any of the upgrades I've done.
No, telnet itself won't break, but the parsing might if the output
format changes (which is not uncommon between code revs.)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 10:30:40 -0400 (EDT)
It hasen't yet. The seperator for page breaks did... but the information
line has not.
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Mon, 20 Sep 1999, Jeff Mcadams wrote:
> Thus spake Paul Farber
> >> >Actually, we do it by using an expect script to telnet to the host
> >> >and get the results back usually within 3-5 seconds no matter how
> >> >many users are logged on. Of course, it's up to you to parse out
> >> >what you need vs what you don't need...
>
> >> That doesn't scale to a large number of chassis' well, and also breaks
> >> easily on upgrades of code. SNMP should be a bit more robust to code
> >> upgrades not breaking the algorithm. :)
>
> >Telnet will not break on code upgrades... list ip networks worked on
> >netserver and ARC. Place a common telnet account on every ARC and use
> >that. I have 3 ARC's that use this telnet setup to get user info...
> >hasn't broke with any of the upgrades I've done.
>
> No, telnet itself won't break, but the parsing might if the output
> format changes (which is not uncommon between code revs.)
> --
> Jeff McAdams Email: jeffm@iglou.com
> Head Network Administrator Voice: (502) 966-3848
> IgLou Internet Services (800) 436-4456
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 10:29:11 -0400
Thus spake Paul Farber
>It hasen't yet. The seperator for page breaks did... but the information
>line has not.
Yup, and the Arc is still very young. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Vadim Tulinov <Vadim_Tulinov@rrc.ru>
Subject: (usr-tc) R2 debug codes
Date: 20 Sep 1999 18:32:34 +0400
Hello,
We try to convert R1 to R2 (ICX c=CFverter) and get following Dual Cas
(1.3.4) information:
Ph_frame_post_xmit: datagramm: frame: t/p: 8/0030:001de394, status
>0x04<
What this is mean?
Where can I read about this status?
Best regards,
Vadim Tulinov.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Vadim Tulinov <Vadim_Tulinov@rrc.ru>
Subject: (usr-tc) R2 debug codes
Date: 20 Sep 1999 18:32:34 +0400
Hello,
We try to convert R1 to R2 (ICX c=CFverter) and get following Dual Cas
(1.3.4) information:
Ph_frame_post_xmit: datagramm: frame: t/p: 8/0030:001de394, status
>0x04<
What this is mean?
Where can I read about this status?
Best regards,
Vadim Tulinov.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike Wronski" <mike@coredump.ae.usr.com>
Subject: (usr-tc) RE: (3Com-TotalControl) Framed routes not being picked up by OSPF broadcasts?
Date: 20 Sep 1999 10:40:54 -0500
|-----Original Message-----
|From: owner-totalcontrol@totalservice.3com.com
|[mailto:owner-totalcontrol@totalservice.3com.com]On Behalf Of Mike
|McHenry
|Sent: Monday, September 20, 1999 7:01 AM
|Subject: (3Com-TotalControl) Framed routes not being picked up by OSPF
|broadcasts?
|
|
|Reply to user-forum-totalcontrol@totalservice.3com.com
|
|
|I have recently upgraded most of my HiperARC cards to 4.2.32-1 and have
|started looking at switching them from RIP to OSPF. Everything is
|working as I would expect for host dialins, HOWEVER it seems that the
|ARC is not advertising any Framed-Routes setup through radius.
|
|For example, an entry like the following in radius:
|
|username Auth-Type=System
| Service-Type=Framed-User,
| Framed-IP-Address = 192.168.0.1,
| Framed-Route = "10.0.0.1/24 192.168.0.1 1",
| Framed-Routing = None,
|
|Once username dials into the TC the host route for 192.168.0.1 is
|correctly broadcast through OSPF but the 10.0.0.1/24 route is not. Am I
|missing a setting here or is this the normal behavior for the ARC card?
|Every other piece of equipment I have recognizes this route added in
|through radius and correctly advertise the route through OSPF.
|
At this time you have to add a "SEND Policy" to get the framed-routes to
advertise. This iss done by
"ADD OSPF SENDPOLICY 10.0.0.1/24 SOURCE REMOTE ACTION ADVERTISE"
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: (usr-tc) Another "so this is how you did it with a netserver" question: pt
Date: 20 Sep 1999 10:50:34 -0500
Hi--
Really about the last question on my list about ARC's is how do I do a
ptrace on an ARC like I did with Netservers?
Was quite simple to add a little filter with the appropriate IP's, then
ptrace filter
and I'd get the output from the Netserver.
Is there an equivilent on the ARC? (please tell me it's as easy to
use...too...)
SMT
Scott Trautman 608-240-4638,4637fax
Global Dialog Internet www.gdinet.com
2810 Crossroads, STE LL2
Madison WI 53718
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: (usr-tc) RE: (3Com-TotalControl) Framed routes not being picked up by OSPF broadcasts?
Date: 20 Sep 1999 10:58:44 -0500
I was thinking along those lines, one question though. Can I specify a
superset of the network blocks I want advertised in my SENDPOLICY? For
example, I know that all of my framed routes will come out of a supernet of
4 class C blocks, can I specify
add ospf sendpolicy 10.0.0.1/22 source REMOTE action ADVERTISE
or do I need to list every possible framed-route separately like
add ospf sendpolicy 10.0.0.1/28 source REMOTE action ADVERTISE
add ospf sendpolicy 10.0.0.64/28 source REMOTE action ADVERTISE
add ospf sendpolicy 10.0.0.128/28 source REMOTE action ADVERTISE
add ospf sendpolicy 10.0.0.192/28 source REMOTE action ADVERTISE
etc...
Thanks for your response :)
Mike
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Wronski
Sent: Monday, September 20, 1999 10:41 AM
up by OSPF broadcasts?
|-----Original Message-----
|From: owner-totalcontrol@totalservice.3com.com
|[mailto:owner-totalcontrol@totalservice.3com.com]On Behalf Of Mike
|McHenry
|Sent: Monday, September 20, 1999 7:01 AM
|Subject: (3Com-TotalControl) Framed routes not being picked up by OSPF
|broadcasts?
|
|
|Reply to user-forum-totalcontrol@totalservice.3com.com
|
|
|I have recently upgraded most of my HiperARC cards to 4.2.32-1 and have
|started looking at switching them from RIP to OSPF. Everything is
|working as I would expect for host dialins, HOWEVER it seems that the
|ARC is not advertising any Framed-Routes setup through radius.
|
|For example, an entry like the following in radius:
|
|username Auth-Type=System
| Service-Type=Framed-User,
| Framed-IP-Address = 192.168.0.1,
| Framed-Route = "10.0.0.1/24 192.168.0.1 1",
| Framed-Routing = None,
|
|Once username dials into the TC the host route for 192.168.0.1 is
|correctly broadcast through OSPF but the 10.0.0.1/24 route is not. Am I
|missing a setting here or is this the normal behavior for the ARC card?
|Every other piece of equipment I have recognizes this route added in
|through radius and correctly advertise the route through OSPF.
|
At this time you have to add a "SEND Policy" to get the framed-routes to
advertise. This iss done by
"ADD OSPF SENDPOLICY 10.0.0.1/24 SOURCE REMOTE ACTION ADVERTISE"
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: (usr-tc) RE: Another "so this is how you did it with a netserver" question
Date: 20 Sep 1999 11:33:36 -0500
Okay, so I did a little research and found 'monitor ppp'.
Nifty enough except the output is useless to me:
Incoming PPP Data on interface: slot:12/mod:17
UTCP_DATA ff 03 00 2f 45 00 00 28 74 44 40 00 40 07 3f e9 9c 2e 7a fa
...
Outgoing PPP Data on interface: slot:12/mod:17
IP_DATA 45 00 00 89 61 ea 40 00 30 06 61 e2 ce 87 a0 f2 9c 2e 7a fa
...
Incoming PPP Data on interface: slot:12/mod:17
CTCP_DATA ff 03 00 2d 54 07 bd 00 61 48 54 54 50 2f 31 2e 31 20 32 30
...
Outgoing PPP Data on interface: slot:12/mod:17
IP_DATA 45 00 00 28 b2 ea 40 00 30 06 11 43 ce 87 a0 f2 9c 2e 7a fa
...
The format with the Netserver ptrace was infinately useful--
Gave the protocol, the ip address source and destination and port source and
destination.
This must require a "super decoder ring" to figure out--
Anything I'm missing here?
SMT
From: Scott Trautman
Sent: Monday, September 20, 1999 10:51 AM
ptrace
Hi--
Really about the last question on my list about ARC's is how do I do a
ptrace on an ARC like I did with Netservers?
Was quite simple to add a little filter with the appropriate IP's, then
ptrace filter
and I'd get the output from the Netserver.
Is there an equivilent on the ARC? (please tell me it's as easy to
use...too...)
SMT
Scott Trautman 608-240-4638,4637fax
Global Dialog Internet www.gdinet.com
2810 Crossroads, STE LL2
Madison WI 53718
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) RE: Another "so this is how you did it with a netserver"
Date: 20 Sep 1999 12:46:10 -0400 (EDT)
Maybe you're looking for 'set packet_logging logging all packet_size 80',
wihch tells the ARC to syslog the first 80 bytes of every packet that
matches any filter.
Unfortunately it does exactly that -- just logs the bytes, without
interpreting any of it... so you have to parse the output to decode the
TCP/IP headers to make any sense out of it.
'monitor ppp' monitors the entire PPP session, not just the part that
matches a filter. And again, that's kinda raw output, which needs a
script to decode and make sense of.
It sounds like we need a web page like Livingston's old PPP Decoder Ring
page, where you could paste 'debug 0x51' output into their web page and
get something intelligent back. Maybe we need a worklike for 'monitor
ppp'. That'll give me something more interesting to waste the afternoon
on than cleaning up our customer database :)
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
On Mon, 20 Sep 1999, Scott Trautman wrote:
> Okay, so I did a little research and found 'monitor ppp'.
>
> Nifty enough except the output is useless to me:
>
> Incoming PPP Data on interface: slot:12/mod:17
> UTCP_DATA ff 03 00 2f 45 00 00 28 74 44 40 00 40 07 3f e9 9c 2e 7a fa
> ...
[munch]
> ...
>
> The format with the Netserver ptrace was infinately useful--
> Gave the protocol, the ip address source and destination and port source and
> destination.
> This must require a "super decoder ring" to figure out--
>
> Anything I'm missing here?
>
> SMT
>
> From: Scott Trautman
> Sent: Monday, September 20, 1999 10:51 AM
> To: 'usr-tc@lists.xmission.com'
> Subject: Another "so this is how you did it with a netserver" question:
> ptrace
>
>
> Hi--
>
> Really about the last question on my list about ARC's is how do I do a
> ptrace on an ARC like I did with Netservers?
>
> Was quite simple to add a little filter with the appropriate IP's, then
> ptrace filter
>
> and I'd get the output from the Netserver.
>
> Is there an equivilent on the ARC? (please tell me it's as easy to
> use...too...)
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 12:53:44 -0400 (EDT)
All I was really hoping for here was that someone would give me some
useful OID's that might be faster than what I was using. :)
I did manage to reduce it from two snmpwalks down to one though.
What I'm doing now is walking 1.3.6.1.4.1.429.4.10.1.1.9
(usrCipPortIpAddress) -- the OIDs returned contain the port number, the
values returned contain the IP address. Find the OID that matches,
extract the port number, then get the username via an snmpget on
1.3.6.1.4.1.429.4.10.1.1.18.$portname (usrCipUserName).
The performance problem I was having was the snmpwalk I had in Perl didn't
return the OIDs, just the values, so I had to do a second walk to the the
port numbers. That made the entire process take about 9 seconds from
start to end, which is just too long when you've got it in a CGI that's
running in a frame on your home page. :) I did some brain surgery on my
snmpwalk and got it to return both OIDs and values, and that sped it up to
about 4 seconds.
It also let me speed up another program or two I had (like 'arcwho') by
removing one walk from each of those.
Now I just have to figure out why ucd-snmp's snmpwalk (in C) is a full
second or two faster than the Perl one I have. :p
It'd still be nice if there was a way to not have to walk a full table
just to find one value...
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
On Sat, 18 Sep 1999, Mike Andrews wrote:
> OK, got a little challenge for you all. :)
>
> On a HiPer ARC... Given a dialup user's IP address, find their username.
> As fast as possible. (Think CGI here.)
>
> I've had code to do this, but it is slow, and it broke on ARC release
> 4.2.x... forcing me to use an even slower method. :p I'd like to speed
> it up.
>
> The best I can do right now is two snmpwalks, followed by a single
> snmpget. I'd like to get rid of the snmpwalks, but for some reason the
> ARC will not let you directly snmpget some variables -- you have to walk
> the whole table it's contained in. (And this got worse in 4.2.x. A bug,
> I would think.)
>
> Can anyone get it down to just snmpgets?
>
> (3Com?)
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) RE: Another "so this is how you did it with a netser
Date: 20 Sep 1999 11:57:26 -0500
Hmmm...well, that's pretty sad then.
It took something I was able to do yesterday on a netserver, which was show
a user that their connection
was misconfigured, (cut and paste into email and there you go) into a long
complicated
thing my techs will obviously not be able to do, and probably me either.
Maybe I'm the only one out there using it, but that was a strong, simple
feature.
This aint that. Pretty much useless to 99% of the people. Shrug.
I <like> that you can specify username, next session, that kind of thing,
but getting hex back,
who's under the impression that's going to be useful?
SMT
-----Original Message-----
Sent: Monday, September 20, 1999 11:46 AM
netserver" question : ptrace
Maybe you're looking for 'set packet_logging logging all packet_size 80',
wihch tells the ARC to syslog the first 80 bytes of every packet that
matches any filter.
Unfortunately it does exactly that -- just logs the bytes, without
interpreting any of it... so you have to parse the output to decode the
TCP/IP headers to make any sense out of it.
'monitor ppp' monitors the entire PPP session, not just the part that
matches a filter. And again, that's kinda raw output, which needs a
script to decode and make sense of.
It sounds like we need a web page like Livingston's old PPP Decoder Ring
page, where you could paste 'debug 0x51' output into their web page and
get something intelligent back. Maybe we need a worklike for 'monitor
ppp'. That'll give me something more interesting to waste the afternoon
on than cleaning up our customer database :)
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
On Mon, 20 Sep 1999, Scott Trautman wrote:
> Okay, so I did a little research and found 'monitor ppp'.
>
> Nifty enough except the output is useless to me:
>
> Incoming PPP Data on interface: slot:12/mod:17
> UTCP_DATA ff 03 00 2f 45 00 00 28 74 44 40 00 40 07 3f e9 9c 2e 7a fa
> ...
[munch]
> ...
>
> The format with the Netserver ptrace was infinately useful--
> Gave the protocol, the ip address source and destination and port source
and
> destination.
> This must require a "super decoder ring" to figure out--
>
> Anything I'm missing here?
>
> SMT
>
> From: Scott Trautman
> Sent: Monday, September 20, 1999 10:51 AM
> To: 'usr-tc@lists.xmission.com'
> Subject: Another "so this is how you did it with a netserver" question:
> ptrace
>
>
> Hi--
>
> Really about the last question on my list about ARC's is how do I do a
> ptrace on an ARC like I did with Netservers?
>
> Was quite simple to add a little filter with the appropriate IP's, then
> ptrace filter
>
> and I'd get the output from the Netserver.
>
> Is there an equivilent on the ARC? (please tell me it's as easy to
> use...too...)
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 13:00:46 -0400 (EDT)
On Sat, 18 Sep 1999, Jeff Mcadams wrote:
> OK...given my knowledge of the hiperarc.mib and snmp (both of which
> aren't terribly complete). The quickest executing way of doing this
> would be to snmpwalk usrCipPortIndex (Index'es tend to return
> considerably faster than when you're actually pulling data), then do
> gets (so you can have multiple OIDs in one request...again...faster than
> a ping pong walk) on usrCipPortIpAddress.xxxx with "xxxx" being filled
> in with the index values that you collected from the walk. When you
> find the IP address you need, then you can just do a get on
> usrCipUserName.xxxx, with "xxxx" this time being the specific index
> found from the PortIpAddress. Sorta two walks...but one can be
> implemented as a few gets which will go faster than ping-ponging the
> walk if you're really pressed for speed.
That's exactly what I had before. :) I removed the usrCipPortIndex walk
by using the OIDs returned by the usrCipPortIpAddress walk and peeling the
port number off the end.
> >I'd like to get rid of the snmpwalks, but for some reason the
> >ARC will not let you directly snmpget some variables -- you have to walk
> >the whole table it's contained in. (And this got worse in 4.2.x. A bug,
> >I would think.)
>
> Eh? Like what?
Well, now that I look at it, it's behaving itself for the tables above...
but... there are/were some tables where you cannot snmpget the
individual values in the table. For instance:
% snmpwalk -v 1 chass comm .1.3.6.1.4.1.429.blah.blah.blah | grep value
enterprises.usr.blah.blah.blah.foo = "value"
but then try to get it directly and it fails:
% snmpget -v 1 chass comm .1.3.6.1.4.1.429.blah.blah.blah.foo
This name doesn't exist: enterprises.usr.blah.blah.blah.foo
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 13:12:14 -0400
Thus spake Mike Andrews
>That's exactly what I had before. :) I removed the usrCipPortIndex walk
>by using the OIDs returned by the usrCipPortIpAddress walk and peeling the
>port number off the end.
Man...maybe we're using different PERL modules? The one we have will
walk through 96 ports of data in something like a second or two...its
*quite* fast....and that's displaying the output as it gets it, so its
probably slowed down considerably by the display output. We're using
http://cpan.valueclick.com/authors/id/GSM/SNMP-1.8.2.tar.gz
and it seems to be quite quick. Also seems, from what I can tell so
far...haven't checked in depth, to parallelize walks...ie, puts multiple
getnext requests of different OIDs into a single request. Rather nice.
>but... there are/were some tables where you cannot snmpget the
>individual values in the table. For instance:
>% snmpwalk -v 1 chass comm .1.3.6.1.4.1.429.blah.blah.blah | grep value
>enterprises.usr.blah.blah.blah.foo = "value"
>but then try to get it directly and it fails:
>% snmpget -v 1 chass comm .1.3.6.1.4.1.429.blah.blah.blah.foo
>This name doesn't exist: enterprises.usr.blah.blah.blah.foo
Wow...I've not run into anything like that, but you're probably hitting
more stuff than I am.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Andres Kroonmaa" <andre@mail.lbi.ee>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 21:33:16 +0300
AFAIK, logical way to get this done is in 2 snmpgets:
Given that you look for IP address of "12.45.78.23"
$port = snmpget ip.ipRouteTable.ipRouteEntry.ipRouteIfIndex.12.45.78.23
$user = snmpget usrCipUserName.$portname
and of course 3com is always ready to screw up. You can't snmpget item
from ipRouteIfIndex, you can only walk it, or it returns always "0"
The only thing positive here is that you can walk subset of the table:
snmpwalk ip.ipRouteTable.ipRouteEntry.ipRouteIfIndex.12.45.78
that is you omit last octet from the IP address. You get all ports for
given /24, and search your interested IP yourself.
Or, an interesting hack that would probably also work is to ask:
snmpnext ip.ipRouteTable.ipRouteEntry.ipRouteIfIndex.12.45.78.22
instead of:
snmpget ip.ipRouteTable.ipRouteEntry.ipRouteIfIndex.12.45.78.23
note snmp _next_ request and off by -1 IP address.
Basically, we cheat, yet amazingly it seems to work.
You might use this as "wild guess", check returned snmpindex and if
it doesn't match what you are looking for, fallback to longer walkouts.
I believe you wouldn't need to.
On 20 Sep 99, at 12:53, Mike Andrews <usr-tc@lists.xmission.com> wrote:
> All I was really hoping for here was that someone would give me some
> useful OID's that might be faster than what I was using. :)
>
> I did manage to reduce it from two snmpwalks down to one though.
>
> What I'm doing now is walking 1.3.6.1.4.1.429.4.10.1.1.9
> (usrCipPortIpAddress) -- the OIDs returned contain the port number, the
> values returned contain the IP address. Find the OID that matches,
> extract the port number, then get the username via an snmpget on
> 1.3.6.1.4.1.429.4.10.1.1.18.$portname (usrCipUserName).
>
> The performance problem I was having was the snmpwalk I had in Perl didn't
> return the OIDs, just the values, so I had to do a second walk to the the
> port numbers. That made the entire process take about 9 seconds from
> start to end, which is just too long when you've got it in a CGI that's
> running in a frame on your home page. :) I did some brain surgery on my
> snmpwalk and got it to return both OIDs and values, and that sped it up to
> about 4 seconds.
>
> It also let me speed up another program or two I had (like 'arcwho') by
> removing one walk from each of those.
>
> Now I just have to figure out why ucd-snmp's snmpwalk (in C) is a full
> second or two faster than the Perl one I have. :p
>
> It'd still be nice if there was a way to not have to walk a full table
> just to find one value...
>
>
>
> Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
> mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
> "If you're not part of the solution.... you're part of the precipitate."
>
> On Sat, 18 Sep 1999, Mike Andrews wrote:
>
> > OK, got a little challenge for you all. :)
> >
> > On a HiPer ARC... Given a dialup user's IP address, find their username.
> > As fast as possible. (Think CGI here.)
> >
> > I've had code to do this, but it is slow, and it broke on ARC release
> > 4.2.x... forcing me to use an even slower method. :p I'd like to speed
> > it up.
> >
> > The best I can do right now is two snmpwalks, followed by a single
> > snmpget. I'd like to get rid of the snmpwalks, but for some reason the
> > ARC will not let you directly snmpget some variables -- you have to walk
> > the whole table it's contained in. (And this got worse in 4.2.x. A bug,
> > I would think.)
> >
> > Can anyone get it down to just snmpgets?
> >
> > (3Com?)
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
----------------------------------------------------------------------
Andres Kroonmaa mail: andre@online.ee
Senior Network Engineer
Organization: MicroLink Online Tel: 6308 909
Tallinn, Sakala 19 Pho: +372 6308 909
Estonia, EE0001 http://www.online.ee Fax: +372 6308 901
----------------------------------------------------------------------
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike Wronski" <mike@coredump.ae.usr.com>
Subject: RE: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 13:59:23 -0500
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews
|Sent: Monday, September 20, 1999 11:54 AM
|To: usr-tc@lists.xmission.com
|Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
|
|
|All I was really hoping for here was that someone would give me some
|useful OID's that might be faster than what I was using. :)
|
|I did manage to reduce it from two snmpwalks down to one though.
|
|What I'm doing now is walking 1.3.6.1.4.1.429.4.10.1.1.9
|(usrCipPortIpAddress) -- the OIDs returned contain the port number, the
|values returned contain the IP address. Find the OID that matches,
|extract the port number, then get the username via an snmpget on
|1.3.6.1.4.1.429.4.10.1.1.18.$portname (usrCipUserName).
|
|The performance problem I was having was the snmpwalk I had in Perl didn't
|return the OIDs, just the values, so I had to do a second walk to the the
|port numbers. That made the entire process take about 9 seconds from
|start to end, which is just too long when you've got it in a CGI that's
|running in a frame on your home page. :) I did some brain surgery on my
|snmpwalk and got it to return both OIDs and values, and that sped it up to
|about 4 seconds.
|
|It also let me speed up another program or two I had (like 'arcwho') by
|removing one walk from each of those.
|
|Now I just have to figure out why ucd-snmp's snmpwalk (in C) is a full
|second or two faster than the Perl one I have. :p
|
|It'd still be nice if there was a way to not have to walk a full table
|just to find one value...
|
|
|
|Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
|mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
|"If you're not part of the solution.... you're part of the precipitate."
|
|On Sat, 18 Sep 1999, Mike Andrews wrote:
|
|> OK, got a little challenge for you all. :)
|>
|> On a HiPer ARC... Given a dialup user's IP address, find their username.
|> As fast as possible. (Think CGI here.)
|>
|> I've had code to do this, but it is slow, and it broke on ARC release
|> 4.2.x... forcing me to use an even slower method. :p I'd like to speed
|> it up.
Can someone clarify the above? What broke? OID?
|> The best I can do right now is two snmpwalks, followed by a single
|> snmpget. I'd like to get rid of the snmpwalks, but for some reason the
|> ARC will not let you directly snmpget some variables -- you have to walk
|> the whole table it's contained in. (And this got worse in 4.2.x. A bug,
|> I would think.)
|>
|> Can anyone get it down to just snmpgets?
|>
|> (3Com?)
Since the information you are asking for is not indexed by IP address it can
never be retrieved with a single get.
For that to work the ip would have to be a part of the OID. IE if the ip assigned
was 10.10.10.1 the oid would be
USR-PREFIX.10.10.10.1.X where X is the index to say the username or other info
about that user record.
Unfortunately the user records are organized by port ID (4 digit index). So this
is not possible.
I have a perl script that calls UCD snmp. I can get the info from a chassis in
<2 seconds using a HiperNMC.
In my example I process the walk as it comes in. (IE i dont walk the branch, then
look for the IP) I look at each leaf and see if it matches the IP desired, if so
it does the get to retried the Username.
Code follows: (NOTE: Works on 4.1 and 4.2 without a problem)
#!/usr/local/bin/perl
# Script takes IP address as input and returns user name and slot/modem info.
$WALK_BIN = '/usr/local/bin/snmpwalk -s -q -v 1';
$GET_BIN = '/usr/local/bin/snmpget -s -q -v 1';
$IP_LIST_OID = '.1.3.6.1.4.1.429.4.10.1.1.9';
$UNAME_OID = '.1.3.6.1.4.1.429.4.10.1.1.18';
$SLOT_CHAD_OID = '.1.3.6.1.4.1.429.4.10.1.1.25';
die "usage $0 <HOST> <COMMUNITY> <IP_ADDRESS>\n" if $#ARGV != 2;
$HOST = $ARGV[0];
$READ_STRING = $ARGV[1];
$TARGET_IP = $ARGV[2];
open(IFILE,"$WALK_BIN $HOST $READ_STRING $IP_LIST_OID |") or die "Cant run
snmpwalk!\n";
while ($line = <IFILE>) {
if ($line =~ /$TARGET_IP/) {
#print "$line";
($OID,$CRAP) = split / /,$line;
#print $OID."\n";
@SOID = split /\./, $OID;
$PORT = pop(@SOID);
$NAME_LINE = `$GET_BIN $HOST $READ_STRING $UNAME_OID.$PORT`;
chomp $NAME_LINE;
@SNAME_LINE = split / /,$NAME_LINE;
$USERNAME = pop(@SNAME_LINE);
# Comment out next 4 lines if slot chan info is not required.
$SLOT_LINE = `$GET_BIN $HOST $READ_STRING $SLOT_CHAD_OID.$PORT`;
chomp $SLOT_LINE;
@SSLOT_LINE = split / /,$SLOT_LINE;
$SLOT = pop(@SSLOT_LINE);
print "$TARGET_IP is on port $PORT ($SLOT) as user :$USERNAME\n";
}
}
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Kevin Benton <s1kevin@tims.net>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 15:01:07 -0400 (EDT)
On Mon, 20 Sep 1999, Mike Andrews wrote:
> All I was really hoping for here was that someone would give me some
> useful OID's that might be faster than what I was using. :)
>
> I did manage to reduce it from two snmpwalks down to one though.
>
> What I'm doing now is walking 1.3.6.1.4.1.429.4.10.1.1.9
> (usrCipPortIpAddress) -- the OIDs returned contain the port number, the
> values returned contain the IP address. Find the OID that matches,
> extract the port number, then get the username via an snmpget on
> 1.3.6.1.4.1.429.4.10.1.1.18.$portname (usrCipUserName).
>
> The performance problem I was having was the snmpwalk I had in Perl didn't
> return the OIDs, just the values, so I had to do a second walk to the the
> port numbers. That made the entire process take about 9 seconds from
> start to end, which is just too long when you've got it in a CGI that's
> running in a frame on your home page. :) I did some brain surgery on my
> snmpwalk and got it to return both OIDs and values, and that sped it up to
> about 4 seconds.
>
> It also let me speed up another program or two I had (like 'arcwho') by
> removing one walk from each of those.
>
> Now I just have to figure out why ucd-snmp's snmpwalk (in C) is a full
> second or two faster than the Perl one I have. :p
>
> It'd still be nice if there was a way to not have to walk a full table
> just to find one value...
Thanks to your message above, I did (I'll leave it up to you to
implement the shell script in CGI)...
#!/bin/sh
chassis=$1
mibname=$2
username=$3
snmpwalk "$chassis" "$mibname" .1.3.6.1.4.1.429.4.10.1.1.18 \
.1.3.6.1.4.1.429.4.10.1.1.19 \
.1.3.6.1.4.1.429.4.10.1.1.25 | \
egrep -1 -e "$username"
which produced (sorry for the lack of mib.txt file entries -too long)
enterprises.usr.4.10.1.1.9.1521 = IpAddress: 111.222.33.44
enterprises.usr.4.10.1.1.18.1521 = OCTET STRING: "userid"
enterprises.usr.4.10.1.1.25.1521 = OCTET STRING: "slot:2/mod:1"
and the results came back in less than two seconds consistently using
CMU-SNMP for Linux v3.5 which can be found at http://www.gaertner.de/snmp/
User names and IP addresses have been changed to protect their identity.
:)
Want the user name from the address? Try replacing the egrep above with...
egrep -2 -e "$username" | tail +3
Bon Apetite!
Kevin
> Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
> mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
> "If you're not part of the solution.... you're part of the precipitate."
>
> On Sat, 18 Sep 1999, Mike Andrews wrote:
>
> > OK, got a little challenge for you all. :)
> >
> > On a HiPer ARC... Given a dialup user's IP address, find their username.
> > As fast as possible. (Think CGI here.)
> >
> > I've had code to do this, but it is slow, and it broke on ARC release
> > 4.2.x... forcing me to use an even slower method. :p I'd like to speed
> > it up.
> >
> > The best I can do right now is two snmpwalks, followed by a single
> > snmpget. I'd like to get rid of the snmpwalks, but for some reason the
> > ARC will not let you directly snmpget some variables -- you have to walk
> > the whole table it's contained in. (And this got worse in 4.2.x. A bug,
> > I would think.)
> >
> > Can anyone get it down to just snmpgets?
> >
> > (3Com?)
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
E-Mail: s1kevin@tims.net
Web: http://users.sota-oh.com/~s1kevin/
Unsolicited advertisements processing fee: $50 subject to change without notice
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Greg Coffey <greg@coffey.com>
Subject: (usr-tc) Netserver8 Problem
Date: 20 Sep 1999 13:42:16 -0600
I just got off the phone with a 3Com tech regarding an issue that we have
with a Netserver8 Plus. The modems hang at least once a day and we have to
go in and reset each manually to get them to answer an incoming call. We
tried some S register settings and flashed the modems down to an earlier
code version with no luck. The modems all still seem to hang at random
intervals. I have a fair number of the older netserver16's still in
service and we don't have this problem with any of them. This unit is
fairly new, much newer than the NS16's that I have. After days of trying
different things with them, 3Com now tells me that the code has problems
and is nothing that they can or will fix. We can continue to reset the
modems manually which is a royal pain and unacceptable. Their other
suggestion is that I can upgrade the memory from 2meg to 4meg for $1300
plus $300 for advanced shipping. I knew that memory prices recently went
up but not by THAT much. Did I just buy a large doorstop or do any of you
have any ideas that we can try?
Thanks, Greg Coffey <gcoffey@vcn.com>
Visionary Communications V 307-234-5443 F 307-234-5446
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: (usr-tc) V90 & 2.0.81....problems only at one site
Date: 20 Sep 1999 15:16:53 -0500
Hi--
Anyone else experience problems with v90 and 2.0.81 DSP code?
Up until Saturday, was running 1.2.25 code without problems since a similiar
problem several months ago in the same location.
Could the CO switch type have anything to do with it? Running 2.0.81 quite
happily everywhere else,
at this site on this DSP, try and negotiate a V90 connection and you get a
long ugly tone and that's all.
X2, fine. V34 & others, fine. V90? Not at all.
I replaced the DSP even and no change. Same thing.
Strange!!!
SMT
Scott M. Trautman 800-482-4638
Global Dialog Internet 608-240-4638,4637fax
2810 Crossroads, STE LL2 scott@gdinet.com
Madison WI 53718 http://www.gdinet.com
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Andres Kroonmaa" <andre@mail.lbi.ee>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 23:31:44 +0300
On 20 Sep 99, at 21:33, Andres Kroonmaa <usr-tc@lists.xmission.com> wrote:
> AFAIK, logical way to get this done is in 2 snmpgets:
> Given that you look for IP address of "12.45.78.23"
>
> $port = snmpget ip.ipRouteTable.ipRouteEntry.ipRouteIfIndex.12.45.78.23
> $user = snmpget usrCipUserName.$portname
> Or, an interesting hack that would probably also work is to ask:
> snmpnext ip.ipRouteTable.ipRouteEntry.ipRouteIfIndex.12.45.78.22
> note snmp _next_ request and off by -1 IP address.
sample script:
#!/usr/local/bin/perl
# ftp://ftp.switch.ch/software/sources/network/snmp/perl/SNMP_Session-0.74.tar.gz
use BER;
use SNMP_Session;
use SNMP_util;
my $community = 'public';
my $host = $ARGV[0] || die "usage: $0 target ipaddress";
my $target = $ARGV[1] || die "usage: $0 target ipaddress";
@ip = split(/\./,$target); $ip[3]--; $pretarg = join('.',@ip);
@ret = &snmpgetnext("$community\@$host", "1.3.6.1.2.1.4.21.1.2.$pretarg");
foreach $index (@ret)
{
($oid, $index) = split(':', $index, 2);
if ($oid =~ "\.$target\$") {
($user) = &snmpget("$community\@$host", "1.3.6.1.4.1.429.4.10.1.1.18.$index");
print "$target = $user\n";
}
}
unix> ptime tcwho Hiper 1.2.3.4
1.2.3.4 = userX
real 0.393
user 0.224
sys 0.053
----------------------------------------------------------------------
Andres Kroonmaa mail: andre@online.ee
Senior Network Engineer
Organization: MicroLink Online Tel: 6308 909
Tallinn, Sakala 19 Pho: +372 6308 909
Estonia, EE0001 http://www.online.ee Fax: +372 6308 901
----------------------------------------------------------------------
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: RE: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 16:37:31 -0400 (EDT)
On Mon, 20 Sep 1999, Mike Wronski wrote:
> |> I've had code to do this, but it is slow, and it broke on ARC release
> |> 4.2.x... forcing me to use an even slower method. :p I'd like to speed
> |> it up.
>
> Can someone clarify the above? What broke? OID?
It took me a while to dredge up my old code so I can back up silly claims
like this (I deleted my old version after fixing it all Saturday... dumb).
On 4.1.59, I was doing this:
($portname) = &ma_snmp::snmpwalk ($tsname, $commname,
"1.3.6.1.4.1.429.4.19.24.1.10.$ipaddr.255.255.255.255");
to get the port number, then I could (and still can) get the username
with:
($username) = &ma_snmp::snmpget ($tsname, $commname,
"1.3.6.1.4.1.429.4.10.1.1.18.$portname");
But the snmpwalk broke on upgrading to 4.2.29 and 4.2.32.
That's when I switched over to walking two different trees,
1.3.6.1.4.1.429.4.10.1.1.1 to get port numbers and
1.3.6.1.4.1.429.4.10.1.1.9 to get IP addresses. That doubled the runtime.
By fixing my snmpwalk to give me the OIDs instead of just the values, I
could just walk the ...4.10.1.1.9 tree and get all I needed, get it back
down to one snmpwalk, and solve my original problem. And as far as I know
it's backward compatible to 4.1.59.
As far as the walk/get inconsistency, I'll get to that below.
> I have a perl script that calls UCD snmp. I can get the info from a chassis in
> <2 seconds using a HiperNMC.
> In my example I process the walk as it comes in. (IE i dont walk the branch, then
> look for the IP) I look at each leaf and see if it matches the IP desired, if so
> it does the get to retried the Username.
>
> Code follows: (NOTE: Works on 4.1 and 4.2 without a problem)
>
> #!/usr/local/bin/perl
> # Script takes IP address as input and returns user name and slot/modem info.
>
> $WALK_BIN = '/usr/local/bin/snmpwalk -s -q -v 1';
> $GET_BIN = '/usr/local/bin/snmpget -s -q -v 1';
> $IP_LIST_OID = '.1.3.6.1.4.1.429.4.10.1.1.9';
> $UNAME_OID = '.1.3.6.1.4.1.429.4.10.1.1.18';
> $SLOT_CHAD_OID = '.1.3.6.1.4.1.429.4.10.1.1.25';
[munch]
This is exactly what I came up with in the end, except I calculate the
slot/channel numbers from the port number. (Subtract 1000 decimal, then
the low order byte is the channel, high order byte is the slot.)
The rest of my speed problem is probably because I'm using an all-Perl
snmpwalk instead of calling /usr/local/bin/snmpwalk. The snmpwalk code
I'm using is probably very sloppy and could be optimized. It probably
doesn't help that the machine it's running on is only a Pentium 166. :)
Now, as far as snmpwalk/snmpget being strange, here's an actual example,
using 206.240.130.20 as a dialup IP address currently in use by a user
on slot:11/mod:18 (3834 - 1000 = 0xb12)....
andrew% snmpwalk -v 1 fra1-arc xxxxxx .1.3.6.1.4.1.429.4.19.24.1.10 | grep 206.240.130.20
enterprises.usr.common.usrIpRouting.usrIpRTE.usrIpRTEEntry.usrIpRTEIfIndex.206.240.130.20.255.255.255.255.0.0.1.0 = 3834
enterprises.usr.common.usrIpRouting.usrIpRTE.usrIpRTEEntry.usrIpRTEIfIndex.206.240.130.20.255.255.255.255.0.1.1.0 = 3834
andrew% snmpwalk -v 1 fra1-arc xxxxxx .1.3.6.1.4.1.429.4.19.24.1.10.206.240.130.20
[returns nothing whatsoever]
andrew% snmpwalk -v 1 fra1-arc xxxxxx .1.3.6.1.4.1.429.4.19.24.1.10.206.240.130.20.255.255.255.255
[also returns nothing whatsoever on 4.2.x, but I believe used to on 4.1.x]
andrew% snmpget -v 1 fra1-arc xxxxxx .1.3.6.1.4.1.429.4.19.24.1.10.206.240.130.20.255.255.255.255.0.0.1.0
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
This name doesn't exist:
enterprises.usr.common.usrIpRouting.usrIpRTE.usrIpRTEEntry.usrIpRTEIfIndex.206.240.130.20.255.255.255.255.0.0.1.0
andrew% snmpget -v 1 fra1-arc xxxxxx .1.3.6.1.4.1.429.4.19.24.1.10.206.240.130.20.255.255.255.255.0.1.1.0
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
This name doesn't exist:
enterprises.usr.common.usrIpRouting.usrIpRTE.usrIpRTEEntry.usrIpRTEIfIndex.206.240.130.20.255.255.255.255.0.1.1.0
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) V90 & 2.0.81....problems only at one site
Date: 20 Sep 1999 15:43:27 -0500
Just downgraded to 1.25.90, still same thing. V90 squeels and that's it.
IS there any CO settings that could have anything to do with this?
I just learned that this starting to happen <didn't> start just after
the DSP upgrade; users having problems now WERE able to get on until
this morning, the upgrade was 24 hours before than and we can show they
were able to get V90 connections previous to that.
VERY weird....
SMT
> -----Original Message-----
> From: Scott Trautman [mailto:scottt@corp.gdinet.com]
> Sent: Monday, September 20, 1999 3:17 PM
> To: 'usr-tc@lists.xmission.com'
> Subject: (usr-tc) V90 & 2.0.81....problems only at one site
>
>
> Hi--
>
> Anyone else experience problems with v90 and 2.0.81 DSP code?
> Up until Saturday, was running 1.2.25 code without problems
> since a similiar
> problem several months ago in the same location.
>
> Could the CO switch type have anything to do with it? Running
> 2.0.81 quite
> happily everywhere else,
> at this site on this DSP, try and negotiate a V90 connection
> and you get a
> long ugly tone and that's all.
> X2, fine. V34 & others, fine. V90? Not at all.
>
> I replaced the DSP even and no change. Same thing.
>
> Strange!!!
>
> SMT
>
> Scott M. Trautman 800-482-4638
> Global Dialog Internet 608-240-4638,4637fax
> 2810 Crossroads, STE LL2 scott@gdinet.com
> Madison WI 53718 http://www.gdinet.com
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) V90 & 2.0.81....problems only at one site
Date: 20 Sep 1999 15:53:23 -0500
And all our friends the ever lovely "Rockwells".
A 3com modem, DOES connect with V90 just fine.....
> -----Original Message-----
> From: Scott Trautman [mailto:scottt@corp.gdinet.com]
> Sent: Monday, September 20, 1999 3:43 PM
> To: 'usr-tc@lists.xmission.com'
> Subject: RE: (usr-tc) V90 & 2.0.81....problems only at one site
>
>
> Just downgraded to 1.25.90, still same thing. V90 squeels and
> that's it.
>
> IS there any CO settings that could have anything to do with this?
>
> I just learned that this starting to happen <didn't> start just after
> the DSP upgrade; users having problems now WERE able to get on until
> this morning, the upgrade was 24 hours before than and we can
> show they
> were able to get V90 connections previous to that.
>
> VERY weird....
>
> SMT
>
> > -----Original Message-----
> > From: Scott Trautman [mailto:scottt@corp.gdinet.com]
> > Sent: Monday, September 20, 1999 3:17 PM
> > To: 'usr-tc@lists.xmission.com'
> > Subject: (usr-tc) V90 & 2.0.81....problems only at one site
> >
> >
> > Hi--
> >
> > Anyone else experience problems with v90 and 2.0.81 DSP code?
> > Up until Saturday, was running 1.2.25 code without problems
> > since a similiar
> > problem several months ago in the same location.
> >
> > Could the CO switch type have anything to do with it? Running
> > 2.0.81 quite
> > happily everywhere else,
> > at this site on this DSP, try and negotiate a V90 connection
> > and you get a
> > long ugly tone and that's all.
> > X2, fine. V34 & others, fine. V90? Not at all.
> >
> > I replaced the DSP even and no change. Same thing.
> >
> > Strange!!!
> >
> > SMT
> >
> > Scott M. Trautman 800-482-4638
> > Global Dialog Internet 608-240-4638,4637fax
> > 2810 Crossroads, STE LL2 scott@gdinet.com
> > Madison WI 53718 http://www.gdinet.com
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) V90 & 2.0.81....problems only at one site
Date: 20 Sep 1999 16:43:22 -0500
Okay, so this time I REALLY downgraded it to 1.2.59 (sorry for the typo),
and it does in fact work again...V90 that is....very very odd.....
SMT
> -----Original Message-----
> From: Scott Trautman [mailto:scottt@corp.gdinet.com]
> Sent: Monday, September 20, 1999 3:43 PM
> To: 'usr-tc@lists.xmission.com'
> Subject: RE: (usr-tc) V90 & 2.0.81....problems only at one site
>
>
> Just downgraded to 1.25.90, still same thing. V90 squeels and
> that's it.
>
> IS there any CO settings that could have anything to do with this?
>
> I just learned that this starting to happen <didn't> start just after
> the DSP upgrade; users having problems now WERE able to get on until
> this morning, the upgrade was 24 hours before than and we can
> show they
> were able to get V90 connections previous to that.
>
> VERY weird....
>
> SMT
>
> > -----Original Message-----
> > From: Scott Trautman [mailto:scottt@corp.gdinet.com]
> > Sent: Monday, September 20, 1999 3:17 PM
> > To: 'usr-tc@lists.xmission.com'
> > Subject: (usr-tc) V90 & 2.0.81....problems only at one site
> >
> >
> > Hi--
> >
> > Anyone else experience problems with v90 and 2.0.81 DSP code?
> > Up until Saturday, was running 1.2.25 code without problems
> > since a similiar
> > problem several months ago in the same location.
> >
> > Could the CO switch type have anything to do with it? Running
> > 2.0.81 quite
> > happily everywhere else,
> > at this site on this DSP, try and negotiate a V90 connection
> > and you get a
> > long ugly tone and that's all.
> > X2, fine. V34 & others, fine. V90? Not at all.
> >
> > I replaced the DSP even and no change. Same thing.
> >
> > Strange!!!
> >
> > SMT
> >
> > Scott M. Trautman 800-482-4638
> > Global Dialog Internet 608-240-4638,4637fax
> > 2810 Crossroads, STE LL2 scott@gdinet.com
> > Madison WI 53718 http://www.gdinet.com
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 20:30:14 -0400 (EDT)
Most new TC chassis now come with a NMC using P-5 based processor.. not
the 486 or (ack) 386's that most of us still have on service.
Most P-5's have the screw terminals on the back of the NIC.
The 486's are dirt compated to the P-5's.. I have 1 and 2 486's... even
lightly loaded the 486 is butt slow for snmpwalks.
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Mon, 20 Sep 1999, Jeff Mcadams wrote:
> Thus spake Mike Andrews
> >That's exactly what I had before. :) I removed the usrCipPortIndex walk
> >by using the OIDs returned by the usrCipPortIpAddress walk and peeling the
> >port number off the end.
>
> Man...maybe we're using different PERL modules? The one we have will
> walk through 96 ports of data in something like a second or two...its
> *quite* fast....and that's displaying the output as it gets it, so its
> probably slowed down considerably by the display output. We're using
> http://cpan.valueclick.com/authors/id/GSM/SNMP-1.8.2.tar.gz
> and it seems to be quite quick. Also seems, from what I can tell so
> far...haven't checked in depth, to parallelize walks...ie, puts multiple
> getnext requests of different OIDs into a single request. Rather nice.
>
> >but... there are/were some tables where you cannot snmpget the
> >individual values in the table. For instance:
>
> >% snmpwalk -v 1 chass comm .1.3.6.1.4.1.429.blah.blah.blah | grep value
> >enterprises.usr.blah.blah.blah.foo = "value"
>
> >but then try to get it directly and it fails:
>
> >% snmpget -v 1 chass comm .1.3.6.1.4.1.429.blah.blah.blah.foo
> >This name doesn't exist: enterprises.usr.blah.blah.blah.foo
>
> Wow...I've not run into anything like that, but you're probably hitting
> more stuff than I am.
> --
> Jeff McAdams Email: jeffm@iglou.com
> Head Network Administrator Voice: (502) 966-3848
> IgLou Internet Services (800) 436-4456
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Allen Marsalis <am@shreve.net>
Subject: RE: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 20:04:30 -0500
At 01:59 PM 9/20/99 -0500, Mike Wronski wrote:
>Since the information you are asking for is not indexed by IP address it can
>never be retrieved with a single get.
>For that to work the ip would have to be a part of the OID. IE if the ip
>assigned
>was 10.10.10.1 the oid would be
Has anyone thought of retrieving the data (via snmp or telnet) on a
regular interval and placing it into a sql database to be served up
via php or other cgi? And indexed any way you like? If you have a
dozen or more ARC's on the network, and/or plan on a high hit rate
for the cgi (entire userbase), then there could be some real savings
by retrieving the data only once a minute instead of (potentially) many
times in a minute. I would think that polling/updating once every 60
seconds would be sufficient. just a thought..
Allen
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 21:13:34 -0400
Thus spake Paul Farber
>Most new TC chassis now come with a NMC using P-5 based processor.. not
>the 486 or (ack) 386's that most of us still have on service.
>Most P-5's have the screw terminals on the back of the NIC.
>The 486's are dirt compated to the P-5's.. I have 1 and 2 486's... even
>lightly loaded the 486 is butt slow for snmpwalks.
Oh, yeah...that's what I hear...I think Mike and I both are 486 based
across the board though, so I don't think that's the difference.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 21:16:21 -0400
Thus spake Allen Marsalis
>At 01:59 PM 9/20/99 -0500, Mike Wronski wrote:
>>Since the information you are asking for is not indexed by IP address it can
>>never be retrieved with a single get.
>>For that to work the ip would have to be a part of the OID. IE if the ip
>>assigned
>>was 10.10.10.1 the oid would be
>Has anyone thought of retrieving the data (via snmp or telnet) on a
>regular interval and placing it into a sql database to be served up
>via php or other cgi? And indexed any way you like? If you have a
>dozen or more ARC's on the network, and/or plan on a high hit rate
>for the cgi (entire userbase), then there could be some real savings
>by retrieving the data only once a minute instead of (potentially) many
>times in a minute. I would think that polling/updating once every 60
>seconds would be sufficient. just a thought..
I don't know...it probably would work...at the risk of working on
slightly stale data...proly not a big deal, but...
Our perl SNMP module that we're using is doing two walks on each chassis
with a total of over 1000 ports spread across 3 cities in a matter of
about 10 seconds total. These are for queries directly to the Arc, not
to the NMCs...somehow I don't think the actual SNMP operations on the
network and the agents are the problems.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 21:35:03 -0400 (EDT)
On Mon, 20 Sep 1999, Jeff Mcadams wrote:
> Thus spake Paul Farber
> >Most new TC chassis now come with a NMC using P-5 based processor.. not
> >the 486 or (ack) 386's that most of us still have on service.
>
> >Most P-5's have the screw terminals on the back of the NIC.
>
> >The 486's are dirt compated to the P-5's.. I have 1 and 2 486's... even
> >lightly loaded the 486 is butt slow for snmpwalks.
>
> Oh, yeah...that's what I hear...I think Mike and I both are 486 based
> across the board though, so I don't think that's the difference.
486SX, yeah. But it's definitely not the difference since we're talking
about querying the ARC directly, which only involves the PPC603 on it and
not the NMC at all. I'd rather not think about how much slower it would
be if I was using the NMC. :)
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Aaron Nabil <nabil@spiritone.com>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 18:44:39 -0700 (PDT)
Allen Marsalis writes...
>At 01:59 PM 9/20/99 -0500, Mike Wronski wrote:
>
>>Since the information you are asking for is not indexed by IP address it can
>>never be retrieved with a single get.
>>For that to work the ip would have to be a part of the OID. IE if the ip
>>assigned
>>was 10.10.10.1 the oid would be
>
>Has anyone thought of retrieving the data (via snmp or telnet) on a
>regular interval and placing it into a sql database to be served up
>via php or other cgi? And indexed any way you like? If you have a
>dozen or more ARC's on the network, and/or plan on a high hit rate
>for the cgi (entire userbase), then there could be some real savings
>by retrieving the data only once a minute instead of (potentially) many
>times in a minute. I would think that polling/updating once every 60
>seconds would be sufficient. just a thought..
Uh, I'm assuming they want to do this SNMP rigamarole for some specific
reason, and I'm guessing that, like us, they simply save the IP->username
association in a database when the person logs in. If it were just a
matter of finding out what user corresponds to which IP address (or
vice-versa), it's just a couple SQL queries.
--
Aaron Nabil
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Tony Loosle" <tony@tcsourceone.com>
Subject: Re: (usr-tc) Netserver8 Problem
Date: 20 Sep 1999 20:42:37 -0600
Greg,
Do you have the box talking to a syslog program??
tony
Greg Coffey wrote:
> I just got off the phone with a 3Com tech regarding an issue that we have
> with a Netserver8 Plus. The modems hang at least once a day and we have to
> go in and reset each manually to get them to answer an incoming call. We
> tried some S register settings and flashed the modems down to an earlier
> code version with no luck. The modems all still seem to hang at random
> intervals. I have a fair number of the older netserver16's still in
> service and we don't have this problem with any of them. This unit is
> fairly new, much newer than the NS16's that I have. After days of trying
> different things with them, 3Com now tells me that the code has problems
> and is nothing that they can or will fix. We can continue to reset the
> modems manually which is a royal pain and unacceptable. Their other
> suggestion is that I can upgrade the memory from 2meg to 4meg for $1300
> plus $300 for advanced shipping. I knew that memory prices recently went
> up but not by THAT much. Did I just buy a large doorstop or do any of you
> have any ideas that we can try?
>
> Thanks, Greg Coffey <gcoffey@vcn.com>
> Visionary Communications V 307-234-5443 F 307-234-5446
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Brett Murphy" <me@murf.net>
Subject: (usr-tc) SNMP script to disconnect ports
Date: 21 Sep 1999 12:50:41 +1000
Hi All,
Has anyone got a script that uses SNMP to disconnect
a port on Netserver and/or HyperARC that they would be
willing to share with me and/or the list?
All the best,
Brett Murphy
Technical Manager, Alphalink (Australia) PTY LTD
ph: +61 3 9486-8844 fax: +61 3 9486-6822
email: me@murf.net
The contents of this email message may not be quoted,
copied, reproduced or published in part or in whole,
without the written authorization of Brett Murphy,
Director, Alphalink (Australia) Pty Ltd.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Greg Coffey <greg@coffey.com>
Subject: Re: (usr-tc) Netserver8 Problem
Date: 20 Sep 1999 21:08:02 -0600
I don't know. We log the logins and logouts if that is what you are
asking. We don't have anything else that we log that I am aware of. What
do you have in mind?
At 08:42 PM 9/20/99 -0600, you wrote:
>Greg,
> Do you have the box talking to a syslog program??
>
>tony
>
>
>Greg Coffey wrote:
>
>> I just got off the phone with a 3Com tech regarding an issue that we have
>> with a Netserver8 Plus. The modems hang at least once a day and we have to
>> go in and reset each manually to get them to answer an incoming call. We
>> tried some S register settings and flashed the modems down to an earlier
>> code version with no luck. The modems all still seem to hang at random
>> intervals. I have a fair number of the older netserver16's still in
>> service and we don't have this problem with any of them. This unit is
>> fairly new, much newer than the NS16's that I have. After days of trying
>> different things with them, 3Com now tells me that the code has problems
>> and is nothing that they can or will fix. We can continue to reset the
>> modems manually which is a royal pain and unacceptable. Their other
>> suggestion is that I can upgrade the memory from 2meg to 4meg for $1300
>> plus $300 for advanced shipping. I knew that memory prices recently went
>> up but not by THAT much. Did I just buy a large doorstop or do any of you
>> have any ideas that we can try?
>>
>> Thanks, Greg Coffey <gcoffey@vcn.com>
>> Visionary Communications V 307-234-5443 F 307-234-5446
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> 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.
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
>
Thanks,
Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446
=====================================================================
142 S. Center St., Casper, WY 82601 WWW.VCN.COM
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Allen Marsalis <am@shreve.net>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 20 Sep 1999 22:29:55 -0500
At 06:44 PM 9/20/99 -0700, Aaron Nabil wrote:
>Allen Marsalis writes...
>>Has anyone thought of retrieving the data (via snmp or telnet) on a
>>regular interval and placing it into a sql database to be served up
>>via php or other cgi? And indexed any way you like? If you have a
>>dozen or more ARC's on the network, and/or plan on a high hit rate
>>for the cgi (entire userbase), then there could be some real savings
>>by retrieving the data only once a minute instead of (potentially) many
>>times in a minute. I would think that polling/updating once every 60
>>seconds would be sufficient. just a thought..
>
>Uh, I'm assuming they want to do this SNMP rigamarole for some specific
>reason, and I'm guessing that, like us, they simply save the IP->username
>association in a database when the person logs in. If it were just a
>matter of finding out what user corresponds to which IP address (or
>vice-versa), it's just a couple SQL queries.
>
:) nod..
Still, it looks like Mike is linking this cgi off a homepage which can
get a lot of hits in some cases.. (Just don't put a nude picture
near it mike ;)
Allen
>
>--
>Aaron Nabil
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Phil Le Clercq <phil.le.clercq@cinergy.net>
Subject: (usr-tc) User is disconnected once traffic starts.
Date: 21 Sep 1999 10:58:21 +0100
Hi all, having a problem whilst setting up our DSP's and ARC's, they are
running on TCS 3.6.
Basically a dial in user is authenticated fine and connects ok gets assigned
an IP etc using either chassis users or radius. The user can be logged in as
long as they want but as soon as traffic starts going accross the link the
call gets dropped after about 15 seconds.
I've set session_time out and that has not helped. I can't seem to get any
other ideas on this at the mo.
Has anyone had similar before?
Cheers, Phil
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: jeff.binkley@asacomp.com (Jeff Binkley)
Subject: (usr-tc) User is disconne
Date: 21 Sep 1999 06:59:00 -0500
What does RADIUS show as the disconnect cause ?
Jeff Binkley
ASA Network Computing
u>Hi all, having a problem whilst setting up our DSP's and ARC's, they
u>are running on TCS 3.6.
u>Basically a dial in user is authenticated fine and connects ok gets
u>assigned an IP etc using either chassis users or radius. The user can
u>be logged in as long as they want but as soon as traffic starts going
u>accross the link the call gets dropped after about 15 seconds.
u>I've set session_time out and that has not helped. I can't seem to get
u>any other ideas on this at the mo.
u>Has anyone had similar before?
u>Cheers, Phil
u>-
u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
u> with "unsubscribe usr-tc" in the body of the message.
u> For information on digests or retrieving files and old messages send
u> "help" to the same address. Do not use quotes in your message.
u>
CMPQwk 1.42 9999
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Phil Le Clercq <phil.le.clercq@cinergy.net>
Subject: RE: (usr-tc) User is disconne
Date: 21 Sep 1999 13:20:03 +0100
Thanks for the reply. I haven't checked that, because it is doing the same
for users authenticated on the chassis. So I was presuming something more
base level than that. Though if you reckon it'll point me in the right
direction as far as error codes etc?
Cheers Phil
-----Original Message-----
Sent: Tuesday, September 21, 1999 12:59 PM
What does RADIUS show as the disconnect cause ?
Jeff Binkley
ASA Network Computing
u>Hi all, having a problem whilst setting up our DSP's and ARC's, they
u>are running on TCS 3.6.
u>Basically a dial in user is authenticated fine and connects ok gets
u>assigned an IP etc using either chassis users or radius. The user can
u>be logged in as long as they want but as soon as traffic starts going
u>accross the link the call gets dropped after about 15 seconds.
u>I've set session_time out and that has not helped. I can't seem to get
u>any other ideas on this at the mo.
u>Has anyone had similar before?
u>Cheers, Phil
u>-
u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
u> with "unsubscribe usr-tc" in the body of the message.
u> For information on digests or retrieving files and old messages send
u> "help" to the same address. Do not use quotes in your message.
u>
CMPQwk 1.42 9999
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 21 Sep 1999 09:29:13 -0400 (EDT)
SNMP wise it is. The P-5 can whip out an entire chassis in a few seconds
to TCM... teh 486 takes about two minutes. Since all TCM is doing is
balking the majority of the MIB tree to get stats (like your program) the
snmpwalk time diff. on a 486 and P-5 is very noticible. Telnet seems to
have the same speed's for eace processor.
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Mon, 20 Sep 1999, Jeff Mcadams wrote:
> Thus spake Paul Farber
> >Most new TC chassis now come with a NMC using P-5 based processor.. not
> >the 486 or (ack) 386's that most of us still have on service.
>
> >Most P-5's have the screw terminals on the back of the NIC.
>
> >The 486's are dirt compated to the P-5's.. I have 1 and 2 486's... even
> >lightly loaded the 486 is butt slow for snmpwalks.
>
> Oh, yeah...that's what I hear...I think Mike and I both are 486 based
> across the board though, so I don't think that's the difference.
> --
> Jeff McAdams Email: jeffm@iglou.com
> Head Network Administrator Voice: (502) 966-3848
> IgLou Internet Services (800) 436-4456
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 21 Sep 1999 09:28:07 -0400
Thus spake Paul Farber
>SNMP wise it is. The P-5 can whip out an entire chassis in a few seconds
>to TCM... teh 486 takes about two minutes. Since all TCM is doing is
>balking the majority of the MIB tree to get stats (like your program) the
>snmpwalk time diff. on a 486 and P-5 is very noticible. Telnet seems to
>have the same speed's for eace processor.
Well...since TCM/SNMP is going to the NMC, and telnet is going to the
Arc, changing the NMC wouldn't improve telnet speeds much at all. :)
Besides...with this whole discussion, we're talking about sending SNMP
requests to the Arc directly, so the NMC's SNMP speed wouldn't come into
play in our situation either.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Tony Loosle" <tony@tcsourceone.com>
Subject: Re: (usr-tc) Netserver8 Problem
Date: 21 Sep 1999 08:12:45 -0600
You have to have a syslog deamon or program running. You have to tell the
netserver box where to send its messages. If you don't, it will fill up the
memory and crash!!!!
Tony
Greg Coffey wrote:
> I don't know. We log the logins and logouts if that is what you are
> asking. We don't have anything else that we log that I am aware of. What
> do you have in mind?
>
> At 08:42 PM 9/20/99 -0600, you wrote:
> >Greg,
> > Do you have the box talking to a syslog program??
> >
> >tony
> >
> >
> >Greg Coffey wrote:
> >
> >> I just got off the phone with a 3Com tech regarding an issue that we have
> >> with a Netserver8 Plus. The modems hang at least once a day and we have to
> >> go in and reset each manually to get them to answer an incoming call. We
> >> tried some S register settings and flashed the modems down to an earlier
> >> code version with no luck. The modems all still seem to hang at random
> >> intervals. I have a fair number of the older netserver16's still in
> >> service and we don't have this problem with any of them. This unit is
> >> fairly new, much newer than the NS16's that I have. After days of trying
> >> different things with them, 3Com now tells me that the code has problems
> >> and is nothing that they can or will fix. We can continue to reset the
> >> modems manually which is a royal pain and unacceptable. Their other
> >> suggestion is that I can upgrade the memory from 2meg to 4meg for $1300
> >> plus $300 for advanced shipping. I knew that memory prices recently went
> >> up but not by THAT much. Did I just buy a large doorstop or do any of you
> >> have any ideas that we can try?
> >>
> >> Thanks, Greg Coffey <gcoffey@vcn.com>
> >> Visionary Communications V 307-234-5443 F 307-234-5446
> >>
> >> -
> >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> >> 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.
> >
> >
> >-
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
> >
>
> Thanks,
>
> Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446
> =====================================================================
> 142 S. Center St., Casper, WY 82601 WWW.VCN.COM
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Charles Sprickman <spork@inch.com>
Subject: RE: (usr-tc) SNMP challenge: ARC username from IP address
Date: 21 Sep 1999 10:35:14 -0400 (EDT)
On Mon, 20 Sep 1999, Allen Marsalis wrote:
> At 01:59 PM 9/20/99 -0500, Mike Wronski wrote:
>
> Has anyone thought of retrieving the data (via snmp or telnet) on a
> regular interval and placing it into a sql database to be served up
> via php or other cgi? And indexed any way you like?
I hate to make another one of those Radiator plugs, but yes, we use it and
it accounts to a mysql db. So something like this is a trivial database
query... Works well and is very quick. Don't have to bother doing any
snmp unless you want the current connection speed, but at least then you
just do one snmpget. I believe alot of the other radius servers are now
offering the option of logging to a database as well...
Charles
> If you have a
> dozen or more ARC's on the network, and/or plan on a high hit rate
> for the cgi (entire userbase), then there could be some real savings
> by retrieving the data only once a minute instead of (potentially) many
> times in a minute. I would think that polling/updating once every 60
> seconds would be sufficient. just a thought..
>
> Allen
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 21 Sep 1999 11:06:12 -0400 (EDT)
I have a script that uses both the ARC and NMC OID's (so I can verify what
the chassis tells me via TCM). So I assumed that most others did the same
thing.
I know that there are tons of MIB viewers.. but using 3Com's TCM as a data
backup to verify program outout just makes sense.
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Tue, 21 Sep 1999, Jeff Mcadams wrote:
> Thus spake Paul Farber
> >SNMP wise it is. The P-5 can whip out an entire chassis in a few seconds
> >to TCM... teh 486 takes about two minutes. Since all TCM is doing is
> >balking the majority of the MIB tree to get stats (like your program) the
> >snmpwalk time diff. on a 486 and P-5 is very noticible. Telnet seems to
> >have the same speed's for eace processor.
>
> Well...since TCM/SNMP is going to the NMC, and telnet is going to the
> Arc, changing the NMC wouldn't improve telnet speeds much at all. :)
>
> Besides...with this whole discussion, we're talking about sending SNMP
> requests to the Arc directly, so the NMC's SNMP speed wouldn't come into
> play in our situation either.
> --
> Jeff McAdams Email: jeffm@iglou.com
> Head Network Administrator Voice: (502) 966-3848
> IgLou Internet Services (800) 436-4456
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 21 Sep 1999 11:09:02 -0400
Thus spake Paul Farber
>I have a script that uses both the ARC and NMC OID's (so I can verify what
>the chassis tells me via TCM). So I assumed that most others did the same
>thing.
>I know that there are tons of MIB viewers.. but using 3Com's TCM as a data
>backup to verify program outout just makes sense.
Assuming you're on a platform that supports TCM, and want to put up with
some of its braindeadedness (not all of it, but some). I find it
terribly tedious to use personally.
Besides...most of these data sources and the algorithms used to get this
data has been confirmed...just in discussion now is the fastest way to
get it. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Allen Marsalis <am@shreve.net>
Subject: RE: (usr-tc) SNMP challenge: ARC username from IP address
Date: 21 Sep 1999 10:24:11 -0500
At 10:35 AM 9/21/99 -0400, Charles Sprickman wrote:
>On Mon, 20 Sep 1999, Allen Marsalis wrote:
>
>> At 01:59 PM 9/20/99 -0500, Mike Wronski wrote:
>>
>> Has anyone thought of retrieving the data (via snmp or telnet) on a
>> regular interval and placing it into a sql database to be served up
>> via php or other cgi? And indexed any way you like?
>
>I hate to make another one of those Radiator plugs, but yes, we use it and
>it accounts to a mysql db. So something like this is a trivial database
>query... Works well and is very quick. Don't have to bother doing any
>snmp unless you want the current connection speed, but at least then you
>just do one snmpget. I believe alot of the other radius servers are now
>offering the option of logging to a database as well...
I agree, Radiator rocks the casba.. We use it in conjunction with
postgres sql and swear by it.
But for Mikes specific 'challenge' at hand, I'd rather impliment a
Radiator/sql like methodology, rather than walking the chassis (once
or twice) per cgi hit... especially if it was going on homepage(s)..
Allen
>
>Charles
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike Wronski" <mike@coredump.ae.usr.com>
Subject: RE: (usr-tc) SNMP challenge: ARC username from IP address
Date: 21 Sep 1999 10:35:09 -0500
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Allen Marsalis
|Sent: Tuesday, September 21, 1999 10:24 AM
|To: usr-tc@lists.xmission.com
|Subject: RE: (usr-tc) SNMP challenge: ARC username from IP address
|
|
|At 10:35 AM 9/21/99 -0400, Charles Sprickman wrote:
|>On Mon, 20 Sep 1999, Allen Marsalis wrote:
|>
|>> At 01:59 PM 9/20/99 -0500, Mike Wronski wrote:
|>>
|>> Has anyone thought of retrieving the data (via snmp or telnet) on a
|>> regular interval and placing it into a sql database to be served up
|>> via php or other cgi? And indexed any way you like?
|>
|>I hate to make another one of those Radiator plugs, but yes, we use it and
|>it accounts to a mysql db. So something like this is a trivial database
|>query... Works well and is very quick. Don't have to bother doing any
|>snmp unless you want the current connection speed, but at least then you
|>just do one snmpget. I believe alot of the other radius servers are now
|>offering the option of logging to a database as well...
|
|I agree, Radiator rocks the casba.. We use it in conjunction with
|postgres sql and swear by it.
|
|But for Mikes specific 'challenge' at hand, I'd rather impliment a
|Radiator/sql like methodology, rather than walking the chassis (once
|or twice) per cgi hit... especially if it was going on homepage(s)..
|
I would have to agree here. Either by logging the RADIUS accouting info to a DB
or if you set up the harc to send call details in the syslogs (FORMAT_ONE) and
either DB that or flat file for some interval, the search will be much faster and
non-impacting to the network.
-M
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Marcelo Barros <thbarros@ntwxpress.com.br>
Subject: Re: (usr-tc) Current Consumption
Date: 17 Sep 1999 10:21:00 -0300
Current (A) Current (A)
Configuration Choices +5.2 Volt +/- 12.2 Volt Watts
HiPer ARC 4 20.8 70.9
HiPer ARC Max. Set 7 36.4 124.1
HiPer DSP 4.3 22.4 76.2
HiPer DSP NIC only .6 3.1 10.6
HiPer DSP Set 4.9 25.5 86.9
EdgeServer Set 4.5 23.4 79.8
Digital Quad Modems 2.1 10.9 37.2
Quad Modem NIC 1 5.2 17.7
486 NETServer 3 15.6 53.2
NET Enet NIC 1.5 7.8 26.6
NET Token NIC 2 10.4 35.5
NMC (486SX) 3 15.6 53.2
NMC Enet NIC 1.5 7.8 26.6
Dual PRI NAC 1.5 7.8 26.6
Dual PRI NIC .5 2.6 8.9
At 09:00 9/17/99 -0400, you wrote:
>
>
>Can someone tell me the current consumption for:
>
> Quad-NAC
> Dual-PRI-NIC
> Dual-PRI-NAC
>
>Jim
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Chris Ashcraft" <Chris_Ashcraft@mw.3com.com>
Subject: (usr-tc) Managing a Total Control Chassis
Date: 10 Sep 1999 15:05:05 -0500
3Com is interested in how you manage the Total Control chassis. To help us
better serve you, please complete the brief section below and reply to this
email with your response.
=================================================================================
1. Simply rate the following Total Control management tools (1=used most; 3=used
least)
_ MIB browser (please indicate the software package you are using: NerveCenter,
CMU SNMP, UCD-SNMP, SNMPc, HP OpenView, other:___________)
_ Total Control Manager/HiPer ARC Manager
_ Terminal emulation (e.g., Telnet or HyperTerminal)
2. Do you manage the various Total Control cards differently? If so, please list
which of the above management tools you most often use for:
- Quad Modem:___________________
- Trunk Cards:___________________
- HiPer DSP:___________________
- HiPer ARC:___________________
- EdgeServer Cards:___________________
=================================================================================
Any other comments or suggestions are welcome.
Thank you for your time.
Carrier Systems Group
3Com Corp.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Marcelo Barros <thbarros@ntwxpress.com.br>
Subject: Re: (usr-tc) Sawin for Windows silently died?
Date: 10 Sep 1999 11:39:14 -0300
The correct part number is: USR 000950-07
At 16:19 9/10/99 +0200, you wrote:
>Hi
>When I went through the latest 3Com price list I could no longer find
>the Security and Accounting Server for Windows. Did anybody of you
>receive information about this product beeing discontinued?
>
>Thanks.
>
>Ralph
>
>
>--
>==========================================================================
>R. Helfenberger Internet r.helfenberger@comlight.ch
>Comlight AG Tel +41 31 740 40 40
>Industriestr. 17 Fax +41 31 740 40 90
>3178 Boesingen
>Switzerland www.comlight.ch
>==========================================================================
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Christopher Arlis Hanes" <chanes@inetconn.net>
Subject: (usr-tc) Static IPs with large dialin pools
Date: 09 Sep 1999 15:21:12 -0400
How does one handle static IPs when the pools used by a particular
dialin number span multiple class Cs? (i.e. a user dialing in has the
possibility of of dialing into a box whose router card is not on the
same network as the user's static IP.)
Thanks,
Chris Hanes
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Levent Cosan" <levent21@netzero.net>
Subject: (usr-tc) Rockwell HCF 56k v.90
Date: 09 Sep 1999 14:03:05 -0400
This is a multi-part message in MIME format.
------=_NextPart_000_0005_01BEFACC.0A10D420
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,=20
I have a HP computer and the modem is a Rockwell HCF 56k v.90 =
speakerphone pci modem. The modem dials out but it doesn't do the =
"handshake". I had the modem replaced but i still run into problems =
with the new modem. I usually get a, "no answer" or a "modem doesn't =
carrier a signal". I've tried numerous ISPs but i get the same error =
message. Any help will be appreciated
------=_NextPart_000_0005_01BEFACC.0A10D420
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#b8b8b8>
<DIV><FONT size=3D2>Hi, </FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>I have a HP computer and the modem is a Rockwell HCF =
56k v.90=20
speakerphone pci modem. The modem dials out but it doesn't do the=20
"handshake". I had the modem replaced but i still run into =
problems with=20
the new modem. I usually get a, "no answer" or a "modem doesn't =
carrier a=20
signal". I've tried numerous ISPs but i get the same error =
message. =20
Any help will be appreciated</FONT></DIV></BODY></HTML>
------=_NextPart_000_0005_01BEFACC.0A10D420--
________________________________________________________
NetZero - We believe in a FREE Internet. Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Christopher Arlis Hanes" <chanes@inetconn.net>
Subject: (usr-tc) Static IPs with large dialin pools
Date: 09 Sep 1999 10:13:47 -0400
How does one handle static IPs when the pools used by a particular
dialin number span multiple class Cs? (i.e. a user dialing in has the
possibility of of dialing into a box whose router card is not on the
same network as the user's static IP.)
Thanks,
Chris Hanes
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Ben Tyger (vh.net staff)" <bct@vh.net>
Subject: (usr-tc) Server Assigned DNS
Date: 08 Sep 1999 18:10:09 -0400
We are running a Port Master 2e, Total Control Netserver 16 v.34, and
NETServer 16 - I Modem Plus.
We are running it with 3.3.3 Livingston code.
I am interested in running server assigned DNS. Is this possible? If
so what changes to I have to do.
--
Ben Tyger
Virtual Horizons, Inc. technical staff
Home Page: www.vh.net
Tech email: support@vh.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: <pferraro@wna-linknet.com>
Subject: Re: (usr-tc) Current Consumption
Date: 21 Sep 1999 12:35:21 -0400 (EDT)
Are watts added together to get a ballpark consumption rate?
For example if I add all the components for a QUAD hub I get 820watts!
So if I have a 850watt UPS it will hold it for about 3 minutes...
I am looking for a way to spreadload power among UPSz!
==============================================================================
Phillip Ferraro WorldNet Access, Inc
pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
Voice (910) 346-0835 824 Gumbranch Square, Suite R3
FAX (910) 455-1933 Jacksonville, Nc 28540-6269
==============================================================================
On Fri, 17 Sep 1999, Marcelo Barros wrote:
>
> Current (A) Current (A)
> Configuration Choices +5.2 Volt +/- 12.2 Volt Watts
>
>
> HiPer ARC 4 20.8 70.9
> HiPer ARC Max. Set 7 36.4 124.1
> HiPer DSP 4.3 22.4 76.2
> HiPer DSP NIC only .6 3.1 10.6
> HiPer DSP Set 4.9 25.5 86.9
> EdgeServer Set 4.5 23.4 79.8
> Digital Quad Modems 2.1 10.9 37.2
> Quad Modem NIC 1 5.2 17.7
> 486 NETServer 3 15.6 53.2
> NET Enet NIC 1.5 7.8 26.6
> NET Token NIC 2 10.4 35.5
> NMC (486SX) 3 15.6 53.2
> NMC Enet NIC 1.5 7.8 26.6
> Dual PRI NAC 1.5 7.8 26.6
> Dual PRI NIC .5 2.6 8.9
>
>
> At 09:00 9/17/99 -0400, you wrote:
> >
> >
> >Can someone tell me the current consumption for:
> >
> > Quad-NAC
> > Dual-PRI-NIC
> > Dual-PRI-NAC
> >
> >Jim
> >
> >-
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: Re: (usr-tc) Rockwell HCF 56k v.90
Date: 21 Sep 1999 12:37:35 -0400
At 02:03 PM 9/9/99 -0400, "Levent Cosan" <levent21@netzero.net> wrote:
>Hi,
I have a HP computer and the modem is a Rockwell HCF 56k v.90 speakerphone
pci modem. The modem dials out but it doesn't do the "handshake". I had
the modem replaced but i still run into problems with the new modem. I
usually get a, "no answer" or a "modem doesn't carrier a signal". I've
tried numerous ISPs but i get the same error message. Any help will be
appreciated
HCF modems are notoriously crappy, but they do seem to perform somewhat
decently with the latest code. Check http://www.808hi.com/56k/rockhcf.htm
for pointers.
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Eric Billeter" <ebilleter@cableone.net>
Subject: (usr-tc) Anyone near Sioux City?
Date: 21 Sep 1999 09:54:24 -0700
I lost a power supply on a chassis this morning and the soonest I can get
one out there
this afternoon at 5:00 (into Omaha)
Anyone who can spare a Power Supply in the are would be greatly appreciated.
Please call on my cell phone if possible.
602-550-8477
Thanks
Eric Billeter
Internet Engineer
Cable One, Inc.
eric.billeter@cableone.net
602-364-6462
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: eric@dol.net
Subject: (usr-tc) wet total control units :((
Date: 21 Sep 1999 11:24:00 -0600
We had some total control racks get submerged during hurricane Floyd.
Has anyone had to recover units like this after sustaining water damage
and what is the best way to try and get the units back in shape?
thanks
eric
Delaware Online!.........The SMART Choice!
With 56K V.90 & X2 & Flex Modems
Phone : 302-762-0375
Fax: 302-762-3462
Failure is NOT an option...
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Aaron Nabil <nabil@spiritone.com>
Subject: Re: (usr-tc) wet total control units :((
Date: 21 Sep 1999 12:21:16 -0700 (PDT)
eric@dol.net writes...
>We had some total control racks get submerged during hurricane Floyd.
>Has anyone had to recover units like this after sustaining water damage
>and what is the best way to try and get the units back in shape?
Short answer, get a professional to do it. Also talk to your
insurance company first.
If you must do it yourself, here's the basic proceedure.
Dissassemble everything, cards out of rack, daughter cards
removed, SIMMS out of sockets.
First, wash everything with plain old water to get it
completely clean (were are talking garden hose here). You
may want to use some surfactant, if you can find one
that is non-reactive. It may be difficult to get crud out
of sockets, but you need to get it completely clean.
After the garden hose, wash everything down with some DI
(or distilled, if that what you can have handy) water.
Shake the water off everything, or let it drip for a few mins.
Dunk everything in anyhydrous isopropanol (this dissolves the
remaining water out of things like contacts), shake it off.
Bake in an oven, say 150F, till dry.
--
Aaron Nabil
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: RE: (usr-tc) Server Assigned DNS
Date: 21 Sep 1999 14:26:14 -0500
set nameserver 10.0.0.1
set nameserver 2 10.0.0.2
Nothing else should be needed, the Portmasters and Netservers will correctly
send the dns servers as part of a normal PPP negotiation sequence with a
customer dialing in...
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ben Tyger (vh.net
staff)
Sent: Wednesday, September 08, 1999 5:10 PM
We are running a Port Master 2e, Total Control Netserver 16 v.34, and
NETServer 16 - I Modem Plus.
We are running it with 3.3.3 Livingston code.
I am interested in running server assigned DNS. Is this possible? If
so what changes to I have to do.
--
Ben Tyger
Virtual Horizons, Inc. technical staff
Home Page: www.vh.net
Tech email: support@vh.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: RE: (usr-tc) Static IPs with large dialin pools
Date: 21 Sep 1999 14:25:03 -0500
You have to run an interior routing protocol such as RIP or OSPF or apply
static routes on your gateway router. I highly suggest using an interior
routing protocol...
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Christopher Arlis
Hanes
Sent: Thursday, September 09, 1999 9:14 AM
How does one handle static IPs when the pools used by a particular
dialin number span multiple class Cs? (i.e. a user dialing in has the
possibility of of dialing into a box whose router card is not on the
same network as the user's static IP.)
Thanks,
Chris Hanes
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: RE: (usr-tc) Server Assigned DNS
Date: 21 Sep 1999 14:26:14 -0500
set nameserver 10.0.0.1
set nameserver 2 10.0.0.2
Nothing else should be needed, the Portmasters and Netservers will correctly
send the dns servers as part of a normal PPP negotiation sequence with a
customer dialing in...
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ben Tyger (vh.net
staff)
Sent: Wednesday, September 08, 1999 5:10 PM
We are running a Port Master 2e, Total Control Netserver 16 v.34, and
NETServer 16 - I Modem Plus.
We are running it with 3.3.3 Livingston code.
I am interested in running server assigned DNS. Is this possible? If
so what changes to I have to do.
--
Ben Tyger
Virtual Horizons, Inc. technical staff
Home Page: www.vh.net
Tech email: support@vh.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) Static IPs with large dialin pools
Date: 21 Sep 1999 15:39:36 -0400
Thus spake Mike McHenry
>You have to run an interior routing protocol such as RIP or OSPF or apply
>static routes on your gateway router. I highly suggest using an interior
>routing protocol...
Of, if you're willing to toss the concept of address classes out the
window (which I strongly urge you to do), you could just use a shorter
netmask on the network, and everything happily continues to work. (if
you insist on thinking classfully, this would be considered a supernet)
:)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Theodore Cekan" <ted@mho.net>
Subject: (usr-tc) problems with CHAP authentication
Date: 21 Sep 1999 13:38:48 -0600
Hi,
I have a user trying to dial in with a Livingston Office Router U-AP,
running software version 3.7.1 AP.5. For some reason they cannot connect to
my TC Hiper system, ARC verson 4.1.59, unless PAP is selected as the only
allowed authentication scheme. "Any" doesnt work, chap kicks in and they
get denied access. The Livingston box does have chap turned off, btw. We
are stumped. Any help is much appreciated.
Thanks
Ted Cekan
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: RE: (usr-tc) problems with CHAP authentication
Date: 21 Sep 1999 16:47:15 -0300
Have you tried doing "set ppp authENTICATION_PREFERENCE pap"? That should
set PAP as the first authentication protocol to be used.
On Tuesday, September 21, 1999 4:39 PM, Theodore Cekan [SMTP:ted@mho.net]
wrote:
> Hi,
>
> I have a user trying to dial in with a Livingston Office Router U-AP,
> running software version 3.7.1 AP.5. For some reason they cannot connect
to
> my TC Hiper system, ARC verson 4.1.59, unless PAP is selected as the only
> allowed authentication scheme. "Any" doesnt work, chap kicks in and they
> get denied access. The Livingston box does have chap turned off, btw. We
> are stumped. Any help is much appreciated.
>
> Thanks
>
> Ted Cekan
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Jason Cropper" <jason@clearsail.net>
Subject: RE: (usr-tc) problems with CHAP authentication
Date: 21 Sep 1999 14:50:56 -0500
Do you want to use CHAP or PAP? You're not clear in your message.
Jason
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Theodore Cekan
Sent: Tuesday, September 21, 1999 14:39
Hi,
I have a user trying to dial in with a Livingston Office Router U-AP,
running software version 3.7.1 AP.5. For some reason they cannot connect to
my TC Hiper system, ARC verson 4.1.59, unless PAP is selected as the only
allowed authentication scheme. "Any" doesnt work, chap kicks in and they
get denied access. The Livingston box does have chap turned off, btw. We
are stumped. Any help is much appreciated.
Thanks
Ted Cekan
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: RE: (usr-tc) Static IPs with large dialin pools
Date: 21 Sep 1999 15:00:50 -0500
Actually this will not work on certain equipment like Livingston Portmaster
2s even though it should. Portmaster 2s do not seem to like any dialin
network outside of the class C their ethernet port lives on. The other
disadvantage with trying to side-step running OSPF or RIP is the difficulty
in dealing with "routed network" or "static IP" customers. It quickly
becomes a pain to deal with people having to dial into specific termservers
to get their network blocks correctly routed to them.
I suggest taking the jump now and running OSPF or RIP, you will probably
have to sooner or later and it really makes life easy when you are done
configuring it.
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
Sent: Tuesday, September 21, 1999 2:40 PM
Thus spake Mike McHenry
>You have to run an interior routing protocol such as RIP or OSPF or apply
>static routes on your gateway router. I highly suggest using an interior
>routing protocol...
Of, if you're willing to toss the concept of address classes out the
window (which I strongly urge you to do), you could just use a shorter
netmask on the network, and everything happily continues to work. (if
you insist on thinking classfully, this would be considered a supernet)
:)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Theodore Cekan" <ted@mho.net>
Subject: Re: (usr-tc) problems with CHAP authentication
Date: 21 Sep 1999 14:08:07 -0600
Sorry, I need to use PAP. CHAP wont authenticate for some reason.
Ted Cekan
Mile High Online
-----Original Message-----
>Do you want to use CHAP or PAP? You're not clear in your message.
>
>Jason
>
>
>-----Original Message-----
>From: owner-usr-tc@lists.xmission.com
>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Theodore Cekan
>Sent: Tuesday, September 21, 1999 14:39
>To: usr-tc@lists.xmission.com
>Subject: (usr-tc) problems with CHAP authentication
>
>
>Hi,
>
>I have a user trying to dial in with a Livingston Office Router U-AP,
>running software version 3.7.1 AP.5. For some reason they cannot connect
to
>my TC Hiper system, ARC verson 4.1.59, unless PAP is selected as the only
>allowed authentication scheme. "Any" doesnt work, chap kicks in and they
>get denied access. The Livingston box does have chap turned off, btw. We
>are stumped. Any help is much appreciated.
>
>Thanks
>
>Ted Cekan
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) Static IPs with large dialin pools
Date: 21 Sep 1999 16:10:26 -0400
Thus spake Mike McHenry
>Actually this will not work on certain equipment like Livingston Portmaster
>2s even though it should. Portmaster 2s do not seem to like any dialin
>network outside of the class C their ethernet port lives on. The other
>disadvantage with trying to side-step running OSPF or RIP is the difficulty
>in dealing with "routed network" or "static IP" customers. It quickly
>becomes a pain to deal with people having to dial into specific termservers
>to get their network blocks correctly routed to them.
>I suggest taking the jump now and running OSPF or RIP, you will probably
>have to sooner or later and it really makes life easy when you are done
>configuring it.
Oh...I heartily agree...practically speaking you're going to be better
off going to a dynamically routed situation when you get to that point
(we use RIPv2 redistributed into OSPF at the first hop cisco). Just
pointed out that the old classful thinking doesn't (shouldn't) restrict
you to a single "Class C".
Personally, if I set this up and found that a PM wouldn't handle a
"supernet." I'd be calling Livingston^WLucent and screaming bloody
murder at not supporting classless addressing correctly. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Clayton Zekelman <clayton@MNSi.Net>
Subject: Re: (usr-tc) problems with CHAP authentication
Date: 21 Sep 1999 16:13:10 -0400
If you're using a Radius server with a DEFAULT entry pointing to a Unix
password file, rather
than storing the individual user profiles in the users file with passwords
in clear text, CHAP will fail.
To make CHAP work, add an entry for that user in the Radius users file.
At 02:08 PM 9/21/99 -0600, you wrote:
>Sorry, I need to use PAP. CHAP wont authenticate for some reason.
>
>Ted Cekan
>Mile High Online
>-----Original Message-----
>From: Jason Cropper <jason@clearsail.net>
>To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>
>Date: Tuesday, September 21, 1999 2:03 PM
>Subject: RE: (usr-tc) problems with CHAP authentication
>
>
>>Do you want to use CHAP or PAP? You're not clear in your message.
>>
>>Jason
>>
>>
>>-----Original Message-----
>>From: owner-usr-tc@lists.xmission.com
>>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Theodore Cekan
>>Sent: Tuesday, September 21, 1999 14:39
>>To: usr-tc@lists.xmission.com
>>Subject: (usr-tc) problems with CHAP authentication
>>
>>
>>Hi,
>>
>>I have a user trying to dial in with a Livingston Office Router U-AP,
>>running software version 3.7.1 AP.5. For some reason they cannot connect
>to
>>my TC Hiper system, ARC verson 4.1.59, unless PAP is selected as the only
>>allowed authentication scheme. "Any" doesnt work, chap kicks in and they
>>get denied access. The Livingston box does have chap turned off, btw. We
>>are stumped. Any help is much appreciated.
>>
>>Thanks
>>
>>Ted Cekan
>>
>>
>>
>>-
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> 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.
>>
>>
>>-
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> 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.
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6
tel. 519-985-8410
fax. 519-258-3009
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Theodore Cekan" <ted@mho.net>
Subject: Re: (usr-tc) problems with CHAP authentication
Date: 21 Sep 1999 14:22:10 -0600
Thanks Matthew, that worked! Does this setting mean that all users will now
be authenticated with PAP? Will it ever even try CHAP for users that can
use it?
Ted Cekan
-----Original Message-----
>
>Have you tried doing "set ppp authENTICATION_PREFERENCE pap"? That should
>set PAP as the first authentication protocol to be used.
>
>On Tuesday, September 21, 1999 4:39 PM, Theodore Cekan [SMTP:ted@mho.net]
>wrote:
>> Hi,
>>
>> I have a user trying to dial in with a Livingston Office Router U-AP,
>> running software version 3.7.1 AP.5. For some reason they cannot connect
>to
>> my TC Hiper system, ARC verson 4.1.59, unless PAP is selected as the only
>> allowed authentication scheme. "Any" doesnt work, chap kicks in and they
>> get denied access. The Livingston box does have chap turned off, btw.
We
>> are stumped. Any help is much appreciated.
>>
>> Thanks
>>
>> Ted Cekan
>>
>>
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> 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.
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: RE: (usr-tc) problems with CHAP authentication
Date: 21 Sep 1999 15:38:18 -0500
Yes, the USR will still try CHAP if you have it enabled. This setting FORCES
the USR to try PAP negotiation first which is what you really want it to do.
Then if PAP fails it will proceed with other forms of authentication
including CHAP.
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Theodore Cekan
Sent: Tuesday, September 21, 1999 3:22 PM
Thanks Matthew, that worked! Does this setting mean that all users will now
be authenticated with PAP? Will it ever even try CHAP for users that can
use it?
Ted Cekan
-----Original Message-----
>
>Have you tried doing "set ppp authENTICATION_PREFERENCE pap"? That should
>set PAP as the first authentication protocol to be used.
>
>On Tuesday, September 21, 1999 4:39 PM, Theodore Cekan [SMTP:ted@mho.net]
>wrote:
>> Hi,
>>
>> I have a user trying to dial in with a Livingston Office Router U-AP,
>> running software version 3.7.1 AP.5. For some reason they cannot connect
>to
>> my TC Hiper system, ARC verson 4.1.59, unless PAP is selected as the only
>> allowed authentication scheme. "Any" doesnt work, chap kicks in and they
>> get denied access. The Livingston box does have chap turned off, btw.
We
>> are stumped. Any help is much appreciated.
>>
>> Thanks
>>
>> Ted Cekan
>>
>>
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> 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.
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jim Johnson <jim@perigee.net>
Subject: (usr-tc) Cisco 802
Date: 21 Sep 1999 16:39:11 -0400
Can anyone post a working config for a cisco 802 router connecting to a
Total Control?
Thanks,
Jim
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: RE: (usr-tc) Static IPs with large dialin pools
Date: 21 Sep 1999 15:42:21 -0500
> Personally, if I set this up and found that a PM wouldn't handle a
> "supernet." I'd be calling Livingston^WLucent and screaming bloody
> murder at not supporting classless addressing correctly. :)
I pulled out enough hair on this one myself that I probably should. There is
nothing like equipment that does not properly work with classless addressing
:) It may well work as it should now, however I think ComOS 3.7.2 exhibited
the same odd behavior and that is the most recent "stable" OS for the
platform. In any case I thought I would throw out a warning for others...
The main benefit IMO of running an IRP (interior routing protocol) is that
any of my customers can dial into any bank of equipment at any time and get
the same IP address or network block that I have assigned them. Without
running some sort of IRP this is impossible to do. Just thought I would
clarify that for anyone who was interested in the difference between running
OSPF/RIP and not running it.
Mike McHenry
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) Static IPs with large dialin pools
Date: 21 Sep 1999 17:04:38 -0400
Thus spake Mike McHenry
>> Personally, if I set this up and found that a PM wouldn't handle a
>> "supernet." I'd be calling Livingston^WLucent and screaming bloody
>> murder at not supporting classless addressing correctly. :)
>I pulled out enough hair on this one myself that I probably should. There is
>nothing like equipment that does not properly work with classless addressing
>:) It may well work as it should now, however I think ComOS 3.7.2 exhibited
>the same odd behavior and that is the most recent "stable" OS for the
>platform. In any case I thought I would throw out a warning for others...
Lovely...doncha just love bug hunting supposedly non-beta software for
vendors? :/
>The main benefit IMO of running an IRP (interior routing protocol) is that
>any of my customers can dial into any bank of equipment at any time and get
>the same IP address or network block that I have assigned them. Without
>running some sort of IRP this is impossible to do. Just thought I would
>clarify that for anyone who was interested in the difference between running
>OSPF/RIP and not running it.
Amen...and if you're careful about how you assign your dynamic IP
addresses for the non-static customers, you can still do summarization
on them at your first-hop (maybe even sooner!) which will cut down on
the /32's being advertised around your network...big win there! :) I
tend to do summarization on the first-hop cisco since they have better
control over summarization and redistribution. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jim Johnson <jim@perigee.net>
Subject: (usr-tc) Cisco 802 Connecting to ARC
Date: 21 Sep 1999 17:35:41 -0400
We are trying to connect a Cisco 802 to our HiperARC chassis using ISDN
and not having much success.
Mon Radius shows the router authenticated fine.
Mon PPP shows only an Outgoing PAP AUTH packet on the link.
The router shows that it was authenticated.
But then there is no additional PPP traffic.
Eventually, the ARC gets an incoming LCP TERM packet from the router
when the router decides to close down the link.
The radius entry for the router is:
router Password=secret
Framed-IP-Address=xxx.xxx.32.35,
Framed-IP-Netmask=255.255.255.255,
Framed-Route="xxx.xxx.33.8/30 xxx.xxx.32.35 1"
I'm sure there is something realy simple I am missing here...
Thanks,
-Jim Johnson
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Steve Rivera <sales@wrca.net>
Subject: (usr-tc) WTB: Quad Analog/Digital Modems
Date: 21 Sep 1999 17:46:37 -0400
Sorry for the intrusion, but I am member of this list and know
there are some of you that can help me out.
I am located in NJ, hit pretty good by floyd.
I have several customers that are in the same situation as Eric at Delaware
Online.
Soaked Equipment, although the drying methods mentioned will work in some cases
it doesnt in most. After several attempts in that manner we are on the look
out.
If you have any quad analog/digital cards that you can sell or trade out
for Quad digitals,
you'd be helping out some of your own.
We have heard some great support stories during this crisis. I hope we can
add to it :)
Please email or call me at sales@wrca.net or 732-833-2111
Appraciate any offers for available modem cards.
....................................................
Steve Rivera - VP-WR Consultant Associates, Inc. (WRCA)
sales@wrca.net v-732-833-2111 pgr-732-325-1092
WAN ACCESS SPECIALIST---http://www.wrca.net (CompleteLine Card)
Cisco, Ascend,USR,Adtran, Kentrox,Livingston, Microcom,Computone,Verilink
IBM,Motorola,UDS,Codex,ATT/Paradyne,Hayes,Racal Datacom,GDC,Telebit
MultiTech,Sync/Tylink,Wellfleet,BayNetworks(5399),Black Box,Micom & More
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Bob Purdon (Lists)" <lists@aussie.nu>
Subject: Re: (usr-tc) Static IPs with large dialin pools
Date: 22 Sep 1999 08:42:36 +1000 (EST)
> How does one handle static IPs when the pools used by a particular
> dialin number span multiple class Cs? (i.e. a user dialing in has the
> possibility of of dialing into a box whose router card is not on the
> same network as the user's static IP.)
We actually force such users to NOT be in the same network as the 'router'
card's NIC. The routing is handled by redistributing the RIPv2 routes
into OSPF.
Bob Purdon, Ground Floor, Marine Board Building
Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000
Southern Internet Services. +61 (3) 6234 7444
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Bob Purdon (Lists)" <lists@aussie.nu>
Subject: RE: (usr-tc) Static IPs with large dialin pools
Date: 22 Sep 1999 08:46:31 +1000 (EST)
> Actually this will not work on certain equipment like Livingston
> Portmaster 2s even though it should. Portmaster 2s do not seem to like
> any dialin network outside of the class C their ethernet port lives
> on.
Hmmm, don't tell ours that...
Bob Purdon, Ground Floor, Marine Board Building
Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000
Southern Internet Services. +61 (3) 6234 7444
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: John Nelson <johnn@jorsm.com>
Subject: (usr-tc) Problems with a busy channel with no connection on it.
Date: 21 Sep 1999 18:14:41 -0500
We have a problem with a DSP (2.0.81), where the central office sees the
trunk as idle, but TC is saying the trunk is busy. CLI on the hiper list
connections shows nothing being connected to the card in question.
Incoming calls were not failing, they were just given a busy signal. The
card was put local out of service, the PRI is being used on another card
with no problems as we speak, but TC is still showing one led lit in the
modem section. Session monitor is showing one connection on one port only,
even without a PRI. Has anyone else seen this problem? Where did it come
from? How/can we catch this when/if it happens again? I know that
resetting the card will more than likely clear everything up. Its just
really strange to me.
-John-
=========================================================|
| -John Nelson | email: |
| --Technical Support | johnn@jorsm.com |
| ---JORSM Internet | |
| ----Toll Free # 1-877-JORSM95 | |
==========================================================
==========================================================
| JORSM Internet |
| Regional Premium Internet Service Provider |
| Serving Chicagoland and NW Indiana |
| 927 Sheffield Ave Dyer, IN |
| Tech hours: M-F 9-9, Sat 10-2 http://www.jorsm.com |
==========================================================
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Robert Reynolds <lists@lcii.net>
Subject: (usr-tc) Sega DreamCast
Date: 21 Sep 1999 19:33:21 -0500 (CDT)
Anyone been able to get one these to connect to a TC or is it just me?
Connected fine to our Cisco.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Ed" <ed@taylors.com>
Subject: Re: (usr-tc) Sega DreamCast
Date: 21 Sep 1999 21:30:23 -0400
Yes should work no problem. Have signed up at least 30 of them already.
Ed
----- Original Message -----
Sent: Tuesday, September 21, 1999 8:33 PM
Anyone been able to get one these to connect to a TC or is it just me?
Connected fine to our Cisco.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Rick <rallan@monmouth.com>
Subject: Re: (usr-tc) Playing with OSPF
Date: 21 Sep 1999 21:34:52 -0400
You have to set the arc to be an ASBR (set ospf global asbr enable). Unlike
cisco and other vendors where ASBR is determined by the ospf configuration, you
must explicitly tell the arc to be an ASBR. Pretty backwards if you ask me but
then again...
Mike McHenry wrote:
> I have recently upgraded most of my HiperARC cards to 4.2.32-1 and have
> started looking at switching them from RIP to OSPF. Everything is working as
> I would expect for host dialins, HOWEVER it seems that the ARC is not
> advertising any Framed-Routes setup through radius.
>
> For example, an entry like the following in radius:
>
> username Auth-Type=System
> Service-Type=Framed-User,
> Framed-IP-Address = 192.168.0.1,
> Framed-Route = "10.0.0.1/24 192.168.0.1 1",
> Framed-Routing = None,
>
> Once username dials into the TC the host route for 192.168.0.1 is correctly
> broadcast through OSPF but the 10.0.0.1/24 route is not. Am I missing a
> setting here or is this the normal behavior for the ARC card? Every other
> piece of equipment I have recognizes this route added in through radius and
> correctly advertise the route through OSPF.
>
> Mike
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone
Head of Network Engineering | Monmouth Internet Corporation
732-842-5366=====extension 102 | http://www.monmouth.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Rick <rallan@monmouth.com>
Subject: Re: (usr-tc) Playing with OSPF
Date: 21 Sep 1999 21:34:52 -0400
You have to set the arc to be an ASBR (set ospf global asbr enable). Unlike
cisco and other vendors where ASBR is determined by the ospf configuration, you
must explicitly tell the arc to be an ASBR. Pretty backwards if you ask me but
then again...
Mike McHenry wrote:
> I have recently upgraded most of my HiperARC cards to 4.2.32-1 and have
> started looking at switching them from RIP to OSPF. Everything is working as
> I would expect for host dialins, HOWEVER it seems that the ARC is not
> advertising any Framed-Routes setup through radius.
>
> For example, an entry like the following in radius:
>
> username Auth-Type=System
> Service-Type=Framed-User,
> Framed-IP-Address = 192.168.0.1,
> Framed-Route = "10.0.0.1/24 192.168.0.1 1",
> Framed-Routing = None,
>
> Once username dials into the TC the host route for 192.168.0.1 is correctly
> broadcast through OSPF but the 10.0.0.1/24 route is not. Am I missing a
> setting here or is this the normal behavior for the ARC card? Every other
> piece of equipment I have recognizes this route added in through radius and
> correctly advertise the route through OSPF.
>
> Mike
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone
Head of Network Engineering | Monmouth Internet Corporation
732-842-5366=====extension 102 | http://www.monmouth.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Rick <rallan@monmouth.com>
Subject: Re: (usr-tc) RE: (3Com-TotalControl) Framed routes not being picked up
Date: 21 Sep 1999 21:41:07 -0400
Mike, rather then having to add a new OSPF SENDPOLICY for each framed-route
profile(when you have hundreds that option is no longer feasible) why not
just enable ASBR globally. We have it working here using " set ospf global
asbr enable" . It seems the arc believes the framed-routes are being learned
via another AS so it then propagates the route via ospf.
Mike Wronski wrote:
> |-----Original Message-----
> |From: owner-totalcontrol@totalservice.3com.com
> |[mailto:owner-totalcontrol@totalservice.3com.com]On Behalf Of Mike
> |McHenry
> |Sent: Monday, September 20, 1999 7:01 AM
> |Subject: (3Com-TotalControl) Framed routes not being picked up by OSPF
> |broadcasts?
> |
> |
> |Reply to user-forum-totalcontrol@totalservice.3com.com
> |
> |
> |I have recently upgraded most of my HiperARC cards to 4.2.32-1 and have
> |started looking at switching them from RIP to OSPF. Everything is
> |working as I would expect for host dialins, HOWEVER it seems that the
> |ARC is not advertising any Framed-Routes setup through radius.
> |
> |For example, an entry like the following in radius:
> |
> |username Auth-Type=System
> | Service-Type=Framed-User,
> | Framed-IP-Address = 192.168.0.1,
> | Framed-Route = "10.0.0.1/24 192.168.0.1 1",
> | Framed-Routing = None,
> |
> |Once username dials into the TC the host route for 192.168.0.1 is
> |correctly broadcast through OSPF but the 10.0.0.1/24 route is not. Am I
> |missing a setting here or is this the normal behavior for the ARC card?
> |Every other piece of equipment I have recognizes this route added in
> |through radius and correctly advertise the route through OSPF.
> |
>
> At this time you have to add a "SEND Policy" to get the framed-routes to
> advertise. This iss done by
> "ADD OSPF SENDPOLICY 10.0.0.1/24 SOURCE REMOTE ACTION ADVERTISE"
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone
Head of Network Engineering | Monmouth Internet Corporation
732-842-5366=====extension 102 | http://www.monmouth.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: Re: (usr-tc) Sega DreamCast
Date: 21 Sep 1999 21:47:00 -0400
At 07:33 PM 9/21/99 -0500, Robert Reynolds <lists@lcii.net> wrote:
>Anyone been able to get one these to connect to a TC or is it just me?
>
>Connected fine to our Cisco.
This was discussed recently, I believe the answer was to enable ppp offloading
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Michael DeMan" <michael@prf.org>
Subject: Re: (usr-tc) Playing with OSPF
Date: 21 Sep 1999 20:47:50 -0700
Hi,
How dangerous is the move from RIP to OSPF from a service outage point
of view? I've never done OSPF routing before, but have been reading about
it, and want to move over as soon as I can, but I'm worried about making a
mess of the TC unit and having it down for a long period of time.
Any advice out there?
- Mike
----------
>From: Rick <rallan@monmouth.com>
>To: usr-tc@lists.xmission.com
>Subject: Re: (usr-tc) Playing with OSPF
>Date: Tue, Sep 21, 1999, 6:34 PM
>
>You have to set the arc to be an ASBR (set ospf global asbr enable). Unlike
>cisco and other vendors where ASBR is determined by the ospf configuration, you
>must explicitly tell the arc to be an ASBR. Pretty backwards if you ask me but
>then again...
>
>
>
>Mike McHenry wrote:
>
>> I have recently upgraded most of my HiperARC cards to 4.2.32-1 and have
>> started looking at switching them from RIP to OSPF. Everything is working as
>> I would expect for host dialins, HOWEVER it seems that the ARC is not
>> advertising any Framed-Routes setup through radius.
>>
>> For example, an entry like the following in radius:
>>
>> username Auth-Type=System
>> Service-Type=Framed-User,
>> Framed-IP-Address = 192.168.0.1,
>> Framed-Route = "10.0.0.1/24 192.168.0.1 1",
>> Framed-Routing = None,
>>
>> Once username dials into the TC the host route for 192.168.0.1 is correctly
>> broadcast through OSPF but the 10.0.0.1/24 route is not. Am I missing a
>> setting here or is this the normal behavior for the ARC card? Every other
>> piece of equipment I have recognizes this route added in through radius and
>> correctly advertise the route through OSPF.
>>
>> Mike
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> 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.
>
>--
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone
>Head of Network Engineering | Monmouth Internet Corporation
>732-842-5366=====extension 102 | http://www.monmouth.com
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: RE: (usr-tc) Playing with OSPF
Date: 21 Sep 1999 22:54:40 -0500
I highly recommend playing with it late at night, major routing changes
never work as expected :) Leave your RIP routing configurations intact and
worse case you can bring RIP back up if you can't get OSPF to work. If you
have enough extra capacity just busy out a USR TC chassis and play with it.
When you are in the middle of making changes anyone dialed into the chassis
will not be able to go anywhere (depending on your exact routing
configuration) so it is a somewhat disruptive thing to do.
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael DeMan
Sent: Tuesday, September 21, 1999 10:48 PM
Hi,
How dangerous is the move from RIP to OSPF from a service outage point
of view? I've never done OSPF routing before, but have been reading about
it, and want to move over as soon as I can, but I'm worried about making a
mess of the TC unit and having it down for a long period of time.
Any advice out there?
- Mike
----------
>From: Rick <rallan@monmouth.com>
>To: usr-tc@lists.xmission.com
>Subject: Re: (usr-tc) Playing with OSPF
>Date: Tue, Sep 21, 1999, 6:34 PM
>
>You have to set the arc to be an ASBR (set ospf global asbr enable). Unlike
>cisco and other vendors where ASBR is determined by the ospf configuration,
you
>must explicitly tell the arc to be an ASBR. Pretty backwards if you ask me
but
>then again...
>
>
>
>Mike McHenry wrote:
>
>> I have recently upgraded most of my HiperARC cards to 4.2.32-1 and have
>> started looking at switching them from RIP to OSPF. Everything is working
as
>> I would expect for host dialins, HOWEVER it seems that the ARC is not
>> advertising any Framed-Routes setup through radius.
>>
>> For example, an entry like the following in radius:
>>
>> username Auth-Type=System
>> Service-Type=Framed-User,
>> Framed-IP-Address = 192.168.0.1,
>> Framed-Route = "10.0.0.1/24 192.168.0.1 1",
>> Framed-Routing = None,
>>
>> Once username dials into the TC the host route for 192.168.0.1 is
correctly
>> broadcast through OSPF but the 10.0.0.1/24 route is not. Am I missing a
>> setting here or is this the normal behavior for the ARC card? Every other
>> piece of equipment I have recognizes this route added in through radius
and
>> correctly advertise the route through OSPF.
>>
>> Mike
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> 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.
>
>--
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone
>Head of Network Engineering | Monmouth Internet Corporation
>732-842-5366=====extension 102 | http://www.monmouth.com
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Marius Strom <marius@alpha1.net>
Subject: Re: (usr-tc) Sega DreamCast
Date: 21 Sep 1999 23:15:57 -0500 (CDT)
Connected fine to our TC.. Had to tack an extra "," behind the phone # to
delay the 56k negotiation, however.
--
Marius Strom <marius@alpha1.net>
Professional Geek/Unix System Administrator
Alpha1 Internet <http://www.alpha1.net>
http://www.marius.org/marius.pgp 0x5645C228
In theory, there is no difference between theory and practice...
...In practice, there is a big difference.
On Tue, 21 Sep 1999, Robert Reynolds wrote:
> Anyone been able to get one these to connect to a TC or is it just me?
>
> Connected fine to our Cisco.
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Brian M. Gordon" <administrator@westelcom.com>
Subject: Re: (usr-tc) Sega DreamCast
Date: 22 Sep 1999 07:49:59 -0400
Assign DNS manual.
----- Original Message -----
Sent: Tuesday, September 21, 1999 9:47 PM
> At 07:33 PM 9/21/99 -0500, Robert Reynolds <lists@lcii.net> wrote:
> >Anyone been able to get one these to connect to a TC or is it just me?
> >
> >Connected fine to our Cisco.
>
> This was discussed recently, I believe the answer was to enable ppp
offloading
>
>
> --
> Kirk Mitchell-General Manager mitch@keyconn.net
> Keystone Connect Unlock Your World
> Altoona, PA 814-941-5000 http://www.keyconn.net
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Jamie Orzechowski" <mhz@ripnet.com>
Subject: Re: (usr-tc) Sega DreamCast
Date: 22 Sep 1999 08:41:03 -0400
I believe the dreamcast uses an HCF =)
----- Original Message -----
Sent: Tuesday, September 21, 1999 9:47 PM
> At 07:33 PM 9/21/99 -0500, Robert Reynolds <lists@lcii.net> wrote:
> >Anyone been able to get one these to connect to a TC or is it just me?
> >
> >Connected fine to our Cisco.
>
> This was discussed recently, I believe the answer was to enable ppp
offloading
>
>
> --
> Kirk Mitchell-General Manager mitch@keyconn.net
> Keystone Connect Unlock Your World
> Altoona, PA 814-941-5000 http://www.keyconn.net
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Brian <signal@shreve.net>
Subject: Re: (usr-tc) Static IPs with large dialin pools
Date: 22 Sep 1999 08:16:50 -0500 (CDT)
On Thu, 9 Sep 1999, Christopher Arlis Hanes wrote:
> How does one handle static IPs when the pools used by a particular
> dialin number span multiple class Cs? (i.e. a user dialing in has the
> possibility of of dialing into a box whose router card is not on the
> same network as the user's static IP.)
use a dynamic interior routing protocol like OSPF/RipV2
>
> Thanks,
> Chris Hanes
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Chris Ashcraft" <Chris_Ashcraft@mw.3com.com>
Subject: Re: (usr-tc) Sega DreamCast
Date: 22 Sep 1999 08:43:19 -0500
Hi Ben,
Should we keep a list of tips and tricks per the current client modems, e.g.,
the Sega DreamCast modem, Rockwell, and so on? see below
Thanks
/Chris
K Mitchell <mitch@keyconn.net> on 09/21/99 08:47:00 PM
Please respond to usr-tc@lists.xmission.com
Sent by: K Mitchell <mitch@keyconn.net>
cc: (Chris Ashcraft/MW/US/3Com)
At 07:33 PM 9/21/99 -0500, Robert Reynolds <lists@lcii.net> wrote:
>Anyone been able to get one these to connect to a TC or is it just me?
>
>Connected fine to our Cisco.
This was discussed recently, I believe the answer was to enable ppp offloading
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) Managing a Total Control Chassis
Date: 22 Sep 1999 09:41:23 -0400 (EDT)
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Fri, 10 Sep 1999, Chris Ashcraft wrote:
>
>
> 3Com is interested in how you manage the Total Control chassis. To help us
> better serve you, please complete the brief section below and reply to this
> email with your response.
>
> =================================================================================
>
> 1. Simply rate the following Total Control management tools (1=used most; 3=used
> least)
>
> 1 MIB browser (please indicate the software package you are using:
NerveCenter,
> CMU SNMP, UCD-SNMP, SNMPc, HP OpenView, other:(_________)
> 2 Total Control Manager/HiPer ARC Manager
> 3 Terminal emulation (e.g., Telnet or HyperTerminal)
>
> 2. Do you manage the various Total Control cards differently? If so, please list
> which of the above management tools you most often use for:
> - Quad Modem:___________________
> - Trunk Cards:___________________
> - HiPer DSP:CLI
> - HiPer ARC:CLI
> - EdgeServer Cards:___________________
>
> =================================================================================
>
> Any other comments or suggestions are welcome.
>
PORT TCM TO LINUX! PORT TCM TO LINUX! PORT TCM TO LINUX!
> Thank you for your time.
>
> Carrier Systems Group
> 3Com Corp.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Chris Ashcraft" <Chris_Ashcraft@mw.3com.com>
Subject: Re: (usr-tc) Sega DreamCast
Date: 22 Sep 1999 08:50:20 -0500
Please disregard my last email.
==============================================================================
Hi Ben,
Should we keep a list of tips and tricks per the current client modems, e.g.,
the Sega DreamCast modem, Rockwell, and so on? see below
Thanks
/Chris
K Mitchell <mitch@keyconn.net> on 09/21/99 08:47:00 PM
Please respond to usr-tc@lists.xmission.com
Sent by: K Mitchell <mitch@keyconn.net>
cc: (Chris Ashcraft/MW/US/3Com)
At 07:33 PM 9/21/99 -0500, Robert Reynolds <lists@lcii.net> wrote:
>Anyone been able to get one these to connect to a TC or is it just me?
>
>Connected fine to our Cisco.
This was discussed recently, I believe the answer was to enable ppp offloading
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Brian <signal@shreve.net>
Subject: (usr-tc) p50 question
Date: 22 Sep 1999 10:15:54 -0500 (CDT)
A little off topic, please no flames, I figured this would be the best
list to ask this on.
On the p50, do you have to configure the Rem Address to the IP address of
say your router, your NAS, etc, or is their a way to just say like 0.0.0.0
and have it use the next hop? How do you all go about this?
Brian
Brian Feeny (BF304) signal@shreve.net
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jim Johnson <jim@perigee.net>
Subject: (usr-tc) Cisco 800 to Arc
Date: 22 Sep 1999 11:21:30 -0400
I am still having trouble getting any traffic passing between the ARCs
and a Cisco 800.
The MON PPP for the user is below:
Outgoing PPP Data on interface: slot:14/mod:3
PAP ACK ....Tracing for user "xxx"; Escape to
stop...
Outgoing PPP Data on interface: slot:10/mod:13
PAP ACK ....Tracing for user "xxx"; Escape to
stop...
Incoming PPP Data on interface: slot:10/mod:13
LCP TERM_REQ
Outgoing PPP Data on interface: slot:10/mod:13
LCP TERM_ACK
Anyone have a suggestion?
Thanks,
Jim
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jim Johnson <jim@perigee.net>
Subject: (usr-tc) Cisco 800 to Arc
Date: 22 Sep 1999 11:56:02 -0400
If anyone out there can take a look at this config/debug trace and tell
me what the problem is, I would appreciate it. I hope I am not wrong in
assuming that the Cisco 800 series can connect to the USR TC chassis.
Regards,
Jim
ARC MON PPP
----------
On the ARC all I see is:
Outgoing PPP Data on interface: slot:10/mod:13
PAP ACK ....Tracing for user "xxx"; Escape to
stop...
Incoming PPP Data on interface: slot:10/mod:13
LCP TERM_REQ
Outgoing PPP Data on interface: slot:10/mod:13
LCP TERM_ACK
Cisco Config
--------------------------
!
version 12.0
no service pad
service timestamps debug uptime
service timestamps log uptime
service password-encryption
service udp-small-servers
service tcp-small-servers
!
hostname Router
!
no logging console
enable secret 5 $1$3NxJ$hNMKdU72/q/0z9vJLJRkv.
!
ip subnet-zero
!
isdn switch-type basic-ni
!
!
!
interface Ethernet0
ip address xxx.xxx.63.9 255.255.255.252
no ip directed-broadcast
!
interface BRI0
description PPP to Internet
ip address negotiated
no ip directed-broadcast
encapsulation ppp
dialer idle-timeout 2147483
dialer map ip xxx.xxx.60.3 5551212
dialer hold-queue 10
dialer load-threshold 1 outbound
dialer-group 1
isdn switch-type basic-ni
isdn spid1 70455511110100
isdn spid2 70455511120100
no fair-queue
no cdp enable
no ppp lcp fast-start
ppp authentication pap
ppp pap sent-username dsi password 7 130C2111020812
Debug Session
03:07:55840355292: BR0:1 PPP: Treating connection as a callout
03:07:55834615808: BR0:1 PPP: Phase is ESTABLISHING, Active Open
03:07:55835256358: BR0:1 LCP: O CONFREQ [Closed] id 174 len 14
03:07:60129542143: BR0:1 LCP: AuthProto PAP (0x0304C023)
03:07:55834615808: BR0:1 LCP: MagicNumber 0xD0B16CC6 (0x0506D0B16CC6)
03:07:14: BR0:1 PPP: I pkt type 0xC021, datagramsize 33
03:07:14: BR0:1 LCP: I CONFREQ [REQsent] id 1 len 29
03:07:14: BR0:1 LCP: MRU 1514 (0x010405EA)
03:07:14: BR0:1 LCP: AuthProto PAP (0x0304C023)
03:07:14: BR0:1 LCP: MagicNumber 0xB6EBDD04 (0x0506B6EBDD04)
03:07:14: BR0:1 LCP: PFC (0x0702)
03:07:14: BR0:1 LCP: ACFC (0x0802)
03:07:14: BR0:1 LCP: MRRU 1514 (0x110405EA)
03:07:14: BR0:1 LCP: EndpointDisc 0 Null (0x130300)
03:07:15: BR0:1 LCP: O CONFREJ [REQsent] id 1 len 11
.03:07:15: BR0:1 LCP: MRRU 1514 (0x110405EA)
03:07:15: BR0:1 LCP: EndpointDisc 0 Null (0x130300)
03:07:15: BR0:1 PPP: I pkt type 0xC021, datagramsize 26
03:07:15: BR0:1 LCP: I CONFREQ [REQsent] id 2 len 22
03:07:15: BR0:1 LCP: MRU 1514 (0x010405EA)
03:07:15: BR0:1 LCP: AuthProto PAP (0x0304C023)
03:07:15: BR0:1 LCP: MagicNumber 0xB6EBDD04 (0x0506B6EBDD04)
03:07:15: BR0:1 LCP: PFC (0x0702)
03:07:15: BR0:1 LCP: ACFC (0x0802)
03:07:15: BR0:1 LCP: O CONFACK [REQsent] id 2 len 22
03:07:15: BR0:1 LCP: MRU 1514 (0x010405EA)
03:07:15: BR0:1 LCP: AuthProto PAP (0x0304C023)
03:07:15: BR0:1 LCP: MagicNumber 0xB6EBDD04 (0x0506B6EBDD04)
03:07:15: BR0:1 LCP: PFC (0x0702)
03:07:15: BR0:1 LCP: ACFC (0x0802)
03:07:15: BR0:1 LCP: TIMEout: State ACKsent
03:07:15: BR0:1 LCP: O CONFREQ [ACKsent] id 175 len 14
03:07:15: BR0:1 LCP: AuthProto PAP (0x0304C023)
03:07:15: BR0:1 LCP: MagicNumber 0xD0B16CC6 (0x0506D0B16CC6)
03:07:15: BR0:1 PPP: I pkt type 0xC021, datagramsize .18
03:07:15: BR0:1 LCP: I CONFACK [ACKsent] id 175 len 14
03:07:15: BR0:1 LCP: AuthProto PAP (0x0304C023)
03:07:15: BR0:1 LCP: MagicNumber 0xD0B16CC6 (0x0506D0B16CC6)
03:07:15: BR0:1 LCP: State is Open
03:07:15: BR0:1 PPP: Phase is AUTHENTICATING, by both
03:07:15: BR0:1: PAP_SENDREQUEST (0x288A500) id 0 (0s.) queued
1/1/2
03:07:15: BR0:1: AAA_PER_USER LCP_UP (0x288A5B0) id 0 (0s.)
queued 2/2/2
03:07:15: BR0:1: PAP_SENDREQUEST (0x288A500) id 0 (0s.) busy/0
started 1/2/2
03:07:15: BR0:1 PAP: O AUTH-REQ id 51 len 15 from "dsi"
03:07:15: BR0:1: PAP_SENDREQUEST (0x288A500) id 0 (0s.) busy/0 done
in 0 s. 0/1/2
03:07:15: BR0:1: AAA_PER_USER LCP_UP (0x288A5B0) id 0 (0s.)
busy/0 started 1/1/2
03:07:15: BR0:1: AAA_PER_USER LCP_UP (0x288A5B0) id 0 (0s.)
busy/0 done in 0 s. 0/0/2
03:07:16: BR0:1 PPP: I pkt type 0xC023, datagramsize 9
03:07:16: BR0:1 PAP: I AUTH-ACK id 51 len 5.
03:07:19: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 9440140
..
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Kurtiss Johnson" <Kurtiss_Johnson@mw.3com.com>
Subject: (usr-tc) Moving on
Date: 22 Sep 1999 11:35:30 -0500
As a few of you have heard, I have reached a decision to move on to other
opportunites, and so today is my last day with 3Com. I have certainly enjoyed
my time with USR and then 3Com, made a lot of good friends (and met my wife!),
and worked with a top-notch group of people both within and outside of the
company. To say that I've had a lot of fun would be an understatement.
I've been with USR/3Com for 7 years (almost exactly to the day), and it's time
to move on to something different. I'll be taking a position with Advanced
Switching Communications (ASC, Inc. - www.asc1.com) starting 9/27/99, where
I'll be The Product Management Team. (Yes, the entire team. It's no longer
challenging enough for me to be a single person, so I'm going to try to be a
team now. OK, I'm kidding...actually, it's a start-up company.)
I'm moving to Virginia (Washington DC/Reston/Vienna-area) as part of this new
position, and as such I don't have an e-mail address or phone number at the new
work location yet. In the meantime, I can be reached at "kwjohn@ais.net" or
"kwjohn@mindspring.net" going forward. (Yes, those of you who know me shouldn't
be surprised that I have two private e-mail accounts on two different ISPs.) In
the meantime, I'll be unsubscribing from the various mail-lists that I'm a part
of. I may be resubscribing to some of them, depending on my available time.
The networking industry is small, and I am certain that I'll cross paths with
many of you again throughout our careers. I look forward to it.
Best of luck to all.
KJ
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: (usr-tc) RE: (3Com-TotalControl) Framed routes not being picked up by OSPF broadcasts?
Date: 22 Sep 1999 12:58:50 -0500
Thank you for the advice everyone, turns out you do have to have the
sendpolicy in place for framed routes to get advertised. This seems to be
the case even with ASBR enabled, at least in my testing. I was however able
to add a blanket sendpolicy that covered all my network blocks with one
policy, something like
add ospf sendpolicy 10.0.0.0/19 source remote action advertise
This seems to correctly broadcast any framed route built by the ARC card in
the 32 class C network blocks starting at 10.0.0.0
For anyone else who is interested in working on OSPF here are the commands
(in order) that I used to configure OSPF on my USR ARC card. This was using
area 1 with MD5 authentication, the eth:1 interface is 10.0.0.1, possible
framed routes coming from 10.0.1.0/19
set ospf default_area_id 0.0.0.1
set ip network ip routing_protocol ospf
set ospf global router_id 10.0.0.1
set ospf global asbr enable
enable ospf
set ospf interface 10.0.0.1 router_priority 0
set ospf interface 10.0.0.1 auth_type cryptographic
add ospf cryptographic_key 1 interface 10.0.0.1 shared_key "YOUR_OSPF_KEY"
add ospf sendpolicy 10.0.1.0/19 source remote action advertise
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Rick
Sent: Tuesday, September 21, 1999 8:41 PM
Cc: user-forum-totalcontrol@totalservice.3com.com
picked up by OSPF broadcasts?
Mike, rather then having to add a new OSPF SENDPOLICY for each framed-route
profile(when you have hundreds that option is no longer feasible) why not
just enable ASBR globally. We have it working here using " set ospf global
asbr enable" . It seems the arc believes the framed-routes are being learned
via another AS so it then propagates the route via ospf.
Mike Wronski wrote:
> |-----Original Message-----
> |From: owner-totalcontrol@totalservice.3com.com
> |[mailto:owner-totalcontrol@totalservice.3com.com]On Behalf Of Mike
> |McHenry
> |Sent: Monday, September 20, 1999 7:01 AM
> |Subject: (3Com-TotalControl) Framed routes not being picked up by OSPF
> |broadcasts?
> |
> |
> |Reply to user-forum-totalcontrol@totalservice.3com.com
> |
> |
> |I have recently upgraded most of my HiperARC cards to 4.2.32-1 and have
> |started looking at switching them from RIP to OSPF. Everything is
> |working as I would expect for host dialins, HOWEVER it seems that the
> |ARC is not advertising any Framed-Routes setup through radius.
> |
> |For example, an entry like the following in radius:
> |
> |username Auth-Type=System
> | Service-Type=Framed-User,
> | Framed-IP-Address = 192.168.0.1,
> | Framed-Route = "10.0.0.1/24 192.168.0.1 1",
> | Framed-Routing = None,
> |
> |Once username dials into the TC the host route for 192.168.0.1 is
> |correctly broadcast through OSPF but the 10.0.0.1/24 route is not. Am I
> |missing a setting here or is this the normal behavior for the ARC card?
> |Every other piece of equipment I have recognizes this route added in
> |through radius and correctly advertise the route through OSPF.
> |
>
> At this time you have to add a "SEND Policy" to get the framed-routes to
> advertise. This iss done by
> "ADD OSPF SENDPOLICY 10.0.0.1/24 SOURCE REMOTE ACTION ADVERTISE"
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone
Head of Network Engineering | Monmouth Internet Corporation
732-842-5366=====extension 102 | http://www.monmouth.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: (usr-tc) Channelized T1 vs PRI
Date: 22 Sep 1999 15:29:01 -0300
Overnight tonight the telco is changing one of our T1s to channelized T1
from PRI service for testing. I seem to remember that there is different
code for the dual T1/PRI cards depending on which service you have but I'm
using all DSPs now and I can't seem to have any CT1 specific code for these
cards on TotalService. Does the one code base now support both CT1 and PRI
or am I missing something?
Thanks...
Matthew
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) Channelized T1 vs PRI
Date: 22 Sep 1999 14:37:09 -0400 (EDT)
On Wed, 22 Sep 1999, Stainforth, Matthew wrote:
>
> Overnight tonight the telco is changing one of our T1s to channelized T1
> from PRI service for testing. I seem to remember that there is different
> code for the dual T1/PRI cards depending on which service you have but I'm
> using all DSPs now and I can't seem to have any CT1 specific code for these
> cards on TotalService. Does the one code base now support both CT1 and PRI
yes
> or am I missing something?
no
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: RE: (usr-tc) Channelized T1 vs PRI
Date: 22 Sep 1999 13:46:25 -0500
You should be able to use the same code for either a PRI or a channelized T1
on the DSP, just go into the TCM, select the T1 portion of the DSP (top LED
below the power LED), click Configure-->Programmed Settings-->Trunk Settings
You will see a setting called signal mode, it should be set to robbed bit
for a channelized T1 and message oriented for a PRI. Unless the telco is
changing other things (ie switch type, etc) that should be the only setting
you need to change when the telco changes your PRI to a channelized T1.
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew
Sent: Wednesday, September 22, 1999 1:29 PM
Overnight tonight the telco is changing one of our T1s to channelized T1
from PRI service for testing. I seem to remember that there is different
code for the dual T1/PRI cards depending on which service you have but I'm
using all DSPs now and I can't seem to have any CT1 specific code for these
cards on TotalService. Does the one code base now support both CT1 and PRI
or am I missing something?
Thanks...
Matthew
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: RE: (usr-tc) Channelized T1 vs PRI
Date: 22 Sep 1999 15:48:48 -0300
Part of the reason we're doing this is because CT1 is cheaper but I've never
used CT1 before and I'm wondering what other functionality we're going to
lose. I gather it will no longer be possible to do busy out the channels
from this end and we'll also probably lose ANI too. Are there any other
drawbacks that I might be overlooking?
On Wednesday, September 22, 1999 3:46 PM, Mike McHenry
[SMTP:mmchen@minn.net] wrote:
> You should be able to use the same code for either a PRI or a channelized
T1
> on the DSP, just go into the TCM, select the T1 portion of the DSP (top
LED
> below the power LED), click Configure-->Programmed Settings-->Trunk
Settings
>
> You will see a setting called signal mode, it should be set to robbed bit
> for a channelized T1 and message oriented for a PRI. Unless the telco is
> changing other things (ie switch type, etc) that should be the only
setting
> you need to change when the telco changes your PRI to a channelized T1.
>
> Mike McHenry
> Systems Administrator
> MinnNet Communications, Inc.
>
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew
> Sent: Wednesday, September 22, 1999 1:29 PM
> To: 'usr-tc@lists.xmission.com'
> Subject: (usr-tc) Channelized T1 vs PRI
>
>
>
> Overnight tonight the telco is changing one of our T1s to channelized T1
> from PRI service for testing. I seem to remember that there is different
> code for the dual T1/PRI cards depending on which service you have but I'm
> using all DSPs now and I can't seem to have any CT1 specific code for
these
> cards on TotalService. Does the one code base now support both CT1 and
PRI
> or am I missing something?
>
> Thanks...
>
> Matthew
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) Channelized T1 vs PRI
Date: 22 Sep 1999 14:59:52 -0400 (EDT)
You have to set signeling type from Message Oriented to RobbedBit in
TC.
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Wed, 22 Sep 1999, Stainforth, Matthew wrote:
>
> Overnight tonight the telco is changing one of our T1s to channelized T1
> from PRI service for testing. I seem to remember that there is different
> code for the dual T1/PRI cards depending on which service you have but I'm
> using all DSPs now and I can't seem to have any CT1 specific code for these
> cards on TotalService. Does the one code base now support both CT1 and PRI
> or am I missing something?
>
> Thanks...
>
> Matthew
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jim Riley <jriley@infinityhealthcare.com>
Subject: Re: (usr-tc) Channelized T1 vs PRI
Date: 22 Sep 1999 13:54:07 -0500
This is a cryptographically signed message in MIME format.
--------------ms6DDF3DF98072ECBB8D34148C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
You will no longer be able to do ISDN.
"Stainforth, Matthew" wrote:
>
> Part of the reason we're doing this is because CT1 is cheaper but I've never
> used CT1 before and I'm wondering what other functionality we're going to
> lose. I gather it will no longer be possible to do busy out the channels
> from this end and we'll also probably lose ANI too. Are there any other
> drawbacks that I might be overlooking?
>
> On Wednesday, September 22, 1999 3:46 PM, Mike McHenry
> [SMTP:mmchen@minn.net] wrote:
> > You should be able to use the same code for either a PRI or a channelized
> T1
> > on the DSP, just go into the TCM, select the T1 portion of the DSP (top
> LED
> > below the power LED), click Configure-->Programmed Settings-->Trunk
> Settings
> >
> > You will see a setting called signal mode, it should be set to robbed bit
> > for a channelized T1 and message oriented for a PRI. Unless the telco is
> > changing other things (ie switch type, etc) that should be the only
> setting
> > you need to change when the telco changes your PRI to a channelized T1.
> >
> > Mike McHenry
> > Systems Administrator
> > MinnNet Communications, Inc.
> >
> > -----Original Message-----
> > From: owner-usr-tc@lists.xmission.com
> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew
> > Sent: Wednesday, September 22, 1999 1:29 PM
> > To: 'usr-tc@lists.xmission.com'
> > Subject: (usr-tc) Channelized T1 vs PRI
> >
> >
> >
> > Overnight tonight the telco is changing one of our T1s to channelized T1
> > from PRI service for testing. I seem to remember that there is different
> > code for the dual T1/PRI cards depending on which service you have but I'm
> > using all DSPs now and I can't seem to have any CT1 specific code for
> these
> > cards on TotalService. Does the one code base now support both CT1 and
> PRI
> > or am I missing something?
> >
> > Thanks...
> >
> > Matthew
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
--
Jim Riley jriley@infinityhealthcare.com
Network Specialist
Infinity HealthCare, Inc. voice (414) 290-6751
1251 Glen Oaks Lane fax (414) 290-6780
Mequon, WI 53092
===================================================
--------------ms6DDF3DF98072ECBB8D34148C
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIKUQYJKoZIhvcNAQcCoIIKQjCCCj4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
B90wggSnMIIEEKADAgECAhBRgJfTBjkhitGgd/zVpHdLMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MDUyNjAwMDAw
MFoXDTAwMDYwODIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEjAQBgNVBAMUCUppbSBSaWxleTEsMCoGCSqGSIb3DQEJ
ARYdanJpbGV5QGluZmluaXR5aGVhbHRoY2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAJ1wHI4M+VobqaDFePhj9NTcjhYgsOHcmGSvFpXYClv4MsKEiZ4KrlTttkTAnbpK
x6yCORhvMzDPJqausWuajtVXrZg6oliNTxLIayLJX+urAO9Cq5UJDWuMm7TpkS3XXNjv9QI3
0zp//l7xwGqhFuOEo8BMNeD2/tLbIT3tx6ItAgMBAAGjggE4MIIBNDAJBgNVHRMEAjAAMIGs
BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB
ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5
NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEGBwQiFiAxMjBkMWE3
NzUxYzBiMTg2MjE3MTNkNWYwYTFiNjkyYTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3Js
LnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBACPb4IlP1WpnvNDd
cxV0AuVhVFqLM9lFixLUSZD9CFJ+Fp2z5yZi9B54c2NjU4dGTiXTUxZKSI2Okczptzt5Uiec
h8G7fErsKpRi0D6o8QNV8UWSMDXGECPnmNkq20Ptr4BWPDoYIoqHYNLG+sd4zNNZXNUwO7hw
DmvlPY7W1t+7MIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQEC
BQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5D
bGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUx
MjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u
Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD
VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25h
IE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6
ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIO
Aukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nb
N2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CG
SAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3
O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7D
PrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqax
qJLFWGrBjQM868PNBaKQrm4xggI8MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24s
IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52
ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMp
OTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
LVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQUYCX0wY5IYrRoHf81aR3SzAJBgUrDgMCGgUAoIGx
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MDkyMjE4NTQw
N1owIwYJKoZIhvcNAQkEMRYEFFkVYqROGzLrZ7IxVvDqtrx98EIMMFIGCSqGSIb3DQEJDzFF
MEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFA
MA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAj84915UYeLEjyeY8RyHhHiY+idb7
uN2Xv/yg9/T49ryfqL+ForXRUDqsWcAAy8594U/BvNTF9MeNNqG0r6f6nQXD6YEfDaPf3Zxj
kbDPrCYcJuZAFbbV2aoHhuKBk064QRJ/1mbYkAx4ASMmuRMLFlgtFaMhX8xQfLtu/8AhkF8=
--------------ms6DDF3DF98072ECBB8D34148C--
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: RE: (usr-tc) Channelized T1 vs PRI
Date: 22 Sep 1999 14:04:46 -0500
You should be able to busy out channels just like you did before with a CT1.
CT1s also support ANI if configured that way from the telco. The only
functionality I figure you will lose is the ability to take incoming 64k
clear channel ISDN calls on your Total Control chassis.
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew
Sent: Wednesday, September 22, 1999 1:49 PM
Part of the reason we're doing this is because CT1 is cheaper but I've never
used CT1 before and I'm wondering what other functionality we're going to
lose. I gather it will no longer be possible to do busy out the channels
from this end and we'll also probably lose ANI too. Are there any other
drawbacks that I might be overlooking?
On Wednesday, September 22, 1999 3:46 PM, Mike McHenry
[SMTP:mmchen@minn.net] wrote:
> You should be able to use the same code for either a PRI or a channelized
T1
> on the DSP, just go into the TCM, select the T1 portion of the DSP (top
LED
> below the power LED), click Configure-->Programmed Settings-->Trunk
Settings
>
> You will see a setting called signal mode, it should be set to robbed bit
> for a channelized T1 and message oriented for a PRI. Unless the telco is
> changing other things (ie switch type, etc) that should be the only
setting
> you need to change when the telco changes your PRI to a channelized T1.
>
> Mike McHenry
> Systems Administrator
> MinnNet Communications, Inc.
>
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew
> Sent: Wednesday, September 22, 1999 1:29 PM
> To: 'usr-tc@lists.xmission.com'
> Subject: (usr-tc) Channelized T1 vs PRI
>
>
>
> Overnight tonight the telco is changing one of our T1s to channelized T1
> from PRI service for testing. I seem to remember that there is different
> code for the dual T1/PRI cards depending on which service you have but I'm
> using all DSPs now and I can't seem to have any CT1 specific code for
these
> cards on TotalService. Does the one code base now support both CT1 and
PRI
> or am I missing something?
>
> Thanks...
>
> Matthew
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Clayton Zekelman <clayton@MNSi.Net>
Subject: RE: (usr-tc) Channelized T1 vs PRI
Date: 22 Sep 1999 15:03:30 -0400
At 01:46 PM 9/22/99 -0500, you wrote:
>You should be able to use the same code for either a PRI or a channelized T1
>on the DSP, just go into the TCM, select the T1 portion of the DSP (top LED
>below the power LED), click Configure-->Programmed Settings-->Trunk Settings
>
>You will see a setting called signal mode, it should be set to robbed bit
>for a channelized T1 and message oriented for a PRI. Unless the telco is
>changing other things (ie switch type, etc)
>
Switch type makes no difference on a CT1
>that should be the only setting
>you need to change when the telco changes your PRI to a channelized T1.
>
You need to reboot the DSP card, and most likely the ARC card. In our
experience, the ARC still shows it as a 23 channel circuit 'till you
reboot, then it goes to 24.
>Mike McHenry
> Systems Administrator
> MinnNet Communications, Inc.
>
>-----Original Message-----
>From: owner-usr-tc@lists.xmission.com
>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew
>Sent: Wednesday, September 22, 1999 1:29 PM
>To: 'usr-tc@lists.xmission.com'
>Subject: (usr-tc) Channelized T1 vs PRI
>
>
>
>Overnight tonight the telco is changing one of our T1s to channelized T1
>from PRI service for testing. I seem to remember that there is different
>code for the dual T1/PRI cards depending on which service you have but I'm
>using all DSPs now and I can't seem to have any CT1 specific code for these
>cards on TotalService. Does the one code base now support both CT1 and PRI
>or am I missing something?
>
>Thanks...
>
>Matthew
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6
tel. 519-985-8410
fax. 519-258-3009
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Clayton Zekelman <clayton@MNSi.Net>
Subject: RE: (usr-tc) Channelized T1 vs PRI
Date: 22 Sep 1999 15:07:05 -0400
At 03:48 PM 9/22/99 -0300, you wrote:
>
>Part of the reason we're doing this is because CT1 is cheaper but I've never
>used CT1 before and I'm wondering what other functionality we're going to
>lose. I gather it will no longer be possible to do busy out the channels
>from this end and we'll also probably lose ANI too.
You can do a soft or hard busy out with CT1. You never had ANI to begin
with - you had Calling Line ID. True ANI is only on FGD MF or ISUP trunks,
and yes, you will lose Calling Line ID.
>Are there any other
>drawbacks that I might be overlooking?
>
Slightly lower modem performance - your 33.6 callers will probably be
limited to 31.2, and your PCM (x2/v90) callers will probably lose a couple
of kbps.
>On Wednesday, September 22, 1999 3:46 PM, Mike McHenry
>[SMTP:mmchen@minn.net] wrote:
>> You should be able to use the same code for either a PRI or a channelized
>T1
>> on the DSP, just go into the TCM, select the T1 portion of the DSP (top
>LED
>> below the power LED), click Configure-->Programmed Settings-->Trunk
>Settings
>>
>> You will see a setting called signal mode, it should be set to robbed bit
>> for a channelized T1 and message oriented for a PRI. Unless the telco is
>> changing other things (ie switch type, etc) that should be the only
>setting
>> you need to change when the telco changes your PRI to a channelized T1.
>>
>> Mike McHenry
>> Systems Administrator
>> MinnNet Communications, Inc.
>>
>> -----Original Message-----
>> From: owner-usr-tc@lists.xmission.com
>> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew
>> Sent: Wednesday, September 22, 1999 1:29 PM
>> To: 'usr-tc@lists.xmission.com'
>> Subject: (usr-tc) Channelized T1 vs PRI
>>
>>
>>
>> Overnight tonight the telco is changing one of our T1s to channelized T1
>> from PRI service for testing. I seem to remember that there is different
>> code for the dual T1/PRI cards depending on which service you have but I'm
>> using all DSPs now and I can't seem to have any CT1 specific code for
>these
>> cards on TotalService. Does the one code base now support both CT1 and
>PRI
>> or am I missing something?
>>
>> Thanks...
>>
>> Matthew
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> 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.
>>
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> 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.
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6
tel. 519-985-8410
fax. 519-258-3009
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: (usr-tc) An odd authentication problem
Date: 22 Sep 1999 14:16:38 -0500
For the past several months people have been reporting a LONG delay in
authentication after connecting to our modems. Try as I might I couldn't
duplicate this until today. Seems that normal PAP authentication works fine.
However, about 1/10th of the time that I dial into my USR equipment using a
terminal window I experience the problem.
Here is what happens, dial into USR, handshake goes well, I am prompted for
my login. After entering my username and hitting enter the USR hangs for
about a minute before coming back with "Login incorrect" and then prompts me
again for my username. It never asks for a password. Watching things on the
radius server I see about 30 lines come across my radius logs saying
something like "Error: no username: [] (from nas tc-1.minn.net)"
Obviously my one minute delay on login is being caused by the USR timing out
on this null username request. The question is why is the USR sending a null
radius request and timing out on it? It only does this about 1/10th of the
time and it never seems to happen when doing straight PAP. Anyone else run
into this before?
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: RE: (usr-tc) Channelized T1 vs PRI
Date: 22 Sep 1999 15:53:53 -0400 (EDT)
The ability to do ISDN at 64 KBps, some say that the robbed bit signeling
is "dirty-er" then out of bands messageing on the D channel.
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Wed, 22 Sep 1999, Stainforth, Matthew wrote:
>
> Part of the reason we're doing this is because CT1 is cheaper but I've never
> used CT1 before and I'm wondering what other functionality we're going to
> lose. I gather it will no longer be possible to do busy out the channels
> from this end and we'll also probably lose ANI too. Are there any other
> drawbacks that I might be overlooking?
>
> On Wednesday, September 22, 1999 3:46 PM, Mike McHenry
> [SMTP:mmchen@minn.net] wrote:
> > You should be able to use the same code for either a PRI or a channelized
> T1
> > on the DSP, just go into the TCM, select the T1 portion of the DSP (top
> LED
> > below the power LED), click Configure-->Programmed Settings-->Trunk
> Settings
> >
> > You will see a setting called signal mode, it should be set to robbed bit
> > for a channelized T1 and message oriented for a PRI. Unless the telco is
> > changing other things (ie switch type, etc) that should be the only
> setting
> > you need to change when the telco changes your PRI to a channelized T1.
> >
> > Mike McHenry
> > Systems Administrator
> > MinnNet Communications, Inc.
> >
> > -----Original Message-----
> > From: owner-usr-tc@lists.xmission.com
> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew
> > Sent: Wednesday, September 22, 1999 1:29 PM
> > To: 'usr-tc@lists.xmission.com'
> > Subject: (usr-tc) Channelized T1 vs PRI
> >
> >
> >
> > Overnight tonight the telco is changing one of our T1s to channelized T1
> > from PRI service for testing. I seem to remember that there is different
> > code for the dual T1/PRI cards depending on which service you have but I'm
> > using all DSPs now and I can't seem to have any CT1 specific code for
> these
> > cards on TotalService. Does the one code base now support both CT1 and
> PRI
> > or am I missing something?
> >
> > Thanks...
> >
> > Matthew
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Michael DeMan" <michael@prf.org>
Subject: Re: (usr-tc) Channelized T1 vs PRI
Date: 22 Sep 1999 14:24:04 -0700
Doesn't PRI have some advantages for error checking, etc. Basically it's
easier to trace down and correct line noise problems, signal bounces, etc.
than a channelized T1?
- mike
----------
>From: "Mike McHenry" <mmchen@minn.net>
>To: <usr-tc@lists.xmission.com>
>Subject: RE: (usr-tc) Channelized T1 vs PRI
>Date: Wed, Sep 22, 1999, 12:04 PM
>
>You should be able to busy out channels just like you did before with a CT1.
>CT1s also support ANI if configured that way from the telco. The only
>functionality I figure you will lose is the ability to take incoming 64k
>clear channel ISDN calls on your Total Control chassis.
>
>Mike McHenry
> Systems Administrator
> MinnNet Communications, Inc.
>
>-----Original Message-----
>From: owner-usr-tc@lists.xmission.com
>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew
>Sent: Wednesday, September 22, 1999 1:49 PM
>To: 'usr-tc@lists.xmission.com'
>Subject: RE: (usr-tc) Channelized T1 vs PRI
>
>
>
>Part of the reason we're doing this is because CT1 is cheaper but I've never
>used CT1 before and I'm wondering what other functionality we're going to
>lose. I gather it will no longer be possible to do busy out the channels
>from this end and we'll also probably lose ANI too. Are there any other
>drawbacks that I might be overlooking?
>
>On Wednesday, September 22, 1999 3:46 PM, Mike McHenry
>[SMTP:mmchen@minn.net] wrote:
>> You should be able to use the same code for either a PRI or a channelized
>T1
>> on the DSP, just go into the TCM, select the T1 portion of the DSP (top
>LED
>> below the power LED), click Configure-->Programmed Settings-->Trunk
>Settings
>>
>> You will see a setting called signal mode, it should be set to robbed bit
>> for a channelized T1 and message oriented for a PRI. Unless the telco is
>> changing other things (ie switch type, etc) that should be the only
>setting
>> you need to change when the telco changes your PRI to a channelized T1.
>>
>> Mike McHenry
>> Systems Administrator
>> MinnNet Communications, Inc.
>>
>> -----Original Message-----
>> From: owner-usr-tc@lists.xmission.com
>> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew
>> Sent: Wednesday, September 22, 1999 1:29 PM
>> To: 'usr-tc@lists.xmission.com'
>> Subject: (usr-tc) Channelized T1 vs PRI
>>
>>
>>
>> Overnight tonight the telco is changing one of our T1s to channelized T1
>> from PRI service for testing. I seem to remember that there is different
>> code for the dual T1/PRI cards depending on which service you have but I'm
>> using all DSPs now and I can't seem to have any CT1 specific code for
>these
>> cards on TotalService. Does the one code base now support both CT1 and
>PRI
>> or am I missing something?
>>
>> Thanks...
>>
>> Matthew
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> 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.
>>
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> 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.
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Campbell Simpson" <Campbell.Simpson@telecom.co.nz>
Subject: (usr-tc) Undocumented DSP debug commands
Date: 23 Sep 1999 09:37:01 +1200
Hi
Was wondering if anyone out there has had a play around with the "trc"
command on the HiPer DSP cards. The docs on the trc command are very
brief and was wondering if anyone had a more complete explanation.
What I want to be able to do is capture modem data as a call is in
progress in a way similar to the Ascend MAX4000. Frantically typing AT
commands to capture call info is not my idea of fun!
Any help would be much appreciated.
Campbell
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Clayton Zekelman <clayton@MNSi.Net>
Subject: Re: (usr-tc) Channelized T1 vs PRI
Date: 22 Sep 1999 18:12:57 -0400
At 02:24 PM 9/22/99 -0700, you wrote:
>Doesn't PRI have some advantages for error checking, etc. Basically it's
>easier to trace down and correct line noise problems, signal bounces, etc.
>than a channelized T1?
Shouldn't be any differences. Possibly if the CT1 is configured with SF,
you might not have as much diag info, but if the CT1 is configured as
B8ZS/ESF (same framing as PRI), you'd have the same link diagnostics
available.
>
>- mike
>
>----------
>>From: "Mike McHenry" <mmchen@minn.net>
>>To: <usr-tc@lists.xmission.com>
>>Subject: RE: (usr-tc) Channelized T1 vs PRI
>>Date: Wed, Sep 22, 1999, 12:04 PM
>>
>
>>You should be able to busy out channels just like you did before with a CT1.
>>CT1s also support ANI if configured that way from the telco. The only
>>functionality I figure you will lose is the ability to take incoming 64k
>>clear channel ISDN calls on your Total Control chassis.
>>
>>Mike McHenry
>> Systems Administrator
>> MinnNet Communications, Inc.
>>
>>-----Original Message-----
>>From: owner-usr-tc@lists.xmission.com
>>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew
>>Sent: Wednesday, September 22, 1999 1:49 PM
>>To: 'usr-tc@lists.xmission.com'
>>Subject: RE: (usr-tc) Channelized T1 vs PRI
>>
>>
>>
>>Part of the reason we're doing this is because CT1 is cheaper but I've never
>>used CT1 before and I'm wondering what other functionality we're going to
>>lose. I gather it will no longer be possible to do busy out the channels
>>from this end and we'll also probably lose ANI too. Are there any other
>>drawbacks that I might be overlooking?
>>
>>On Wednesday, September 22, 1999 3:46 PM, Mike McHenry
>>[SMTP:mmchen@minn.net] wrote:
>>> You should be able to use the same code for either a PRI or a channelized
>>T1
>>> on the DSP, just go into the TCM, select the T1 portion of the DSP (top
>>LED
>>> below the power LED), click Configure-->Programmed Settings-->Trunk
>>Settings
>>>
>>> You will see a setting called signal mode, it should be set to robbed bit
>>> for a channelized T1 and message oriented for a PRI. Unless the telco is
>>> changing other things (ie switch type, etc) that should be the only
>>setting
>>> you need to change when the telco changes your PRI to a channelized T1.
>>>
>>> Mike McHenry
>>> Systems Administrator
>>> MinnNet Communications, Inc.
>>>
>>> -----Original Message-----
>>> From: owner-usr-tc@lists.xmission.com
>>> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew
>>> Sent: Wednesday, September 22, 1999 1:29 PM
>>> To: 'usr-tc@lists.xmission.com'
>>> Subject: (usr-tc) Channelized T1 vs PRI
>>>
>>>
>>>
>>> Overnight tonight the telco is changing one of our T1s to channelized T1
>>> from PRI service for testing. I seem to remember that there is different
>>> code for the dual T1/PRI cards depending on which service you have but I'm
>>> using all DSPs now and I can't seem to have any CT1 specific code for
>>these
>>> cards on TotalService. Does the one code base now support both CT1 and
>>PRI
>>> or am I missing something?
>>>
>>> Thanks...
>>>
>>> Matthew
>>>
>>> -
>>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>>> 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.
>>>
>>>
>>> -
>>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>>> 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.
>>
>>
>>
>>-
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> 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.
>>
>>
>>-
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> 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.
>>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6
tel. 519-985-8410
fax. 519-258-3009
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Steve Coleman" <scoleman2@csolutions.net>
Subject: (usr-tc) ISDN Problem with Netgear RH348
Date: 22 Sep 1999 23:31:03 -0600
Can't seem to get this unit working in any configuration. We have are using
the HiperArc and HiperDSP with the latest code on both. The connection will
establish and work for a few minutes, but it keeps resetting, usually after
3-5 minutes. This happens if the Netgear calls in using NAT, calls in using
a routed subnet, or if the HiperARC calls the Netgear. Idle timers on both
ends have been set to 0. Any ideas?
Thanks,
Steve Coleman
Computer Solutions
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: das <das@gol.com>
Subject: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 23 Sep 1999 15:06:12 +0900
I'm having quite a few problems with macs connecting with FreePPP to my HARC
running 4.1.59. It will never connect on the first try, but subsequent attempts
seem to be OK. It is completely reproduceable and is happening on more than one
card.
I am willing to re-flash the card to older code, except the last time I did this
the HARC lost it's configuration. (forgot it's IP Address) Being that the problem
cards are in remote pops, I would rather try a fix for the current code first.
Anyone have any ideas?
Sorry if this has been answered before, I was mysteriously unsubscribed from this
list and missed a lot of posts.
das
--
____________________________________________
Alex Substanley Global OnLine Japan
Engineering Department
Das Man TEL: 81-3-5334-1700
Systems Engineer FAX: 81-3-5334-1711
The Highest Quality Service, Bar None
____________________________________________
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Aaron Nabil <nabil@spiritone.com>
Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 23 Sep 1999 00:01:56 -0700 (PDT)
das writes...
>I'm having quite a few problems with macs connecting with FreePPP to my HARC
>running 4.1.59. It will never connect on the first try, but subsequent attempts
>seem to be OK. It is completely reproduceable and is happening on more than one
>card.
It happened here too. I haven't checked to see if V4.2.29 fixes it, the
problem might have went away, nobody has mentioned it for a while.
--
Aaron Nabil
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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 <kenk@shreve.net>
Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 23 Sep 1999 00:16:27 -0700
Speaking of 4.2.29, which manly men among us has this up and running?
Hows it look? Hows the OSPF working so far?
And in addition to the original post, we are having Mac problems as
well, but the code release prior to 4.1.59 seemed to make the problem
much worse if I recall correctly.
Aaron Nabil wrote:
>
> das writes...
> >I'm having quite a few problems with macs connecting with FreePPP to my HARC
> >running 4.1.59. It will never connect on the first try, but subsequent attempts
> >seem to be OK. It is completely reproduceable and is happening on more than one
> >card.
>
> It happened here too. I haven't checked to see if V4.2.29 fixes it, the
> problem might have went away, nobody has mentioned it for a while.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jim Johnson <jim@perigee.net>
Subject: Re: (usr-tc) Cisco 802 Connecting to ARC
Date: 23 Sep 1999 08:27:02 -0400
Thanks for all the help, but no luck.
Anyone want to buy a SLIGHTLY USED Cisco 802 router, the customer we
bought it for has moved on.
Regards,
Jim
Jim Johnson wrote:
>
> We are trying to connect a Cisco 802 to our HiperARC chassis using ISDN
> and not having much success.
>
> Mon Radius shows the router authenticated fine.
>
> Mon PPP shows only an Outgoing PAP AUTH packet on the link.
>
> The router shows that it was authenticated.
>
> But then there is no additional PPP traffic.
>
> Eventually, the ARC gets an incoming LCP TERM packet from the router
> when the router decides to close down the link.
>
> The radius entry for the router is:
>
> router Password=secret
> Framed-IP-Address=xxx.xxx.32.35,
> Framed-IP-Netmask=255.255.255.255,
> Framed-Route="xxx.xxx.33.8/30 xxx.xxx.32.35 1"
>
> I'm sure there is something realy simple I am missing here...
>
> Thanks,
>
> -Jim Johnson
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Martin Oberle" <moberle@gmx.de>
Subject: (usr-tc) Latest Netserver code?
Date: 23 Sep 1999 17:14:05 +0200
Hi,
I have to update my Total Control Netserver to be Y2K.
I use the Netserver to dial out.
I believe someone posted in this list that the netserver code
3.8 (which I think is the newest) has bug and doesn't support
dial out. Is this true?
Thanks
Martin
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jim Johnson <jim@perigee.net>
Subject: Re: (usr-tc) Cisco 802 Connecting to ARC
Date: 23 Sep 1999 12:41:47 -0400
Just kidding about selling the router to see if I could get anyone to
respond. I am a little surprised that there is not more Cisco expertise
on this list (e.g., the ppp 'callin' flag). I guess this list is more
like a self help therapy session for overworked network technicians who
can't complain to anyone else but their peers. :) Oh well, at least it
works.
This morning, after going through the warehouse full of poor
documentation at www.cisco.com for the umpteenth time, I found out what
the problem was and now we are up and running with the Cisco 802.
Now, in case any of you folks ever need to connect a Cisco router to a
TC chassis don't forget about *** unidirectional authentication ***!
To allow the Cisco to connect without having to have the TC authenticate
itself, the complete Cisco command is:
(config-if)# ppp authentication pap callin
This command enables PAP and specifies authentication on incoming calls
only. Unidirectional authentication is used because non-Cisco routers
that do not support bidirectional authentication (e.g., a TC Chassis).
If you ever had a situation where you could not figure out why CHAP
would work and PAP wouldn't, then you also needed to know this!
Cheers,
-Jim
Jim Johnson wrote:
>
> Thanks for all the help, but no luck.
>
> Anyone want to buy a SLIGHTLY USED Cisco 802 router, the customer we
> bought it for has moved on.
>
> Regards,
>
> Jim
>
> Jim Johnson wrote:
> >
> > We are trying to connect a Cisco 802 to our HiperARC chassis using ISDN
> > and not having much success.
> >
> > Mon Radius shows the router authenticated fine.
> >
> > Mon PPP shows only an Outgoing PAP AUTH packet on the link.
> >
> > The router shows that it was authenticated.
> >
> > But then there is no additional PPP traffic.
> >
> > Eventually, the ARC gets an incoming LCP TERM packet from the router
> > when the router decides to close down the link.
> >
> > The radius entry for the router is:
> >
> > router Password=secret
> > Framed-IP-Address=xxx.xxx.32.35,
> > Framed-IP-Netmask=255.255.255.255,
> > Framed-Route="xxx.xxx.33.8/30 xxx.xxx.32.35 1"
> >
> > I'm sure there is something realy simple I am missing here...
> >
> > Thanks,
> >
> > -Jim Johnson
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jerry Wright <jwright@hyperserv.com>
Subject: (usr-tc) TCBox won't make T1 Connect
Date: 23 Sep 1999 10:10:00 -0700
We have an older TC Box with digital/analog cards, and a dual T1 setup,
as well as NMC and NetServer. Okay... If you set the modem card to
Nic, you can dial in on an analog line and connect.
If you dial in on the T1, nothing. Now, for a bit, it was working, but
I didn't have the pool set properly in the Security Server, and
authentication didn't work. That's fixed.
Now, call-ins on the T1 say, "Your call did not go through, would you
please hang up and dial again."
We're set to esf and b8zs, wink start... just what the phone co
wants. They say they can't get a wink acknowledge, our NAC passes
allinternal tests.
Local Digital loopback works, Remote loopback fails, and it says, NO
dialtone.
Any suggestions???
Jerry Wright
www.iaml.net
mailto:jwright@iaml.net
mailto:jwright@hyperserv.com
Internet Access of Moses Lake
Hypernet Services.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: (usr-tc) Upgrading DSPs
Date: 23 Sep 1999 13:27:49 -0400
Finally got my new DSP problems straightened out for the most part.
Original card was bad, swapped with a replacement. Everything appears to be
fine except I can't get the type from STATIC to DYNAMIC, seems to be
working ok though so I'm not sure what difference it makes.
On to my main point, I'm currently running 1.2.60 on all cards and
4.1.59-6 ARC code. On the DSPs, should I go with 1.2.37 or move up to
2.0.81? Any problems with either? Same question on the ARC, is 4.2.31-1
worth bumping up to?
Thanks,
Kirk
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Ahmed Saeed <Ahmed.Saeed@widener.edu>
Subject: Re: (usr-tc) modem that will
Date: 23 Sep 1999 13:55:51 -0400 (EDT)
From what is written, it seems that the modem picks up the call fine but
there is no packet bus data to tell hiper arc to terminate call.
try
reset modem slot:x/mod:x
Best bet is to go to tcm, and download the parameters from another good
working modem.
By these steps, you eradicate the packet bus, config values, only other
thing might be the packet bus interface for that particular modem.
This would come under hardware issue.
Ahmed
On Tue, 14 Sep 1999, Stainforth, Matthew wrote:
>
> I'm having a problem with one modem that refuses to pick up. When I watch
> the status in performance monitor, I can see the call coming in (RingIn or
> RingRcvd states), DNIS and ANI information comes up, but the modem never
> picks up the call. I have replaced the DSP NAC and the problem didn't go
> away. The only other place I can think to look is to the ARC itself but the
> modem interface is UP/UP. I've also tried a full reconfig (restore from
> default, save to nvram, reboot, reconfig, save to nvram, reboot) and no
> luck. When a user happens to grab that line they hear a long pause of dead
> air (maybe 5 seconds or more) and then it starts ringing endlessly. Any
> ideas?
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: RE: (usr-tc) Upgrading DSPs
Date: 23 Sep 1999 15:20:12 -0300
I'm running 2.0.81 on most of my DSPs and I have no complaints specific to
that version. I needed it so I could do NFAS which also seems to work
great.
On Thursday, September 23, 1999 2:28 PM, K Mitchell [SMTP:mitch@keyconn.net]
wrote:
> On to my main point, I'm currently running 1.2.60 on all cards and
> 4.1.59-6 ARC code. On the DSPs, should I go with 1.2.37 or move up to
> 2.0.81? Any problems with either? Same question on the ARC, is 4.2.31-1
> worth bumping up to?
>
> Thanks,
> Kirk
>
> --
> Kirk Mitchell-General Manager mitch@keyconn.net
> Keystone Connect Unlock Your World
> Altoona, PA 814-941-5000 http://www.keyconn.net
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) Upgrading DSPs
Date: 23 Sep 1999 13:23:04 -0500
HiPer>> sho nmc
NMC SETTINGS
Chassis Awareness: ENABLED
Dynamic Slot Assignment: DISABLED
DSA Idle Rebalancing: ENABLED
Invariably your Chassis Awareness is DISABLED, which will mean no "DYNAMIC"
enable nmc chassis_awareness
Will fix it.
You'll probably want to reboot the ARC.
SMT
-----Original Message-----
Sent: Thursday, September 23, 1999 12:28 PM
Finally got my new DSP problems straightened out for the most part.
Original card was bad, swapped with a replacement. Everything appears to be
fine except I can't get the type from STATIC to DYNAMIC, seems to be
working ok though so I'm not sure what difference it makes.
On to my main point, I'm currently running 1.2.60 on all cards and
4.1.59-6 ARC code. On the DSPs, should I go with 1.2.37 or move up to
2.0.81? Any problems with either? Same question on the ARC, is 4.2.31-1
worth bumping up to?
Thanks,
Kirk
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) Upgrading DSPs
Date: 23 Sep 1999 13:26:08 -0500
I have one stinkin' site where 2.0.81 = no Rockwell modes@V90 (long
screeching, no negotiation),
that site I use 1.2.59, everywhere else quite happy with 2.0.81.
SMT
-----Original Message-----
Sent: Thursday, September 23, 1999 1:20 PM
I'm running 2.0.81 on most of my DSPs and I have no complaints specific to
that version. I needed it so I could do NFAS which also seems to work
great.
On Thursday, September 23, 1999 2:28 PM, K Mitchell [SMTP:mitch@keyconn.net]
wrote:
> On to my main point, I'm currently running 1.2.60 on all cards and
> 4.1.59-6 ARC code. On the DSPs, should I go with 1.2.37 or move up to
> 2.0.81? Any problems with either? Same question on the ARC, is 4.2.31-1
> worth bumping up to?
>
> Thanks,
> Kirk
>
> --
> Kirk Mitchell-General Manager mitch@keyconn.net
> Keystone Connect Unlock Your World
> Altoona, PA 814-941-5000 http://www.keyconn.net
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: RE: (usr-tc) Upgrading DSPs
Date: 23 Sep 1999 15:28:46 -0300
Speaking of firmware problems, has anyone heard if 3Com is almost ready to
release a version that fixes that stupid "modems go freaky in pairs"
problem? I have 6 channels busied out due to this at the moment. I know
there was some bleeding edge code that helped but I'm less than enthusiastic
about running that on my production boxes.
On Thursday, September 23, 1999 3:26 PM, Scott Trautman
[SMTP:scottt@corp.gdinet.com] wrote:
> I have one stinkin' site where 2.0.81 = no Rockwell modes@V90 (long
> screeching, no negotiation),
> that site I use 1.2.59, everywhere else quite happy with 2.0.81.
>
> SMT
>
> -----Original Message-----
> From: Stainforth, Matthew [mailto:MatthewS@staff.brunnet.net]
> Sent: Thursday, September 23, 1999 1:20 PM
> To: 'usr-tc@lists.xmission.com'
> Subject: RE: (usr-tc) Upgrading DSPs
>
>
>
> I'm running 2.0.81 on most of my DSPs and I have no complaints specific to
> that version. I needed it so I could do NFAS which also seems to work
> great.
>
> On Thursday, September 23, 1999 2:28 PM, K Mitchell
[SMTP:mitch@keyconn.net]
> wrote:
> > On to my main point, I'm currently running 1.2.60 on all cards and
> > 4.1.59-6 ARC code. On the DSPs, should I go with 1.2.37 or move up to
> > 2.0.81? Any problems with either? Same question on the ARC, is 4.2.31-1
> > worth bumping up to?
> >
> > Thanks,
> > Kirk
> >
> > --
> > Kirk Mitchell-General Manager mitch@keyconn.net
> > Keystone Connect Unlock Your World
> > Altoona, PA 814-941-5000 http://www.keyconn.net
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Michael DeMan" <michael@prf.org>
Subject: Re: (usr-tc) Server Assigned DNS
Date: 23 Sep 1999 11:43:53 -0700
I tried this on a HiperARC card and it still does not seem to work. Is
there something else I need to configure, or is it different for HiperARC?
- Mike
----------
>From: "Mike McHenry" <mmchen@minn.net>
>To: <usr-tc@lists.xmission.com>, <usr-tc@xmission.com>
>Subject: RE: (usr-tc) Server Assigned DNS
>Date: Tue, Sep 21, 1999, 12:26 PM
>
>set nameserver 10.0.0.1
>set nameserver 2 10.0.0.2
>
>Nothing else should be needed, the Portmasters and Netservers will correctly
>send the dns servers as part of a normal PPP negotiation sequence with a
>customer dialing in...
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: RE: (usr-tc) Upgrading DSPs
Date: 23 Sep 1999 14:44:00 -0400
At 03:28 PM 9/23/99 -0300, "Stainforth, Matthew"
<MatthewS@staff.brunnet.net> wrote:
>
>Speaking of firmware problems, has anyone heard if 3Com is almost ready to
>release a version that fixes that stupid "modems go freaky in pairs"
>problem? I have 6 channels busied out due to this at the moment. I know
>there was some bleeding edge code that helped but I'm less than enthusiastic
>about running that on my production boxes.
Does rebooting the DSP take care of the modems? I have a pair on one card
that go freaky every few weeks. I just busy out the card to shove all my
traffic off, reboot the card, restore to service, and it's good for another
few weeks.
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: RE: (usr-tc) Upgrading DSPs
Date: 23 Sep 1999 14:41:22 -0400
At 01:23 PM 9/23/99 -0500, Scott Trautman <scottt@corp.gdinet.com> wrote:
>Invariably your Chassis Awareness is DISABLED, which will mean no "DYNAMIC"
>
>enable nmc chassis_awareness
>
>Will fix it.
I thought I had it enabled, apparently not :o/
>You'll probably want to reboot the ARC.
If I'm gonna reboot the ARC anyway, any issues or warnings for 4.2.31-1?
Thanks,
Kirk
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: RE: (usr-tc) Server Assigned DNS
Date: 23 Sep 1999 13:54:40 -0500
Ahh, Netserver and ARC are not the same thing, in your first email you said
Netserver I believe. For an ARC card:
set dns server 10.0.0.1 preference 1
set dns server 10.0.0.2 preference 2
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael DeMan
Sent: Thursday, September 23, 1999 1:44 PM
I tried this on a HiperARC card and it still does not seem to work. Is
there something else I need to configure, or is it different for HiperARC?
- Mike
----------
>From: "Mike McHenry" <mmchen@minn.net>
>To: <usr-tc@lists.xmission.com>, <usr-tc@xmission.com>
>Subject: RE: (usr-tc) Server Assigned DNS
>Date: Tue, Sep 21, 1999, 12:26 PM
>
>set nameserver 10.0.0.1
>set nameserver 2 10.0.0.2
>
>Nothing else should be needed, the Portmasters and Netservers will
correctly
>send the dns servers as part of a normal PPP negotiation sequence with a
>customer dialing in...
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: mmm3@cornell.edu
Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 23 Sep 1999 14:52:26 -0400
>Speaking of 4.2.29, which manly men among us has this up and running?
>Hows it look? Hows the OSPF working so far?
Manly men??? Hmph. 4.2.29 was removed from the downloads because of
major problems with the code. The latest version is 4.2.32-1 which I
have downloaded but am not *manly* enough to put on my ARCs yet. Am
waiting to hear from others, first. 8-)
*********************************************************
Michelle M. Mogil
N&CS, Network Operations Center
Rhodes Hall, Cornell University, Ithaca, NY 14853
vox: (607) 255-0516, fax: (607) 255-8420
email: mmm3@cornell.edu
**********************************************
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike McHenry" <mmchen@minn.net>
Subject: RE: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 23 Sep 1999 14:04:52 -0500
Have been running 4.2.32-1 for about a week on my production chassis,
everything is working very well so far. I have yet to see or hear of any
customer problems. I would rank 4.2.32-1 as being one of the most stable
releases yet, if there were any serious issues I am sure I would have heard
about them by now :)
OSPF is working very well too, the configuration was a little cryptic to me
at first (see the archives for my configuration steps) but now that I think
about things it really was no different than the OSPF setup on any other
piece of equipment, just different :)
Mike McHenry
Systems Administrator
MinnNet Communications, Inc.
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of mmm3@cornell.edu
Sent: Thursday, September 23, 1999 1:52 PM
>Speaking of 4.2.29, which manly men among us has this up and running?
>Hows it look? Hows the OSPF working so far?
Manly men??? Hmph. 4.2.29 was removed from the downloads because of
major problems with the code. The latest version is 4.2.32-1 which I
have downloaded but am not *manly* enough to put on my ARCs yet. Am
waiting to hear from others, first. 8-)
*********************************************************
Michelle M. Mogil
N&CS, Network Operations Center
Rhodes Hall, Cornell University, Ithaca, NY 14853
vox: (607) 255-0516, fax: (607) 255-8420
email: mmm3@cornell.edu
**********************************************
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: RE: (usr-tc) Server Assigned DNS
Date: 23 Sep 1999 16:02:05 -0300
There are two other places you can set this information. I don't know what
the effects of each of them are, but I put all three of them in, just for
good measure. I got this from a config Charles Sprickman once posted to
this list (thanks Charles!) which I use as a base config when I set up a new
box.
add dns server x.x.x.x preference 1
set ppp pppdns_primary x.x.x.x
set network user default primary_dns_server x.x.x.x secondary_dns_server
y.y.y.y
On Thursday, September 23, 1999 3:55 PM, Mike McHenry [SMTP:mmchen@minn.net]
wrote:
> Ahh, Netserver and ARC are not the same thing, in your first email you
said
> Netserver I believe. For an ARC card:
>
> set dns server 10.0.0.1 preference 1
> set dns server 10.0.0.2 preference 2
>
> Mike McHenry
> Systems Administrator
> MinnNet Communications, Inc.
>
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael DeMan
> Sent: Thursday, September 23, 1999 1:44 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) Server Assigned DNS
>
>
> I tried this on a HiperARC card and it still does not seem to work. Is
> there something else I need to configure, or is it different for HiperARC?
>
> - Mike
>
>
> ----------
> >From: "Mike McHenry" <mmchen@minn.net>
> >To: <usr-tc@lists.xmission.com>, <usr-tc@xmission.com>
> >Subject: RE: (usr-tc) Server Assigned DNS
> >Date: Tue, Sep 21, 1999, 12:26 PM
> >
>
> >set nameserver 10.0.0.1
> >set nameserver 2 10.0.0.2
> >
> >Nothing else should be needed, the Portmasters and Netservers will
> correctly
> >send the dns servers as part of a normal PPP negotiation sequence with a
> >customer dialing in...
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: RE: (usr-tc) Upgrading DSPs
Date: 23 Sep 1999 16:08:08 -0300
Rebooting does seem to correct the DSPs for a while but the problem always
creeps back. They always go in adjacent pairs because one controller
controls two adjacent modems. As fate would have it, the very first two
modems in my largest hunt group went freaky the other day. I haven't
noticed whether the problem creeps back on the very same two modems every
time or if it's random though since I always just busy out the trunks and
wait until I have another reason to reboot the card, by which time I've long
since forgotten which two modems they were :)
On Thursday, September 23, 1999 3:44 PM, K Mitchell [SMTP:mitch@keyconn.net]
wrote:
> At 03:28 PM 9/23/99 -0300, "Stainforth, Matthew"
> <MatthewS@staff.brunnet.net> wrote:
> >
> Does rebooting the DSP take care of the modems? I have a pair on one card
> that go freaky every few weeks. I just busy out the card to shove all my
> traffic off, reboot the card, restore to service, and it's good for
another
> few weeks.
>
>
> --
> Kirk Mitchell-General Manager mitch@keyconn.net
> Keystone Connect Unlock Your World
> Altoona, PA 814-941-5000 http://www.keyconn.net
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 23 Sep 1999 14:10:20 -0500
So far so good with the very manly 4.2.32 code. I've got 4 of 'em on this
rev of code
for a week and no problems.
I'm not using the extremely manly OSPF yet (subject of most commentary so
far),
using the un-manly rip->OSPF gateway of yore yet.
SMT
-----Original Message-----
Sent: Thursday, September 23, 1999 1:52 PM
>Speaking of 4.2.29, which manly men among us has this up and running?
>Hows it look? Hows the OSPF working so far?
Manly men??? Hmph. 4.2.29 was removed from the downloads because of
major problems with the code. The latest version is 4.2.32-1 which I
have downloaded but am not *manly* enough to put on my ARCs yet. Am
waiting to hear from others, first. 8-)
*********************************************************
Michelle M. Mogil
N&CS, Network Operations Center
Rhodes Hall, Cornell University, Ithaca, NY 14853
vox: (607) 255-0516, fax: (607) 255-8420
email: mmm3@cornell.edu
**********************************************
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike Wilker" <mikew@LL.NET>
Subject: (usr-tc) ISDN on TC
Date: 23 Sep 1999 14:13:29 -0500
Is there any way to either do 56K DOV over Channelize T1 on a HiperArc, or
is there a BRI product for the TC? Thanks.
Mike Wilker
Operations Manager
Local Link, Inc.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: RE: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 23 Sep 1999 16:37:17 -0400 (EDT)
4.2.32-1 works well for us *except* for the route aggregation bug I've
mentioned a few times before. Whether it's OSPF-specific or not I'm not
sure. Whether or not it's a problem in practice depends on how your
subnets are laid out...
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
On Thu, 23 Sep 1999, Mike McHenry wrote:
> Have been running 4.2.32-1 for about a week on my production chassis,
> everything is working very well so far. I have yet to see or hear of any
> customer problems. I would rank 4.2.32-1 as being one of the most stable
> releases yet, if there were any serious issues I am sure I would have heard
> about them by now :)
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) Upgrading DSPs
Date: 23 Sep 1999 16:38:24 -0400 (EDT)
2.0.81 works pretty well for everything but Rockwell HCF's. Still major
problems with that combo... though most of it is really on the Rockwell
end, and upgrading to the newest Rockwell HCF drivers takes care of it
completely 99% of the time.
Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com
"If you're not part of the solution.... you're part of the precipitate."
On Thu, 23 Sep 1999, K Mitchell wrote:
> Finally got my new DSP problems straightened out for the most part.
> Original card was bad, swapped with a replacement. Everything appears to be
> fine except I can't get the type from STATIC to DYNAMIC, seems to be
> working ok though so I'm not sure what difference it makes.
> On to my main point, I'm currently running 1.2.60 on all cards and
> 4.1.59-6 ARC code. On the DSPs, should I go with 1.2.37 or move up to
> 2.0.81? Any problems with either? Same question on the ARC, is 4.2.31-1
> worth bumping up to?
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: (usr-tc) ActionTec Call waiting modem?
Date: 23 Sep 1999 17:48:14 -0300
Has anybody tried this call-waiting modem? Supposedly it'll allow you to
answer a call and talk for up to 7 seconds without dropping the connection
to the ISP. I'm a little skeptical but I'm willing to entertain the
thought. There's a brief promo at
http://www.actiontec.com/products/modems/cwi/index.html
Matthew
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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 <kenk@shreve.net>
Subject: Re: (usr-tc) ISDN Problem with Netgear RH348
Date: 23 Sep 1999 18:02:38 -0500 (CDT)
On Wed, 22 Sep 1999, Steve Coleman wrote:
> Can't seem to get this unit working in any configuration. We have are using
> the HiperArc and HiperDSP with the latest code on both. The connection will
> establish and work for a few minutes, but it keeps resetting, usually after
> 3-5 minutes. This happens if the Netgear calls in using NAT, calls in using
> a routed subnet, or if the HiperARC calls the Netgear. Idle timers on both
> ends have been set to 0. Any ideas?
Latest code as in 4.2.32-1 on the ARC? Hmm. I know we are running
2.0.81/4.1.59 and my Netgear RT-328 at the house hasnt had any problems.
I use NAT also. Your Netgear is using v1.50 frimware I hope?
___ ___
(___) Kenneth Kirchner .o. mailto:kenk@shreve.net (___)
(__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__)
(_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_)
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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 <kenk@shreve.net>
Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 23 Sep 1999 18:10:01 -0500 (CDT)
On Thu, 23 Sep 1999 mmm3@cornell.edu wrote:
> >Speaking of 4.2.29, which manly men among us has this up and running?
> >Hows it look? Hows the OSPF working so far?
>
> Manly men??? Hmph. 4.2.29 was removed from the downloads because of
> major problems with the code. The latest version is 4.2.32-1 which I
> have downloaded but am not *manly* enough to put on my ARCs yet. Am
> waiting to hear from others, first. 8-)
Well I meant that in a completely gender neutral way. ;-) In the future I
will use "fearless guinea pigs." heh
Yes, I meant 4.2.31. Looks like a few people have tried it and it looks
good *so far*.
___ ___
(___) Kenneth Kirchner .o. mailto:kenk@shreve.net (___)
(__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__)
(_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_)
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Paul Farber <farber@admin.f-tech.net>
Subject: Re: (usr-tc) ISDN on TC
Date: 23 Sep 1999 19:28:45 -0400 (EDT)
DOV is a telco switch issue. 5Ess will do it, but the telco can simply
"turn it off" and filter the tone (2100Hz??) that tells the switch to keep
56K and not shift to 64K.
BA in PA at my local 5Ess turned it off... rat turds! ISDN is a big
seller for small biz.. but it's a hard sell when you say "per minute
charges".
Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
farber@admin.f-tech.net
On Thu, 23 Sep 1999, Mike Wilker wrote:
> Is there any way to either do 56K DOV over Channelize T1 on a HiperArc, or
> is there a BRI product for the TC? Thanks.
>
> Mike Wilker
> Operations Manager
> Local Link, Inc.
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Steve Coleman" <scoleman2@csolutions.net>
Subject: Re: (usr-tc) ISDN Problem with Netgear RH348
Date: 23 Sep 1999 20:54:24 -0600
It turned out to be a CHAP problem. It would authenticate and work for
about 3 minutes, then the CHAP timed out and disconnected. I switched to
PAP and it's been fine.
Thanks.
----- Original Message -----
Sent: Thursday, September 23, 1999 5:02 PM
> On Wed, 22 Sep 1999, Steve Coleman wrote:
>
> > Can't seem to get this unit working in any configuration. We have are
using
> > the HiperArc and HiperDSP with the latest code on both. The connection
will
> > establish and work for a few minutes, but it keeps resetting, usually
after
> > 3-5 minutes. This happens if the Netgear calls in using NAT, calls in
using
> > a routed subnet, or if the HiperARC calls the Netgear. Idle timers on
both
> > ends have been set to 0. Any ideas?
>
> Latest code as in 4.2.32-1 on the ARC? Hmm. I know we are running
> 2.0.81/4.1.59 and my Netgear RT-328 at the house hasnt had any problems.
> I use NAT also. Your Netgear is using v1.50 frimware I hope?
> ___ ___
> (___) Kenneth Kirchner .o. mailto:kenk@shreve.net (___)
> (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__)
> (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_)
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: <vanhalen@coredcs.com>
Subject: RE: (usr-tc) Server Assigned DNS
Date: 23 Sep 1999 23:12:01 -0500 (CDT)
Any chance of getting that config from Mr. Sprickman posted to the list?
On Thu, 23 Sep 1999, Stainforth, Matthew wrote:
>
> There are two other places you can set this information. I don't know what
> the effects of each of them are, but I put all three of them in, just for
> good measure. I got this from a config Charles Sprickman once posted to
> this list (thanks Charles!) which I use as a base config when I set up a new
> box.
>
> add dns server x.x.x.x preference 1
> set ppp pppdns_primary x.x.x.x
> set network user default primary_dns_server x.x.x.x secondary_dns_server
> y.y.y.y
>
> On Thursday, September 23, 1999 3:55 PM, Mike McHenry [SMTP:mmchen@minn.net]
> wrote:
> > Ahh, Netserver and ARC are not the same thing, in your first email you
> said
> > Netserver I believe. For an ARC card:
> >
> > set dns server 10.0.0.1 preference 1
> > set dns server 10.0.0.2 preference 2
> >
> > Mike McHenry
> > Systems Administrator
> > MinnNet Communications, Inc.
> >
> > -----Original Message-----
> > From: owner-usr-tc@lists.xmission.com
> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael DeMan
> > Sent: Thursday, September 23, 1999 1:44 PM
> > To: usr-tc@lists.xmission.com
> > Subject: Re: (usr-tc) Server Assigned DNS
> >
> >
> > I tried this on a HiperARC card and it still does not seem to work. Is
> > there something else I need to configure, or is it different for HiperARC?
> >
> > - Mike
> >
> >
> > ----------
> > >From: "Mike McHenry" <mmchen@minn.net>
> > >To: <usr-tc@lists.xmission.com>, <usr-tc@xmission.com>
> > >Subject: RE: (usr-tc) Server Assigned DNS
> > >Date: Tue, Sep 21, 1999, 12:26 PM
> > >
> >
> > >set nameserver 10.0.0.1
> > >set nameserver 2 10.0.0.2
> > >
> > >Nothing else should be needed, the Portmasters and Netservers will
> > correctly
> > >send the dns servers as part of a normal PPP negotiation sequence with a
> > >customer dialing in...
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Steve Coleman" <scoleman2@csolutions.net>
Subject: (usr-tc) Multilink Question
Date: 23 Sep 1999 22:31:31 -0600
I have a ISDN user setup as network,dialout, continuous. It works fine when
the HiperARC first calls the client. It bonds both channels just great. If
for some reason a channel is dropped, the HiperARC never tries to
re-establish the dropped channel. I have tried both linear and constant
for the expansion algorithm. How do you make the HiperARC maintain 2
channels relentlessly?
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike Wilker" <mikew@LL.NET>
Subject: Re: (usr-tc) ISDN on TC
Date: 24 Sep 1999 11:14:28 -0500
So if it is enabled on the switch, I can have an ISDN user connect with an
ISDN modem on either one or two channels to my HiperDSP with a Channelized
T1? Will it have a port type of Async or ISDN?
----- Original Message -----
Sent: Thursday, September 23, 1999 6:28 PM
> DOV is a telco switch issue. 5Ess will do it, but the telco can simply
> "turn it off" and filter the tone (2100Hz??) that tells the switch to keep
> 56K and not shift to 64K.
>
> BA in PA at my local 5Ess turned it off... rat turds! ISDN is a big
> seller for small biz.. but it's a hard sell when you say "per minute
> charges".
>
> Paul D. Farber II
> Farber Technology
> Ph. 570-628-5303
> Fax 570-628-5545
> farber@admin.f-tech.net
>
> On Thu, 23 Sep 1999, Mike Wilker wrote:
>
> > Is there any way to either do 56K DOV over Channelize T1 on a HiperArc,
or
> > is there a BRI product for the TC? Thanks.
> >
> > Mike Wilker
> > Operations Manager
> > Local Link, Inc.
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Ahmed Saeed <Ahmed.Saeed@widener.edu>
Subject: Re: (usr-tc) problems with CHAP authentication
Date: 24 Sep 1999 12:33:52 -0400 (EDT)
kindly post the ppp negotiation and the show ppp settings.
Ahmed
On Tue, 21 Sep 1999, Theodore Cekan wrote:
> Hi,
>
> I have a user trying to dial in with a Livingston Office Router U-AP,
> running software version 3.7.1 AP.5. For some reason they cannot connect to
> my TC Hiper system, ARC verson 4.1.59, unless PAP is selected as the only
> allowed authentication scheme. "Any" doesnt work, chap kicks in and they
> get denied access. The Livingston box does have chap turned off, btw. We
> are stumped. Any help is much appreciated.
>
> Thanks
>
> Ted Cekan
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: John Schmerold <john@katy.com>
Subject: Re: (usr-tc) ISDN Problem with Netgear RH348
Date: 24 Sep 1999 11:33:51 -0500
I don't remember why, but PAP is all we use with the Netserver+ 8I
Steve Coleman wrote:
> It turned out to be a CHAP problem. It would authenticate and work for
> about 3 minutes, then the CHAP timed out and disconnected. I switched to
> PAP and it's been fine.
>
> Thanks.
>
> ----- Original Message -----
> From: Ken Kirchner <kenk@shreve.net>
> To: <usr-tc@lists.xmission.com>
> Sent: Thursday, September 23, 1999 5:02 PM
> Subject: Re: (usr-tc) ISDN Problem with Netgear RH348
>
> > On Wed, 22 Sep 1999, Steve Coleman wrote:
> >
> > > Can't seem to get this unit working in any configuration. We have are
> using
> > > the HiperArc and HiperDSP with the latest code on both. The connection
> will
> > > establish and work for a few minutes, but it keeps resetting, usually
> after
> > > 3-5 minutes. This happens if the Netgear calls in using NAT, calls in
> using
> > > a routed subnet, or if the HiperARC calls the Netgear. Idle timers on
> both
> > > ends have been set to 0. Any ideas?
> >
> > Latest code as in 4.2.32-1 on the ARC? Hmm. I know we are running
> > 2.0.81/4.1.59 and my Netgear RT-328 at the house hasnt had any problems.
> > I use NAT also. Your Netgear is using v1.50 frimware I hope?
> > ___ ___
> > (___) Kenneth Kirchner .o. mailto:kenk@shreve.net (___)
> > (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__)
> > (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_)
> >
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
--
John Schmerold
Katy Computer, LLC
20 Meramec Station Rd
Valley Park, MO 63088
314-316-9000
314-316-9200 fax
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: mmm3@cornell.edu
Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 24 Sep 1999 14:49:50 -0400
>On Thu, 23 Sep 1999 mmm3@cornell.edu wrote:
>
>> >Speaking of 4.2.29, which manly men among us has this up and running?
>> >Hows it look? Hows the OSPF working so far?
>>
>> Manly men??? Hmph. 4.2.29 was removed from the downloads because of
>> major problems with the code. The latest version is 4.2.32-1 which I
>> have downloaded but am not *manly* enough to put on my ARCs yet. Am
>> waiting to hear from others, first. 8-)
>
>Well I meant that in a completely gender neutral way. ;-) In the future I
>will use "fearless guinea pigs." heh
*snort* No offense taken. Just wanted to remind you all there there is
a <gasp> woman out here! I prefer the term "lemming without a conscience".
Thanks. 8-)
>Yes, I meant 4.2.31. Looks like a few people have tried it and it looks
>good *so far*.
That's 4.2.32-1, though, right? In this version-confused world, just
want to be sure I'm keeping track of things...*some* things, anyway.
*********************************************************
Michelle M. Mogil
N&CS, Network Operations Center
Rhodes Hall, Cornell University, Ithaca, NY 14853
vox: (607) 255-0516, fax: (607) 255-8420
email: mmm3@cornell.edu
**********************************************
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 24 Sep 1999 15:14:56 -0400
At 02:49 PM 9/24/99 -0400, you wrote:
>*snort* No offense taken. Just wanted to remind you all there there is
>a <gasp> woman out here! I prefer the term "lemming without a conscience".
"lemming without a conscience"...I like that :)
>That's 4.2.32-1, though, right? In this version-confused world, just
>want to be sure I'm keeping track of things...*some* things, anyway.
Been running 4.2.32-1 for 12 hours no, so far so good :)
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: <vanhalen@coredcs.com>
Subject: (usr-tc) Ascend Pipeline 50
Date: 24 Sep 1999 14:59:35 -0500 (CDT)
Hello-
For whatever reason, unknown to me, I cannot get an Ascend Pipeline 50 to
connect correctly via ISDN. I have other users connecting 100% fine to a
Netserver based box running Quads. Most of those users are ISDN.
When this user with the Ascend dials in, they never get a Start record in
radius accounting. I can see them come across but it never starts and it
immediately disconnects them.
Anyone have any ideas on what I can change on the Pipeline to get them to
work?
Since I have everyone running fine on this box except the Ascend, I don't
think I need to change anything on the box or at the very least I'm really
reluctant to do so.
Here are the versions anyway.
NMC 5.5.0
Netserver ??
Quad 5.10.9
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
Date: 25 Sep 1999 22:25:30 -0400 (EDT)
On Mon, 20 Sep 1999, Aaron Nabil wrote:
> Uh, I'm assuming they want to do this SNMP rigamarole for some specific
> reason, and I'm guessing that, like us, they simply save the IP->username
> association in a database when the person logs in. If it were just a
> matter of finding out what user corresponds to which IP address (or
> vice-versa), it's just a couple SQL queries.
The specific reason is "it's portable". It works on any platform
regardless of Radius server or SQL server or even operating system
(NT/Unix). This is for a set of tools I give away... and if I'm giving
away code, it makes sense to have as little site specific code as
possible. :)
The code is pretty easy to replace with faster site-specific code if you
want to. I could speed it up for my own use by having Cistron log to
MySQL and do queries off of that, sure... I'm not currently doing that
but it'd be easy for me to do.
Telnet would also work and is more or less portable, but I'd rather not
have the admin password for my ARCs in plaintext in a Perl script.
Cistron Radius's built-in tracking of users currently online doesn't work
if you are running two parallel Radius servers for redundancy. If Radius
server 1 goes down and server 2 starts authenticating people for a few
minutes, your database of who's online at the time is trashed. Even with
just one running, it tends to drift out of sync with reality at times. I
need something that's going to always work.
Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
"With sufficient thrust, pigs fly just fine." -- RFC 1925
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Todd Keister" <Todd_Keister@mw.3com.com>
Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 26 Sep 1999 15:42:49 -0500
Das:
This is a known issue. According to Network Engineers on our DSP team the
issue is in the Free PPP code. Apparently the later versions of our Hiper Arc
code have now exposed an issue that was latent in the Free PPP code all along.
Since this issue is in the FreePPP Product, we can not directly resolve this
issue. Currently I have been told there are no plans for a 3Com fix for this
issue. The obvious work around is to have the Mac End Users use any other
program than Free PPP.
Hope this helps.
Todd ;-}
das <das@gol.com> on 09/23/99 01:06:12 AM
Please respond to usr-tc@lists.xmission.com
Sent by: das <das@gol.com>
cc: (Todd Keister/MW/US/3Com)
I'm having quite a few problems with macs connecting with FreePPP to my HARC
running 4.1.59. It will never connect on the first try, but subsequent attempts
seem to be OK. It is completely reproduceable and is happening on more than one
card.
I am willing to re-flash the card to older code, except the last time I did this
the HARC lost it's configuration. (forgot it's IP Address) Being that the
problem
cards are in remote pops, I would rather try a fix for the current code first.
Anyone have any ideas?
Sorry if this has been answered before, I was mysteriously unsubscribed from
this
list and missed a lot of posts.
das
--
____________________________________________
Alex Substanley Global OnLine Japan
Engineering Department
Das Man TEL: 81-3-5334-1700
Systems Engineer FAX: 81-3-5334-1711
The Highest Quality Service, Bar None
____________________________________________
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 26 Sep 1999 16:44:15 -0400
Thus spake Todd Keister
> This is a known issue. According to Network Engineers on our DSP team the
>issue is in the Free PPP code. Apparently the later versions of our Hiper Arc
>code have now exposed an issue that was latent in the Free PPP code all along.
>Since this issue is in the FreePPP Product, we can not directly resolve this
>issue. Currently I have been told there are no plans for a 3Com fix for this
>issue. The obvious work around is to have the Mac End Users use any other
>program than Free PPP.
Come on 3Com folks...here's where you can make an improvement to your
customer service.
What is the bug in FreePPP? Giving specifics is a good thing. It gives
you more credibility, and helps us help our customers better. :) Who
knows...one of us intelligent people out here might be able to figure
out a fix that you all hadn't thought of. :)
(I get annoyed when companies think that everyone intelligent works for
them :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Todd Keister" <Todd_Keister@mw.3com.com>
Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 26 Sep 1999 16:15:48 -0500
Jeff:
If I had known the specifics of this issue, I would have posted them.
Resolving this type of issue at the code level is beyond me (I'm not a
programer) and this goes double for Macintosh. I will try to get a more
specific answer, but I thought that Das would like confirmation of this issue.
I work in tech support, and sometimes just knowing that a weird issue is
real can be comforting.
If you have further questions, please email me directly at:
todd_keister@mw.3com.com
Todd ;-}
Jeff Mcadams <jeffm@iglou.com> on 09/26/99 03:44:15 PM
Please respond to usr-tc@lists.xmission.com
Sent by: Jeff Mcadams <jeffm@iglou.com>
cc: (Todd Keister/MW/US/3Com)
Thus spake Todd Keister
> This is a known issue. According to Network Engineers on our DSP team the
>issue is in the Free PPP code. Apparently the later versions of our Hiper Arc
>code have now exposed an issue that was latent in the Free PPP code all along.
>Since this issue is in the FreePPP Product, we can not directly resolve this
>issue. Currently I have been told there are no plans for a 3Com fix for this
>issue. The obvious work around is to have the Mac End Users use any other
>program than Free PPP.
Come on 3Com folks...here's where you can make an improvement to your
customer service.
What is the bug in FreePPP? Giving specifics is a good thing. It gives
you more credibility, and helps us help our customers better. :) Who
knows...one of us intelligent people out here might be able to figure
out a fix that you all hadn't thought of. :)
(I get annoyed when companies think that everyone intelligent works for
them :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Todd Keister" <Todd_Keister@mw.3com.com>
Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 26 Sep 1999 16:25:55 -0500
Jeff:
Here is some more specific information regarding the Free PPP issue. This
information will soon be published on the 3Com Knowledgebase website
(http://knowledgebase.3com.com).
I hope this helps.
Todd ;-}
Solution ID: 1.0.33772876.2240281 Domain:3KB01
Partition: Unassigned
Type: pending-Public Status:Standards review
complete
Shared: Yes
Incident Count: 1
Owner: tkeister_mw
Author: tkeister_mw Date Created:Tue Jul 20, 1999
1:08:26 PM
Last Modified By: tcwikla_mw Date Modified: Thu Aug 5,
1999 5:49:27 PM
Title: Total Control Chassis - Connectivity with Macintosh
Clients using Free PPP
Goal: Total Control Chassis - Connectivity with Macintosh
Clients using Free PPP
Fact: Apple Macintosh
Fact: Mac has been rebooted recently
Fact: System 7
Fact: Free PPP
Fact: Free PPP 2.62
Fact: Total Control HiPer ARC
Fact: Total Control HiPer DSP
Fact: Total Control Quad Modem
Fact: Total Control Chassis
Fact: PPP
Symptom: Call fails on First attempt
Symptom: Subsequent calls connect
Symptom: Connectivity with Macintosh Clients using Free PPP
Cause: This is an issue that is known to exist, and stems from a
timing issue that has been exposed by the HiPerARC since it builds a
call so much faster than the NetServer does.
Fix: There are several fixes:
1. In Free PPP dialog box - do NOT enter the Username and
Password - do NOT select direct - choose "Connect Using a Log On Script"
- then choose "Wait for - Login" next line send: user
name - wait for password & send password:
2. Do not enter the Username and Password (force Mac to
prompt for them) - Please Note: This fix has NOT been widely tested
yet.
3. Use Open Transport, which is built in to System 8 OS
for the Mac. Open Transport (Mac RAS client) is also available as an
add on product for systems using System 7.x OS (that won't support
8.x).
4. Have End User downgrade to Free PPP 2.53
Fact: Search Group Total Control Remote Access Concentrator
Fact: Last Reviewed July 1999
Comments
Jeff Mcadams <jeffm@iglou.com> on 09/26/99 03:44:15 PM
Please respond to usr-tc@lists.xmission.com
Sent by: Jeff Mcadams <jeffm@iglou.com>
cc: (Todd Keister/MW/US/3Com)
Thus spake Todd Keister
> This is a known issue. According to Network Engineers on our DSP team the
>issue is in the Free PPP code. Apparently the later versions of our Hiper Arc
>code have now exposed an issue that was latent in the Free PPP code all along.
>Since this issue is in the FreePPP Product, we can not directly resolve this
>issue. Currently I have been told there are no plans for a 3Com fix for this
>issue. The obvious work around is to have the Mac End Users use any other
>program than Free PPP.
Come on 3Com folks...here's where you can make an improvement to your
customer service.
What is the bug in FreePPP? Giving specifics is a good thing. It gives
you more credibility, and helps us help our customers better. :) Who
knows...one of us intelligent people out here might be able to figure
out a fix that you all hadn't thought of. :)
(I get annoyed when companies think that everyone intelligent works for
them :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 26 Sep 1999 17:43:22 -0400
Thus spake Todd Keister
> If I had known the specifics of this issue, I would have posted them.
>Resolving this type of issue at the code level is beyond me (I'm not a
>programer) and this goes double for Macintosh. I will try to get a more
>specific answer, but I thought that Das would like confirmation of this issue.
> I work in tech support, and sometimes just knowing that a weird issue is
>real can be comforting.
Oh...I can understand where you're coming from. :) And the
notification that the problem was real, and known, is certainly a huge
benefit. :) Just trying to help 3Com be even better.
My comment really wasn't directed at you per se...just your post
happened to be the latest occurance of this. :)
My opinion is the you can't give me too much information. :) I'll
filter out what I don't need. :) Just trying to encourage 3Com to give
as much information as possible, whenever possible. 3Com has had a
tendancy in the past to treat customers like mushrooms. :)
Its amazing what people will put up with when they're given information
about it. :)
Thanks for checking into it and finding out more about what's going on
with it. This might actually help me with a specific problem that I'm
having with my uncle's computer. :) (MacOS 7.6 with FreePPP) I'll see
what I can do next time I've over at his house and give you some
feedback. :) (Too bad FreePPP's logging is pretty much non-existant)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: das <das@gol.com>
Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 27 Sep 1999 10:09:55 +0900
Todd,
Thank you. I did appreciate this information, even if, at first, it didn't
give me all of the details. It did give me a place where I could start and something
that I could tell my customers. (although they didn't like it ^_^) In Japan, Mac is
still very popular, and for the foreign community, FreePPP is happier with Japanese
modems than OT/PPP. (at least in my experience ^_^)
Thanks also goes to Jeff for prompting for more information as that is _always_
needed and welcome.
Does anyone know if the makers of FreePPP (can't remember the company right now) is
responding to this in any way?
das
Todd Keister (Todd_Keister@mw.3com.com) spake:
>
>
>
> Jeff:
>
>
> Here is some more specific information regarding the Free PPP issue. This
> information will soon be published on the 3Com Knowledgebase website
> (http://knowledgebase.3com.com).
>
>
> I hope this helps.
>
>
> Todd ;-}
>
>
>
<snip>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Jason Cropper" <jason@clearsail.net>
Subject: RE: (usr-tc) Ascend Pipeline 50
Date: 27 Sep 1999 13:34:45 -0500
The reason you're not getting a "Start" in your RADIUS is simple. The
Ascend is not accepting the IP assigned to it by the Netserver/ARC. Enable
"NAT" in the Ascend. All should be well then. I've had that problem many
times before.
Jason
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
vanhalen@coredcs.com
Sent: Friday, September 24, 1999 15:00
Hello-
For whatever reason, unknown to me, I cannot get an Ascend Pipeline 50 to
connect correctly via ISDN. I have other users connecting 100% fine to a
Netserver based box running Quads. Most of those users are ISDN.
When this user with the Ascend dials in, they never get a Start record in
radius accounting. I can see them come across but it never starts and it
immediately disconnects them.
Anyone have any ideas on what I can change on the Pipeline to get them to
work?
Since I have everyone running fine on this box except the Ascend, I don't
think I need to change anything on the box or at the very least I'm really
reluctant to do so.
Here are the versions anyway.
NMC 5.5.0
Netserver ??
Quad 5.10.9
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Steve Rivera <sales@wrca.net>
Subject: Re: (usr-tc) Multilink Question
Date: 24 Sep 1999 11:53:50 -0400
The customer may be varying the bond on his hardware.
I run MultiLink PPP here and I have my office router
config'd for 55%. That where the other channel will kick in.
It may be possible that he is dropping the line.
At 10:31 PM 09/23/1999 -0600, you wrote:
>I have a ISDN user setup as network,dialout, continuous. It works fine when
>the HiperARC first calls the client. It bonds both channels just great. If
>for some reason a channel is dropped, the HiperARC never tries to
>re-establish the dropped channel. I have tried both linear and constant
>for the expansion algorithm. How do you make the HiperARC maintain 2
>channels relentlessly?
>
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Gustavo Ruiz Zastrow <gustavo.zastrow@conexion.com.py>
Subject: Re: (usr-tc) Failure to negociate V90
Date: 27 Sep 1999 17:46:46 -0400
I have a similar problem with a user that have a Compaq 420 Microcom K56/V90 PCMCIA
modem, and fails to connect to our TotalControl.
How can I disable the V.90 and X2 features ?
Gustavo Ruiz
Ray Whelan wrote:
> Hi Fred,
>
> I have a document which I will send you offline which will enable you to further
> trouble shoot this problem
>
> Ray W
>
> "Fred Williams" <fwilliams@gtnet.gov.uk> on 01/04/99 14:29:38
>
> Please respond to usr-tc@lists.xmission.com
>
> To: usr-tc@lists.xmission.com
> cc: (Ray Whelan/IE/3Com)
> Subject: (usr-tc) Failure to negociate V90
>
> We have a user with a Compaq 420 Microcom K56/V90 PCMCIA
> modem. He is failing to get a connection better than 31.2K when
> dialiing into our TC Racks (mix of Quads and Netserver plus Hiper
> DSP and ARC). He regularly gets a 41 to 44K connection into other
> ISPs. He claims to have the latest V90 code on his modem. Can
> anyone offer a solution please?
>
> ****************************************************************
> * Fred Williams email fwilliams@gtnet.gov.uk *
> * CCTA voice 01603 704706 *
> * Rosebery Court GTN 3040 4706 *
> * St Andrews Business Park fax 01603 704817 *
> * NORWICH GTN fax 3040 4817 *
> * NR7 0HS UK *
> ****************************************************************
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jerry Wright <jwright@iaml.net>
Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
Date: 26 Sep 1999 15:32:54 -0700
Todd Keister wrote:
> 3. Use Open Transport, which is built in to System 8 OS
> for the Mac. Open Transport (Mac RAS client) is also available as an
> add on product for systems using System 7.x OS (that won't support
> 8.x).
This is really the best solution. Open Transport is a much more robust PPP solution
than FreePPP...
--Jerry
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: ROC Services <roc@itol.com>
Subject: (usr-tc) Acct-Terminate-Cause values
Date: 24 Sep 1999 00:19:20 -0500 (CDT)
Since just recently (probably since upgrading to 4.2 HiperARC code) I'm
seeing a fair number of RADIUS log entries with Terminate-Cause 29 and 30
which are not in my RADIUS dictionary, nor in RFC 2139, nor revealed by a
quick perusal of the HiPerARC reference guide. Can any of the TC gurus
give me a quick answer as to what these are? A pointer to the correct FM
to read would be fine also.
Thanks...
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Ahmed Saeed <Ahmed.Saeed@widener.edu>
Subject: Re: (usr-tc) Cisco 800 to Arc
Date: 23 Sep 1999 14:03:49 -0400 (EDT)
This only states that after the pap authentication, the end node is
sending out a terminate request. Functionality of hiper arc is to send an
ack to that packet.
Need to provide the LCP config requests - mon ppp - next session.
The end node is sending the terminate request - you need to look into his
config settings - it should not be sending out a terminate request right
after a auth ack.
Ahmed
On Wed, 22 Sep 1999, Jim Johnson wrote:
>
> If anyone out there can take a look at this config/debug trace and tell
> me what the problem is, I would appreciate it. I hope I am not wrong in
> assuming that the Cisco 800 series can connect to the USR TC chassis.
>
> Regards,
>
> Jim
>
> ARC MON PPP
> ----------
> On the ARC all I see is:
>
> Outgoing PPP Data on interface: slot:10/mod:13
> PAP ACK ....Tracing for user "xxx"; Escape to
> stop...
>
> Incoming PPP Data on interface: slot:10/mod:13
> LCP TERM_REQ
>
> Outgoing PPP Data on interface: slot:10/mod:13
> LCP TERM_ACK
>
>
>
> Cisco Config
> --------------------------
>
> !
> version 12.0
> no service pad
> service timestamps debug uptime
> service timestamps log uptime
> service password-encryption
> service udp-small-servers
> service tcp-small-servers
>
> !
> hostname Router
>
> !
> no logging console
> enable secret 5 $1$3NxJ$hNMKdU72/q/0z9vJLJRkv.
>
> !
> ip subnet-zero
>
> !
> isdn switch-type basic-ni
>
> !
>
> !
>
> !
> interface Ethernet0
> ip address xxx.xxx.63.9 255.255.255.252
> no ip directed-broadcast
> !
> interface BRI0
> description PPP to Internet
> ip address negotiated
> no ip directed-broadcast
> encapsulation ppp
> dialer idle-timeout 2147483
> dialer map ip xxx.xxx.60.3 5551212
> dialer hold-queue 10
> dialer load-threshold 1 outbound
> dialer-group 1
> isdn switch-type basic-ni
> isdn spid1 70455511110100
> isdn spid2 70455511120100
> no fair-queue
> no cdp enable
> no ppp lcp fast-start
> ppp authentication pap
> ppp pap sent-username dsi password 7 130C2111020812
>
>
>
> Debug Session
> ------------------------------------
>
> 03:07:55840355292: BR0:1 PPP: Treating connection as a callout
> 03:07:55834615808: BR0:1 PPP: Phase is ESTABLISHING, Active Open
> 03:07:55835256358: BR0:1 LCP: O CONFREQ [Closed] id 174 len 14
> 03:07:60129542143: BR0:1 LCP: AuthProto PAP (0x0304C023)
> 03:07:55834615808: BR0:1 LCP: MagicNumber 0xD0B16CC6 (0x0506D0B16CC6)
> 03:07:14: BR0:1 PPP: I pkt type 0xC021, datagramsize 33
> 03:07:14: BR0:1 LCP: I CONFREQ [REQsent] id 1 len 29
> 03:07:14: BR0:1 LCP: MRU 1514 (0x010405EA)
> 03:07:14: BR0:1 LCP: AuthProto PAP (0x0304C023)
> 03:07:14: BR0:1 LCP: MagicNumber 0xB6EBDD04 (0x0506B6EBDD04)
> 03:07:14: BR0:1 LCP: PFC (0x0702)
> 03:07:14: BR0:1 LCP: ACFC (0x0802)
> 03:07:14: BR0:1 LCP: MRRU 1514 (0x110405EA)
> 03:07:14: BR0:1 LCP: EndpointDisc 0 Null (0x130300)
> 03:07:15: BR0:1 LCP: O CONFREJ [REQsent] id 1 len 11
> .03:07:15: BR0:1 LCP: MRRU 1514 (0x110405EA)
> 03:07:15: BR0:1 LCP: EndpointDisc 0 Null (0x130300)
> 03:07:15: BR0:1 PPP: I pkt type 0xC021, datagramsize 26
> 03:07:15: BR0:1 LCP: I CONFREQ [REQsent] id 2 len 22
> 03:07:15: BR0:1 LCP: MRU 1514 (0x010405EA)
> 03:07:15: BR0:1 LCP: AuthProto PAP (0x0304C023)
> 03:07:15: BR0:1 LCP: MagicNumber 0xB6EBDD04 (0x0506B6EBDD04)
> 03:07:15: BR0:1 LCP: PFC (0x0702)
> 03:07:15: BR0:1 LCP: ACFC (0x0802)
> 03:07:15: BR0:1 LCP: O CONFACK [REQsent] id 2 len 22
> 03:07:15: BR0:1 LCP: MRU 1514 (0x010405EA)
> 03:07:15: BR0:1 LCP: AuthProto PAP (0x0304C023)
> 03:07:15: BR0:1 LCP: MagicNumber 0xB6EBDD04 (0x0506B6EBDD04)
> 03:07:15: BR0:1 LCP: PFC (0x0702)
> 03:07:15: BR0:1 LCP: ACFC (0x0802)
> 03:07:15: BR0:1 LCP: TIMEout: State ACKsent
> 03:07:15: BR0:1 LCP: O CONFREQ [ACKsent] id 175 len 14
> 03:07:15: BR0:1 LCP: AuthProto PAP (0x0304C023)
> 03:07:15: BR0:1 LCP: MagicNumber 0xD0B16CC6 (0x0506D0B16CC6)
> 03:07:15: BR0:1 PPP: I pkt type 0xC021, datagramsize .18
> 03:07:15: BR0:1 LCP: I CONFACK [ACKsent] id 175 len 14
> 03:07:15: BR0:1 LCP: AuthProto PAP (0x0304C023)
> 03:07:15: BR0:1 LCP: MagicNumber 0xD0B16CC6 (0x0506D0B16CC6)
> 03:07:15: BR0:1 LCP: State is Open
> 03:07:15: BR0:1 PPP: Phase is AUTHENTICATING, by both
> 03:07:15: BR0:1: PAP_SENDREQUEST (0x288A500) id 0 (0s.) queued
> 1/1/2
> 03:07:15: BR0:1: AAA_PER_USER LCP_UP (0x288A5B0) id 0 (0s.)
> queued 2/2/2
> 03:07:15: BR0:1: PAP_SENDREQUEST (0x288A500) id 0 (0s.) busy/0
> started 1/2/2
> 03:07:15: BR0:1 PAP: O AUTH-REQ id 51 len 15 from "dsi"
> 03:07:15: BR0:1: PAP_SENDREQUEST (0x288A500) id 0 (0s.) busy/0 done
> in 0 s. 0/1/2
> 03:07:15: BR0:1: AAA_PER_USER LCP_UP (0x288A5B0) id 0 (0s.)
> busy/0 started 1/1/2
> 03:07:15: BR0:1: AAA_PER_USER LCP_UP (0x288A5B0) id 0 (0s.)
> busy/0 done in 0 s. 0/0/2
> 03:07:16: BR0:1 PPP: I pkt type 0xC023, datagramsize 9
> 03:07:16: BR0:1 PAP: I AUTH-ACK id 51 len 5.
> 03:07:19: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 9440140
> ..
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: <pferraro@wna-linknet.com>
Subject: Re: (usr-tc) Failure to negociate V90
Date: 27 Sep 1999 18:05:24 -0400 (EDT)
Best thing to do would be to have the client go out and get the
latest "SoftPak" upgrade from Compaq... We have had a number of new users
with Compaqs (All series) that had problems, but the Softpak upgrade CURED
99% of them!
==============================================================================
Phillip Ferraro WorldNet Access, Inc
pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
Voice (910) 346-0835 824 Gumbranch Square, Suite R3
FAX (910) 455-1933 Jacksonville, Nc 28540-6269
==============================================================================
On Mon, 27 Sep 1999, Gustavo Ruiz Zastrow wrote:
> I have a similar problem with a user that have a Compaq 420 Microcom K56/V90 PCMCIA
> modem, and fails to connect to our TotalControl.
> How can I disable the V.90 and X2 features ?
> Gustavo Ruiz
>
> Ray Whelan wrote:
>
> > Hi Fred,
> >
> > I have a document which I will send you offline which will enable you to further
> > trouble shoot this problem
> >
> > Ray W
> >
> > "Fred Williams" <fwilliams@gtnet.gov.uk> on 01/04/99 14:29:38
> >
> > Please respond to usr-tc@lists.xmission.com
> >
> > To: usr-tc@lists.xmission.com
> > cc: (Ray Whelan/IE/3Com)
> > Subject: (usr-tc) Failure to negociate V90
> >
> > We have a user with a Compaq 420 Microcom K56/V90 PCMCIA
> > modem. He is failing to get a connection better than 31.2K when
> > dialiing into our TC Racks (mix of Quads and Netserver plus Hiper
> > DSP and ARC). He regularly gets a 41 to 44K connection into other
> > ISPs. He claims to have the latest V90 code on his modem. Can
> > anyone offer a solution please?
> >
> > ****************************************************************
> > * Fred Williams email fwilliams@gtnet.gov.uk *
> > * CCTA voice 01603 704706 *
> > * Rosebery Court GTN 3040 4706 *
> > * St Andrews Business Park fax 01603 704817 *
> > * NORWICH GTN fax 3040 4817 *
> > * NR7 0HS UK *
> > ****************************************************************
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: tatamo@simicro.mg (Simicro - RAKOTOBE Tatamo)
Subject: (usr-tc) need iformation about hiper DSP card
Date: 22 Sep 1999 12:00:13 +0300
Hi,
I'm a student from Madagascar and I'm doing now a training at an ISP. We =
want to give ISDN access to our Clients that why I contact you, we use =
now Total control with Quad Modem card and Edge Server card.=20
Can you give me information related in ISDN, Hiper DSp card, Dual PRI =
card, their price, and other technical information.
Thank you.
PS: is it possible to send the answer in french because I'm francophone.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
tatamo@simicro.mg
na koa trakotob@syfed.refer.mg
hafa koa shiny_lotus@geocities.com
MADAGASIKARA
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: <liping@netsol.net>
Subject: RE: (usr-tc) need iformation about hiper DSP card
Date: 27 Sep 1999 16:06:10 -0700
Get the ISDN PRI instead of trunk T-1.
Sorry, No Franch.
Liping
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Simicro - RAKOTOBE
Tatamo
Sent: Wednesday, September 22, 1999 2:00 AM
Hi,
I'm a student from Madagascar and I'm doing now a training at an ISP. We
want to give ISDN access to our Clients that why I contact you, we use now
Total control with Quad Modem card and Edge Server card.
Can you give me information related in ISDN, Hiper DSp card, Dual PRI card,
their price, and other technical information.
Thank you.
PS: is it possible to send the answer in french because I'm francophone.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
tatamo@simicro.mg
na koa trakotob@syfed.refer.mg
hafa koa shiny_lotus@geocities.com
MADAGASIKARA
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Martin Lathoud <nytral@enDirect.qc.ca>
Subject: (usr-tc) Netserver FC3
Date: 28 Sep 1999 08:34:58 -0400 (EDT)
Hi,
you advised me to check for chip revision on my Netserver card about the
crash problem. I had a chance to do it this morning, and guess what? It's
a FC3.. Since it seems to be a known problem, will 3Com do something even
without contract support (as far as you know) ?
Thanks,
Martin
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) Netserver FC3
Date: 28 Sep 1999 09:11:13 -0400
Thus spake Martin Lathoud
>you advised me to check for chip revision on my Netserver card about the
>crash problem. I had a chance to do it this morning, and guess what? It's
>a FC3.. Since it seems to be a known problem, will 3Com do something even
>without contract support (as far as you know) ?
They have claimed they are still doing hardware support for the
NETServers (which, by law, I believe they have to ;). So, if your
NETServer is still under warranty, you should be able to get a hardware
fix/replacement. It won't be an advanced replacement, so you'll either
be down a few lines, or need a spare you can put into service for a
couple of weeks while yours goes back to 3Com and is replaced.
FWIW, I've found 3Com to be quite quick about warranty
repair/replacement...usually a small fraction of the time they tell you
to allow.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: jeff.binkley@asacomp.com (Jeff Binkley)
Subject: (usr-tc) Web Ramps ?
Date: 28 Sep 1999 09:08:00 -0500
We are still running HiPerArc code 4.1.64 due to 4.1.56 breaking the
ability of older Web Ramps to connect. We are looking to go to a newer
version of HiPerArc code. Does anyone know if this problem is fixed in
the newer code ? I couldn't find it in the release notes. Also does
anyone know if the intermittient loss of Radius accounting records is
fixed either ?
Thanks,
Jeff Binkley
ASA Network Computing
CMPQwk 1.42 9999
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Sheldon Koehler" <sheldon@tenforward.com>
Subject: Re: (usr-tc) Web Ramps ?
Date: 28 Sep 1999 09:58:09 -0700
We have an issue with a couple of Webramps. We are using 4.1.46 and I was
going to upgrade to 4.2.32 to see if it worked. Does anyone else have input
on this?
Sheldon
----- Original Message -----
Sent: Tuesday, September 28, 1999 7:08 AM
>
>
> We are still running HiPerArc code 4.1.64 due to 4.1.56 breaking the
> ability of older Web Ramps to connect. We are looking to go to a newer
> version of HiPerArc code. Does anyone know if this problem is fixed in
> the newer code ? I couldn't find it in the release notes. Also does
> anyone know if the intermittient loss of Radius accounting records is
> fixed either ?
>
>
> Thanks,
>
> Jeff Binkley
> ASA Network Computing
>
> CMPQwk 1.42 9999
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike Wilker" <mikew@LL.NET>
Subject: (usr-tc) HiperDSPs to HiperArcs
Date: 28 Sep 1999 12:32:43 -0500
I keep hearing 7 DSPs per Arc. Is this a set maximum or a practical max if
you are running lots of services? Can I run 8 DSPs on one Arc if I'm just
doing basic dial-up with no tunneling and such?
Mike Wilker
Operations Manager
Local Link, Inc.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike Wronski" <mike@coredump.ae.usr.com>
Subject: RE: (usr-tc) Web Ramps ?
Date: 28 Sep 1999 13:32:33 -0500
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley
|Sent: Tuesday, September 28, 1999 9:08 AM
|To: usr-tc@lists.xmission.com
|Subject: (usr-tc) Web Ramps ?
|
|
|
|
|We are still running HiPerArc code 4.1.64 due to 4.1.56 breaking the
|ability of older Web Ramps to connect. We are looking to go to a newer
|version of HiPerArc code. Does anyone know if this problem is fixed in
|the newer code ? I couldn't find it in the release notes. Also does
|anyone know if the intermittient loss of Radius accounting records is
|fixed either ?
|
4.1.56? What were you given that for? Does 4.1.59-6 not work for you as well?
There have been no specific WebRamp issues resolved. There have been fixes to PPP
strict checking on HARC and some interaction changes involving the DSP card.
These fixes are available in 4.2.32-1 and shortly in a new 4.1 service release.
If you do not need OSPF, wait for the 4.1 service release or open a support
ticket to get it as an ER.
As for the RADIUS accouting record loss. A few items have been resolved that may
casue this symptom. They are available in a 4.1.x ER now (if you open a ticket).
4.2.32-1, or you can wait for the service release. Opening a ticket would be the
better option. Since different factors and configurations may result in the loss
of the packet, until further inestigation is done, a fix for your problem cannot
be guaranteed.
-M
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike Wronski" <mike@coredump.ae.usr.com>
Subject: RE: (usr-tc) HiperDSPs to HiperArcs
Date: 28 Sep 1999 13:37:42 -0500
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Wilker
|Sent: Tuesday, September 28, 1999 12:33 PM
|To: usr-tc@lists.xmission.com
|Subject: (usr-tc) HiperDSPs to HiperArcs
|
|
|I keep hearing 7 DSPs per Arc. Is this a set maximum or a practical max if
|you are running lots of services? Can I run 8 DSPs on one Arc if I'm just
|doing basic dial-up with no tunneling and such?
|
The 7DSP number came about from stress testing of HiperARC 4.0.x code. from that
testing a performance fall off was seen after adding the 8th span of calls.
(these calls are all doing PPP and FTP downloads. ). Since then the falloff has
moved out and the severity of the fall off greatly reduced to a point of little
impact for a full 14 spans. The FTP test is a little more severe than the stand
mix of activities/data rates/packet sizes seen in normal operation.
The 7 span recommendation is still in effect if IPX or l2tp is to be run over the
PPP links.
So the answer to your question is 8 DSPs will not be a problem. You should be
running 4.1.59-6 or newer code on your HARC and DSP 2.0.81 or newer.
-M
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Rick <rallan@monmouth.com>
Subject: Re: (usr-tc) HiperDSPs to HiperArcs
Date: 28 Sep 1999 20:29:33 -0400
If you are running IP only then a single Arc can support upto 14 DSP's. IPX has
a limitation of 7DSP's.
Mike Wilker wrote:
> I keep hearing 7 DSPs per Arc. Is this a set maximum or a practical max if
> you are running lots of services? Can I run 8 DSPs on one Arc if I'm just
> doing basic dial-up with no tunneling and such?
>
> Mike Wilker
> Operations Manager
> Local Link, Inc.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone
Head of Network Engineering | Monmouth Internet Corporation
732-842-5366=====extension 102 | http://www.monmouth.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Greg Coffey <greg@coffey.com>
Subject: (usr-tc) 3Com, Please Address This
Date: 28 Sep 1999 21:28:07 -0600
Enclosed is some dialogue with a customer of mine.
************
Bill, thanks for the feedback. Trib uses Ascend servers for their modems.
We use 3Com (merged with USR) exclusively. We've noted that some
subscribers that dial in using 3Com modems connect FASTER with the Ascend
than the 3Com. In fact, they never connect >33.6 with the 3Com servers but
consistently with the Ascends at a v.90 rate. I pointed out the problem to
3Com about a year ago and there was not much interest on their part at the
time. A couple months ago, it came up again. This time there was more
interest and discussion. 3Com tells me that there is a bug in the Ascend
server software that permits this anomaly. The number of subscribers that
this impacts is small (I believe), though I've not really spent much time
regarding it. 3Com told me earlier that if they fixed the software, it
would break other modems connect rates and even connectivity. One of my
techs (lives in Mills) can connect to Trib from home under the same
circumstances as you. I gave him a Courier v.everything to try last week
with the latest firmware. Same results as his Sportster model. We are
running current software on our end too. We just spent thousands to
upgrade our quad modems to the newer hiper design, no change. We added a
hiperarc, again newer design and, again, thousands more invested. No
change. We did dump the Sportster modem registers and send them to a 3Com
engineer both a year ago and more recently. I've not heard anything about
it for about a month since the last time it came up. I've looked at Ascend
equipment but so far have stayed with 3Com. Baffles me too why brand-x
modems work better with brand-y's servers. Why brand-x can't or won't
resolve the issue baffles me too. The 3Com servers are not junk. We do
have lots of subscribers that can connect to our servers and getting v.90
connection rates. I think we've dealt with maybe 6 or so people that are
in your situation. Perhaps the number is higher but they aren't aware of
it. I don't have an answer for you at this point but will forward this to
3Com.
At 08:15 PM 9/28/99 -0600, you wrote:
>I signed up today and got onto your system.
>
>It is only a few hours, but so far I'm not impressed with the speed over
>Trib.com.
>
>First of all, I cannot connect at as fast a speed.
>
>I have a USR Sportster Voice 56k v.90 modem model 00178501 with the latest
>drivers and firmware.
>
>With trib.com, I can connect sometimes @ 45,333 and always @ 37,333.
>
>I tried your 3 numbers:
>
> 234-2088 26,400 most of the time, 28,800 sometimes.
> 234-6324 same
> 266-4165 31,200 all the time.
>
>I tried several file download tests between the two systems and trib won
>handily.
>
>I will do some more comparing over the next few days, but it isn't what I
>was hoping for.
>
>If you have any other ideas, I would love to hear them.
>
>Thanks,
>
>Bill xxxxx
>
>-----Original Message-----
>From: Greg Coffey <gcoffey@vcn.com>
>To: Bill
>Date: Friday, September 10, 1999 8:45 AM
>Subject: Re:
>
>
>>We have 3 separate T1's to the Internet and are getting a fract T3 within
>>two months. You are welcome to try us and compare for yourself. Sign up
>>online or come by the store. If you don't like our service, I will refund
>>your fee for the month. We are in the process of a major upgrade that
>>takes place on September 20th. That will make us even better than we are
>now.
>>
>>
>>At 06:48 AM 9/10/99 -0600, you wrote:
>>>I am in Casper - in the Sunrise 8 area.
>>>
>>>I am looking for bandwidth to the net overall.
>>>
>>>I can connect @ 37,333 to Trib and maintain connection.
>>>
>>>I can connect @ around 45,000, but the connection is not stable.
Thanks,
Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446
=====================================================================
100 N. Center St., Casper, WY 82601 WWW.VCN.COM
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Ed" <ed@taylors.com>
Subject: Re: (usr-tc) 3Com, Please Address This
Date: 28 Sep 1999 23:50:03 -0400
Greg Coffey wrote:
"Perhaps the number is higher but they aren't aware of it. I don't have an
answer for you at this point but will forward this to 3Com"
My 2 Cents:
It is higher. This is the same subject I raised about a month ago on this
list. We have tested this and 3com is supposed to be working on a fix for it
however it seems they have now pushed it to the back burners once again.
They even developed a non-public alpha code to try to resolve it.
No doubt in some circumstances Ascends work better. We have tested on the
same PRI line hooked into the 3com and then moved it to the Ascend. The
customers are able to get V.90 more often on the Ascends than on the 3com's.
This even happens with 3com client modems.
We screamed about this discovery and it seemed 3com was sincerely concerned
but now I am not so certain it wasn't just to appease us.
If I were 3com I would be a little more concerned with this... but thats me.
I can say we won't wait forever for a fix. Other technologies are going to
overtake V90 before they resolve it, it seems.
Ed
----- Original Message -----
Sent: Tuesday, September 28, 1999 11:28 PM
Enclosed is some dialogue with a customer of mine.
************
Bill, thanks for the feedback. Trib uses Ascend servers for their modems.
We use 3Com (merged with USR) exclusively. We've noted that some
subscribers that dial in using 3Com modems connect FASTER with the Ascend
than the 3Com. In fact, they never connect >33.6 with the 3Com servers but
consistently with the Ascends at a v.90 rate. I pointed out the problem to
3Com about a year ago and there was not much interest on their part at the
time. A couple months ago, it came up again. This time there was more
interest and discussion. 3Com tells me that there is a bug in the Ascend
server software that permits this anomaly. The number of subscribers that
this impacts is small (I believe), though I've not really spent much time
regarding it. 3Com told me earlier that if they fixed the software, it
would break other modems connect rates and even connectivity. One of my
techs (lives in Mills) can connect to Trib from home under the same
circumstances as you. I gave him a Courier v.everything to try last week
with the latest firmware. Same results as his Sportster model. We are
running current software on our end too. We just spent thousands to
upgrade our quad modems to the newer hiper design, no change. We added a
hiperarc, again newer design and, again, thousands more invested. No
change. We did dump the Sportster modem registers and send them to a 3Com
engineer both a year ago and more recently. I've not heard anything about
it for about a month since the last time it came up. I've looked at Ascend
equipment but so far have stayed with 3Com. Baffles me too why brand-x
modems work better with brand-y's servers. Why brand-x can't or won't
resolve the issue baffles me too. The 3Com servers are not junk. We do
have lots of subscribers that can connect to our servers and getting v.90
connection rates. I think we've dealt with maybe 6 or so people that are
in your situation. Perhaps the number is higher but they aren't aware of
it. I don't have an answer for you at this point but will forward this to
3Com.
At 08:15 PM 9/28/99 -0600, you wrote:
>I signed up today and got onto your system.
>
>It is only a few hours, but so far I'm not impressed with the speed over
>Trib.com.
>
>First of all, I cannot connect at as fast a speed.
>
>I have a USR Sportster Voice 56k v.90 modem model 00178501 with the latest
>drivers and firmware.
>
>With trib.com, I can connect sometimes @ 45,333 and always @ 37,333.
>
>I tried your 3 numbers:
>
> 234-2088 26,400 most of the time, 28,800 sometimes.
> 234-6324 same
> 266-4165 31,200 all the time.
>
>I tried several file download tests between the two systems and trib won
>handily.
>
>I will do some more comparing over the next few days, but it isn't what I
>was hoping for.
>
>If you have any other ideas, I would love to hear them.
>
>Thanks,
>
>Bill xxxxx
>
>-----Original Message-----
>From: Greg Coffey <gcoffey@vcn.com>
>To: Bill
>Date: Friday, September 10, 1999 8:45 AM
>Subject: Re:
>
>
>>We have 3 separate T1's to the Internet and are getting a fract T3 within
>>two months. You are welcome to try us and compare for yourself. Sign up
>>online or come by the store. If you don't like our service, I will refund
>>your fee for the month. We are in the process of a major upgrade that
>>takes place on September 20th. That will make us even better than we are
>now.
>>
>>
>>At 06:48 AM 9/10/99 -0600, you wrote:
>>>I am in Casper - in the Sunrise 8 area.
>>>
>>>I am looking for bandwidth to the net overall.
>>>
>>>I can connect @ 37,333 to Trib and maintain connection.
>>>
>>>I can connect @ around 45,000, but the connection is not stable.
Thanks,
Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446
=====================================================================
100 N. Center St., Casper, WY 82601 WWW.VCN.COM
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Brian Gordon" <brian@westelcom.com>
Subject: Re: (usr-tc) 3Com, Please Address This
Date: 29 Sep 1999 08:00:12 -0400
This is not consistent with my finding at all. I have a courier and get
49,300 every time flawlessly to my total control dsp equip. Looks like a
telco issue if you ask me.
Just my two sense.
Brian Gordon
MCP, A+, Network +
Network Administrator
Westelcom Internet
518.566.6726 Voice
419.831.9137 Fax
http://www.westelcom.com
administrator@westelcom.com
----- Original Message -----
Sent: Tuesday, September 28, 1999 11:28 PM
> Enclosed is some dialogue with a customer of mine.
>
> ************
> Bill, thanks for the feedback. Trib uses Ascend servers for their modems.
> We use 3Com (merged with USR) exclusively. We've noted that some
> subscribers that dial in using 3Com modems connect FASTER with the Ascend
> than the 3Com. In fact, they never connect >33.6 with the 3Com servers
but
> consistently with the Ascends at a v.90 rate. I pointed out the problem
to
> 3Com about a year ago and there was not much interest on their part at the
> time. A couple months ago, it came up again. This time there was more
> interest and discussion. 3Com tells me that there is a bug in the Ascend
> server software that permits this anomaly. The number of subscribers that
> this impacts is small (I believe), though I've not really spent much time
> regarding it. 3Com told me earlier that if they fixed the software, it
> would break other modems connect rates and even connectivity. One of my
> techs (lives in Mills) can connect to Trib from home under the same
> circumstances as you. I gave him a Courier v.everything to try last week
> with the latest firmware. Same results as his Sportster model. We are
> running current software on our end too. We just spent thousands to
> upgrade our quad modems to the newer hiper design, no change. We added a
> hiperarc, again newer design and, again, thousands more invested. No
> change. We did dump the Sportster modem registers and send them to a 3Com
> engineer both a year ago and more recently. I've not heard anything about
> it for about a month since the last time it came up. I've looked at
Ascend
> equipment but so far have stayed with 3Com. Baffles me too why brand-x
> modems work better with brand-y's servers. Why brand-x can't or won't
> resolve the issue baffles me too. The 3Com servers are not junk. We do
> have lots of subscribers that can connect to our servers and getting v.90
> connection rates. I think we've dealt with maybe 6 or so people that are
> in your situation. Perhaps the number is higher but they aren't aware of
> it. I don't have an answer for you at this point but will forward this to
> 3Com.
>
> At 08:15 PM 9/28/99 -0600, you wrote:
> >I signed up today and got onto your system.
> >
> >It is only a few hours, but so far I'm not impressed with the speed over
> >Trib.com.
> >
> >First of all, I cannot connect at as fast a speed.
> >
> >I have a USR Sportster Voice 56k v.90 modem model 00178501 with the
latest
> >drivers and firmware.
> >
> >With trib.com, I can connect sometimes @ 45,333 and always @ 37,333.
> >
> >I tried your 3 numbers:
> >
> > 234-2088 26,400 most of the time, 28,800 sometimes.
> > 234-6324 same
> > 266-4165 31,200 all the time.
> >
> >I tried several file download tests between the two systems and trib won
> >handily.
> >
> >I will do some more comparing over the next few days, but it isn't what I
> >was hoping for.
> >
> >If you have any other ideas, I would love to hear them.
> >
> >Thanks,
> >
> >Bill xxxxx
> >
> >-----Original Message-----
> >From: Greg Coffey <gcoffey@vcn.com>
> >To: Bill
> >Date: Friday, September 10, 1999 8:45 AM
> >Subject: Re:
> >
> >
> >>We have 3 separate T1's to the Internet and are getting a fract T3
within
> >>two months. You are welcome to try us and compare for yourself. Sign
up
> >>online or come by the store. If you don't like our service, I will
refund
> >>your fee for the month. We are in the process of a major upgrade that
> >>takes place on September 20th. That will make us even better than we
are
> >now.
> >>
> >>
> >>At 06:48 AM 9/10/99 -0600, you wrote:
> >>>I am in Casper - in the Sunrise 8 area.
> >>>
> >>>I am looking for bandwidth to the net overall.
> >>>
> >>>I can connect @ 37,333 to Trib and maintain connection.
> >>>
> >>>I can connect @ around 45,000, but the connection is not stable.
>
>
> Thanks,
>
> Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446
> =====================================================================
> 100 N. Center St., Casper, WY 82601 WWW.VCN.COM
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Kevin Benton <s1kevin@tims.net>
Subject: Re: (usr-tc) 3Com, Please Address This
Date: 29 Sep 1999 08:26:35 -0400 (EDT)
On Tue, 28 Sep 1999, Ed wrote:
> Greg Coffey wrote:
> "Perhaps the number is higher but they aren't aware of it. I don't have an
> answer for you at this point but will forward this to 3Com"
>
> My 2 Cents:
> It is higher. This is the same subject I raised about a month ago on this
> list. We have tested this and 3com is supposed to be working on a fix for it
> however it seems they have now pushed it to the back burners once again.
> They even developed a non-public alpha code to try to resolve it.
yadda yadda yadda... Rest deleted.
Do you guys have cases open with 3Com about this? I would be happy to
help push this issue as another 3Com customer with my NC, however, there's
little I can do to help if I don't have something I can give him... I'm
not interested in working on your case for you but I do want our equipment
to be able to handle calls as well or better than Ascend product.
Kevin
E-Mail: s1kevin@tims.net
Web: http://users.sota-oh.com/~s1kevin/
Unsolicited advertisements processing fee: $50 subject to change without notice
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: jeff.binkley@asacomp.com (Jeff Binkley)
Subject: RE: (usr-tc) Web Ramps ?
Date: 29 Sep 1999 08:24:00 -0500
u>|-----Original Message-----
u>|From: owner-usr-tc@lists.xmission.com
u>|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley
u>|Sent: Tuesday, September 28, 1999 9:08 AM
u>|To: usr-tc@lists.xmission.com
u>|Subject: (usr-tc) Web Ramps ?
u>|
u>|
u>|
u>|
u>|We are still running HiPerArc code 4.1.64 due to 4.1.56 breaking the
u>|ability of older Web Ramps to connect. We are looking to go to a
u>newer |version of HiPerArc code. Does anyone know if this problem is
u>fixed in |the newer code ? I couldn't find it in the release notes.
u>Also does |anyone know if the intermittient loss of Radius accounting
u>records is |fixed either ?
u>|
u>4.1.56? What were you given that for? Does 4.1.59-6 not work for you
u>as well?
u>There have been no specific WebRamp issues resolved. There have been
u>fixes to PPP
u>strict checking on HARC and some interaction changes involving the DSP
u>card. These fixes are available in 4.2.32-1 and shortly in a new 4.1
u>service release.
u>If you do not need OSPF, wait for the 4.1 service release or open a
u>support ticket to get it as an ER.
u>As for the RADIUS accouting record loss. A few items have been
u>resolved that may
u>casue this symptom. They are available in a 4.1.x ER now (if you open
u>a ticket).
u>4.2.32-1, or you can wait for the service release. Opening a ticket
u>would be the
u>better option. Since different factors and configurations may result
u>in the loss
u>of the packet, until further inestigation is done, a fix for your
u>problem cannot
u>be guaranteed.
Mike,
That was a typo on my part. We are running 4.1.64 instead of 4.1.59-6
because, as I understand it, you folks put a fix in 4.1.59-6 in the
HiPerArc code to fix the timing problem you were having with the DSP
code. When this happened, it broke the ability for certain Web Ramps to
connect. Going back to 4.1.64 was the only solution. Krish was aware
of this. So I am not sure, based upon your comments, whether web ramps
will work again or not with the 4.2.32-1 code. As for the accounting
record loss, this has been a problem for some time now. I don't know
exactly what code release introduced the problem but I know we cannot
turn on concurrency checking on the S/A software because after a few
hours we will start getting calls about folks not being able to connect.
Checking the S/A users table will show a connection but looking in the
HiPerArc they aren't connected.
Thanks,
Jeff Binkley
ASA Network Computing
CMPQwk 1.42 9999
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: jeff.binkley@asacomp.com (Jeff Binkley)
Subject: (usr-tc) Ascend Pipelines
Date: 29 Sep 1999 08:24:00 -0500
We have 3 Ascend Pipeline 50/75 customers connecting to our TC chassis'.
In each case we give them a static IP address via Radius. In all cases
we cannot ping the static address (i.e. Ascend doesn't respond) yet the
users behind the pipeline work fine adn we can telnet into the Ascend if
we add a static route for port 23 to the static IP address. Does anyone
know how to correct this ? It makes troubleshooting more difficult when
ping doesn't work.
Thanks,
Jeff Binkley
ASA Network Computing
CMPQwk 1.42 9999
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: david@carolnet.com (David Swearingin)
Subject: (usr-tc) MRTG & Quads & Analog
Date: 29 Sep 1999 08:53:10 -0500
Can anyone tell me the MRTG target to use for tracking modem usage on Quad
modem cards connected to analog lines?
Thanks.
David
__________________________________________________
David Swearingin (david@carolnet.com)
CARROLLTON INTERNET SERVICE (www.carolnet.com)
First Financial Group, Inc.
11 N. Folger, Carrollton, MO 64633
660-542-3002 Fax 660-542-3003
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: <farber@admin.f-tech.net>
Subject: Re: (usr-tc) 3Com, Please Address This
Date: 29 Sep 1999 09:41:56 -0400 (EDT)
Phone lines!
If you have customers going through SLC or line multiplexors, or long runs
or old switches or any other of number of line impairments they will not
get the 52K they *THINK* they are paying for.
If you go from QUADS to ARC's and still have the same poor perf then it's
most likely lines.
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
On Tue, 28 Sep 1999, Greg Coffey wrote:
> Enclosed is some dialogue with a customer of mine.
>
> ************
> Bill, thanks for the feedback. Trib uses Ascend servers for their modems.
> We use 3Com (merged with USR) exclusively. We've noted that some
> subscribers that dial in using 3Com modems connect FASTER with the Ascend
> than the 3Com. In fact, they never connect >33.6 with the 3Com servers but
> consistently with the Ascends at a v.90 rate. I pointed out the problem to
> 3Com about a year ago and there was not much interest on their part at the
> time. A couple months ago, it came up again. This time there was more
> interest and discussion. 3Com tells me that there is a bug in the Ascend
> server software that permits this anomaly. The number of subscribers that
> this impacts is small (I believe), though I've not really spent much time
> regarding it. 3Com told me earlier that if they fixed the software, it
> would break other modems connect rates and even connectivity. One of my
> techs (lives in Mills) can connect to Trib from home under the same
> circumstances as you. I gave him a Courier v.everything to try last week
> with the latest firmware. Same results as his Sportster model. We are
> running current software on our end too. We just spent thousands to
> upgrade our quad modems to the newer hiper design, no change. We added a
> hiperarc, again newer design and, again, thousands more invested. No
> change. We did dump the Sportster modem registers and send them to a 3Com
> engineer both a year ago and more recently. I've not heard anything about
> it for about a month since the last time it came up. I've looked at Ascend
> equipment but so far have stayed with 3Com. Baffles me too why brand-x
> modems work better with brand-y's servers. Why brand-x can't or won't
> resolve the issue baffles me too. The 3Com servers are not junk. We do
> have lots of subscribers that can connect to our servers and getting v.90
> connection rates. I think we've dealt with maybe 6 or so people that are
> in your situation. Perhaps the number is higher but they aren't aware of
> it. I don't have an answer for you at this point but will forward this to
> 3Com.
>
> At 08:15 PM 9/28/99 -0600, you wrote:
> >I signed up today and got onto your system.
> >
> >It is only a few hours, but so far I'm not impressed with the speed over
> >Trib.com.
> >
> >First of all, I cannot connect at as fast a speed.
> >
> >I have a USR Sportster Voice 56k v.90 modem model 00178501 with the latest
> >drivers and firmware.
> >
> >With trib.com, I can connect sometimes @ 45,333 and always @ 37,333.
> >
> >I tried your 3 numbers:
> >
> > 234-2088 26,400 most of the time, 28,800 sometimes.
> > 234-6324 same
> > 266-4165 31,200 all the time.
> >
> >I tried several file download tests between the two systems and trib won
> >handily.
> >
> >I will do some more comparing over the next few days, but it isn't what I
> >was hoping for.
> >
> >If you have any other ideas, I would love to hear them.
> >
> >Thanks,
> >
> >Bill xxxxx
> >
> >-----Original Message-----
> >From: Greg Coffey <gcoffey@vcn.com>
> >To: Bill
> >Date: Friday, September 10, 1999 8:45 AM
> >Subject: Re:
> >
> >
> >>We have 3 separate T1's to the Internet and are getting a fract T3 within
> >>two months. You are welcome to try us and compare for yourself. Sign up
> >>online or come by the store. If you don't like our service, I will refund
> >>your fee for the month. We are in the process of a major upgrade that
> >>takes place on September 20th. That will make us even better than we are
> >now.
> >>
> >>
> >>At 06:48 AM 9/10/99 -0600, you wrote:
> >>>I am in Casper - in the Sunrise 8 area.
> >>>
> >>>I am looking for bandwidth to the net overall.
> >>>
> >>>I can connect @ 37,333 to Trib and maintain connection.
> >>>
> >>>I can connect @ around 45,000, but the connection is not stable.
>
>
> Thanks,
>
> Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446
> =====================================================================
> 100 N. Center St., Casper, WY 82601 WWW.VCN.COM
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Ed" <ed@taylors.com>
Subject: Re: (usr-tc) 3Com, Please Address This
Date: 29 Sep 1999 10:45:21 -0400
Paul Farber worte:
"If you have customers going through SLC or line multiplexors, or long runs
or old switches or any other of number of line impairments they will not
get the 52K they *THINK* they are paying for."
Response:
No as stated before we know without a doubt in these scenarios it is NOT
Phone Lines. Please read the letters completely before responding and
confusing others.
As stated before we have used the same PRI line and switched it between the
Ascend box and the 3com box. Used the same client location and modem. The
client is using a 3com modem and has the latest code revisions and drivers.
When they connect to the Ascend they get V90 and when they connect to the
3com no V90. It's that simple...
Again 3com has acknowledged the issue.
Ed
----- Original Message -----
Sent: Wednesday, September 29, 1999 9:41 AM
Phone lines!
If you have customers going through SLC or line multiplexors, or long runs
or old switches or any other of number of line impairments they will not
get the 52K they *THINK* they are paying for.
If you go from QUADS to ARC's and still have the same poor perf then it's
most likely lines.
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
On Tue, 28 Sep 1999, Greg Coffey wrote:
> Enclosed is some dialogue with a customer of mine.
>
> ************
> Bill, thanks for the feedback. Trib uses Ascend servers for their modems.
> We use 3Com (merged with USR) exclusively. We've noted that some
> subscribers that dial in using 3Com modems connect FASTER with the Ascend
> than the 3Com. In fact, they never connect >33.6 with the 3Com servers
but
> consistently with the Ascends at a v.90 rate. I pointed out the problem
to
> 3Com about a year ago and there was not much interest on their part at the
> time. A couple months ago, it came up again. This time there was more
> interest and discussion. 3Com tells me that there is a bug in the Ascend
> server software that permits this anomaly. The number of subscribers that
> this impacts is small (I believe), though I've not really spent much time
> regarding it. 3Com told me earlier that if they fixed the software, it
> would break other modems connect rates and even connectivity. One of my
> techs (lives in Mills) can connect to Trib from home under the same
> circumstances as you. I gave him a Courier v.everything to try last week
> with the latest firmware. Same results as his Sportster model. We are
> running current software on our end too. We just spent thousands to
> upgrade our quad modems to the newer hiper design, no change. We added a
> hiperarc, again newer design and, again, thousands more invested. No
> change. We did dump the Sportster modem registers and send them to a 3Com
> engineer both a year ago and more recently. I've not heard anything about
> it for about a month since the last time it came up. I've looked at
Ascend
> equipment but so far have stayed with 3Com. Baffles me too why brand-x
> modems work better with brand-y's servers. Why brand-x can't or won't
> resolve the issue baffles me too. The 3Com servers are not junk. We do
> have lots of subscribers that can connect to our servers and getting v.90
> connection rates. I think we've dealt with maybe 6 or so people that are
> in your situation. Perhaps the number is higher but they aren't aware of
> it. I don't have an answer for you at this point but will forward this to
> 3Com.
>
> At 08:15 PM 9/28/99 -0600, you wrote:
> >I signed up today and got onto your system.
> >
> >It is only a few hours, but so far I'm not impressed with the speed over
> >Trib.com.
> >
> >First of all, I cannot connect at as fast a speed.
> >
> >I have a USR Sportster Voice 56k v.90 modem model 00178501 with the
latest
> >drivers and firmware.
> >
> >With trib.com, I can connect sometimes @ 45,333 and always @ 37,333.
> >
> >I tried your 3 numbers:
> >
> > 234-2088 26,400 most of the time, 28,800 sometimes.
> > 234-6324 same
> > 266-4165 31,200 all the time.
> >
> >I tried several file download tests between the two systems and trib won
> >handily.
> >
> >I will do some more comparing over the next few days, but it isn't what I
> >was hoping for.
> >
> >If you have any other ideas, I would love to hear them.
> >
> >Thanks,
> >
> >Bill xxxxx
> >
> >-----Original Message-----
> >From: Greg Coffey <gcoffey@vcn.com>
> >To: Bill
> >Date: Friday, September 10, 1999 8:45 AM
> >Subject: Re:
> >
> >
> >>We have 3 separate T1's to the Internet and are getting a fract T3
within
> >>two months. You are welcome to try us and compare for yourself. Sign
up
> >>online or come by the store. If you don't like our service, I will
refund
> >>your fee for the month. We are in the process of a major upgrade that
> >>takes place on September 20th. That will make us even better than we
are
> >now.
> >>
> >>
> >>At 06:48 AM 9/10/99 -0600, you wrote:
> >>>I am in Casper - in the Sunrise 8 area.
> >>>
> >>>I am looking for bandwidth to the net overall.
> >>>
> >>>I can connect @ 37,333 to Trib and maintain connection.
> >>>
> >>>I can connect @ around 45,000, but the connection is not stable.
>
>
> Thanks,
>
> Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446
> =====================================================================
> 100 N. Center St., Casper, WY 82601 WWW.VCN.COM
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Greg Coffey <greg@coffey.com>
Subject: Re: (usr-tc) 3Com, Please Address This
Date: 29 Sep 1999 08:50:59 -0600
There are some rare instances where the customer calling in using the SAME
computer, software, modem and phone line can connect to Ascend boxes at
v.90 and not to 3Coms. In ALL instances that I have seen, the client was
using a 3Com modem to dial.
At 08:00 AM 9/29/99 -0400, you wrote:
>This is not consistent with my finding at all. I have a courier and get
>49,300 every time flawlessly to my total control dsp equip. Looks like a
>telco issue if you ask me.
>
>Just my two sense.
>
>------------------------------------
>Brian Gordon
>MCP, A+, Network +
>Network Administrator
>Westelcom Internet
>518.566.6726 Voice
>419.831.9137 Fax
>http://www.westelcom.com
>administrator@westelcom.com
>----- Original Message -----
>From: Greg Coffey <greg@coffey.com>
>To: <usr-tc@lists.xmission.com>
>Sent: Tuesday, September 28, 1999 11:28 PM
>Subject: (usr-tc) 3Com, Please Address This
>
>
> > Enclosed is some dialogue with a customer of mine.
> >
> > ************
> > Bill, thanks for the feedback. Trib uses Ascend servers for their modems.
> > We use 3Com (merged with USR) exclusively. We've noted that some
> > subscribers that dial in using 3Com modems connect FASTER with the Ascend
> > than the 3Com. In fact, they never connect >33.6 with the 3Com servers
>but
> > consistently with the Ascends at a v.90 rate. I pointed out the problem
>to
> > 3Com about a year ago and there was not much interest on their part at the
> > time. A couple months ago, it came up again. This time there was more
> > interest and discussion. 3Com tells me that there is a bug in the Ascend
> > server software that permits this anomaly. The number of subscribers that
> > this impacts is small (I believe), though I've not really spent much time
Thanks, Greg Coffey <gcoffey@vcn.com>
Visionary Communications V 307-234-5443 F 307-234-5446
100 N. Center, Casper, WY 82601 www.vcn.com
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Greg Coffey <greg@coffey.com>
Subject: Re: (usr-tc) 3Com, Please Address This
Date: 29 Sep 1999 09:06:18 -0600
It tis not a phone line issue. 3Com has admitted there is an issue here
and is aware of what the cause is. I get a message a month regarding this
topic from customers. When it comes up, the subscribers are usually on the
fringe of the 56k area. My biggest competitor runs Ascends and when they
call it, they get a FortySomething connect just about every time. It is a
true connect too, we've tested the throughput. They have NEVER obtained a
v.90 connect through us at the same location using the same PC, modem and
phone line. We currently have 12 CT1 spans running in Casper. Some are on
quads with netservers and others are hiperarcs with hiperdsps. We get lots
of v90 connects on all the chassis.
At 09:41 AM 9/29/99 -0400, you wrote:
>Phone lines!
>
>If you have customers going through SLC or line multiplexors, or long runs
>or old switches or any other of number of line impairments they will not
>get the 52K they *THINK* they are paying for.
>
>If you go from QUADS to ARC's and still have the same poor perf then it's
>most likely lines.
>
>Paul Farber
>Farber Technology
>farber@admin.f-tech.net
>Ph 570-628-5303
>Fax 570-628-5545
>
>On Tue, 28 Sep 1999, Greg Coffey wrote:
>
> > Enclosed is some dialogue with a customer of mine.
> >
> > ************
> > Bill, thanks for the feedback. Trib uses Ascend servers for their modems.
> > We use 3Com (merged with USR) exclusively. We've noted that some
> > subscribers that dial in using 3Com modems connect FASTER with the Ascend
> > than the 3Com. In fact, they never connect >33.6 with the 3Com servers but
> > consistently with the Ascends at a v.90 rate. I pointed out the problem to
> > 3Com about a year ago and there was not much interest on their part at the
> > time. A couple months ago, it came up again. This time there was more
> > interest and discussion. 3Com tells me that there is a bug in the Ascend
> > server software that permits this anomaly. The number of subscribers that
> > this impacts is small (I believe), though I've not really spent much time
> > regarding it. 3Com told me earlier that if they fixed the software, it
> > would break other modems connect rates and even connectivity. One of my
> > techs (lives in Mills) can connect to Trib from home under the same
> > circumstances as you. I gave him a Courier v.everything to try last week
> > with the latest firmware. Same results as his Sportster model. We are
> > running current software on our end too. We just spent thousands to
> > upgrade our quad modems to the newer hiper design, no change. We added a
> > hiperarc, again newer design and, again, thousands more invested. No
> > change. We did dump the Sportster modem registers and send them to a 3Com
> > engineer both a year ago and more recently. I've not heard anything about
> > it for about a month since the last time it came up. I've looked at Ascend
> > equipment but so far have stayed with 3Com. Baffles me too why brand-x
> > modems work better with brand-y's servers. Why brand-x can't or won't
> > resolve the issue baffles me too. The 3Com servers are not junk. We do
> > have lots of subscribers that can connect to our servers and getting v.90
> > connection rates. I think we've dealt with maybe 6 or so people that are
> > in your situation. Perhaps the number is higher but they aren't aware of
> > it. I don't have an answer for you at this point but will forward this to
> > 3Com.
> >
> > At 08:15 PM 9/28/99 -0600, you wrote:
> > >I signed up today and got onto your system.
> > >
> > >It is only a few hours, but so far I'm not impressed with the speed over
> > >Trib.com.
> > >
> > >First of all, I cannot connect at as fast a speed.
> > >
> > >I have a USR Sportster Voice 56k v.90 modem model 00178501 with the latest
> > >drivers and firmware.
> > >
> > >With trib.com, I can connect sometimes @ 45,333 and always @ 37,333.
> > >
> > >I tried your 3 numbers:
> > >
> > > 234-2088 26,400 most of the time, 28,800 sometimes.
> > > 234-6324 same
> > > 266-4165 31,200 all the time.
> > >
> > >I tried several file download tests between the two systems and trib won
> > >handily.
> > >
> > >I will do some more comparing over the next few days, but it isn't what I
> > >was hoping for.
> > >
> > >If you have any other ideas, I would love to hear them.
> > >
> > >Thanks,
> > >
> > >Bill xxxxx
> > >
> > >-----Original Message-----
> > >From: Greg Coffey <gcoffey@vcn.com>
> > >To: Bill
> > >Date: Friday, September 10, 1999 8:45 AM
> > >Subject: Re:
> > >
> > >
> > >>We have 3 separate T1's to the Internet and are getting a fract T3 within
> > >>two months. You are welcome to try us and compare for yourself. Sign up
> > >>online or come by the store. If you don't like our service, I will
> refund
> > >>your fee for the month. We are in the process of a major upgrade that
> > >>takes place on September 20th. That will make us even better than we are
> > >now.
> > >>
> > >>
> > >>At 06:48 AM 9/10/99 -0600, you wrote:
> > >>>I am in Casper - in the Sunrise 8 area.
> > >>>
> > >>>I am looking for bandwidth to the net overall.
> > >>>
> > >>>I can connect @ 37,333 to Trib and maintain connection.
> > >>>
> > >>>I can connect @ around 45,000, but the connection is not stable.
> >
> >
> > Thanks,
> >
> > Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446
> > =====================================================================
> > 100 N. Center St., Casper, WY 82601 WWW.VCN.COM
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
Thanks, Greg Coffey <gcoffey@vcn.com>
Visionary Communications V 307-234-5443 F 307-234-5446
100 N. Center, Casper, WY 82601 www.vcn.com
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Martin Lathoud <nytral@enDirect.qc.ca>
Subject: Re: (usr-tc) 3Com, Please Address This
Date: 29 Sep 1999 12:03:06 -0400 (EDT)
> It tis not a phone line issue. 3Com has admitted there is an issue here
> and is aware of what the cause is. I get a message a month regarding this
> topic from customers. When it comes up, the subscribers are usually on the
> fringe of the 56k area. My biggest competitor runs Ascends and when they
> call it, they get a FortySomething connect just about every time. It is a
> true connect too, we've tested the throughput. They have NEVER obtained a
> v.90 connect through us at the same location using the same PC, modem and
> phone line. We currently have 12 CT1 spans running in Casper. Some are on
> quads with netservers and others are hiperarcs with hiperdsps. We get lots
> of v90 connects on all the chassis.
It's a phone line issue not properly addressed by 3Com modem code. I
deleted the mail where John Powell explained what exactly was wrong with
the line, but he said (a year ago?) that a fix was worked on..
I don't know about Ascend, but PM3 modem code is way worse than 3Com, so
stick with it and be patient :-) It seems that Cisco modem code is much
better at this, too.
Martin
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Paul Oster" <devious@minot.com>
Subject: (usr-tc) HiPER Dsp Vs Quad Modem
Date: 29 Sep 1999 11:36:01 -0500
This is a multi-part message in MIME format.
------=_NextPart_000_0145_01BF0A6E.CE74BAA0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Ok, I've brought this up with 3com tech support, and they have not
been able
to answer my questions... I run approximately 8-10% Lost-Carrier
Rates on
my Quad Modem based chassis. On my DSP based chassis, that number is
15-17%.
I can attribute 1 in 10 calls dropping to flakey phone lines, poor
client modems
etc, but beyond that, I have to question what is going on.
I have tested to eliminate T1's from the equation by switching the 2
spans that
plugged into the Quad-Chassis with the 2 from the DSP-Chassis, and the
results
are exactly the same (24 hour test period in both cases)
Now I've got 7 dsp cards in service (2 chassis split 5/2) and both
chassis show
the 15+% loss.
Any suggestions as to why these dsp modems are more prone to dropping
connections?
DSP Code 2.0.81
ARC Code 4.1.59-6
NMC 6.2.17
Thanks
Paul
------=_NextPart_000_0145_01BF0A6E.CE74BAA0
Content-Type: text/x-vcard;
name="Paul M Oster.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="Paul M Oster.vcf"
BEGIN:VCARD
VERSION:2.1
N:Oster;Paul;M;Mr
FN:Paul M Oster
ORG:Magic Internet Services
TITLE:IT Manager
TEL;WORK;VOICE:701-838-1265
TEL;WORK;FAX:701-852-4374
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;400 10th St =
SE=3D0D=3D0A;Minot;ND;58701;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:400 10th St =
SE=3D0D=3D0A=3D0D=3D0AMinot, ND 58701=3D0D=3D0AUSA
EMAIL;PREF;INTERNET:admin@minot.com
REV:19990929T163601Z
END:VCARD
------=_NextPart_000_0145_01BF0A6E.CE74BAA0--
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Chad Scheiter <chad@amouse.net>
Subject: Re: (usr-tc) Ascend Pipelines
Date: 29 Sep 1999 15:44:06 -0700
Jeff Binkley wrote:
> We have 3 Ascend Pipeline 50/75 customers connecting to our TC chassis'.
> In each case we give them a static IP address via Radius. In all cases
> we cannot ping the static address (i.e. Ascend doesn't respond) yet the
> users behind the pipeline work fine adn we can telnet into the Ascend if
> we add a static route for port 23 to the static IP address. Does anyone
> know how to correct this ? It makes troubleshooting more difficult when
> ping doesn't work.
I have a Pipeline 75 connect to my TC with NAT and I cannot ping it, but my
customer can connect fine. And with a default server set in the NAT config
I can pass SMTP traffic through it, but still cannot ping. And I have a
Pipeline 130 connected to a Max 4000, with no NAT and it is bridged not
routed and my Max 4000 responds to ANY ping sent from the Pipeline or any
computer on that side of the link. Basically the only thing I have seen
that Ascends can do well is V.90, I've had to send 4 Max4048 back because
of hardware failures in the past 2 years. Can you guess why I'll put up the
worse V.90 connect rates in a TC?
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Jason Cropper" <jason@clearsail.net>
Subject: RE: (usr-tc) Ascend Pipelines
Date: 29 Sep 1999 11:40:30 -0500
You must disable the "firewall" in the Ascend. It is turned on by default.
I'm not sure of the procedure though... it's been a while.
Jason
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley
Sent: Wednesday, September 29, 1999 8:24
We have 3 Ascend Pipeline 50/75 customers connecting to our TC chassis'.
In each case we give them a static IP address via Radius. In all cases
we cannot ping the static address (i.e. Ascend doesn't respond) yet the
users behind the pipeline work fine adn we can telnet into the Ascend if
we add a static route for port 23 to the static IP address. Does anyone
know how to correct this ? It makes troubleshooting more difficult when
ping doesn't work.
Thanks,
Jeff Binkley
ASA Network Computing
CMPQwk 1.42 9999
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: Re: (usr-tc) HiPER Dsp Vs Quad Modem
Date: 29 Sep 1999 12:52:25 -0400
At 11:36 AM 9/29/99 -0500, "Paul Oster" <devious@minot.com> wrote:
>
>DSP Code 2.0.81
>ARC Code 4.1.59-6
>NMC 6.2.17
Try bumping the ARC code up to 4.2.32, with that and 2.0.81 I'm seeing
8-10% failure rates. This has actually gone up from about 5% when I was
running ARC 4.1.59-6/DSP 1.2.60. I'm hoping the next DSP upgrade gets the
rate back down some.
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Carl Litt <carl@execulink.com>
Subject: (usr-tc) Netserver to ARC using Multilink
Date: 29 Sep 1999 13:04:51 -0400 (EDT)
Is it possible to get a Netserver to connect to a HiPer ARC
with more than one channel (by using multilink)?
We're trying to move a customer over from dialing into another
Netserver (not ours) into an ARC running 4.1.59. The login is set
in RADIUS, and does work for a single channel. We have no
Port-Limits set, and the ARC has the default 2 Max-Chan.
We can get the first channel up, but the second channel connects
then drops. Here is the "mon ppp" output:
Incoming PPP Data on interface: slot:10/mod:23
LCP CFG_ACK MRU 05 ea
ASYNC_MAP ff ff ff ff
MAGIC_NUM 4c 56 1b da
PROTO_COMP
AC_COMP
MPP_MRRU 05 ea
MPP_ENDPTID 00
Incoming PPP Data on interface: slot:10/mod:23
LCP CFG_REQ MPP_ENDPTID 04 6f f7 09 08
ASYNC_MAP ff ff ff ff
MAGIC_NUM 23 ea 32 19
Outgoing PPP Data on interface: slot:10/mod:23
LCP CFG_ACK MPP_ENDPTID 04 6f f7 09 08
ASYNC_MAP ff ff ff ff
MAGIC_NUM 23 ea 32 19
--- [The call is then dropped] ---
From what I can see, there are no NAK's which should cause a
protocol termination. In the RADIUS accounting logs, the session
has a Term-Cause of NAS-Error.
Any advice?
Thanks,
Carl
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) Netserver to ARC using Multilink
Date: 29 Sep 1999 13:14:17 -0400
Thus spake Carl Litt
>Is it possible to get a Netserver to connect to a HiPer ARC
>with more than one channel (by using multilink)?
>We're trying to move a customer over from dialing into another
>Netserver (not ours) into an ARC running 4.1.59. The login is set
>in RADIUS, and does work for a single channel. We have no
>Port-Limits set, and the ARC has the default 2 Max-Chan.
>We can get the first channel up, but the second channel connects
>then drops. Here is the "mon ppp" output:
>Incoming PPP Data on interface: slot:10/mod:23
> LCP CFG_ACK MRU 05 ea
> ASYNC_MAP ff ff ff ff
> MAGIC_NUM 4c 56 1b da
> PROTO_COMP
> AC_COMP
> MPP_MRRU 05 ea
> MPP_ENDPTID 00
>Incoming PPP Data on interface: slot:10/mod:23
> LCP CFG_REQ MPP_ENDPTID 04 6f f7 09 08
> ASYNC_MAP ff ff ff ff
> MAGIC_NUM 23 ea 32 19
>Outgoing PPP Data on interface: slot:10/mod:23
> LCP CFG_ACK MPP_ENDPTID 04 6f f7 09 08
> ASYNC_MAP ff ff ff ff
> MAGIC_NUM 23 ea 32 19
>--- [The call is then dropped] ---
>From what I can see, there are no NAK's which should cause a
>protocol termination. In the RADIUS accounting logs, the session
>has a Term-Cause of NAS-Error.
Well...you're apparently not catching all of the PPP negotiation...which
means we might be missing some useful data, but...
You'll notice that the incoming config request does *not* have the MPP_MRRU
attribute in it. The MPP_MRRU attribute is the attribute/value that
indicates that Multi-Link can/will be used on that link. If one side
doesn't negotiation the MPP_MRRU, then Multi-Link can't work on that
link.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Christopher Arlis Hanes" <chanes@usacars.com>
Subject: (usr-tc) Intermittent static on lines...
Date: 29 Sep 1999 13:13:48 -0400
I'm having a problem with static coming and going on my PRIs. The
effect then is that users are unable to temporarily dial in - the modems
aren't able to negotiate a connection. I'm fairly certain the
interference is being produced on the utp cat 5 cable running about 25
feet on a ladder rack from the demarc point to my boxes. I'm planning
on installing shielded cable immediately but was wondering if anyone has
run into similar problems and has some advice? What is the best way to
measure the noise on the line? I noticed under Performance Monitor on
modems you can get s/n ratio info for each connection. What are
acceptable levels?
Thanks,
Chris Hanes
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: (usr-tc) testing csu/dsu on DSP
Date: 29 Sep 1999 13:22:07 -0400
Hi folks...
I've got a CSU/DSU on a HiPer DSP that I *think* may be going bad...not
really sure though. I'd like to be able to test it, but I'm not really
sure how. I've got some equipment that can send BERT patterns at it,
but I'm not sure how to set up the DSP to actually deal with that. I've
gotten it into a line loopback, so I can bounce the pattern off the
loopback, but that's not terribly helpful when you're trying to test the
actual CSU/DSU. :/ I've found that the DSP can send, what appears to
be a quasi-random signal, but I can't get it to sync up when sending it.
My current setup to try to test this is the DSP card is connected via a
"null-t1" cable to my other equipment (a Cisco 7507 with a multi-channel
port adapter...has integrated CSU/DSU's and ability to run quite a few
different BERT patterns...more capability in this area from 3Com would
be *really* cool to have ;). I can get the T1's to sync up normally
(non-BERT) by setting the clock source on the Cisco to internal (which
is expected...*someone* has to generate clock...although it seems
they'll coast for a while with both pulling it off the line without
falling out of sync). I can also set up a loopback on the DSP, and run
anything I want from the cisco and it works (BERT, true T1 signalling,
etc.), but I can't reverse it. I have tried setting the cisco to have a
loopback and run qrs from the DSP (available via the "cmd sendcode qrs"
command on the console) but it never seems to want to sync up that way.
I've tried all different combinations of clocking sources on the DSP and
cisco with the DSP running qrs, but never can get it to be happy.
Anyone have any knowledge about, or experience with, testing a DSP
CSU/DSU for problems using BERT patterns and the like?
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: <farber@admin.f-tech.net>
Subject: Re: (usr-tc) Intermittent static on lines...
Date: 29 Sep 1999 14:00:42 -0400 (EDT)
How can you verify that there is static on the line? Shielded cable is a
considerable expense... plus having to rerun the cable.
Check the span for errors. CRC and BPV's are indications of signal
problems.
If you can do without the span for an hour or two have the telco loop you
DSP for about 30 minutes and run a bit pattern (1 of 8).
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
On Wed, 29 Sep 1999, Christopher Arlis Hanes wrote:
> I'm having a problem with static coming and going on my PRIs. The
> effect then is that users are unable to temporarily dial in - the modems
> aren't able to negotiate a connection. I'm fairly certain the
> interference is being produced on the utp cat 5 cable running about 25
> feet on a ladder rack from the demarc point to my boxes. I'm planning
> on installing shielded cable immediately but was wondering if anyone has
> run into similar problems and has some advice? What is the best way to
> measure the noise on the line? I noticed under Performance Monitor on
> modems you can get s/n ratio info for each connection. What are
> acceptable levels?
>
> Thanks,
> Chris Hanes
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Carl Litt <carl@execulink.com>
Subject: Re: (usr-tc) Netserver to ARC using Multilink
Date: 29 Sep 1999 14:11:18 -0400 (EDT)
Yes, I did clip out a bit of info... here's the complete output:
Monitoring the next session to start up.
Decode tracing started, press ESCAPE to stop; press X for hex tracing.
....Tracing the current/next session; Escape to stop...
Outgoing PPP Data on interface: slot:10/mod:12
LCP CFG_REQ MRU 05 ea
ASYNC_MAP 00 00 00 00
MAGIC_NUM 9e 5a aa e5
PROTO_COMP
AC_COMP
MPP_MRRU 05 ea
MPP_ENDPTID 00
Incoming PPP Data on interface: slot:10/mod:12
LCP CFG_REQ MPP_ENDPTID 04 6f f7 09 08
ASYNC_MAP 00 00 00 00
MAGIC_NUM eb c4 d4 f4
Outgoing PPP Data on interface: slot:10/mod:12
LCP CFG_ACK MPP_ENDPTID 04 6f f7 09 08
ASYNC_MAP 00 00 00 00
MAGIC_NUM eb c4 d4 f4
Incoming PPP Data on interface: slot:10/mod:12
LCP CFG_ACK MRU 05 ea
ASYNC_MAP 00 00 00 00
MAGIC_NUM 9e 5a aa e5
PROTO_COMP
AC_COMP
MPP_MRRU 05 ea
MPP_ENDPTID 00
I've also tried durning off PPP offloading for the hell of it, but
no difference.
Thanks,
Carl
On Wed, 29 Sep 1999, Jeff Mcadams wrote:
> Thus spake Carl Litt
> >Is it possible to get a Netserver to connect to a HiPer ARC
> >with more than one channel (by using multilink)?
>
> >We're trying to move a customer over from dialing into another
> >Netserver (not ours) into an ARC running 4.1.59. The login is set
> >in RADIUS, and does work for a single channel. We have no
> >Port-Limits set, and the ARC has the default 2 Max-Chan.
>
> >We can get the first channel up, but the second channel connects
> >then drops. Here is the "mon ppp" output:
>
> >Incoming PPP Data on interface: slot:10/mod:23
> > LCP CFG_ACK MRU 05 ea
> > ASYNC_MAP ff ff ff ff
> > MAGIC_NUM 4c 56 1b da
> > PROTO_COMP
> > AC_COMP
> > MPP_MRRU 05 ea
> > MPP_ENDPTID 00
>
> >Incoming PPP Data on interface: slot:10/mod:23
> > LCP CFG_REQ MPP_ENDPTID 04 6f f7 09 08
> > ASYNC_MAP ff ff ff ff
> > MAGIC_NUM 23 ea 32 19
>
> >Outgoing PPP Data on interface: slot:10/mod:23
> > LCP CFG_ACK MPP_ENDPTID 04 6f f7 09 08
> > ASYNC_MAP ff ff ff ff
> > MAGIC_NUM 23 ea 32 19
> >--- [The call is then dropped] ---
>
> >From what I can see, there are no NAK's which should cause a
> >protocol termination. In the RADIUS accounting logs, the session
> >has a Term-Cause of NAS-Error.
>
> Well...you're apparently not catching all of the PPP negotiation...which
> means we might be missing some useful data, but...
>
> You'll notice that the incoming config request does *not* have the MPP_MRRU
> attribute in it. The MPP_MRRU attribute is the attribute/value that
> indicates that Multi-Link can/will be used on that link. If one side
> doesn't negotiation the MPP_MRRU, then Multi-Link can't work on that
> link.
> --
> Jeff McAdams Email: jeffm@iglou.com
> Head Network Administrator Voice: (502) 966-3848
> IgLou Internet Services (800) 436-4456
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) Netserver to ARC using Multilink
Date: 29 Sep 1999 14:20:08 -0400
Thus spake Carl Litt
>Incoming PPP Data on interface: slot:10/mod:12
> LCP CFG_REQ MPP_ENDPTID 04 6f f7 09 08
> ASYNC_MAP 00 00 00 00
> MAGIC_NUM eb c4 d4 f4
Here's the first incoming lcp config request....
Again...no MPP_MRRU in this, Multi-Link won't work without that
attribute being negotiated during the LCP phase. If a system tries to
send a multi-link encapsulated packet without negotiating the MRRU, it
is considered an error.
So, the other side is not negotiating MP correctly.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mike Andrews <mandrews@bit0.com>
Subject: Re: (usr-tc) HiPER Dsp Vs Quad Modem
Date: 29 Sep 1999 14:21:25 -0400 (EDT)
I'll bet the difference is customers with Rockwell HCF modems. They
connect more reliably to Quads. Not that they connect very reliably to
*anything*...
Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
"With sufficient thrust, pigs fly just fine." -- RFC 1925
On Wed, 29 Sep 1999, Paul Oster wrote:
> Ok, I've brought this up with 3com tech support, and they have not
> been able
> to answer my questions... I run approximately 8-10% Lost-Carrier
> Rates on
> my Quad Modem based chassis. On my DSP based chassis, that number is
> 15-17%.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: RE: (usr-tc) Intermittent static on lines...
Date: 29 Sep 1999 15:19:56 -0300
Have you looked at your DS1 errors under TCM? That should tell you if you
have problems with the signal. Also, your telco should be able to look and
see if you have accumulated any slips.
On Wednesday, September 29, 1999 2:14 PM, Christopher Arlis Hanes
[SMTP:chanes@usacars.com] wrote:
> I'm having a problem with static coming and going on my PRIs. The
> effect then is that users are unable to temporarily dial in - the modems
> aren't able to negotiate a connection. I'm fairly certain the
> interference is being produced on the utp cat 5 cable running about 25
> feet on a ladder rack from the demarc point to my boxes. I'm planning
> on installing shielded cable immediately but was wondering if anyone has
> run into similar problems and has some advice? What is the best way to
> measure the noise on the line? I noticed under Performance Monitor on
> modems you can get s/n ratio info for each connection. What are
> acceptable levels?
>
> Thanks,
> Chris Hanes
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Barry Yost <barry@zebra.net>
Subject: (usr-tc) 2 Issues
Date: 30 Sep 1999 01:45:17 +0600 (GMT)
We have recently consolidated all of our nodes to use the
TC HiPerARC + DSP chasses, and in doing so, have come across 2 issues:
The main problem is what I refer to as "hung modem" where 2 contiguous modems
in a DSP will somehow fail in such a way that incoming calls are answered,
but never complete the carrier. (list con shows them as call type
DIALIN INVALID) The errant modems show orders of magnitude more failed calls
in performance monitor. What the user dialing in experiences is something like
this: The TC picks up and transmits the answer tone. The client modem begins
making the handshake sounds, but the TC continues with the single tone as if
the client modem had not responded. Selecting the modems in TCM and
performing a software reset on them will clear it up 99% of the time.
They always appear in pairs.
Does anyone know what might cause this?
The chases have 130A dual power supplies, and the following code rev's:
DSP: 2.0.81
ARC: 4.2.32
NMC: 6.2.17
(This happens in different POPs as well.)
Also, we had bad experiences turning on BACP in earlier code rev's of the ARC
cards, and at 3Com's advise, left the feature disabled. We have many users of
Ascend Pipeline routers that apparently insist on using bacp for dynamic
bandwidth if they can't have their proprietary Ascend protocol. One user in
particular has spent extensive hours with Ascend trying unsuccessfully to make
a P130 do dynamic channel allocation with our HiPerARC servers.
Does anyone have a workaround for this, or has BACP been stabalized enough
to warrant activating the feature?
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Curt Shambeau <curt@execpc.com>
Subject: Re: (usr-tc) 2 Issues
Date: 29 Sep 1999 13:56:39 -0500 (CDT)
> The main problem is what I refer to as "hung modem" where 2 contiguous modems
> in a DSP will somehow fail in such a way that incoming calls are answered,
> but never complete the carrier. (list con shows them as call type
> DIALIN INVALID) The errant modems show orders of magnitude more failed calls
> in performance monitor. What the user dialing in experiences is something like
> this: The TC picks up and transmits the answer tone. The client modem begins
> making the handshake sounds, but the TC continues with the single tone as if
> the client modem had not responded. Selecting the modems in TCM and
> performing a software reset on them will clear it up 99% of the time.
> They always appear in pairs.
>
> Does anyone know what might cause this?
DSP Lockups. Each DSP handles 2 modems, and as such, when it locks up in
any way, it takes out 2 modems. Depending on switch type, it manifests
itself to the customer in various ways. You described one.
This has been a horrible bug in the DSP since it was first introduced, and
they have NEVER been able to fix it. It has gotten better over the years,
but it is still a major concern for us.
Our solution is to watch for it - busy out the entire card, wait for
customers to drop off the card, and then reboot it.
| Curtis V. Shambeau | curt@execpc.com | Senior Vice President |
| ExecPC, Inc. - A Voyager.net company - NASDAQ Symbol: VOYN |
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: <pferraro@wna-linknet.com>
Subject: Re: (usr-tc) 2 Issues
Date: 29 Sep 1999 15:03:35 -0400 (EDT)
This is an unacceptable alternative! If you experience these
problems and it has been noted by 3Com, then it should be addressed and
corrected!! What about all those that are running several HUNDRED TC
hubs!
Just my .02 worth!
==============================================================================
Phillip Ferraro WorldNet Access, Inc
pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
Voice (910) 346-0835 824 Gumbranch Square, Suite R3
FAX (910) 455-1933 Jacksonville, Nc 28540-6269
==============================================================================
On Wed, 29 Sep 1999, Curt Shambeau wrote:
> > The main problem is what I refer to as "hung modem" where 2 contiguous modems
> > in a DSP will somehow fail in such a way that incoming calls are answered,
> > but never complete the carrier. (list con shows them as call type
> > DIALIN INVALID) The errant modems show orders of magnitude more failed calls
> > in performance monitor. What the user dialing in experiences is something like
> > this: The TC picks up and transmits the answer tone. The client modem begins
> > making the handshake sounds, but the TC continues with the single tone as if
> > the client modem had not responded. Selecting the modems in TCM and
> > performing a software reset on them will clear it up 99% of the time.
> > They always appear in pairs.
> >
> > Does anyone know what might cause this?
>
> DSP Lockups. Each DSP handles 2 modems, and as such, when it locks up in
> any way, it takes out 2 modems. Depending on switch type, it manifests
> itself to the customer in various ways. You described one.
>
> This has been a horrible bug in the DSP since it was first introduced, and
> they have NEVER been able to fix it. It has gotten better over the years,
> but it is still a major concern for us.
>
> Our solution is to watch for it - busy out the entire card, wait for
> customers to drop off the card, and then reboot it.
>
>
> ---------------------------------------------------------------------
> | Curtis V. Shambeau | curt@execpc.com | Senior Vice President |
> | ExecPC, Inc. - A Voyager.net company - NASDAQ Symbol: VOYN |
> ---------------------------------------------------------------------
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Curt Shambeau <curt@execpc.com>
Subject: Re: (usr-tc) 2 Issues
Date: 29 Sep 1999 14:07:56 -0500 (CDT)
> This is an unacceptable alternative! If you experience these
> problems and it has been noted by 3Com, then it should be addressed and
> corrected!! What about all those that are running several HUNDRED TC
> hubs!
I agree that it is unacceptable, and I am running several hundred TC hubs.
| Curtis V. Shambeau | curt@execpc.com | Senior Vice President |
| ExecPC, Inc. - A Voyager.net company - NASDAQ Symbol: VOYN |
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Mark Lemmert <cto@athenet.net>
Subject: (usr-tc) NFAS Dilema
Date: 29 Sep 1999 14:24:19 -0500
I am about to switch all my PRIs at one location to NFAS.
The telco I am working with only supports 5 circuits per
d channel.
Since only 14 DPS can fit in a chassis that
maximum # of groups of 5 I can fit is 2, which is only
10 DSPs per chassis. For management/organization reasons
I want to have consistent sizes for the NFAS groups
only put 10 DSPs chassis.
My recollection is that 7 DSPs is the maximum that you
are supposed to use per HiperARC card.
Given this situation if you were me would you spend
the extra money on the second ARC or stretch the
first ARC a bit and run 10 DSPs on it? Thanks for
the input!
Mark Lemmert AthEnet Data Exchange
Chief Technical Officer 888-919-8700
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Mike Wilker" <mikew@LL.NET>
Subject: (usr-tc) DSL
Date: 29 Sep 1999 14:30:13 -0500
Does anyone still run the Affinity DSL on their TotalControls? I am trying
to set one up that we've had for a year now, but I can't get the command
line to come up on the card. Does it use the same console cable as the
HiperArcs and NMCs, and is there another way to configure it, say through
the Viper DSL? Thanks.
Mike Wilker
Operations Manager
Local Link, Inc.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: <farber@admin.f-tech.net>
Subject: Re: (usr-tc) 2 Issues
Date: 29 Sep 1999 15:41:36 -0400 (EDT)
It happened about 3 times in a year over 6 DSP's.... ANY complex equipment
will have quirks.
Solution? A pager and a perl script.
Paul Farber
Farber Technology
farber@admin.f-tech.net
Ph 570-628-5303
Fax 570-628-5545
On Wed, 29 Sep 1999 pferraro@wna-linknet.com wrote:
>
> This is an unacceptable alternative! If you experience these
> problems and it has been noted by 3Com, then it should be addressed and
> corrected!! What about all those that are running several HUNDRED TC
> hubs!
>
> Just my .02 worth!
>
> ==============================================================================
> Phillip Ferraro WorldNet Access, Inc
> pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
> Voice (910) 346-0835 824 Gumbranch Square, Suite R3
> FAX (910) 455-1933 Jacksonville, Nc 28540-6269
> ==============================================================================
>
> On Wed, 29 Sep 1999, Curt Shambeau wrote:
>
> > > The main problem is what I refer to as "hung modem" where 2 contiguous modems
> > > in a DSP will somehow fail in such a way that incoming calls are answered,
> > > but never complete the carrier. (list con shows them as call type
> > > DIALIN INVALID) The errant modems show orders of magnitude more failed calls
> > > in performance monitor. What the user dialing in experiences is something like
> > > this: The TC picks up and transmits the answer tone. The client modem begins
> > > making the handshake sounds, but the TC continues with the single tone as if
> > > the client modem had not responded. Selecting the modems in TCM and
> > > performing a software reset on them will clear it up 99% of the time.
> > > They always appear in pairs.
> > >
> > > Does anyone know what might cause this?
> >
> > DSP Lockups. Each DSP handles 2 modems, and as such, when it locks up in
> > any way, it takes out 2 modems. Depending on switch type, it manifests
> > itself to the customer in various ways. You described one.
> >
> > This has been a horrible bug in the DSP since it was first introduced, and
> > they have NEVER been able to fix it. It has gotten better over the years,
> > but it is still a major concern for us.
> >
> > Our solution is to watch for it - busy out the entire card, wait for
> > customers to drop off the card, and then reboot it.
> >
> >
> > ---------------------------------------------------------------------
> > | Curtis V. Shambeau | curt@execpc.com | Senior Vice President |
> > | ExecPC, Inc. - A Voyager.net company - NASDAQ Symbol: VOYN |
> > ---------------------------------------------------------------------
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Carl Litt <carl@execulink.com>
Subject: Re: (usr-tc) 2 Issues
Date: 29 Sep 1999 15:35:51 -0400 (EDT)
Not only is it unacceptable to have to babysit a ~$10,000 DSP card,
but we can't do it here anyways. When we soft-busy out the card,
incoming callers get a switch-bitch message. (We're new to PRI,
and haven't had time to debug yet).
We're using round-robin modem assignment. With fixed assignment, a bad
modem will always be assigned to the n'th DS0. Any time that DS0 rings,
that bad modem answers. With round-robin on PRI, the bad modem will
answer once, then rotate out to be the spare for a little while.
I usually have several modems each day going FUBAR. Of course, you
can't busy out a modem, and software resets don't do the job, so we're
stuck living with it.
I noticed this behaviour of the locking modem pairs months ago and
pointed it out on the list, but couldn't get a discussion going.
Anyone have any suggestions?
On Wed, 29 Sep 1999 pferraro@wna-linknet.com wrote:
>
> This is an unacceptable alternative! If you experience these
> problems and it has been noted by 3Com, then it should be addressed and
> corrected!! What about all those that are running several HUNDRED TC
> hubs!
>
> Just my .02 worth!
>
> ==============================================================================
> Phillip Ferraro WorldNet Access, Inc
> pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
> Voice (910) 346-0835 824 Gumbranch Square, Suite R3
> FAX (910) 455-1933 Jacksonville, Nc 28540-6269
> ==============================================================================
>
> On Wed, 29 Sep 1999, Curt Shambeau wrote:
>
> > > The main problem is what I refer to as "hung modem" where 2 contiguous modems
> > > in a DSP will somehow fail in such a way that incoming calls are answered,
> > > but never complete the carrier. (list con shows them as call type
> > > DIALIN INVALID) The errant modems show orders of magnitude more failed calls
> > > in performance monitor. What the user dialing in experiences is something like
> > > this: The TC picks up and transmits the answer tone. The client modem begins
> > > making the handshake sounds, but the TC continues with the single tone as if
> > > the client modem had not responded. Selecting the modems in TCM and
> > > performing a software reset on them will clear it up 99% of the time.
> > > They always appear in pairs.
> > >
> > > Does anyone know what might cause this?
> >
> > DSP Lockups. Each DSP handles 2 modems, and as such, when it locks up in
> > any way, it takes out 2 modems. Depending on switch type, it manifests
> > itself to the customer in various ways. You described one.
> >
> > This has been a horrible bug in the DSP since it was first introduced, and
> > they have NEVER been able to fix it. It has gotten better over the years,
> > but it is still a major concern for us.
> >
> > Our solution is to watch for it - busy out the entire card, wait for
> > customers to drop off the card, and then reboot it.
> >
> >
> > ---------------------------------------------------------------------
> > | Curtis V. Shambeau | curt@execpc.com | Senior Vice President |
> > | ExecPC, Inc. - A Voyager.net company - NASDAQ Symbol: VOYN |
> > ---------------------------------------------------------------------
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: RE: (usr-tc) NFAS Dilema
Date: 29 Sep 1999 16:38:16 -0300
If you're not running IPX, you can safely do 10 DSPs per ARC. I'm using a
single ARC on 10 DSPs but I'm only doing PPP, no IPX, all static routing.
Also, your power supplies will be a limiting factor - I believe the maximum
for a 70A chassis is 10 DSPs but I'm running dual 130's so I can't testify
to that.
On Wednesday, September 29, 1999 4:24 PM, Mark Lemmert
[SMTP:cto@athenet.net] wrote:
> I am about to switch all my PRIs at one location to NFAS.
> The telco I am working with only supports 5 circuits per
> d channel.
>
> Since only 14 DPS can fit in a chassis that
> maximum # of groups of 5 I can fit is 2, which is only
> 10 DSPs per chassis. For management/organization reasons
> I want to have consistent sizes for the NFAS groups
> only put 10 DSPs chassis.
>
> My recollection is that 7 DSPs is the maximum that you
> are supposed to use per HiperARC card.
>
> Given this situation if you were me would you spend
> the extra money on the second ARC or stretch the
> first ARC a bit and run 10 DSPs on it? Thanks for
> the input!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -----------------------------------------------------------------------
> Mark Lemmert AthEnet Data Exchange
> Chief Technical Officer 888-919-8700
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) 2 Issues
Date: 29 Sep 1999 15:47:39 -0400
Thus spake Carl Litt
>Not only is it unacceptable to have to babysit a ~$10,000 DSP card,
>but we can't do it here anyways. When we soft-busy out the card,
>incoming callers get a switch-bitch message. (We're new to PRI,
>and haven't had time to debug yet).
Get off of NI-2 and go to a custom translation. NI-2 doesn't have any
concept of "service messages" meaning that if you soft-busy out a ds0,
it has no way of informing the switch of that, so the switch will still
try to send calls down that ds0.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
Subject: RE: (usr-tc) 2 Issues
Date: 29 Sep 1999 16:56:18 -0300
On Wednesday, September 29, 1999 4:36 PM, Carl Litt
[SMTP:carl@execulink.com] wrote:
> I noticed this behaviour of the locking modem pairs months ago and
> pointed it out on the list, but couldn't get a discussion going.
>
> Anyone have any suggestions?
>
There was some ER code floating around that addressed this but I wasn't too
keen on running this on my production systems. I'm just waiting for them to
hopefully merge the fix into the next 2.0.x DSP code release. Maybe someone
from 3Com can confirm whether the next release will have this fixed.
Matthew
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Aaron Nabil <nabil@spiritone.com>
Subject: Re: (usr-tc) NFAS Dilema
Date: 29 Sep 1999 13:36:44 -0700 (PDT)
Mark Lemmert writes...
> . . .
>Given this situation if you were me would you spend
>the extra money on the second ARC or stretch the
>first ARC a bit and run 10 DSPs on it? Thanks for
>the input!
If I were you I wouldn't run NFAS. In my opinion, the
extra hassle it causes isn't worth the money saved.
--
Aaron Nabil
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Aaron Nabil <nabil@spiritone.com>
Subject: Re: (usr-tc) Intermittent static on lines...
Date: 29 Sep 1999 13:41:28 -0700 (PDT)
Slips would be just about the worst indicator when looking for
line problems, look at any other counter first.
Stainforth, Matthew writes...
>Have you looked at your DS1 errors under TCM? That should tell you if you
>have problems with the signal. Also, your telco should be able to look and
>see if you have accumulated any slips.
>
>On Wednesday, September 29, 1999 2:14 PM, Christopher Arlis Hanes
>[SMTP:chanes@usacars.com] wrote:
>> I'm having a problem with static coming and going on my PRIs. The
>> effect then is that users are unable to temporarily dial in - the modems
>> aren't able to negotiate a connection. I'm fairly certain the
>> interference is being produced on the utp cat 5 cable running about 25
>> feet on a ladder rack from the demarc point to my boxes. I'm planning
>> on installing shielded cable immediately but was wondering if anyone has
>> run into similar problems and has some advice? What is the best way to
>> measure the noise on the line? I noticed under Performance Monitor on
>> modems you can get s/n ratio info for each connection. What are
>> acceptable levels?
>>
>> Thanks,
>> Chris Hanes
>>
--
Aaron Nabil
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Marius Strom <marius@alpha1.net>
Subject: (usr-tc) Pipe 75 + Static IP + NAT
Date: 29 Sep 1999 16:29:48 -0500 (CDT)
I'm trying to hook up a Pipe 75 with a Static IP and NAT enabled to a
HiPerARC chassis.. When I disable the NAT on the Pipe, it connects, when I
enable it, it won't connect.. The pipe has been dialing into a Livingston
PM2e up until now, and when I modify the remote address and the phone
number to have it dial to our TC equipment, it won't do it. I've gone and
disabled things such as STAC and all other compressions.. I did set the
Pipe to MP with BACP=Yes.
Please let me know if you guys have had any success, and if you've got
success, let me know how I can have it too *chuckle*
Thanks in advance!
--
Marius Strom <marius@alpha1.net>
Professional Geek/Unix System Administrator
Alpha1 Internet <http://www.alpha1.net>
http://www.marius.org/marius.pgp 0x5645C228
In theory, there is no difference between theory and practice...
...In practice, there is a big difference.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Chad Scheiter <chad@amouse.net>
Subject: Re: (usr-tc) Pipe 75 + Static IP + NAT
Date: 29 Sep 1999 21:13:05 -0700
Marius Strom wrote:
> I'm trying to hook up a Pipe 75 with a Static IP and NAT enabled to a
> HiPerARC chassis.. When I disable the NAT on the Pipe, it connects, when I
> enable it, it won't connect.. The pipe has been dialing into a Livingston
> PM2e up until now, and when I modify the remote address and the phone
> number to have it dial to our TC equipment, it won't do it. I've gone and
> disabled things such as STAC and all other compressions.. I did set the
> Pipe to MP with BACP=Yes.
>
> Please let me know if you guys have had any success, and if you've got
> success, let me know how I can have it too *chuckle*
Do you have the LAN Adrs, WAN Alias, or IF Adrs defined? I left those blank
and assign the static IP from radius. Otherwise you have to set reported IP
on the TC to correspond with the LAN Adrs. You should be able to just define
the WAN Alias but I couldn't even get that to work between two ascends. What
is mon ppp outputting?
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Lon R. Stockton, Jr." <lon@moonstar.com>
Subject: Re: (usr-tc) Pipe 75 + Static IP + NAT
Date: 29 Sep 1999 18:25:43 -0400 (EDT)
If you're running older versions of the TC software (as I am), BACP won't
work (or at least, I can't make it work). Early on, one of my customers
asked for a recommendation and I told 'em to buy the Ascend PL75 and
then found that out. The choice is to 1) upgrade TC software [I think],
2) turn off BACP on the Ascend and tell it to either use just one channel
or both of 'em with MP.
For reference, I'm running Harc 4.0.30 and Hdsp 1.2.5. I'm going to
upgrade after the upgrade is such that it fixes things and doesn't just
trade my current problems for a new batch of problems. This software
load I'm running only seems to have problems with older Rockwell stuff,
and most of those are fixed by upgrading the client modems' code (or
telling the customer they've been duped into buying a crap modem).
...other than that, everything's stable...no webtv problems, incredibly
infrequent hung-modem problems, or any of the other issues that seem
to be terrorizing others on the list here. Even current 3com Sportsters
are speedy (to include a current thread *grin*).
Telling a new customer that they need to upgrade their modem's software
or maybe consider a decent modem is hard, but easier than explaining
to an existing customer that they can't connect anymore or get a good
speed because I "upgraded". [/rant]
As for ISDN lan stuff, nowadays I recommend the smaller offices to use
the 3com LANmodem or bigger places to use the Cisco 800-series. LANmodem
blazingly easy to set up, and although I'd never claim a Cisco was easy
to set up, after they're configured they run like, umm, a Cisco. Turn
out the lights and shut the closet for a couple years.
Lon
On Wed, 29 Sep 1999, Marius Strom wrote:
> I'm trying to hook up a Pipe 75 with a Static IP and NAT enabled to a
> HiPerARC chassis.. When I disable the NAT on the Pipe, it connects, when I
> enable it, it won't connect.. The pipe has been dialing into a Livingston
> PM2e up until now, and when I modify the remote address and the phone
> number to have it dial to our TC equipment, it won't do it. I've gone and
> disabled things such as STAC and all other compressions.. I did set the
> Pipe to MP with BACP=Yes.
>
> Please let me know if you guys have had any success, and if you've got
> success, let me know how I can have it too *chuckle*
>
> Thanks in advance!
>
> --
> Marius Strom <marius@alpha1.net>
> Professional Geek/Unix System Administrator
> Alpha1 Internet <http://www.alpha1.net>
> http://www.marius.org/marius.pgp 0x5645C228
>
> In theory, there is no difference between theory and practice...
> ...In practice, there is a big difference.
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Interests" <interests@linkfast.net>
Subject: (usr-tc) Disconnecting Connections
Date: 29 Sep 1999 17:59:37 -0500
I am trying to find the command to disconnect a particular
connection on a TC. Anyone know off the top of your heads?
Jason A. Nunnelley
President of Linkfast Inc.
"I always respond to E-mail"
PO BOX 202
Cullman AL 35056
256-739-2008 Voice
770-234-5702 Fax
Billing and Office Hours:
9am - 9pm Monday through Friday
Tech Support Hours:
9am - 9pm Monday through Friday
9am - 5pm Saturday
Support Online:
http://linkfast.net/support.html
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Interests" <interests@linkfast.net>
Subject: Re: (usr-tc) Disconnecting Connections
Date: 29 Sep 1999 18:13:54 -0500
I realized this post was not very specific. When you have
a particular dialup or ISDN connection (as you would view
in a telnet session), say on slot:3/mod:20 for EX. How can
you terminate that particular connection and not impact
any other connected users. I can't find the command. In a
Livingston box, you could type in "reset s20" for example.
Jason A. Nunnelley
President of Linkfast Inc.
"I always respond to E-mail"
PO BOX 202
Cullman AL 35056
256-739-2008 Voice
770-234-5702 Fax
Billing and Office Hours:
9am - 9pm Monday through Friday
Tech Support Hours:
9am - 9pm Monday through Friday
9am - 5pm Saturday
Support Online:
http://linkfast.net/support.html
----- Original Message -----
Sent: Wednesday, September 29, 1999 5:59 PM
> I am trying to find the command to disconnect a particular
> connection on a TC. Anyone know off the top of your heads?
>
> Jason A. Nunnelley
> President of Linkfast Inc.
> "I always respond to E-mail"
>
> PO BOX 202
> Cullman AL 35056
>
> 256-739-2008 Voice
> 770-234-5702 Fax
>
> Billing and Office Hours:
> 9am - 9pm Monday through Friday
>
> Tech Support Hours:
> 9am - 9pm Monday through Friday
> 9am - 5pm Saturday
>
> Support Online:
> http://linkfast.net/support.html
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Marcelo Souza <mpsouza@centroin.com.br>
Subject: Re: (usr-tc) Disconnecting Connections
Date: 29 Sep 1999 20:19:09 -0300 (EST)
You can use:
Harc> haNGUP inTERFACE slot:x/mod:y
or
Harc> discoNNECT usER username
- Marcelo
On Wed, 29 Sep 1999, Interests wrote:
|I realized this post was not very specific. When you have
|a particular dialup or ISDN connection (as you would view
|in a telnet session), say on slot:3/mod:20 for EX. How can
|you terminate that particular connection and not impact
|any other connected users. I can't find the command. In a
|Livingston box, you could type in "reset s20" for example.
|
|Jason A. Nunnelley
|President of Linkfast Inc.
|"I always respond to E-mail"
|
|PO BOX 202
|Cullman AL 35056
|
|256-739-2008 Voice
|770-234-5702 Fax
|
|Billing and Office Hours:
|9am - 9pm Monday through Friday
|
|Tech Support Hours:
|9am - 9pm Monday through Friday
|9am - 5pm Saturday
|
|Support Online:
|http://linkfast.net/support.html
|----- Original Message -----
|From: Interests <interests@linkfast.net>
|To: <usr-tc@lists.xmission.com>
|Sent: Wednesday, September 29, 1999 5:59 PM
|Subject: (usr-tc) Disconnecting Connections
|
|
|> I am trying to find the command to disconnect a particular
|> connection on a TC. Anyone know off the top of your heads?
|>
|> Jason A. Nunnelley
|> President of Linkfast Inc.
|> "I always respond to E-mail"
|>
|> PO BOX 202
|> Cullman AL 35056
|>
|> 256-739-2008 Voice
|> 770-234-5702 Fax
|>
|> Billing and Office Hours:
|> 9am - 9pm Monday through Friday
|>
|> Tech Support Hours:
|> 9am - 9pm Monday through Friday
|> 9am - 5pm Saturday
|>
|> Support Online:
|> http://linkfast.net/support.html
|>
|>
|> -
|> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
|> 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.
|
|
|-
| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
| 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.
|
- Marcelo
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Marius Strom <marius@alpha1.net>
Subject: Re: (usr-tc) Disconnecting Connections
Date: 29 Sep 1999 18:19:39 -0500 (CDT)
hangup interface slot:#/mod:#
--
Marius Strom <marius@alpha1.net>
Professional Geek/Unix System Administrator
Alpha1 Internet <http://www.alpha1.net>
http://www.marius.org/marius.pgp 0x5645C228
In theory, there is no difference between theory and practice...
...In practice, there is a big difference.
On Wed, 29 Sep 1999, Interests wrote:
> I realized this post was not very specific. When you have
> a particular dialup or ISDN connection (as you would view
> in a telnet session), say on slot:3/mod:20 for EX. How can
> you terminate that particular connection and not impact
> any other connected users. I can't find the command. In a
> Livingston box, you could type in "reset s20" for example.
>
> Jason A. Nunnelley
> President of Linkfast Inc.
> "I always respond to E-mail"
>
> PO BOX 202
> Cullman AL 35056
>
> 256-739-2008 Voice
> 770-234-5702 Fax
>
> Billing and Office Hours:
> 9am - 9pm Monday through Friday
>
> Tech Support Hours:
> 9am - 9pm Monday through Friday
> 9am - 5pm Saturday
>
> Support Online:
> http://linkfast.net/support.html
> ----- Original Message -----
> From: Interests <interests@linkfast.net>
> To: <usr-tc@lists.xmission.com>
> Sent: Wednesday, September 29, 1999 5:59 PM
> Subject: (usr-tc) Disconnecting Connections
>
>
> > I am trying to find the command to disconnect a particular
> > connection on a TC. Anyone know off the top of your heads?
> >
> > Jason A. Nunnelley
> > President of Linkfast Inc.
> > "I always respond to E-mail"
> >
> > PO BOX 202
> > Cullman AL 35056
> >
> > 256-739-2008 Voice
> > 770-234-5702 Fax
> >
> > Billing and Office Hours:
> > 9am - 9pm Monday through Friday
> >
> > Tech Support Hours:
> > 9am - 9pm Monday through Friday
> > 9am - 5pm Saturday
> >
> > Support Online:
> > http://linkfast.net/support.html
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Interests" <interests@linkfast.net>
Subject: Re: (usr-tc) Disconnecting Connections
Date: 29 Sep 1999 18:41:57 -0500
does this disconnect the user and re-open the line on both
commands? or does the hangup hang the line until you reset
the line?
Jason A. Nunnelley
President of Linkfast Inc.
"I always respond to E-mail"
PO BOX 202
Cullman AL 35056
256-739-2008 Voice
770-234-5702 Fax
Billing and Office Hours:
9am - 9pm Monday through Friday
Tech Support Hours:
9am - 9pm Monday through Friday
9am - 5pm Saturday
Support Online:
http://linkfast.net/support.html
----- Original Message -----
Sent: Wednesday, September 29, 1999 6:19 PM
>
> You can use:
>
> Harc> haNGUP inTERFACE slot:x/mod:y
>
> or
>
> Harc> discoNNECT usER username
>
> - Marcelo
>
> On Wed, 29 Sep 1999, Interests wrote:
>
> |I realized this post was not very specific. When you have
> |a particular dialup or ISDN connection (as you would view
> |in a telnet session), say on slot:3/mod:20 for EX. How can
> |you terminate that particular connection and not impact
> |any other connected users. I can't find the command. In a
> |Livingston box, you could type in "reset s20" for example.
> |
> |Jason A. Nunnelley
> |President of Linkfast Inc.
> |"I always respond to E-mail"
> |
> |PO BOX 202
> |Cullman AL 35056
> |
> |256-739-2008 Voice
> |770-234-5702 Fax
> |
> |Billing and Office Hours:
> |9am - 9pm Monday through Friday
> |
> |Tech Support Hours:
> |9am - 9pm Monday through Friday
> |9am - 5pm Saturday
> |
> |Support Online:
> |http://linkfast.net/support.html
> |----- Original Message -----
> |From: Interests <interests@linkfast.net>
> |To: <usr-tc@lists.xmission.com>
> |Sent: Wednesday, September 29, 1999 5:59 PM
> |Subject: (usr-tc) Disconnecting Connections
> |
> |
> |> I am trying to find the command to disconnect a particular
> |> connection on a TC. Anyone know off the top of your heads?
> |>
> |> Jason A. Nunnelley
> |> President of Linkfast Inc.
> |> "I always respond to E-mail"
> |>
> |> PO BOX 202
> |> Cullman AL 35056
> |>
> |> 256-739-2008 Voice
> |> 770-234-5702 Fax
> |>
> |> Billing and Office Hours:
> |> 9am - 9pm Monday through Friday
> |>
> |> Tech Support Hours:
> |> 9am - 9pm Monday through Friday
> |> 9am - 5pm Saturday
> |>
> |> Support Online:
> |> http://linkfast.net/support.html
> |>
> |>
> |> -
> |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> |> 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.
> |
> |
> |-
> | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> | 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.
> |
>
> - Marcelo
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Ronald Kushner <ron@glis.net>
Subject: Re: (usr-tc) Disconnecting Connections
Date: 29 Sep 1999 19:43:19 -0400
Interests wrote:
>
> I am trying to find the command to disconnect a particular
> connection on a TC. Anyone know off the top of your heads?
I've found DISCONNECT USER username works fine, or you can use hangup
slot:X/mod:Y where X and Y are replaced with slot and modem.
-Ron
GLISnet, Inc.
+1 810/939.9885
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Scot Desort" <scot@njaccess.net>
Subject: RE: (usr-tc) Disconnecting Connections
Date: 29 Sep 1999 19:50:51 -0400
DISC USER kills the connection (I think it drops DTR) and modem resets for
next call automatically. Problem is that if you want to kill one channel of
a MP call, it will knock off both channels since the username is the same
for both. I never knew about the HANGUP INTERFACE command -- that would
seems to take care of that since you can specifiy the exact channel and
leave the other one alone.
-Scot
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Interests
Sent: Wednesday, September 29, 1999 7:42 PM
does this disconnect the user and re-open the line on both
commands? or does the hangup hang the line until you reset
the line?
Jason A. Nunnelley
President of Linkfast Inc.
"I always respond to E-mail"
PO BOX 202
Cullman AL 35056
256-739-2008 Voice
770-234-5702 Fax
Billing and Office Hours:
9am - 9pm Monday through Friday
Tech Support Hours:
9am - 9pm Monday through Friday
9am - 5pm Saturday
Support Online:
http://linkfast.net/support.html
----- Original Message -----
Sent: Wednesday, September 29, 1999 6:19 PM
>
> You can use:
>
> Harc> haNGUP inTERFACE slot:x/mod:y
>
> or
>
> Harc> discoNNECT usER username
>
> - Marcelo
>
> On Wed, 29 Sep 1999, Interests wrote:
>
> |I realized this post was not very specific. When you have
> |a particular dialup or ISDN connection (as you would view
> |in a telnet session), say on slot:3/mod:20 for EX. How can
> |you terminate that particular connection and not impact
> |any other connected users. I can't find the command. In a
> |Livingston box, you could type in "reset s20" for example.
> |
> |Jason A. Nunnelley
> |President of Linkfast Inc.
> |"I always respond to E-mail"
> |
> |PO BOX 202
> |Cullman AL 35056
> |
> |256-739-2008 Voice
> |770-234-5702 Fax
> |
> |Billing and Office Hours:
> |9am - 9pm Monday through Friday
> |
> |Tech Support Hours:
> |9am - 9pm Monday through Friday
> |9am - 5pm Saturday
> |
> |Support Online:
> |http://linkfast.net/support.html
> |----- Original Message -----
> |From: Interests <interests@linkfast.net>
> |To: <usr-tc@lists.xmission.com>
> |Sent: Wednesday, September 29, 1999 5:59 PM
> |Subject: (usr-tc) Disconnecting Connections
> |
> |
> |> I am trying to find the command to disconnect a particular
> |> connection on a TC. Anyone know off the top of your heads?
> |>
> |> Jason A. Nunnelley
> |> President of Linkfast Inc.
> |> "I always respond to E-mail"
> |>
> |> PO BOX 202
> |> Cullman AL 35056
> |>
> |> 256-739-2008 Voice
> |> 770-234-5702 Fax
> |>
> |> Billing and Office Hours:
> |> 9am - 9pm Monday through Friday
> |>
> |> Tech Support Hours:
> |> 9am - 9pm Monday through Friday
> |> 9am - 5pm Saturday
> |>
> |> Support Online:
> |> http://linkfast.net/support.html
> |>
> |>
> |> -
> |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> |> 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.
> |
> |
> |-
> | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> | 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.
> |
>
> - Marcelo
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: K Mitchell <mitch@keyconn.net>
Subject: Re: (usr-tc) Disconnecting Connections
Date: 29 Sep 1999 20:07:54 -0400
At 06:41 PM 9/29/99 -0500, you wrote:
>does this disconnect the user and re-open the line on both
>commands? or does the hangup hang the line until you reset
>the line?
Either command will reset the line also.
--
Kirk Mitchell-General Manager mitch@keyconn.net
Keystone Connect Unlock Your World
Altoona, PA 814-941-5000 http://www.keyconn.net
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Subject: Re: (usr-tc) Netserver to ARC using MultilinkE
Date: 29 Sep 1999 07:32:24 -0500 (CDT)
Need to know your dial out script on the NETServer - You can program the
dial out number on the modem and foce it to dial immediately or you could
have the number of session set to 2 (max ports) - I am not sure but one
of the above method does negotiate multilink and the other does not -
guess it changes the mpedo.
krish
On Wed, 29 Sep 1999, Carl Litt wrote:
>
> Yes, I did clip out a bit of info... here's the complete output:
>
> Monitoring the next session to start up.
> Decode tracing started, press ESCAPE to stop; press X for hex tracing.
> ....Tracing the current/next session; Escape to stop...
>
> Outgoing PPP Data on interface: slot:10/mod:12
> LCP CFG_REQ MRU 05 ea
> ASYNC_MAP 00 00 00 00
> MAGIC_NUM 9e 5a aa e5
> PROTO_COMP
> AC_COMP
> MPP_MRRU 05 ea
> MPP_ENDPTID 00
>
> Incoming PPP Data on interface: slot:10/mod:12
> LCP CFG_REQ MPP_ENDPTID 04 6f f7 09 08
> ASYNC_MAP 00 00 00 00
> MAGIC_NUM eb c4 d4 f4
>
> Outgoing PPP Data on interface: slot:10/mod:12
> LCP CFG_ACK MPP_ENDPTID 04 6f f7 09 08
> ASYNC_MAP 00 00 00 00
> MAGIC_NUM eb c4 d4 f4
>
>
> Incoming PPP Data on interface: slot:10/mod:12
> LCP CFG_ACK MRU 05 ea
> ASYNC_MAP 00 00 00 00
> MAGIC_NUM 9e 5a aa e5
> PROTO_COMP
> AC_COMP
> MPP_MRRU 05 ea
> MPP_ENDPTID 00
>
> I've also tried durning off PPP offloading for the hell of it, but
> no difference.
>
> Thanks,
> Carl
>
> On Wed, 29 Sep 1999, Jeff Mcadams wrote:
>
> > Thus spake Carl Litt
> > >Is it possible to get a Netserver to connect to a HiPer ARC
> > >with more than one channel (by using multilink)?
> >
> > >We're trying to move a customer over from dialing into another
> > >Netserver (not ours) into an ARC running 4.1.59. The login is set
> > >in RADIUS, and does work for a single channel. We have no
> > >Port-Limits set, and the ARC has the default 2 Max-Chan.
> >
> > >We can get the first channel up, but the second channel connects
> > >then drops. Here is the "mon ppp" output:
> >
> > >Incoming PPP Data on interface: slot:10/mod:23
> > > LCP CFG_ACK MRU 05 ea
> > > ASYNC_MAP ff ff ff ff
> > > MAGIC_NUM 4c 56 1b da
> > > PROTO_COMP
> > > AC_COMP
> > > MPP_MRRU 05 ea
> > > MPP_ENDPTID 00
> >
> > >Incoming PPP Data on interface: slot:10/mod:23
> > > LCP CFG_REQ MPP_ENDPTID 04 6f f7 09 08
> > > ASYNC_MAP ff ff ff ff
> > > MAGIC_NUM 23 ea 32 19
> >
> > >Outgoing PPP Data on interface: slot:10/mod:23
> > > LCP CFG_ACK MPP_ENDPTID 04 6f f7 09 08
> > > ASYNC_MAP ff ff ff ff
> > > MAGIC_NUM 23 ea 32 19
> > >--- [The call is then dropped] ---
> >
> > >From what I can see, there are no NAK's which should cause a
> > >protocol termination. In the RADIUS accounting logs, the session
> > >has a Term-Cause of NAS-Error.
> >
> > Well...you're apparently not catching all of the PPP negotiation...which
> > means we might be missing some useful data, but...
> >
> > You'll notice that the incoming config request does *not* have the MPP_MRRU
> > attribute in it. The MPP_MRRU attribute is the attribute/value that
> > indicates that Multi-Link can/will be used on that link. If one side
> > doesn't negotiation the MPP_MRRU, then Multi-Link can't work on that
> > link.
> > --
> > Jeff McAdams Email: jeffm@iglou.com
> > Head Network Administrator Voice: (502) 966-3848
> > IgLou Internet Services (800) 436-4456
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Scot Desort" <scot@njaccess.net>
Subject: RE: (usr-tc) Disconnecting Connections
Date: 29 Sep 1999 19:50:51 -0400
DISC USER kills the connection (I think it drops DTR) and modem resets for
next call automatically. Problem is that if you want to kill one channel of
a MP call, it will knock off both channels since the username is the same
for both. I never knew about the HANGUP INTERFACE command -- that would
seems to take care of that since you can specifiy the exact channel and
leave the other one alone.
-Scot
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Interests
Sent: Wednesday, September 29, 1999 7:42 PM
does this disconnect the user and re-open the line on both
commands? or does the hangup hang the line until you reset
the line?
Jason A. Nunnelley
President of Linkfast Inc.
"I always respond to E-mail"
PO BOX 202
Cullman AL 35056
256-739-2008 Voice
770-234-5702 Fax
Billing and Office Hours:
9am - 9pm Monday through Friday
Tech Support Hours:
9am - 9pm Monday through Friday
9am - 5pm Saturday
Support Online:
http://linkfast.net/support.html
----- Original Message -----
Sent: Wednesday, September 29, 1999 6:19 PM
>
> You can use:
>
> Harc> haNGUP inTERFACE slot:x/mod:y
>
> or
>
> Harc> discoNNECT usER username
>
> - Marcelo
>
> On Wed, 29 Sep 1999, Interests wrote:
>
> |I realized this post was not very specific. When you have
> |a particular dialup or ISDN connection (as you would view
> |in a telnet session), say on slot:3/mod:20 for EX. How can
> |you terminate that particular connection and not impact
> |any other connected users. I can't find the command. In a
> |Livingston box, you could type in "reset s20" for example.
> |
> |Jason A. Nunnelley
> |President of Linkfast Inc.
> |"I always respond to E-mail"
> |
> |PO BOX 202
> |Cullman AL 35056
> |
> |256-739-2008 Voice
> |770-234-5702 Fax
> |
> |Billing and Office Hours:
> |9am - 9pm Monday through Friday
> |
> |Tech Support Hours:
> |9am - 9pm Monday through Friday
> |9am - 5pm Saturday
> |
> |Support Online:
> |http://linkfast.net/support.html
> |----- Original Message -----
> |From: Interests <interests@linkfast.net>
> |To: <usr-tc@lists.xmission.com>
> |Sent: Wednesday, September 29, 1999 5:59 PM
> |Subject: (usr-tc) Disconnecting Connections
> |
> |
> |> I am trying to find the command to disconnect a particular
> |> connection on a TC. Anyone know off the top of your heads?
> |>
> |> Jason A. Nunnelley
> |> President of Linkfast Inc.
> |> "I always respond to E-mail"
> |>
> |> PO BOX 202
> |> Cullman AL 35056
> |>
> |> 256-739-2008 Voice
> |> 770-234-5702 Fax
> |>
> |> Billing and Office Hours:
> |> 9am - 9pm Monday through Friday
> |>
> |> Tech Support Hours:
> |> 9am - 9pm Monday through Friday
> |> 9am - 5pm Saturday
> |>
> |> Support Online:
> |> http://linkfast.net/support.html
> |>
> |>
> |> -
> |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> |> 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.
> |
> |
> |-
> | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> | 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.
> |
>
> - Marcelo
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Dataheart <lists@dataheart.net>
Subject: (usr-tc) E1 Configuration
Date: 30 Sep 1999 14:07:26 +1000
Hi,
I am new to this list and wondering if anyone would be able to give me a
tutorial on how to configure a dual PRI NAC with dual E1 NIC for
analog(56k) connections in Australia.
I have been running straight analog(33.6k) racks for about 3 years now
but now the telco has installed the PRI Trunks and I am stuffed with the
conversion.
Any help is greatly appreciated.
Thanks,
Aaron
P.S. I am sure that this question would have been asked before so if
anyone could point me in the direction of the archives I would
appreciate that as well.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jerry Wright <jwright@hyperserv.com>
Subject: (usr-tc) Going nowhere fast...
Date: 29 Sep 1999 22:42:28 -0700
We had a USR TC box with 48 modems and 2 T1s. It worked...
Well, we got our third T1 and a used TC box. Now, about a third of our
customers log on, get authenticated, and sit there (ping and traceroute
work, web browsing doesn't). Or else, they get an error 750 or 765 or
other type error. Could our new T1 NIC card be bad? It passes the
various tests? Help!!!
Other info, the T1 performance test tells me 3865 bipolar whatever
errors in the last 24 hours. Bad card??? US West says the line tests
out good.
Jerry Wright
Internet Access of Moses Lake
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Startup Suppliers Ltd." <startnet@arcc.or.ke>
Subject: (usr-tc) Modems
Date: 30 Sep 1999 10:31:44 +0300 (EAT)
Hi All!
I need modems in racks for use with PM2E 30 portmasters. I need 100 units
33.6 in racks or something similar. Please respond with best prices.
Okeyo
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Startup Suppliers Ltd." <startnet@arcc.or.ke>
Subject: (usr-tc) Modems
Date: 30 Sep 1999 12:03:45 +0300 (EAT)
Hi All!
Can someone advise me how Netserver 16 I works. Do I need a portmaster to go
with it? Is it an obsolete technology? What are it's problems and disadvantages?
Okeyo.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Brian Hitchcock" <brianh@kcweb.net>
Subject: Re: (usr-tc) Going nowhere fast...
Date: 30 Sep 1999 07:10:06 -0500
Are they getting the right DNS server information?
Brian Hitchcock
----- Original Message -----
Sent: Thursday, September 30, 1999 12:42 AM
> We had a USR TC box with 48 modems and 2 T1s. It worked...
> Well, we got our third T1 and a used TC box. Now, about a third of our
> customers log on, get authenticated, and sit there (ping and traceroute
> work, web browsing doesn't). Or else, they get an error 750 or 765 or
> other type error. Could our new T1 NIC card be bad? It passes the
> various tests? Help!!!
> Other info, the T1 performance test tells me 3865 bipolar whatever
> errors in the last 24 hours. Bad card??? US West says the line tests
> out good.
>
> Jerry Wright
> Internet Access of Moses Lake
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Subject: Re: (usr-tc) Going nowhere fast...
Date: 29 Sep 1999 19:12:53 -0500 (CDT)
On Wed, 29 Sep 1999, Jerry Wright wrote:
> We had a USR TC box with 48 modems and 2 T1s. It worked...
> Well, we got our third T1 and a used TC box. Now, about a third of our
> customers log on, get authenticated, and sit there (ping and traceroute
> work, web browsing doesn't). Or else, they get an error 750 or 765 or
> other type error. Could our new T1 NIC card be bad? It passes the
> various tests? Help!!!
When you say you got a third box - I understand that you got a USR
Chassis, with a T1 card, modems, nmc and a router card (either Hiper arc
or NETSERVER). From what you say is that the users dial in and they get
authenticated but cannot browse etc, then the problem is on the router
card or on your network.
May be you are running out of IP address, or maybe the ip address are
overlapping, or you have a problem with arp cache -
So in short looks like our t1 card is fine and you need to take a look at
the routing part of the connection.
> Other info, the T1 performance test tells me 3865 bipolar whatever
> errors in the last 24 hours. Bad card??? US West says the line tests
> out good.
>
If you have line problems the calls will drop/ not connect etc.
You need to take a look at your hiper/netserver and see what is happeing
from that end.
krish
> Jerry Wright
> Internet Access of Moses Lake
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jeff Mcadams <jeffm@iglou.com>
Subject: Re: (usr-tc) Going nowhere fast...
Date: 30 Sep 1999 09:17:24 -0400
Thus spake Tatai SV Krishnan
>On Wed, 29 Sep 1999, Jerry Wright wrote:
>> Other info, the T1 performance test tells me 3865 bipolar whatever
>> errors in the last 24 hours. Bad card??? US West says the line tests
>> out good.
>If you have line problems the calls will drop/ not connect etc.
>You need to take a look at your hiper/netserver and see what is happeing
>from that end.
To expand a bit...if you're getting bipolar variation errors, that is
cause for concern, but from your description of your problem, this isn't
related. Put the BPV errors on the back burner for now...get your
routing problem solved, and come back to the BPV's...it is definitely
something you need to look at eventually. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Dataheart <lists@dataheart.net>
Subject: (usr-tc) RADIUS Authentication & Accounting
Date: 30 Sep 1999 23:54:36 +1000
Howdy,
I am looking for a good RADIUS server for use with both HiPer and Analog
Total Control Chassis under linux. I need to have the users file as a
table in a PostgreSQL server that contains all the radius attributes
that would normally be specified in the users file(this feature is
necessary to interact with our accounting system). all users need to be
able to be authenticated off the system password e.g. /etc/passwd, and
there needs to be an accurate accessible list of the currently logged in
users.
Similar to the Total Control Security & Accounting Server from 3Com
which I am fairly familiar with, but on a Linux platform.
I have had a look at Cistron Radius and its PAM, but from the docs it
seems to be not quite what I am after.
is there something out there or am I living in a dream world.
Oh yeah and would like realm support but it is not absolutely essential.
Thanks heaps people,
Aaron
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Dataheart <lists@dataheart.net>
Subject: (usr-tc) Netserver problem
Date: 01 Oct 1999 01:49:25 +1000
Well I'm just full of problems arent I :-D
I have a Netserver card that once powered up the rn/fl led flashes green on
and off 13 times, then flashes quickly for a few seconds, then goes solid green
for a while, then repeast the process.
Anyone know whats going on?
Thanks,
Aaron
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Scott Trautman <scottt@corp.gdinet.com>
Subject: RE: (usr-tc) Netserver problem
Date: 30 Sep 1999 10:56:45 -0500
Anything on the console port? Bootup messages? (actually don't think you
would see those if I recall correctly, just a login prompt when it is up...)
Get out the pcsdl, source and re-upload it via serial cable. Hint: set your
serial port to at least 57600 w/dip switches.
Sounds like your flash got corrupted.
Or send it back to 3Com and they'll do probably the same thing.
SMT
> -----Original Message-----
> From: Dataheart [mailto:lists@dataheart.net]
> Sent: Thursday, September 30, 1999 10:49 AM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) Netserver problem
>
>
> Well I'm just full of problems arent I :-D
>
> I have a Netserver card that once powered up the rn/fl led
> flashes green on
> and off 13 times, then flashes quickly for a few seconds,
> then goes solid green
> for a while, then repeast the process.
> Anyone know whats going on?
>
> Thanks,
> Aaron
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Marty Elliott <marty@2assetrecovery.com>
Subject: Re: (usr-tc) Netserver problem
Date: 30 Sep 1999 08:57:46 -0700
Corrupt flash -- reflash it via the serial port Aaron -- same problem we've
got with all of our stock cards (drat).
Marty
At 01:49 AM 10/01/1999 +1000, you wrote:
>Well I'm just full of problems arent I :-D
>
>I have a Netserver card that once powered up the rn/fl led flashes green on
>and off 13 times, then flashes quickly for a few seconds, then goes solid
green
>for a while, then repeast the process.
>Anyone know whats going on?
>
>Thanks,
>Aaron
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Steve Rivera <sales@wrca.net>
Subject: (usr-tc) Quad Digital Modems
Date: 30 Sep 1999 15:23:40 -0400
Are the quad digital modems able to handle analog application,
as long as nic cards are installed on the chassis.
I have customer who is setting up a ISP across seas. He is currently
only able to get POT connections, but that is only for now.
If he buys the quad digital cards will he ba able to suuport the
analog connections now and the digital later.
....................................................
Steve Rivera - VP-WR Consultant Associates, Inc. (WRCA)
sales@wrca.net v-732-833-2111 pgr-732-325-1092
WAN ACCESS SPECIALIST---http://www.wrca.net (CompleteLine Card)
Cisco, Ascend,USR,Adtran, Kentrox,Livingston, Microcom,Computone,Verilink
IBM,Motorola,UDS,Codex,ATT/Paradyne,Hayes,Racal Datacom,GDC,Telebit
MultiTech,Sync/Tylink,Wellfleet,BayNetworks(5399),Black Box,Micom & More
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Blake Fithen <fithen@NetworksPlus.com>
Subject: RE: (usr-tc) Netserver problem
Date: 30 Sep 1999 19:57:04 -0500
Had the same problem once. Try reflashing it using
PCSDL.EXE.
blake
> -----Original Message-----
> From: Dataheart [mailto:lists@dataheart.net]
> Sent: Thursday, September 30, 1999 10:49 AM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) Netserver problem
>
>
> Well I'm just full of problems arent I :-D
>
> I have a Netserver card that once powered up the rn/fl led
> flashes green on
> and off 13 times, then flashes quickly for a few seconds,
> then goes solid green
> for a while, then repeast the process.
> Anyone know whats going on?
>
> Thanks,
> Aaron
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jerry Wright <jwright@hyperserv.com>
Subject: Re: (usr-tc) Quad Digital Modems
Date: 30 Sep 1999 18:00:55 -0700
As far as I know, you need the quad Analog/Digital modems to do that.
They should be as easy to come by, used, as the straight Digital ones.
--Jerry
Steve Rivera wrote:
>
> Are the quad digital modems able to handle analog application,
> as long as nic cards are installed on the chassis.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jerry Wright <jwright@hyperserv.com>
Subject: Re: (usr-tc) Going nowhere fast...
Date: 30 Sep 1999 18:07:58 -0700
Yes, it MUST be a routing problem. I have a Netserver card and NMC,
with a pool of x.x.x.10 thru x.x.x.65 for the first box. In the second
box I have the NMC set to x.x.x.66, the Netserver set to x.x.x.67 and
the pool set to x.x.x.68 thru x.x.x.128.
The I.P. Gateway is set to x.x.x.1 Here...
Command> sho global
System Name: tcbox2
IP Gateway: 207.178.26.1 Gateway Metric: 1
IPX Gateway: 00000000:000000000000 Gateway Metric: 0
Default Route: Broadcast, Listen (On)
Domain: iaml.net Name Service: DNS
Name Servers: 207.178.26.2 0.0.0.0 0.0.0.0
Sys Loghosts: 207.178.26.150 0.0.0.0
RADIUS Server: 207.178.26.3 Port: 1645 Version:
1
Alt. RADIUS Server: 0.0.0.0 Port: 1645 Version:
1
Accounting Server: 207.178.26.3 Port: 1646 Version:
1
Alt. Acct. Server: 0.0.0.0 Port: 1646 Version:
1
NTP Time Server: 0.0.0.0 Alt. Time Server: 0.0.0.0
MPIP Server: 0.0.0.0 Port: 5912
MPIP Server: 0.0.0.0 Port: 5912
MPIP Server: 0.0.0.0 Port: 5912
MPIP Server: 0.0.0.0 Port: 5912
PPTP IP Address: 0.0.0.0
Telnet Access Port: 23 TCP Maximal Segment Size: 0
Assigned Address: 207.178.26.68 Reported Address: 207.178.26.67
Assigned Pool Size: 61 Periodic CHAP timeout: 5
-- Press Return for More --
PPP in modem: ON SLIP in modem: OFF Packet bus clock:
MASTER
ICMP error logging: OFF Connect message: OFF Dial !root access:
ON
Random hosts list: OFF SNMP: ON Proxy Arp:
ON
Response message: OFF PPP message: ON Lan/Wan Routing:
ON
RIP V2 Authen: OFF VPN Local Routing: OFF MPIP Server:
OFF
Hint assigned: OFF Tap Login: OFF Syslog facility:
auth
Extd. IPXCP Opts: OFF Acct AuthChk: OFF/OFF Send DNS info:
ON
DNS cache reset timeout: 0 days 0 hours 30 minutes (30 min)
Configured Ethernet media: Autodetect
Command>
That's what it says....
--Help!!!!
--Jerry
Jeff Mcadams wrote:
>
> Thus spake Tatai SV Krishnan
> >On Wed, 29 Sep 1999, Jerry Wright wrote:
> >> Other info, the T1 performance test tells me 3865 bipolar whatever
> >> errors in the last 24 hours. Bad card??? US West says the line tests
> >> out good.
>
> >If you have line problems the calls will drop/ not connect etc.
> >You need to take a look at your hiper/netserver and see what is happeing
> >from that end.
>
> To expand a bit...if you're getting bipolar variation errors, that is
> cause for concern, but from your description of your problem, this isn't
> related. Put the BPV errors on the back burner for now...get your
> routing problem solved, and come back to the BPV's...it is definitely
> something you need to look at eventually. :)
> --
> Jeff McAdams Email: jeffm@iglou.com
> Head Network Administrator Voice: (502) 966-3848
> IgLou Internet Services (800) 436-4456
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: Jerry Wright <jwright@hyperserv.com>
Subject: Re: (usr-tc) Going nowhere fast...
Date: 30 Sep 1999 18:25:32 -0700
Yes they are... In fact, last night I got logged into the new box, and I
could ping and tracert out of windows, but couldn't go anywhere. It could be
what IP address I was assigned, maybe...
--Jerry
Brian Hitchcock wrote:
> Are they getting the right DNS server information?
>
> Brian Hitchcock
> ----- Original Message -----
> From: Jerry Wright <jwright@hyperserv.com>
> To: <usr-tc@lists.xmission.com>
> Sent: Thursday, September 30, 1999 12:42 AM
> Subject: (usr-tc) Going nowhere fast...
>
> > We had a USR TC box with 48 modems and 2 T1s. It worked...
> > Well, we got our third T1 and a used TC box. Now, about a third of our
> > customers log on, get authenticated, and sit there (ping and traceroute
> > work, web browsing doesn't). Or else, they get an error 750 or 765 or
> > other type error. Could our new T1 NIC card be bad? It passes the
> > various tests? Help!!!
> > Other info, the T1 performance test tells me 3865 bipolar whatever
> > errors in the last 24 hours. Bad card??? US West says the line tests
> > out good.
> >
> > Jerry Wright
> > Internet Access of Moses Lake
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > 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.
> >
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: eric@dol.net
Subject: Re: (usr-tc) Going nowhere fast...
Date: 30 Sep 1999 20:07:59 -0600
>When you say you got a third box - I understand that you got a USR
>Chassis, with a T1 card, modems, nmc and a router card (either Hiper arc
>or NETSERVER). From what you say is that the users dial in and they get
>authenticated but cannot browse etc, then the problem is on the router
>card or on your network.
>
>May be you are running out of IP address, or maybe the ip address are
>overlapping, or you have a problem with arp cache -
>So in short looks like our t1 card is fine and you need to take a look at
>the routing part of the connection.
>
I just had the same problem and my ip addresses were over lapping.
Check to make sure you did not assign the ips anywhere else in your network.
You may have a static route to a customer that you forgot about and the
pools is falling into that area. You may have used some of the ips on a
web server somewhwere. Start digging in this direction.
eric
>Delaware Online!.........The SMART Choice!
With 56K V.90 & X2 & Flex Modems
Phone : 302-762-0375
Fax: 302-762-3462
Failure is NOT an option...
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "albert" <emmanuel@mwt.net>
Subject: (usr-tc) using mp/16 at a POP...
Date: 30 Sep 1999 21:36:04 -0700
I have a client that is setting a POP and wants to use a MP/16..
HE has a leased line from point A to point B, the mp/16 is at point B.
Can the calls be sent to point A without using a portmaster.??
al.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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: "Robb Bryn" <rbryn@cape-fear.net>
Subject: (usr-tc) TCHub and routing
Date: 01 Oct 1999 00:24:31 -0400
This is a multi-part message in MIME format.
------=_NextPart_000_000A_01BF0BA2.6EE25F40
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
I'm configuring my first routed subnet on the TCHub and can't quite figure
out what I'm doing wrong.
I have a Ascend P50 dialing in via ISDN with radius attributes of:
Framed-Address = 208.150.95.241
Framed-Route = 208.150.95.240/29 208.150.95.241 1
After connecting, I can ping the ether address of the TCHub (208.133.28.51)
from any of the subnet hosts can't ping anything past it. I can't ping any
host on the subnet from the TCHub. Below is the output from the show ip
network command.
HiPer>> show ip network test-ip-I4586
SHOW IP NETWORK test-ip-I4586 SETTINGS:
Interface: slot:14/mod:2
Network Address: 208.150.95.241/H
Frame Type: PPP
Status: ENABLED
Reconfigure Needed: FALSE
Mask: 255.255.255.255
Station: 0.0.0.0
Broadcast Algorithm: IETF
Max Reassembly Size: 3464
IP Routing Protocol: NONE
IP Routing Metric: 1
RIP Interface Export Metric: 0
IP RIP Routing Policies:
IP RIP Authentication Key:
HiPer>>
I'm pulling my hair out trying to figure out what I've done wrong. A kick
in the right direction would be greatly appreciated.
Thanks,
Robb Bryn
------=_NextPart_000_000A_01BF0BA2.6EE25F40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D010154603-01101999>I'm =
configuring my=20
first routed subnet on the TCHub and can't quite figure out what I'm =
doing=20
wrong. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D010154603-01101999></SPAN></FONT><FONT=20
face=3DArial size=3D2><SPAN =
class=3D010154603-01101999></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D010154603-01101999>I have =
a Ascend P50=20
dialing in via ISDN with radius attributes of:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D010154603-01101999> =20
Framed-Address =3D 208.150.95.241</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D010154603-01101999> =20
Framed-Route =3D 208.150.95.240/29 208.150.95.241 1</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D010154603-01101999></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2><SPAN=20
class=3D010154603-01101999>After connecting, I can ping the ether =
address of the=20
TCHub (208.133.28.51) from any of the subnet hosts can't ping anything =
past=20
it. I can't ping any host on the subnet from the =
TCHub. Below=20
is the output from the show ip network =
command.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D010154603-01101999></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D010154603-01101999></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D010154603-01101999>HiPer>> show=20
ip network test-ip-I4586</SPAN></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D010154603-01101999>SHOW =
IP =20
NETWORK test-ip-I4586=20
SETTINGS:<BR>Interface: &n=
bsp; &nb=
sp; =20
slot:14/mod:2<BR>Network=20
Address:  =
; =
=20
208.150.95.241/H<BR>Frame=20
Type: &n=
bsp; &nb=
sp; =20
PPP<BR>Status:  =
; =
&=
nbsp;=20
ENABLED<BR>Reconfigure=20
Needed: =
=
FALSE<BR>Mask:  =
; =
&=
nbsp; =20
255.255.255.255<BR>Station: &nbs=
p;  =
; =
=20
0.0.0.0<BR>Broadcast=20
Algorithm: &nb=
sp; =20
IETF<BR>Max Reassembly=20
Size: &n=
bsp; =20
3464<BR>IP Routing=20
Protocol: &nbs=
p; =20
NONE<BR>IP Routing=20
Metric: =
&=
nbsp;=20
1<BR>RIP Interface Export=20
Metric: =
=20
0<BR>IP RIP Routing Policies:<BR>IP RIP Authentication=20
Key:<BR>HiPer>></SPAN></FONT></DIV>
<DIV><SPAN class=3D010154603-01101999>
<P><FONT face=3DArial size=3D2><SPAN=20
class=3D010154603-01101999></SPAN></FONT> </P>
<P><FONT face=3DArial size=3D2><SPAN =
class=3D010154603-01101999>I'</SPAN></FONT><FONT=20
face=3DArial size=3D2><SPAN class=3D010154603-01101999>m pulling my hair =
out trying to=20
figure out what I've done wrong. A kick in the right direction =
would be=20
greatly appreciated.</SPAN></FONT></P>
<P><FONT face=3DArial size=3D2><SPAN=20
class=3D010154603-01101999></SPAN></FONT> </P>
<P><FONT face=3DArial size=3D2><SPAN=20
class=3D010154603-01101999>Thanks,</SPAN></FONT></P>
<P><FONT face=3DArial size=3D2><SPAN class=3D010154603-01101999>Robb=20
Bryn</SPAN></FONT></P></SPAN></DIV></BODY></HTML>
------=_NextPart_000_000A_01BF0BA2.6EE25F40--
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
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.